primarily to do with template sizes available and data transfer costs – a company will have to go through a transformation process to move services to a public cloud provider in the first place. To then transform them again to move to a different one would be a cost that would outweigh the savings of the new provider.
Public cloud offerings also have a problem when it comes to matching private cloud security. Within your own environment you can control access easily with the use of firewalls. Traditional networks utilise a perimeter model and assumes all users and traffic inside is safe. Public clouds are outside that perimeter so how do you secure them? There are two options, the first is to add a huge workload to the IT department and require them to maintain two separate environments, that will most likely be very disparate in functions and ability. The second is to take advantage of the emerging technology of Software Defined Networking (SDN) which allows security profiles to follow the application, but this again falls foul of the issue of compatibility with the platform of the public cloud provider.
The principle of capitalism is supply and demand, the ability to have choice over the best value for money and clearly, if you will be locked in to a specific cloud vendor by transforming your applications to work with one over another then we are back to the pre-virtualisation days where you were tied into a specific hardware vendor so how do we abstract the application from the virtualisation layer?
As with all issues of compatibility, the answer is a common language. The virtualisation layer abstracts from the hardware layer, now we need to abstract from the virtualisation/OS layer and this is done by container technology, which provides a common language for applications to be developed on. The container platform, like a hypervisor, is deployed on any hardware or any platform and means that we now have additional ‘Cloud as a Services’ to add to the list. Containers as a Service (CaaS), which is the equivalent to IaaS, just supplying a container infrastructure. The other new service is Function as a Service (FaaS), which is one step further than PaaS in that the applications are provided, and the client’s only responsibility is maintenance of the code they deploy.
Containers therefore, seem to be the answer to a multi-cloud deployment. Companies only need to transform their applications once to work on a single platform that works on all cloud providers. Bingo! Silver bullet, all problems resolved. Ahhh, but there is a problem with this and that is that not all applications suit a microservices design. It can also take considerable effort to transform applications to microservices. Development cost and time may far exceed the costs of utilising existing SaaS solutions and definitely outweighs cost differences in public cloud providers. The answer may therefore be to develop new applications around microservices rather than transform existing applications and find ways to migrate what is suitable to the public cloud.
This brings us to Hybrid-Cloud. This may sound like a step back as it in theory it came first, but what is different about a Hybrid-Cloud design and when is it Hybrid and not Multi?
If a company, for example, has private infrastructure, but a presence in AWS E2 as well as using Azure O365 are they multi-cloud? Well this is more of a Hybrid Cloud since the data can only exist in the one instance. It is not possible to suddenly change from using O365 to using Gmail without going through a lengthy migration process. And servers running in AWS can’t be downloaded and then uploaded to Azure, their data and applications have to be migrated separately. This can be achieved with backup and restore processes, but this is not instantaneous and is certainly not flexible.
A Hybrid Cloud does not cater for every cloud platform. The design is to allow for a specific function or use of an IaaS or a PaaS, or even a SaaS, that matches the private cloud configuration. It allows for a best of breed utilisation, the ability 