The EGI Cloud Compute service is part of the EGI service catalogue as a federation of Infrastructure as Service (IaaS) cloud providers, where each IaaS is operated by different institutes according to agreed principles & regulations. These principles and regulations require providers’ IaaS clouds to connect with central EGI services (e.g. accounting), and expose their cloud to users through commonly agreed interfaces.
This model has proven to be successful to support several user communities, but after years of production we have found some limitations:
- Reaching a uniform behaviour and interfaces at multiple, independently operated IaaS providers is not realistic in practice. Achieving fully distributed, multi-cloud workloads requires higher-level tools or a lot of customisation and site-specific considerations in the user code.
- Joining the EGI Cloud infrastructure comes with an extra complexity in the operation of IaaS providers. This often causes a decrease in service reliability.
- Only a small fraction of the scientific workloads need access to multiple cloud sites. Most workloads fit into a single cloud and non-federated clouds can be more reliable, so users don’t want to migrate workloads across sites.
Given these findings, we propose three alternative implementations to be considered for inclusion in the EGI Cloud Compute service:
Application Services
This implementation enables ‘Software as a Service’ (SaaS) providers to join the service, this can be done via the EGI Check-in and Marketplace: the SaaS application offerings should be integrated with Check-In to enable Single Sign-On and consistent authorisation across the applications, then registered in the EGI Marketplace for visibility.
IaaS alliance
This model would allow IaaS providers to expose their services in the Marketplace if they meet a simple set of requirements. The minimum requirement is to integrate with EGI Check-In and to register in the EGI Marketplace. Integration with additional, centrally provided EGI operational services & adoption of operational practices would be not mandatory.
Application Platforms
This implementation would allow application and IaaS service providers to join if they support one of the recognised ‘application deployment platforms’, such as Kubernetes for container-based applications or IM for VM-based applications. These technologies enable applications from providers to be shipped and instantiated for/by users at the IaaS sites. This type of model can nicely support cloud-bursting of applications from national clouds to the federation by using higher-level deployment platforms that hide the complexity of a hybrid cloud setup.
These new implementations will introduce a wider range of options, with advanced functionality that can attract new users. The Application Services and Application Platforms implementations allow users to focus on research instead of managing low level infrastructure components, while power users can still benefit from the IaaS Alliance to get the full capabilities of an IaaS.
Read more about this proposal and bring your comments in the dedicated document (preferably by 30 November).
[mc4wp_form id=”48866″]