large database? This is the next level up and is known as Platform-as-a-Service. All the client now has to worry about is the application they want to install, and the catalogue now offers not only VM sizes, but database connections and .NET or J2EE versions. All the patching and security of the OS layer is now the responsibility of the provider, who is probably offering their services from a different IaaS provider.
Finally, we have SaaS (Software-as-a-Service). All the customer needs to worry about here is the data. Examples of this are Office 365, Google G Suite and Salesforce CRM. The customer has no control over versions, but equally has no concerns over patching and security. They just pay for the application to be provided. Packages will normally include backup or resilient storage capability, but with this comes the concern as to where data is being stored as providers will be utilising the cheapest IaaS or hosting they can use.
When does a calf become a bull?
The question left now is when does On-Premises, Co-Lo or Hosted stop being ‘private infrastructure’ and become ‘private cloud’? VMware’s answer is when you add functionality such as automation and operations management – VMware vROps (vRealize Operations) and vRA (VMware vRealize Automation) or CMP (Cloud Management Platform) as it was termed. The problem here is that public cloud providers have billing capabilities and tenancy management so is it truly ‘Cloud’ or still just private infrastructure?
Anyway, this is the ‘Cloud’. It has many flavours, not only in the levels of service and responsibility, but in the underlying platform and this can be a problem for the IaaS and PaaS layer. An obvious example of the differences is between AWS and Azure clouds. Azure is based on the Microsoft (MS) operating platform and AWS is based on Linux. To swap between the two is not an easy task and since there are inherent differences in the way you configure VMs for use in a public cloud environment to your own more flexible environment (Private Cloud) – this is 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 equivalen