And then you get yet another level of abstraction. It's about like developers who want to wrap all of their data access in a repository pattern just in case they want to change databases.

Two things about that -- hardly anyone ever changes infrastructure just to save a little money and their code has to be so generic that they can't take advantage of all of the features of the platform.

The chances are far greater that your company will go out of business way before Amazon stops offering AWS. Theory is great that Terraform allows you to seamlessly move infrastructure between cloud providers, but the amount of risk and regression testing it takes to do so would make it a non starter for most companies.

The idea I'm floating isn't not to use AWS, it's to not be locked into it. Don't use the things that only they offer.

This isn't just about cloud provider lock-in, but something you need to do to have a good DR strategy.

Back on that Christmas Day that Linode got DDOSed, my company was 100% on their infrastructure. I only had to work a couple of hours that day because I had worked and planned in advance to launch our infrastructure on another host. I saved my company from a multi-million dollar loss that day.

So if you're using AWS and instead of using their services, you're just hosting your own equivalents on EC2 instances, what's the point? The entire reason behind using AWS is the "undifferentiated heavy lifting" - allowing them to take most of the burden off of you except where your company can add value.

If all you're doing is hosting a bunch of VPS's, you're really not saving yourself too much over just using a bunch of colocated servers. You can also get much cheaper, less reliable, less geographic diverse hosting somewhere else.

But I would have my head handed to me if I even suggested to a company to base their entire infrastructure on Linode instead of AWS, Azure, or even GCP.

There isn't one way or reason to use cloud infrastructure. Maybe for smaller companies the "undifferentiated heavy lifting" narrative makes sense and I've used it as such in the past.

Managing tens of millions of dollars in physical and cloud infrastructure at multiple providers/dcs for a publicly traded company like I am now? No, that's not the reason to use cloud infrastructure at all. Cloud in this case is more about capacity planning and avoiding managing hardware inventory than anything.

You realize that this is exactly what Netflix is doing? They are using a lot of AWS services and have completely tied their fate to AWS.

That's not entirely true now but has been in the past. They've actually tied their fates to both AWS and GCE in different parts of their infrastructure. The obvious example of this is the one or two global outages they've had due to misconfiguration in GCE this year.

I know their video encoding platform is heavily tied to AWS because the teams that built it optimized for cost (which for them makes a certain amount of sense) and they massively parallelize the encoding work. I talked to some of their engineers at re:Invent last year and it was kind of interesting. They aren't using a lot of AWS-specific stuff though, just AWS EC2 reserved instances.

I don't think that just because they're Netflix that everything they're doing is correct. This can't possibly be true.

That's also what's attractive about Kubernetes - it's nearly a provider-independent cloud API.

What part of terraform is cloud agnostic?

Uh, the whole thing? Do you need a link to the documentation or something?

So you are saying if I take my AWS infrastructure, which I launch with my terraform config, I can simply use that same config to launch the same infra on GCP or DO? Didn't think so. It's only slightly more agnostic than AWS CloudFormation, in that I can at least use some of the same conventions when I completely rewrite my terraform files.

I think you are confusing "agnostic" with "compatible with lots of different providers", but will require a total rewrite if you want to switch providers.

I'm as big of a Hashicorp fanboy as you will ever find for on prem implementations -- I've used Consul, Nomad, and Vault. But that's simply not true. Here is an example of a Terraform template straight from their getting started page.

https://github.com/terraform-providers/terraform-provider-aw...

There's nothing preventing you from using other providers as well. You just have to understand how to achieve the same results when you build your modules.

So you have to rewrite your modules for each platform so you're still tying yourself to one vendor and that still doesn't alleviate risks from migration or the large amount of regression testing -- just in case Amazon goes out of business or you can might be able to find an equivalent slightly cheaper?

If you are a small company, the difference isn't worth the risk and the expense. If you are a large company you can probable negotiate with Amazon.

That doesn't even take into account all of the dependencies that your developers have taken on AWS services....