Multi-Cloud, Hybrid Cloud and Kubernetes

Source:-containerjournal.com

If you’ve been following the DevOps newsfeed, you’ll see that hybrid cloud is hip again! And now it has a trendy new sister, multi-cloud. I’m of the camp that believes both of these infrastructure architecture patterns are different and both require Kubernetes. This post is about why.

Because there is some disagreement on whether hybrid cloud and multi-cloud are the same or different, let’s define them for the sake of this post. When I embrace definitions of techie things, I follow a simple principle: Does the term (no matter how annoying it may be) support a very specific conversation? With that, both hybrid and multi-cloud absolutely do.

Why Cloud’s Plural

There are several clear benefits both for hybrid and multi-cloud:

1. Hybrid connects highly controlled infrastructures with public-facing infrastructure for public-facing apps. This supports organizations where that control is still very necessary but they do not want to be leapfrogged in the modern application development practices.
2. Public clouds offer high-availability, but that ability to have your application running on or portable to another cloud service provider means that if something really bad happens—such as an outage or political differences—you can make a move without being sunk with engineering effort.
3. Currently, most organizations polarize their infrastructure with a single cloud provider. As a result, they will only use services that the cloud provider has, which can hamstring their success. There is a world of specialized cloud services out there, and some from other providers that could be better-suited for your stack and application.

Different but Same Demands

Hybrid cloud assumes that there is some combination of public and private clouds. Hence, the term hybrid—two different models but still connected. Multi-cloud, meanwhile, is 100% public cloud, where infrastructure is spread between cloud providers or within regions on the same cloud.

The distinction is important because there are different considerations. Hybrid cloud, in particular, has some large security considerations, but its setup is more “set it and forget it.” Multi-cloud introduces more simplicity in setup, but it also is a lot more dynamic.

In terms of maturity, hybrid cloud wins. Hybrid cloud became popular around 2015, due to a big push by IBM and HP as part of the digital transformation conversation. As a result, organizations have been working toward hybrid cloud for quite some time. It also predates Kubernetes/containers. Multi-cloud, arguably, is the result of the container orchestration drive—or, at the very least, made it possible. Therein lies the key topic: Are containers required in hybrid cloud and multi-cloud configurations?

The simple answer is, yes.

Backing in from the most simplistic answer, I believe containers and container orchestration are mandatory to support both hybrid and multi-cloud environments. But there are a lot of nuances:

1. Hybrid and multi-cloud assume a certain amount of portability. Both configurations can be configured without containers. But by connecting multiple clouds, there is far more rigidity by default than there is supporting a single self-contained cloud environment. So future portability has to be built into the original design. Portability requires an infrastructure abstraction and compartmentalized/scripted infrastructure. Right now, the best way to accomplish that is via containers and container orchestration.
2. True hybrid and multi-cloud are going to include storage, serverless and PaaS. It is silly for me to claim that cloud is comprised solely of instances of containers you control. The modern application is and will be comprised of your containers, your persistent storage, serverless code and PaaS services. These add some serious twists to the hybrid and multi-cloud scenario. But with multi-cloud, part of the clear benefit of consuming the right service for the right job.

How Multi-cloud Stands to Benefit More

Widgets and abstractions are the name of the game and always have been for modern development. We like things to be widgetized so they are portable, small and easy to manage and build. And we keep adding abstractions to help support that.

Cloud is just an abstraction. And applications are only as portable as their least portable thing, which is the cloud service they are running on. So the benefit of abstracting cloud configuration from the provider so that the cloud itself is portable is ideal for supporting modern applications, especially in areas where we need to support greater complexity of applications such as microservices, where each service has independent stack and life cycle, and performance through approaches such as edge computing.

Users and applications are more demanding on infrastructure. If you want to provide a real-time experience, performance is a huge consideration. Soon there might be client-side microclouds or clouds on-demand based on various scenarios.

The Cloud Management Plane

Tool vendors rose to hybrid cloud demands early on, and hybrid clouds continue to be a small but highly active sub-segment of the DevOps tools market. While I have seen the cloud management tools do well with hybrid cloud scenarios, they still seem lacking with multi-cloud. For one big reason: From what I have seen so far, the relationship between clouds is a loose coupling. Configuration is templated, but production operation is still largely separate. What I would expect to see is a view of the cloud, period, not their individual cloud implementations and their connection points.

Also, some cloud management tools have their own form of lock-in through unique configurations that are required to manage the relationship between your clouds or how templates are created and stored. This is a benefit until it’s not. Cloud management tools bring visibility, which is a huge requirement—visibility in a single pane of glass to see what you have and where it is in UI, but also visibility in creating cloud marketplaces of sorts; the ability of an organization to templatize whole cloud implementations that they can deploy anywhere the base infrastructure supports it. What is still required is the automation of monitoring tools across cloud environments to create the same degree of visibility/observability to production.

It would be a mistake to talk about hybrid or multi-cloud configurations without talking about containers and container orchestration like Kubernetes. While from a pure setup perspective it is very possible to do it without these, there will be no portability. And portability is a key benefit to having multi-cloud and hybrid cloud environments.

Now for the next related term to get hot again: bare metal. And with the above technologies, it can.