The EGI Platform Architecture

Gergely Sipos discusses how technology support will work from May 2013, after the end of the European Middleware Initiative and the Initiative for Globus in Europe

In April 2013, with the end of the EMI and IGE projects, the EGI community lost its two largest technology providers and contri- butors to the Unified Middleware Distribution.

This is a milestone for EGI and grid computing in Europe: for the first time since 2001, we will have no dedicated project for grid middleware development. But just because EMI and IGE are over, development is not finished. Most of the teams involved in EMI and in IGE are still active, fixing bugs for the communities who depend on their products. Some teams even implement new functiona- lities in their software, but the coordination and integration provided by EMI and IGE are gone. For EGI, the answer is the EGI Platform Architecture – a new software integration and provisioning process.

A platform-based EGI

EGI started developing its platform architecture in early 2012 and refined it over the last 14 months. The platform-based EGI is capable of supporting a broad customer base with a very diverse set of requirements, and with a much smaller central coordination effort.
The platform-based EGI consists of:

  1. EGI Core Infrastructure Platform, to operate and manage a distributed infrastructure (e.g. accounting);
  2. EGI Cloud Infrastructure Platform, to operate a federated cloud based infrastructure;
  3. EGI Collaboration Platform, for information exchange and community coordination (e.g. AppDB), and
  4. Community Platforms, service portfolios customised for scientific communities.

The Platform Architecture allows any type and any number of community platform to co-exist on the physical infrastructure. Some can provide a grid functio- nality – similar to EMI’s and IGE’s services. Others can include completely unique services that run, for example, in Virtual Machines.

A flexible system

EMI’s and IGE’s distributions included a large number of services that very few commu- ities required in bulk. In practice, most user groups require a relatively simple, but variable set (e.g. a service for job execution and a file storage service, plus some services for security and access control). The flexibility of the new system allows the ‘long tail of scientists’ to be better represented in the platform-based EGI.

More choice for developers will support the develop- ment of community platforms integrated and operated by scientific communities in collaboration with the NGIs.

will facilitate the interaction of software developers, scientific communities and platform integrators within EGI. Software developers will be able to choose from three levels of involvement in this process.

  • Integrated providers’ have the strongest ties with EGI and scientific communities, via MoUs and SLAs, and support is provided by the EGI Helpdesk. They are represented in the Technical Coordination Board and can influence EGI’s evolution.
  • Community providers’ simply make their software available via AppDB, now extended to incorporate a Community Software Repository.
  • Contributing providers’ are in between – they will offer guarantees on the quality of their software and user support, but not as regimented as for integrated providers.

EGI will move to the platform- based model gradually. The focus will now be on establishing new links between software developers, software integrators and operators across the community.

The conceptual change is big but what scientists will notice is the added freedom and options offered by the EGI Platform Architecture. 

Inspired // Issue #11 April 2013

Posted in EGI News, Uncategorized.