The concept of cloud agnosticism—building applications and services that can operate seamlessly across multiple cloud service providers (CSPs)—has long been hailed as a way to avoid vendor lock-in. In fact, Corey Quinn wrote and spoke about the myth of cloud agnosticism in 2018! A multi-cloud approach can also mean using multiple clouds for different workloads, but doesn’t necessarily prioritize portability. While the idea of maintaining flexibility and portability is appealing, there are inherent trade-offs and technical limitations that make complete cloud agnosticism largely a myth. Nevertheless, the principles behind it are still relevant and valuable for any organization seeking to ensure strategic flexibility.
The Myth of Cloud Agnosticism
Cloud agnosticism is often defined not only as the ability to switch between CSPs easily, but doing so without requiring significant cost or effort. And while Kubernetes and containerization have certainly made workloads more portable, several factors remain that undermine the feasibility of being truly cloud-agnostic:
- Proprietary Services and APIs: CSPs offer useful, value-added services such as Amazon Web Services (AWS) Lambda, Google BigQuery, and Azure AI Services. These tools often provide significant advantages in terms of performance, scalability, and cost but create dependencies that make migration challenging because these services are all optimized for their respective platforms.
- Hidden Dependencies: Even when using open-source tools like Kubernetes, dependencies on CSP-specific features—such as identity and access management (IAM), networking configurations, or storage solutions—can lead to unintentional lock-in. Each CSP has different architectures, APIs, and operational models, making it hard to find direct equivalents or re-engineer applications for a new environment. These dependencies can limit flexibility and increase switching costs, even if (or when) another provider later offers better pricing or features. Another common dependency is that large datasets typically tie your workloads to a specific provider because moving data between clouds can be slow, expensive, and operationally disruptive. Even if your application code is portable, data transfer fees and migration complexity may undermine the benefits of cloud agnosticism.
- Cost and Complexity: Abstracting applications to work across multiple clouds frequently requires additional layers of complexity. Cloud providers evolve their services and APIs frequently, so keeping your abstraction layers up-to-date and compatible requires continuous investment in engineering resources. Troubleshooting and maintaining consistency across multiple environments introduces challenges that you may not encounter in single-cloud or even some multi-cloud setups.
- Performance Trade-offs: Optimizing applications for one cloud provider often results in better performance and lower costs compared to a generalized approach. For example, using managed Kubernetes services like Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), or Microsoft’s Azure Kubernetes Service (AKS) allows deeper integration with each provider’s cloud-native tools but inherently ties you to that provider. You’ll have to pick the Kubernetes cloud provider that makes the most sense for your organization. Generalizing for portability may also lead to higher latency, reduced throughput, or increased costs compared to architectures that are deeply integrated with a single provider’s services.
Cloud Agnosticism Still Matters
Despite these challenges, the principles of cloud agnosticism remain important for any organization that wants to reduce risk and maintain flexibility. Here are six practical ways you can embrace "strategic agnosticism" without adding more complexity than necessary:
- Adopt Microservices and Containerization. Using microservices and containerizing applications improves portability and decouples workloads from underlying infrastructure.
- Choose Universal Tools. This may seem like a no-brainer, but it needs to be said: whenever possible, use widely supported technologies, such as PostgreSQL for databases or RabbitMQ for messaging queues, instead of proprietary alternatives. Use open-source platforms for container orchestration (Kubernetes, maybe?), to ensure support across all major CSPs.
- Adopt Automation but Avoid Proprietary IaC Tools. Adopt automation early on, especially for provisioning and CI/CD pipelines, to minimize manual efforts and improve consistency across clouds. Instead of using CSP-specific Infrastructure-as-Code (IaC) tools, such as AWS CloudFormation, select IaC solutions that support multiple clouds, such as OpenTofu, Terraform, and Pulumi. These tools enable you to define infrastructure in a way that is more portable across providers.
- Use Kubernetes-Native Constructs. Try to stick to Kubernetes-native features and add-ons instead of relying on CSP-specific integrations. For example, use open-source ingress controllers, such as the tried-and-true nginx ingress controller.
- Plan for Data Portability. Think about how to implement data portability mechanisms that allow you to move data between clouds without significant rework. This means using open standards for data storage and ensuring data formats are compatible across different cloud providers. Or consider using 3rd party data providers outside any specific CSP.
- Adopt a Multi-Cloud Strategy. While complete cloud agnosticism may be impractical, you can still take a multi-cloud approach to mitigate some of the risks associated with vendor lock-in. For example, you might run AI workloads on Google Cloud while hosting transactional databases on AWS. This provides flexibility while still making the most of each provider's strength.
Choose the Right Tool for the Job
In its purest form, cloud agnosticism may well be a myth, but the principles it embodies—flexibility, portability, and interoperability—remain relevant in today's multi-cloud world. Degrees of agnosticism are absolutely achievable and valuable. By making thoughtful decisions about tooling, architecture, and vendor relationships, you can achieve a balance between leveraging CSP-specific capabilities and maintaining the agility to adapt when circumstances change.
Long live cloud agnosticism—not as an absolute goal, but as a guiding principle for how you select and deploy the tools, add-ons, and frameworks you use.
Fairwinds builds managed infrastructure across all three major clouds, and works hard to provide as-consistent-as-possible infrastructure to our customers. If you need or want to be multi-cloud on K8s, let’s talk. Fairwinds can help.