Is Cloud-Agnostic Even a Thing?

Before we can examine if cloud-agnostic is a thing, we must understand what it is in the first place. There are a multitude of opinions on this matter, but from my standpoint, being cloud-agnostic is about being able to run a given workload on any cloud platform, without having to modify the workload for it to work correctly. Typically, this would be in a public cloud like AWS, Azure, or GCP. With that in mind, this article examines if cloud-agnostic is achievable and if it should be considered when deploying workloads in the public cloud. Let’s start by abstracting this thinking away from public cloud workloads. What if we apply this to cars? Imagine you wanted an engine to work across platforms. Could you take the engine out of a BMW and drop it into a Mercedes? Probably, but it wouldn’t work very well because the rest of the platform wasn’t designed for that engine. For true engine portability, you’d have to design the engine to fit both the BMW and the Mercedes from the outset and understand how each platform works. This would likely give a compromised setup whereby the engine cannot take full advantage of either platform’s capabilities anymore. Was the additional effort worth it to design a compromised solution? In cloud computing terms, is it worth spending extra time developing an app so it can run in multiple clouds, or is it better to concentrate on one platform and take full advantage of what it has to offer? There are some exceptions to this, and the use of containers seems to be one way to work around this cloud-agnostic conundrum. What’s a container, you ask? If we take Docker's explanation (https://www.docker.com/resources/what-container), it’s “a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.” So, in other words, a container is a level of abstraction where all the software and code are wrapped up in a nice little package and it doesn’t really matter where it runs provided the underlying infrastructure can cater to its requirements. Let’s use another car analogy. What if a child’s car seat is a container? It’s not tied to one manufacturer and is expected to work the same way across platforms. This is possible due to a set of guidelines and standardization as to how a car seat works. ISOFIX to a car seat is what Docker is to a container. (Don’t ask me how to create a Kubernetes analogy for this, I don’t know.) Which brings us to vendor lock-in. Things work better if you fully embrace the ecosystem. Got an iPhone? Bet that works best with a Mac. Using Exchange online for email? I bet you’re using Outlook to access it. Workloads designed to run on a single-vendor public cloud can take advantage of all the available adjacent features. If you’re running a web application in AWS, it would make sense to use AWS S3 storage in the back-end, or maybe AWS RDS for database tasks. They’re designed from the outset to interoperate with each other. If you’re designing for cloud-agnostic, then you can’t take advantage of features like this. In conclusion, yes, cloud-agnostic is a thing, but is it something you should embrace? That’s for you to decide.