As the IT industry transitions into the cloud, organizational decision-makers face the challenge of committing resources in a rapidly changing field. Investments might decay into obsolescence in only years.
Developers working to advance state-of-the-art technologies in this environment deploy various new strategies for creating flexible, resilient, and portable services. But, the pace of innovation has left conventions and pattern definitions struggling to keep up. The industry is fraught with competing standards and lacks consensus on definition and methodology.
Although the cloud industry is moving too quickly and is still too young to have settled on a truly universal set of definitions and practices, several criteria have become obvious contenders. An effective and comprehensive cloud solution isn’t tied to one vendor’s success. At the very least, you should be able to migrate to an alternative platform if your needs or your provider’s situation change.
The diverse patchwork of global approaches to this problem has created some debate around which approach is the most effective at creating software for multi-cloud environments. Developers frequently refer to two specific terms in this discussion: “cloud-native” and “cloud-agnostic.” Occasionally, they mention “cloud-based,” but there’s less confusion about this more generic term.
Although cloud-native and cloud-agnostic definitions overlap, they differ in a few important areas. We’ll explore these differences, then describe a few simple use cases for each architecture type. The Cloud Native Computing Foundation (CNCF), considered the foremost organization working to standardize the cloud, offers a broad definition of cloud-native technologies, which we’ll use as a starting point for our discussion.
Cloud-Native versus Cloud-Agnostic
CNCF defines cloud-native technology as techniques and patterns developers use to create scalable, fault-tolerant applications with access to dynamic resources. Their primary design principle is to make full use of a cloud environment’s advantages. These applications are part of a broader ecosystem of loosely-coupled systems built from components that run in the cloud, and they are typically highly automatable and highly observable.
Software Built and Optimized for the Cloud
Cloud-native applications are designed, built, and run in the cloud. They use architectures that eschew traditional IT models in favor of harnessing containers, programmable infrastructure, microservices, and declarative API programming to take full advantage of cloud computing’s flexible and distributed nature.
Techniques like infrastructure as code (IaC) and containerization enable developers to create and automate reproducible architectures. These architectures efficiently scale in response to demand and handle massive workloads.
Much of cloud computing’s appeal results from containerization practices that structure applications as easily segmented microservices. Containerization refers to the practice of OS-level virtualization and delivery of software as immutable, static files containing all their dependencies. This idea has been in practice to a lesser degree for decades. However, it’s now become a cornerstone technique in the cloud-native field. Many industries have widely adopted containerization for its ease of deploying products.
Docker is the dominant containerization platform. However, Kubernetes, which has long been the primary method for scheduling and orchestrating workloads in the cloud, is slowly moving away from supporting Docker. Both are open-source solutions.
Companies like Airbnb — a classic Kubernetes success story — have used cloud-native technologies to disrupt industries that didn’t consider software a primary driver of success. Industry titans like Microsoft, Amazon, Google, and IBM offer managed Kubernetes software-as-a-service (SaaS) integrations on their cloud platforms, letting developers easily start building solutions using the popular orchestration tool.
The resultant architectures are generally highly-efficient and perform well. In some regards, they are a little more tightly coupled than current microservice development best practices, but they represent a decidedly modern and appropriate category of solutions for many organizations. The benefits of committing to a single vendor can easily outweigh the risk of rewriting your architecture during a migration to a different cloud, particularly when operational goals are clearly defined and the cost is a principal consideration.
For example, an organization running infrastructure on Azure Kubernetes Service (AKS) can expect every component to integrate properly. Components offered by Microsoft as part of the Azure ecosystem are either vetted for use with every other part of the ecosystem or have documented alternatives. Your developers can devote time to their product instead of ensuring their infrastructure runs on any number of competing cloud platforms.
Commitment also carries financial advantages. Applications taking a single-vendor approach to cloud nativity usually benefit from a well-developed stack with features like automatic scaling and load balancing intrinsic to the platform. To make their ecosystems more appealing, vendors often offer explicit discounts on top of these financial efficiencies, too.
So, considering the near-ubiquity of Kubernetes, Docker, and other widely supported tools for creating cloud-native solutions, why does the term cloud-agnostic matter? CNCF promotes open-source and vendor-neutral projects, after all, so why should we insist on another distinction in an already convoluted field?
Hidden Costs of Going Cloud-Native
The truth is that CNCF makes no mention of the term “cloud-agnostic” in its definition. It simply includes its organizational goals under the cloud-native label.
The “agnostic” in cloud-agnostic refers to software interoperability between various platforms and systems. CNCF’s push toward vendor-neutral projects implies “agnostic.” However, it’s still far from being the accepted default approach in the current cloud landscape, even if open source technologies seem to have hit a critical point in adoption.
Developers and decision-makers must generally partition this overly-ambitious designation for one of two reasons. They might use architectures that explicitly run on only one cloud provider’s service and then encounter a setback. Or, what they thought was a multi-cloud solution doesn’t transfer easily across cloud services without additional work.
Let’s use Kubernetes as an example again since it drives much of cloud computing.
Major cloud service providers’ Kubernetes clusters typify the limitations of a cloud-native approach that doesn’t emphasize portability. Although each platform offers the same open-source Kubernetes tooling and supports the same types of configurations — at least nominally — their implementations often rely on services specific to their ecosystems.
For example, you’ll need to set identity and access management (IAM) policies using your cloud provider’s tools. Connecting to legacy on-premise databases while transitioning your IT infrastructure is likewise complicated.
Being forward-looking doesn’t offer much relief either. Many cloud-native AI services and serverless functions use proprietary APIs. Some services impose soft requirements instead, such as Google Kubernetes Engine’s recommendation for gke-deploy rather than kubectl or Elastic Kubernetes Service’s preference for eksctl.
You could simply set up your own clusters for your IT department to administer, but this is the most work-intensive cloud-native approach. With the sheer diversity of open-source options — a list growing in size and complexity faster than any DevOps team can hope to master — it’s better to reserve doing it all yourself for the most specialized applications or niche legacy systems.
Instead, the more sensible alternative is to build a cloud-agnostic infrastructure and manage it with a flexible service.
Building for Every Cloud
Cloud-agnostic approaches represent a subset of cloud-native solutions. They emphasize portability and consistent performance regardless of their underlying platform.
By favoring the creation of even more loosely-coupled systems, “cloud-agnostic” is more faithful to CNCF’s intent for their cloud nativity definition. Organizations taking a cloud-agnostic approach are better protected from failures or shortcomings in individual vendors and enjoy interoperability with the broader selection of features and services available in multi-cloud architectures.
To accomplish a genuinely cloud-agnostic deployment, developers must build with these goals from the outset. They need to build solutions that are more resilient and much more adaptable after release. Yet, these solutions tend to be more challenging to orchestrate and monitor.
The steeper up-front time investment in cloud-agnostic solutions can be daunting. Implementing portable solutions from scratch demands that developers rigorously encapsulate all their application’s functionality in containers. Or, they may use standard implementations of common components and systems and refrain from using services with proprietary APIs — a challenging task to balance against the rest of an organization’s operational realities.
However, with foresight and careful consideration of an organization’s goals, a cloud-agnostic approach can provide impressive results. Furthermore, cloud agnosticism is preferable in applications with features needing frequent but small updates and services with broad geographic reach. These characteristics are becoming commonplace in DevOps, so it’s hardly surprising that Kubernetes and other cloud-agnostic patterns are multiplying.
Conclusion
Describing a technology as cloud-native does not automatically mean that it is also cloud-agnostic. “Cloud-native” describes an approach to software that conforms to the microservice model and fully capitalizes on cloud computing’s capabilities. “Cloud-agnostic” describes those applications and technologies that are cloud-native and portable to the point of being entirely vendor-neutral and loosely coupled. All cloud-agnostic software is cloud-native, but not all cloud-native software is cloud-agnostic.
One significant challenge yet to be resolved in this IT shift is observability, which is presently undergoing its own transformation. The push for increasing amounts of reporting has often made it challenging to parse actionable data about the state of a modern system from among the information noise it produces.
Instead, many organizations defer their analytics or cost management to specialist platforms like Yotascale. This solution handles the burdensome work of keeping modern containerized applications and multi-cloud architectures visible and observable.
It’s worth carefully considering where your organization stands in its approach to multi-cloud environments. Learn how Yotascale cloud cost management solutions help offset the financial costs associated with cloud agnosticism, which promises to be the dominant approach in the decade to come.
If you’re interested in developing expert technical content that performs, let’s have a conversation today.
