Is that Cirrus or Cumulonimbus?

I have never been a fan of the  phrase ‘cloud computing’, it is a buzz word designed to dumb down a technology for people rather than explaining the correct name which is Platform as a Service (PaaS). My go to answer when people would ask “What is Cloud” was “It’s just somebody else’s computer”, but then we termed the phrase ‘private cloud’ which has ruined that! To exacerbate this problem, we now have even more versions with the use of terms like hybrid cloud and multi-cloud.

To explain the differences between these two and what they mean we need to first explain what the ‘cloud’ is. Simply put, it is the next step up from hosting. As the demand for resilient infrastructure became necessary for server infrastructure, the use of external datacentre services grew. This was termed as co-location (Co-Lo) and meant that the responsibility for providing power, cooling, physical security and some networking infrastructure was now a service. The companies that owned these Datacentres (DCs) then realised that they could extend their services by filling cabinets with their own servers and renting these out. The company renting them was responsible for managing the Operating System (OS) or the virtualisation layer and the VMs running on the servers. This service became known as Hosting. It was more flexible than Co-Lo and was the first step to changing server infrastructure from a CAPEX cost to an OPEX cost. The draw back to it, however, was the storage side and how to incorporate that easily.

Coining a Phrase

This led to the first named ‘as a Service’ offering, infrastructure. This is a virtual infrastructure run and managed by a 3rd party that will include tiered performance storage offerings. Clients will pick standardised VM templates to be deployed from a catalogue which they will then be responsible for managing and configuring the OS on. Hosting in other words, but at the virtualisation layer.

What if you didn’t have the skillset in-house to set-up and manage the OS layer, or indeed a 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 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 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 utilising NSX-V, VMware Cloud on AWS offers the best solution to provide a seamless extension to the public cloud, but NSX-T is the choice of SDN for a Multi-Cloud platform, whether that is standard VM based or containerised micro-services.

What VMware Cloud on AWS (and other Hybrid Cloud solutions) offers is a cost efficient and expedient method to migrate suitable workloads to the public cloud. Then utilise that same cloud as a viable, highly resilient and cost efficient, disaster recovery platform for those that are not.

VMware Cloud on AWS also offers an excellent End User Compute (EUC) solution. An on-premises Horizon estate can be seamlessly expanded, with full feature compatibility, to the on-premises environment along with security, monitoring and automation.

Accelerate cloud success with Xtravirt

Xtravirt are one of VMware’s top tier service delivery partners.  Our proven expertise and track record of success has meant we have attained all 5 VMware Master Services Competencies and are one of a handful of Principal Partners for VMware Cloud on AWS and Digital Workspace in the UK.

As a cloud and digital transformation company we can help you unlock the full power of technology. We offer a range of services from assessments, proof-of-concepts to deployment and transformation. Xtravirt will understand your requirements, assess your application estate and ensure that the right solution is chosen to meet both your short-term and long-term goals to get the best ROI for your organisation.

Ready to start the conversation? Email us at [email protected]