Containers bring cloud-agnostic workloads closer to reality

What is cloud-agnostic?

Cloud-agnostic is a term with many purported meanings. It is not, as some think, what occurs when an organization or IT team has no preference as to which cloud platform they use. Nor does it particularly refer to a collection of hardware on which any cloud platform can run.

Cloud agnosticism has far more to do with the IT workload -- a workload that can be implemented on, and moved between, any available cloud platforms. Economic drivers force organizations to evaluate whether they can move certain workloads from high-cost environments to lower-cost ones when those workloads are not required to operate at peak performance.

Multi-cloud vs. cloud agnostic

Many organizations already find themselves in the position of being multi-cloud, meaning they operate workloads with more than one cloud provider -- even if it wasn't planned. As such, workloads become dependent on, for example, AWS or Microsoft Azure, and cannot easily migrate onto Google Cloud or IBM Cloud. Therefore, a mixture of workloads across a number of platforms grows. This multi-cloud setup goes against cloud-agnostic's meaning, as each workload is bound to its respective cloud host, not free to move among the options.

Hypothetically, a cloud-agnostic environment is easier for the IT operations team to manage, compared to a multi-cloud one. With a single, standardized management interface, operations could monitor and report on each distinct workload, no matter where it is. For a multi-cloud environment, IT operations admins must aggregate information feeds from heterogeneous systems, often with a need to normalize the data and apply additional analysis before the administrators can make optimizations or resolve problems.

The challenge with cloud agnosticism

Modern workloads have many interdependencies, requiring common APIs and other standards to operate. If all cloud platforms were equal, then IT teams could create truly agnostic workloads that float between those platforms without any issue. However, the only way for one cloud to be better than another for a given customer is in differentiation. Some of this differentiation comes via availability levels or means of management; however, much is through the cloud services that workloads can consume.

If organizations choose a private or public cloud platform and use any nonstandard extensions or services, that workload becomes tied to the cloud platform and is no longer cloud-agnostic.

Along came containers

Because of the reasons stated above -- differentiation among cloud providers' services and platforms -- it has been difficult, if not impossible, to achieve a cloud-agnostic workload that migrates seamlessly across vendor offerings. But the industry's standardization around container orchestration has made cloud agnosticism more of a reality.

DevOps practices require that developers can create container images in the development environment and push them out to the operations environment -- with minimal intervention. An orchestration tool packages, provisions and updates containers. This tool ensures that required resources come together virtually, which makes the differences between physical and virtual levels of a platform immaterial. Essentially, it creates a level playing field where systems admins don't need to concern themselves with the actual platform itself -- at least not as thoroughly as with a physical infrastructure.

The most ubiquitous container orchestrator is Kubernetes. Support for Kubernetes is available on AWS, Azure, Google Cloud Platform, IBM Cloud and many other public clouds. Some private cloud platforms, such as Red Hat OpenShift and Oracle's private cloud appliance, either offer built-in Kubernetes or facilitate its deployment. And now most DevOps tools have Kubernetes support built in, as well.

So is cloud agnosticism a given?

With Kubernetes as a common factor across most virtualized platforms -- and with Kubernetes itself dealing with the vagaries of the physical and virtual environments -- workload portability should be simple, yes?

Unfortunately, no.

What we end up with is an IT platform that is based nominally on standardized systems, but has unique extensions and modifications from cloud providers. And these non-standard extensions or services tie workloads to specific cloud platforms.

Even with Kubernetes as a common factor, no two Kubernetes distributions are identical. For example, an admin can't use one provider's Kubernetes management dashboard to manage another Kubernetes distribution. Each cloud platform implements its Kubernetes distribution in a slightly different way, and might have a closed dashboard to view and manage that specific implementation. Even if an IT organization has its own Kubernetes monitoring dashboard, it's limited without the ability to tap into the cloud provider's data streams. As a result, teams might end up needing multiple dashboards.

IT needs an orchestrator for the orchestrators to make cloud-agnostic deployments truly viable. This is a sad state of affairs, but an altogether too common issue: As a suitable standard for a technology emerges, vendors decide to support it. But then they add unique features to differentiate themselves -- which makes their version nonstandard. They air lock their environment to tie customers into using their system. They prevent the easy flow of data across boundaries, making an overarching solution impossible.

So, sure, Kubernetes has made a cloud-agnostic approach more feasible. But the ways in which vendors support Kubernetes have made such an approach unlikely.

Instead, plan for a multi-cloud environment and seek the best management systems: Keep an eye on the space as tools improve and evolve. Look for a multi-cloud management tool that adds extra capabilities over time to approach the single pane of glass envisioned for cloud-agnostic operations.