A cloud agnostic Fata Morgana
I would like to start with a word about cloud agnosticism. Probably one of the many questions that popup when embracing the cloud is about multi-cloud. Is it something to take into account? Something to keep in mind while outlining your architecture? Bottom line, is multi-cloud worth the effort?
A multi-cloud setup has some significant downsides. A big trade-off is losing native features, to be more precise, a multi-cloud setup limits services and features to the lowest common denominator.
Furthermore, it shouldn’t be a theoretical exercise. A multi-cloud setup deployed only to a single provider while just applying ‘the philosophy’ of cloud agnosticism is like buying a pig in a poke.
I think a cloud-agnostic setup is a Fata Morgana. It’s not something I aim for. I find more value in developing cloud-native for a platform. Even more, at the application level, I don’t see any reason to avoid vendor lock-in. If there’s ever a need to move an application to another platform, it will cost time and money. It’s a given.
Note: there are always exceptions to a rule. Sometimes it’s a fundamental requirement to be cloud-agnostic. For such projects, there are specific platforms and tools like Spinnaker. Those are not the kind of applications I’m talking about in this paragraph.
Vendor lock-in safeguard: Loose coupling and multiple accounts
As described above, I prefer coupling applications tightly to the platform they run on. IMHO, the disadvantages of that strategy do not outweigh the advantages. Loosely coupled services on a higher level in combination with a multi-account setup is what you need to avoid vendor lock-in.
Prerequisite: a Microservice architecture.
If you’re still stuck with a monolith, then sorry, I’m afraid the story stops here… You see, the first requirement to prevent a vendor lock-in in the cloud is a microservice architecture. On top of that, those microservices need to be spread across multiple accounts. That approach is the best safeguard against vendor lock-in. Let’s visualise things as a picture is worth a thousand words.
Avoid one big account holding all tightly coupled microservices:
Microservices spread over multiple accounts but still tightly coupled:
Loose coupling to the rescue
A second requirement to avoid vendor lock-in is loosely coupling microservices between accounts. Microservices that don’t run in the same account should be coupled as loosely as possible.
Side note: the number of microservices per account can vary. A large microservice can live alone in a single account, others can be grouped for example, by their bounded context (DDD).
The issue with tight coupling
An architecture where services are tightly coupled will inevitably result in A Big Ball of Mud. Instead, microservices in different accounts should never communicate using proprietary technologies. For communication, those services should only rely on the public internet, for example, using HTTPS. Put those services behind a load balancer or API gateway and avoid network peering, SNS, SQS or other closed source solutions.
I can’t stress enough the importance of the public internet in the equation. While coupling services on the network layer doesn’t seem a big deal first, in reality, it is. Coupling on the network layer locks you tightly on a platform.
If inter-account traffic doesn’t go over the public internet and a service needs to move, then the migration workload spans the following:
- Make the service publicly available by putting a gateway or load balancer in front of it
- Review the security setup. Firewall, security groups. management access, WAF, …
- Review authentication and authorisation
- …
But the devil is in the tail. The above is true for the entire dependency tree of a service. Worst case the changes ripple through your complete infrastructure. 😓
Multiple accounts and Loose coupling
With services across multiple accounts and traffic running over the public internet, you create the luxury of flexibility. Where one big account holding all your services will most likely force you to follow an all-or-nothing strategy, the multi-account architecture with loose coupling allows converting accounts one by one. In fact, a service that’s publicly available over HTTPS is cloud-agnostic. To the world, services designed as such could run anywhere. For those services, the underlying technology doesn’t matter, all that matters is how they communicate.
Multi-account enables multi-cloud.
As a bonus, a multi-account setup is also an enabler for multi-cloud. If a particular service is a misfit for your primary cloud provider, nothing withholds you from deploying the outlier to another cloud. As long as they communicate over the public internet, you can sit back. 💪
So to guarantee yourself a smooth transition to a new horizon would the need arise, I recommend going for a microservice architecture in a multi-account setup with inter-account communication over the public internet.
Enjoy and until next time!