Why don’t you like AWS ?

This is the first question people ask me when I talk about redundancy and reliability in conferences or meetings. First of all, the issue isn’t with AWS (they have excellent performance, support, and prices). The problem lies with any “cloud provider.” However, AWS is like:

  • SAP when people think about ERP.
  • MS Office when people think about of Office Suite.
  • MS Windows when people think about Operating System.
  • VMware when people think about Virtualization.
  • Cisco when people think about Networking.
  • Starbucks when people think about coffee. ;-)

In other words, I use AWS as a reference because it is currently the most popular option and the one CEOs probably hear about in the news alongside “the cloud”. :-)

So, what is the problem ?

The problem is all the tools or services that a particular cloud provider offers to us for free or at low prices when used with ten other tools. These tools are nice, easy to configure, and work well. However, every time you use a tool from a specific cloud provider, you create a dependency or “vendor lock”.

Today, with Infrastructure as Code (IaC) and the ability to quickly and easily create all your infrastructure using code that connects to a cloud provider and deploys everything automatically, if you use a tool from a specific cloud provider, your IaC will only work with that specific provider.

Still don’t see the problem ?

Let’s say you have IaC that deploys your infrastructure automatically and quick in a specific provider. That’s great (good for you). But what happens when your cloud provider experiences an outage and remains down for 4, 12, or more hours (which can happen more frecuentely than you think see links above )? Does your company accept the idea of being offline, or would it be better to temporarily or permanently migrate to another cloud provider?

The answer is obvious, but if you have chosen to use a specific tool from your cloud provider, that tool won’t be available on the secondary/backup cloud provider. Now you have a significant problem because you depend on the cloud provider to fix the issue and get your company online again.

Note: I highly recommend thinking and working in a multi-cloud or multi-provider environment. A multi-cloud environment is part of many NIST/ISO and other certification standards. So when the audit comes knocking on your door, you’re already prepared for it. :-)

Alternatives

I don’t know the exact percentage (since I don’t know all the tools from every cloud provider), but I’m confident that almost all the tools provided by our cloud providers can be replaced by our own services. Let’s take some basic examples with three cloud providers and three tools:

Amazon Google Azure Some Alternatives
Router53 Cloud DNS DNS bind, powerdns, maradns
EKS GKE AKS Openshit, Kubernets, SaltStack, Rancher
RDS Cloud SQL SQL PostgreSQL, MariaDB

The idea is to replace these cloud provider tools with a VPS or container (usually I recommended VPS) and install and configure your services inside it using your IaC.

It’s true that you may have more tasks to do, but if you spend a little more time creating a good initial Cloud Provider “Agnostic” Configuration, migrating from one cloud to another shouldn’t take more than the time it takes to run your IaC scripts (a few minutes) when necessary.

Conclusion

As I mentioned, my problem isn’t with a specific provider but with the idea of creating a dependency of my company on a specific provider. It’s a dependency that will continue to grow every day until it becomes impossible to move away from that provider (you become trapped).

In summary, it’s not that I dislike AWS or any specific provider. It’s about avoiding the potential pitfalls of relying too heavily on a single provider. While AWS offers excellent performance, support, and competitive prices, it’s essential to be cautious of the vendor lock-in that comes with utilizing their specific tools and services. By working in a multi-cloud or multi-provider environment and leveraging Infrastructure as Code, you can maintain flexibility and mitigate the risks associated with downtime or service outages. This approach allows you to adapt and migrate to alternative providers seamlessly, ensuring the continuity and reliability of your company’s operations.

Remember, it’s always prudent to assess your options, consider alternative tools and services, and strive for a cloud-agnostic configuration that enables easy migration across different cloud providers. By doing so, you can safeguard your company’s future and avoid being overly dependent on a single cloud provider.

Some Outages Problems:

AWS - 4 hours downtime

Google Cloud - 4 hours downtime

MS Azure - 11 hours downtime