Multi-Cloud Computing

The IT landscape is continually changing and in the application development environment the changes have been fundamental. Agile methodologies and DevOps have already had a huge impact but there is another evolution/revolution underway in the cloud computing domain, that of building applications from many internal and external services.

For example, if you have ever tried to build a buggy for yourself or your children you know that the key task is getting all the components together. You can’t start to build until you have all the parts. Cloud computing has seen a supply of ready-made resources, infrastructure, platform, or software as a service but now it is at the buggy building phase, developing applications from many components. Welcome to multi-cloud computing.

Multi-cloud computing can be defined in several ways: using the same application on more than one cloud service provider (CSP), using different applications mashed up into a new application, or developing applications from components that are supplied from different CSPs. Multi-cloud computing is the evolution of cloud computing that is being included in a general move towards component based developments. In this agile world components can be cloud services, containers, micro services, etc. In this article all of these and other components will be referred to under the generic heading of services.

More and more services are being made available, ranging from government hosted demographic and health data to privately owned insurance quotation micro services. These can be placed in a workflow and enriched with code to create new applications quickly. The ultimate agile application, enterprise grade drag and drop development and deployment is coming closer. There are a number of issues relating to this, including security, interoperability, and standards. Some of these issues, like standardization may take time to resolve, however a critical step in creating a new application from services is to select the right service.

Service Selection

The first stage in developing a business supporting IT solution is to understand the needs of that solution. It doesn’t matter if the development team uses formal requirement engineering or agile user stories, they need to match business needs with the services on offer. Services like email and storage software-as-a-service (SaaS) applications fulfill some business needs and because of their size, scope, and ubiquity, selection has posed no problems. The accelerating proliferation of private and public services makes the selection of smaller “app style” services difficult.

There are still no standards for describing services, despite many current and past attempts. However, there is still a need for support in making decisions about the services that are to be composed into an application.

There have been several research projects looking into this area, sponsored by the European Commission’s framework programs.¹ The MODAClouds project² researched and developed a model based integrated development environment that had a decision support system to help in multi-cloud service selection. Services were selected by functional requirements but also on non-functional requirements such as cost and risk. This work has been adopted and expanded by the MUSA project whose focus is multi-cloud service selection by risk and security metrics.

The MODAClouds project has completed its work and there are open source prototypes for the research product. The MUSA Project³ is under way and expects to have working prototypes when it is complete. The decision support tool in MUSA should enable developers to select services according to their security characteristics contained metrics defined for the service. Once the security metrics have been validated the risks and mitigation measures for each of the services are evaluated and after an iterative selection process the selected services are moved on to the deployment stage. Looking at the scale of some internal environments, where there may be as many as 1,000 services for selection, this problem of service selection will only get worse without supporting tools.

Does Service Selection Really Work and Why Should You Participate?

Service selection is only of importance to those who already do not have a CSP of choice. As is often the case, small developers who work on a project-by-project basis will have a very small number of CSPs which they use. They charge premiums for moving away from their streamlined approach to cloud service deployment. Service managers require greater awareness of what SLA they are passing on to their customer when procuring cloud services. The larger players do not provide this information and therefore there is little confidence in what is being procured, and there is often nothing to hold a provider to account. There is no mechanism for transparent and informed procurement, which leads to misinformed choices by consumers.

Service selection’s main barrier to becoming mainstream, however, is that many providers are unwilling to provide data for benchmarking and comparative purposes. Indeed, many of the providers place legal obstacles to independent measuring of services they provide. This makes it difficult for consumers to understand the differences, especially between the smaller CSPs where the differences in reliability and performance across their cloud services are less easy to quantify.

Conclusion

It is clear that service proliferation can cause delays and errors in composing applications. Just imagine going to a scrap yard looking for wheels for the aforementioned buggy and finding 1,000 wheels of different sizes and shapes all in a heap with no guidance to help you. Without service selection tools this is what your development task will be like. The lack of reliable data from many CSPs exacerbates the problem. Not only are the buggy wheels in a heap, you are not allowed to pick them up and examine them. Cloud service providers have the power to change this, freeing up the legal restrictions and encouraging standard service description languages and structures. It is to be hoped that customers join in and demand free and honest descriptions of services for selection purposes.

In the security domain some of this comparison data has already been aggregated, with CSP agreement by the Cloud Security Alliance (CSA).⁴ The MUSA project is working closely with CSA to develop this further. There are other alternatives ranging from crowd sourced reviews similar to travel review sites or the use of ephemeral public data. This data, copied from public sites, is used and discarded after each comparison. This would have to be legally sustainable as all the other data acquisition approaches.

Service description and selection based on business requirements with security and risk factors being included is the only way that a services-based development environment can grow and respond to the fast changing demands of your customers. Make sure your wheels are labelled, easy to find, and will fit a standard axle and the customer buggy will be rolling down the hill before you know it.