t 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 to expand and collapse resources as required. It also provides for a cost-effective Disaster Recovery (DR) solution. To provide a DR site in an on-premises solution requires hardware to be dedicated to the task and thus potentially under-utilised during normal operations or over-subscribed during disaster situations. A solution that utilises Public Cloud in its disaster design can make use of the usual premise in public cloud that VMs are charged for only when used, apart from a minimal cost associated with the space they take up and even then cost will be tiered according to performance. During normal operations, these clones can sit on low cost storage and then be promoted as required.
Hybrid cloud solutions
A good example of a Hybrid Cloud solution is VMware Cloud on AWS or Cloud Simple. It offers the same functionality as a VMware Private Cloud solution and thus allows a company to move workloads to VMware Cloud on AWS with little or no effort. However, VMware Cloud on AWS shouldn’t be used as a dumping ground for all workloads, it is still a public cloud-based product and as such will not suit all workloads permanently. Companies should be circumspect in their placement of servers and carry out due diligence as to their suitability for use in public cloud first. It does, however, offer a perfect DR solution for all workloads as they can be failed-over or restored to VMware Cloud on AWS as it mirrors the platform they currently work on – assuming it is vSphere.
Until the advent of NSX-T, VMware Cloud on AWS and IBM Cloud for VMware were the only platforms that offered the ability to extend VMware’s SDN solution – and thus the security policies around it – to the public cloud as these platforms were the only ones compatible with NSX-V.
NSX-T has changed that in that it is designed to work with not only any public cloud, but container platforms and thus the ‘on-premises’ infrastructure security can now be extended to follow the application where ever it is resourced from. This means that if you are currently ut