Cloud Agnostic Architecture is a Myth

I’ve been working with my head in the cloud for the past 2 years now and one thing is pretty certain — Cloud-agnostic Architecture is a Myth, at least in a conventional sense.

Overly-generic stock photo to represent vendor lock-in.

In this article, I’ll be discussing the current state of cloud services and how being truly cloud-agnostic is not only something we can’t quite achieve, but why it isn’t necessarily something you may want to achieve.

Dockerizing Your Application

Our first port of call is Docker. I am a seriously massive advocate for containerization technologies such as Docker and have recently given talks demonstrating how these technologies could massively improve the way we build and deploy software.

One of the key advantages of Docker that I like to highlight, is its ability to reduce the friction when it comes to migrating from one cloud service provider to another. You specify everything that your application needs to run in terms of runtime, environment variables and any setup scripts and you are able to start said container almost everywhere. I say *almost* as there are some very minor exceptions such as Windows-only images etc.

This essentially means that the Python application we need to run can be containerized and dropped into any managed container service such as ECS. The underlying container platform will then manage the container lifecycle and provide additional benefits such as logging and monitoring should we wish.

The underlying OCI-compliant container runtime will then handle any discrepancies between hosts and run your application as you intended it to run with minimal fuss.

When it comes to trying to avoid vendor lock-in, containerization is an incredibly low-hanging fruit.

The Growth of Terraform

Terraform is the latest “shiny thing” that I’ve had the pleasure of playing with in my travels and I’m very much a fan of the CLI and how it lets you define your infrastructure as code.

You can specify the provider you wish to use as well as the access keys and secret keys and when you run terraform apply , the CLI will the go away and spin up the appropriate infrastructure for you to then deploy on top of:

If you subsequently need to tear down your infrastructure, you can with ease using the terraform destroy command, which is a command that sounds freaking awesome.

If you are looking for a good reference manual on Terraform, then I highly recommend the Yevgeniy’s book:

Terraform: Up and Running: Writing Infrastructure as Code

Now, this is great for spinning up your system’s required infrastructure on a specific cloud provider, but this means we will have to write multiple Terraform scripts for each of the distinct cloud providers.

This isn’t entirely out of the question, but we then have to maintain these scripts going forward in such a manner that we can ensure their correctness should we need to fail over to a given provider. There also needs to be a certain level of knowledge regarding the underlying platform in order to be explicit about what instance types you are spinning up or what size these instances need to be.

From an application developer’s point-of-view, you may not necessarily have to, or want to, care about what AMI you are creating your t2.micro instances from, you may just care about developing your application and having somewhere stable to run said application so that it can serve your paying customers.

The Nuances between Services

One of the potential solutions to this that I have seen mentioned is to implement a layer of abstraction above all cloud service providers and essentially define your application’s underlying infrastructure as a series of blocks. Essentially an extension on top of Terraform that would have the ability to spin up cloud-platform agnostic infrastructure.

This Terraform-esque abstraction layer would then have the job of interfacing with whichever cloud platform it so chooses and spinning up said infrastructure. This would let you define say, a simple web app, as 1x “Load Balancer” and 2x “Small Server”.

To some, this seems like the obvious solution, but when it comes to implementing this abstraction layer and dealing with the nuances between how different services are exposed, this becomes next to impossible.

Trying to handle this at an application level would be next to impossible and your codebase would be riddled with hundreds, if not thousands of conditional flags in order to cover a large number of services. Could we abstract this into a service-broker or SDK? Maybe, but it just shifts our initial problem left.

Kubernetes

So, Kubernetes is incredible and I’ve discussed some of its potential benefits for Enterprise environments here:

Can Kubernetes Revolutionize The Enterprise World?

Kubernetes, in combination with Docker and Terraform, may actually be somewhat of a good answer when it comes to attempting to be agnostic. It’s also something that has been explored by a number of different companies and individuals and we are starting to see managed solutions come about such as Triton.

Multi-cloud Kubernetes with Triton | Joyent

These federated kube-clusters (klusters?) can then be treated as an amalgamous lump of compute that can then run and manage any container-based applications you may wish to run.

The biggest advantage of this is that application developers need just worry about how they want their application to look and does abstract away the underlying infrastructure.

But then this isn’t perfect, these services are still very young and have yet to hit the mainstream. It’ll most likely be a while before these services become mature enough to be picked up by larger enterprises.

The Value of Managed Services

Vendor lock-in — The art of leveraging specific services from a cloud provider in order to provide value to clients

One of the biggest things I’ve seen people disregard when talking about vendor lock-in, is the fact that there is a huge advantage in leveraging these managed services for your own gain.

When considering the use of these managed services, development teams need to weigh up how much of an advantage these services provide and consider how much of a disadvantage they are subsequently put at by locking themselves into said service.

Building a service like this yourself would take years of work. With managed services, it can be done in a day!

If service X from AWS, or Azure, or GCP can provide you a massive advantage over your competition then it surely doesn’t make sense to avoid using said service because of vendor lock-in. If anything, by actively leveraging these services you may find yourself able to iterate faster with new ideas and push the bounds of what we are currently capable of.

If we consider the likes of AWS’ RDS, if we were to attempt to host our own database instance on an EC2 instance and manage this ourselves, we would end up spending hundreds of hours attempting to achieve the same level of resiliency, or performance that an out-of-the-box RDS offering provides.

This article goes into a more detailed comparison for self-hosted vs RDS:

MySQL Database Migration: EC2 Hosted vs. Amazon RDS

Conclusion

Whilst vendor lock-in is something you should somewhat consider when designing and developing your applications, I would put far more stock in the advantage of using said managed service as long as you understand its constraints fully. Being mindful of the fact that you are relying heavily on these services is far more valuable in the long run and can give you an edge should you leverage these in appropriate ways.

As it stands however, being able to remain fully agnostic of cloud provider is just not possible. More work will have to be done in order to provide that level of abstraction above said provider and at this point it’s just turtles all the way down.

Hopefully, you enjoyed these ramblings, if you don’t agree with anything or would like to add to this then please feel free to let me know in the comments section below!

If you’d like to support me then feel free to follow me on twitter: @Elliot_f or subscribe to my YouTube channel!

TutorialEdge

N.B — This article was peer-reviewed by my good friend Alan Reid so please @ him if you see any mistakes!

Cloud Agnostic Architecture is a Myth was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.