Two of the biggest Strategy buzzwords surrounding Technology rattling around in boardrooms and technical meeting rooms across the length and breadth of Europe are Multi-Cloud, and Hybrid-Cloud; these, together with the associated benefits, potential risks, issues, and constraints that any adoption could bring.
What is confusing about these terms is that, ostensibly, they mean the same thing; you house your resources and data in a most performant or economic location for the service; that may or may not run across multiple clouds. So, perhaps a couple of Amazic definitions to explain the differences between Multi-Cloud and Hybrid Cloud are needed to set the guidelines. Why? Because Google use the following as a definition hybrid cloud
“A hybrid cloud is one in which applications are running in a combination of different environments.”
this definition for multi-cloud
This is at odds with other definitions from vendors like Microsoft, VMware or IBM, whose definition of hybrid and multi-cloud is the exact opposite.
Amazic Hybrid-Cloud Definition
“A hybrid cloud is a customer environment that utilises two or more platforms, one or more is a hyper-scalar (AWS, Azure, GCP), and at least one is an on-Premises environment.”
The On-Premises section could be in a privately owned datacentre or a Co-Lo (hardware possibly owned by a company but operated and managed by an MSP; the key feature is that it is a self-managed infrastructure).
Amazic Multi-Cloud Definition
“A user environment that utilises two or more cloud platforms from different hyper-scalars”.
I would rather have just a single definition, multi-cloud. There is no real difference technically between a hybrid cloud and a multi-cloud; the benefits and risks are the same; the difference is in the ownership model.
Moving on
What are the benefits, and what are the issues, risks, and constraints that people looking to adopt either of these strategies need to look out for?
The Benefits are myriad.
The benefits of either a multi-cloud or Hybrid-Cloud:
- Optimisation of workload resources: you can operate your workloads in the best possible location in terms of performance or cost.
- Reduced CapEx costs: by building out in the public Cloud, costs scale with use.
- Easier ability to scale: usage can be decreased during times of less need and rapidly increased during resource stress; this is perfect for those companies with seasonal peaks and troughs.
- Easier ability to undergo a stressed exit: When you have feet in many camps, the ability to move location quickly is significantly enhanced; the ability to carry out a “stressed exit” is now a requirement for British Financial Institutions; this is something that the former customers of UKCloud (a UK-based Sovereign cloud provider) have had to undergo recently following UKCloud’s fall into administration.
- Greater ability to remain close to your data: The majority of Hyper-scalars do not have multiple Regions in a country outside of the United States. For example, AWS have only a single Region (with three Availability zones) in the UK; Azure has two sites (UK South and UK West. However, UK West has no availability zones and significantly less capacity). Finally, GCP only has a single region with multiple availability zones in the UK.
There are several benefits of keeping a subset of your environment owned in environments fully controlled by yourselves.
- Ease into Cloud Migration: Move at the speed of risk, many Organisations that are moving to the Cloud to support the migration of on-premises data and application workloads into the Cloud, with objectives that include lowering costs, increasing IT efficiency, and reducing time-to-market for new products and services.
- Drain down of legacy technology: By strategically moving key resources to the Cloud, companies can accelerate a transformation project; companies can target those services earmarked for modernisation and keep legacy technology on ageing hardware draining-down to retirement.
- The best Location for the Service: Companies can use “hybrid” cloud systems to leverage the optimal computing environment for every workload. You can choose to process complex workloads in the Public Cloud where additional capacity is low-cost and easy to access but keep simpler workloads on-prem or in private cloud infrastructure.
- Data Sovereignty: Having an environment containing a privately owned site means that you can keep control of your crown jewels (your data) and only move the information being processed out to your public Cloud as required or synchronise data between multiple locations.
The lack of multiple locations within a sovereign boundary is a significant problem for many countries; it is another Brexit problem for UK-based entities requiring their data to remain sovereign. The UK went from a pan-European sovereign boundary to one bounded by the North Sea, English Channel, and Irish Sea.
What are the risks of a multi or hybrid cloud strategy
The most significant risk of a multi-cloud strategy is one of added complexity; breaking those down further a multi-cloud strategy will add the following Risks to a business:
- Various rules: Using Multiple providers forces a company to contend with multiple regulations and systems. The resulting environment is significantly more complex than the previous environment; this results in more time-consuming work for IT departments in monitoring each one.
- Unfamiliarity: the law of unintended consequences; with each cloud provider adoption, the workload of the Operations team will increase, and your training budget will increase as your staff will need to become familiar with them and bring all employees up to speed.
- Security: Monitoring all these clouds can present some security challenges. For instance, it can be difficult to maintain a unified set of controls, which can cause security gaps; there is a potential for platform drift in terms of patching across services. For example, outsourcing your platform does not remove a company’s compliance obligations.
- Cloud economics: Multi-Cloud strategies will mean multiple payment points, which means added complications for the payables team; another possible issue is that all Cloud providers do not charge for data ingress, but data egress is an entirely different matter which could be considered a hidden charge. Also, the flexibility that a Cloud provider gives in terms of on-demand payment is a double-edged sword; without entering into a long-term enterprise purchase agreement, getting visibility of your spending for budgetary purposes is problematic.
How to mitigate and gain actual benefits from a Hybrid or Multi-Cloud Strategy
The first questions that need to be answered before walking down the hybrid or multi-cloud path are not technical but strategic and business-focused. Will your company gain value from running in multiple clouds? Does the increased complexity of design merit the gained flexibility and fluidity of resource movement?
A lot of work is needed to successfully create, deploy and, more importantly, operationalise and manage a cross-cloud strategy. Unless you have a regulatory control that is ultimately forcing your hand, I would highly suggest running a proper cost-benefit analysis on the system or systems being considered for migration to multi-cloud before committing resources to move in that direction.
OK, You have a genuine reason for the added complexity or an abusive relationship with technology and always want to walk the hard path to success.
One of the first things to get correct in a multi-cloud environment is how to deploy consistent applications across domains. Another is where your data will be located, and how you manage compliance and governance across disparate locations. Of course, there are many more questions, but those three alone will keep you awake with worry for days.
It is worth noting that I mentioned Applications rather than Servers. If you are still considering deploying Virtual machines and at the same time considering a multi-cloud strategy, be prepared for a lot of pain. AWS, VMware, and Azure, all deploy virtual machines by differing processes and in differing formats. For example, VMware’s Virtual machine format is not natively compatible with AWS’s AMI or Azure’s. So you are looking at at least three different machine formats to create images for. But what about the OVF format, which is cross-cloud/environment compatible? Yes, there are conversion mechanisms, but these are also slow and prone to annoying post-migration configuration changes. Not exactly conducive to agile and just-in-time deployment processes, which is why I mentioned Applications. To start looking correctly at Multi-Cloud, you need to elevate from the machine/OS layer to the Application layer. This means deploying resources into pre-existing virtual machines, which is expensive; you need virtual machines sitting there waiting for application deployment. It suffices to say that if you are still looking at virtual machines as your application deployment target of choice, you are walking down the wrong path.
OK, so what is the correct path?
I bet you expect me to say Containers or serverless here, aren’t you? Yes, they are options; however, the correct path is to place your applications in the location that will provide the best value for the cost spent. This may mean refactoring your applications to run in a container. Then use something like Terraform or Pulumi to deploy a helm chart onto a native Kubernetes environment in whatever Cloud or clouds you wish to deploy into or deploy the environment into a single cloud on a virtual machine in an autoscaling group handling elasticity.
What about your data? Do you create copies of it in multiple locations and use a synchronisation product to keep them in sync? Possibly, but this all gets way more complicated when you are dealing with multiple locations, especially if you are hoping for Bi-Directional synchronisation. Do you have a central location (perhaps On-Prem) for your data and create read-only cached instances in the Cloud for your applications to run against to lower your egress costs? Again, we have difficult questions about keeping your centralised hub updated with any changes. Further to this issue is that different data types will require differing synchronisation or caching methods; you will need to consider questions about immutability, sovereignty, and ownership. Finally, the latency and bandwidth needed to keep data synchronised within your SLA tolerances may be cost-prohibitive.
What about networking? How do you connect each environment fluidly and securely? Do you attempt to Heath Robinson a solution using native tools that may or may not interact perfectly or utilise another third-party solution like Megaport, MPLS, or an SD-WAN product, further driving up costs?
The point I am making here is that technology is not your starting point; it is “bang for buck.” Like any business, driving value and mitigating risk is much more important to your board or shareholders than how you do it.
Hence we return to an earlier question, “Do you really have a need for true Multi-Cloud?” For many companies, the added pain of managing multiple hyper-scalers is a risk too far. The Risks and potential constraints are just too complicated to surmount, and the increase in complexity makes no sense, technically or financially. However, the answer to the question when considering a Hybrid-Cloud solution is much more nuanced. For example, you will most likely be looking at modernising your ageing estate or managing temporary uplifts in usage requirements. Or thinking of moving new technology to a cloud provider to provide a more flexible solution that is easily scaled, both explosively and implosively.
Summary
In this article, we investigated at a high level the potential drivers for a Hybrid or multi-cloud strategy within a company. We explained a subset of the benefits of Multi-Cloud and some additional hybrid cloud benefits and identified several risks. In Our next article, we will define our use case and investigate some potential architectures to deliver the solution; then we will look at how we would provide that solution wrapped up in DevOps processes.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
