Hybrid & Multi cloud means different things to different people. A decision model helps bust the buzzwords and show the options clearly.
Hybrid is a Reality. Multi-cloud is an option.
Let’s segregate hybrid from multi:
- hybrid: splitting workload(s) across the cloud and on-premise. Generally, these workloads pertain to a single application, meaning the piece in the cloud and the piece on-premise interact to do something useful.
- multi: running workloads with more than one cloud provider. If we get more precise than that, opinions diverge.
Dissecting Multi-cloud
A multi-cloud strategy is an architecture choice you make. Examining common multi-cloud approaches and the motivations behind them helps us make these choices.
Multi-cloud generally falls into one of the following categories:
1. Arbitrary:
Applying this to multi-cloud, a huge percentage of enterprise multi-cloud is the result of poor governance and excessive vendor influence. It basically means that you have some workloads running in one cloud, some others in another cloud. You don’t have much of an idea why things are in one cloud or the other, or, more likely, you started with one cloud provider, then you received a huge credit from other cloud provider thanks to existing license agreements or due to personal relationships and a heavy sales push.
Key capability includes deploying applications to the cloud and the key mechanism is cloud skill.
2. Segmented:
Segmenting workloads across different clouds is also common, and a good step ahead: you deploy specific types of workload to specific clouds.
This scenario often results from different vendor preferences for different kind of workloads, for example due to individual vendors’ strengths or licensing terms. A common combination is to have most workloads in cloud X, Windows-related workloads and ML/analytics in cloud Y.
You may decide to segregate by a number of factors:
- Type of workload (legacy or modern)
- Type of data (confidential vs. open)
- Type of product (compute vs. data analytics vs. collaboration software)
When pursuing this approach, it’s helpful to understand the seams between your applications so you don’t incur excessive egress charges because half your application ends up left and the other half on the right.
Enterprises might slip from segmentation back into arbitrary due to vendor affinity. They may use cloud vendor X for a specific type of service, but their (pre-)sales folks will likely convince teams to use their other services as well.
Key capability includes clear guidance on cloud usage and the key mechanism is governance.
3. Choice:
Many might not consider the first two examples as true multi cloud. What Enterprises are looking for (and pitching) is being able to deploy workloads freely across cloud providers, thus minimizing lock-in (or the perception thereof), usually by means of adding abstraction layers. This ambition again breaks down into multiple flavors, the less complex and more common case allowing an initial choice of cloud platform, with the assumption that you don’t keep changing their mind.
This choice scenario is common for large organizations’ shared IT providers because they are expected to support a wide range of business units and their respective IT preferences. Often, such a setup involves a central commercial relationship and a common framework to create instances on the cloud provider of your choice but with corporate governance and constraints tacked on.
The advantage of this setup is that projects are free to use proprietary cloud services, such as managed databases (depending on their preferred trade-off between avoiding lock-in and minimizing operational overhead). Hence, this setup makes a good initial step for multi-cloud.
Key capability includes support project needs and preferences; reduce lock-in and the key mechanism includes common framework for provisioning, billing, governance.
4. Parallel:
While the previous option gives you a choice among cloud service providers, Enterprises are still bound by the service level of a single provider. Many enterprises are looking to deploy critical applications across multiple clouds to assure higher levels of availability than they could achieve with a single provider, even with that provider’s multiple availability zones.
Being able to deploy the same application into multiple clouds requires a certain set of decoupling from the cloud provider’s proprietary features. This can be achieved in a number of ways, for example:
- Managing cloud-specific functions such as identity management, deployment automation, or monitoring separate from the application in a cloud-specific manner
- Using open source components as much as possible – they will generally run on any cloud. While this works relatively well for pure compute (hosted Kubernetes is available on most clouds), it may reduce your ability to take advantage of other fully managed services, such as data stores or monitoring. Because managed services are one of the key benefits of moving to the clouds, you need to consider your options carefully.
- Utilize a multi-cloud abstraction framework, so you can develop once and deploy to any cloud.
- Maintain two branches for those components of your application that are cloud provider specific and wrap them behind a common interface. For example, you could have a common interface for block data storage.
While the latter sounds kludgy, it’s what we have been doing with databases and many other dependencies for a while. Properly wrapped, it’s a viable option.
The key aspect to watch out for is complexity, which can easily undo the anticipated uptime gain. Additional layers of abstraction and more tooling also increase the chance of a misconfiguration. Also, if you deploy a broken application to both clouds, then you will still suffer downtime, so make sure to account for human error.
Key capability includes higher availability than single cloud and the key mechanism includes automation, abstraction, load balancing.
5. Portable:
The perceived pinnacle of multi-cloud is free portability across clouds, meaning Enterprises can deploy workloads anywhere and also move them as they please. The advantages are easy to grasp: you can avoid vendor lock-in, which for example gives you negotiation power. They can also move applications based on resource needs. For example, they may run normal operations in one cloud and burst excessive traffic into another.
The mechanism to enable this capability is high levels of automation and abstraction away from cloud services. While for parallel deployments you could get away with a semi-manual setup or deployment process, full portability requires you to be able to shift the workload any time, so everything better be fully automated.
Multi-cloud abstraction frameworks promise to make this type of setup easy. However, nothing is ever free, so the cost comes in form of lock-in o a specific vendor, product, and architecture plus a requirement to deploy the application in containers. Also, such abstractions generally don’t take care of your data: if you shift your compute nodes across providers, how are you going to keep your data in sync? And if you manage to overcome this hurdle, egress data costs may increase.
Key capability includes shift workloads as you please and the key mechanism includes full automation, abstraction, Data portability. Source
How Can ITM Help You?
iTM covers all aspects of Cyber Security including but not limited to Home cyber security managed solutions to automated, manage threat intelligence, forensic investigations, Mobile Device Management, Cloud security best practice & architecture, OSINT and cyber security training. Our objective is to support organisations and consumers at every step of their cyber maturity journey. Contact Us for more information.