Cloud Agnostic instead of Multi-Cloud
Multi-Cloud and Cloud-agnostic are not the same thing and one is better than the other. But, what are the differences?
Back in my rebellious tech youth—when downloading FreeBSD over a 32K dial-up connection was a thing—Microsoft Word dominated the school system. WordPerfect and Lotus 1-2-3 were fading, while MS Word was on the rise. In the Free Software circles, we fought back (and we fought HARD!) by installing OpenOffice (the heir to StarOffice) on every possible machine. I had even rename shortcuts to Microsoft Word and change the icon in a naive (yet clever) attempt to make it go unnoticed. Inevitably, my ruse was discovered whenever someone tried to open the document on another computer with the actual Microsoft Word.
People would sometimes figure out how to export and import documents between OpenOffice and Microsoft Word, but the results were never perfect. The formatting, margins, fonts, tables, and printing were always off. This was understandable—Microsoft Word’s format was binary and difficult to reverse-engineer. And just when we were close, Microsoft would create a new closed format with new features, wiping out months or years of work.
Eventually, OpenOffice (now LibreOffice) improved its understanding of the proprietary format. The community grew, the UI got better, and Linux became more stable for desktops (finally, the year of Linux on the desktop!). OpenOffice could handle multiple formats, but maintaining that code must have been a huge effort. Around that time, XML was being used everywhere, sometimes unnecessarily (like today’s blockchains), and OpenOffice was pushing for the open format ODF. In a rogue move, Microsoft created a competing standard, OOXML, which was eventually adopted by ECMA and ISO. This led to two competing “standards,” which wasn’t ideal but significantly improved interoperability.
This little story may not be the best analogy, but it shows the difference between “multi” (support different formats) vs “agnostic” (an interoperable standard). Today’s clouds and dev tools are similar. Most are “multi” rather than “agnostic.” For instance, if you don’t want to learn vendor-specific technology to deploy resources (like Azure ARM vs. AWS CloudFormation), you might use Terraform. This tool lets you declare resources as code and supports multiple clouds, so you don’t need to learn different vendor technologies.
However, when I tried to reuse my code to deploy resources from one cloud to another, I found that 90% of the reuse wasn’t possible without significant complexity. I had to re-code for the different clouds. This might make sense for different implementations (like Amazon Aurora for MySQL vs. Azure SQL for MySQL), but it’s NONSENSICAL for things like Kubernetes. You need to use two different Terraform providers, with two different implementations, to deploy the same cluster on Amazon and Azure. That’s a huge effort, and any changes in Azure or AWS Kubernetes implementations could wipe it out.
Another example is telemetry. If you want multi-cloud observability, you need to learn Azure Monitor and AWS CloudWatch, or Azure AppInsights vs. AWS X-Ray. What we really need are cloud-agnostic implementations, like OpenTelemetry, where you don’t need to learn vendor-specific tools and can easily translate knowledge across different clouds.
Furthermore, the push for multi-cloud often leads to a fragmented skill set within teams. Instead of mastering one set of tools and processes, teams spread their efforts thin across multiple platforms, each with its own idiosyncrasies. This can lead to inefficiencies and a steeper learning curve, which ultimately hampers productivity and innovation. A cloud-agnostic approach, on the other hand, fosters deeper expertise and more streamlined operations.
That’s my point: let’s focus on standards, agnostic tools, and implementations instead of the multi-cloud paradigm, which will only lead to chasing a imaginary carrot that will be outdated in the next version. Cloud-agnostic solutions are the key to innovation, the smart path forward; let’s take it.