[gtirloni]

*> Even if you have nothing but everything hosted on a bunch of VMs, it can take years and millions of dollars to migrate.

I'd assume it takes fewer millions to migrate your own tech stack from AWS to somewhere else than it takes to migrate from AWS proprietary solutions. Is that reasonable?

[scarface_74]

No because you still have to deal with permissions, integrations with AWS services like networking, training, security audits, regression testing, often physical network connections (Direct Connect), DNS…

And you’re dealing with your PMO department, project managers, finance, security, contract negotiations, retraining your ops department…

And you know that Aurora MySQL instance that was suppose to prevent “lock in”? I bet you someone somewhere in your org thought about creating an ETL job and then said forget it and used “select into S3” to move data from MySQL into S3.

As a project manager trying to ship code so you can show “impact” to put on your promo doc, are you going to choose for your team to spend weeks to write an ETL job to prevent “lock in” or are you going to tell the developer to write that one line of SQL?

There are all sorts of choices you can make that will save time and money and ship features that actually deliver value instead of worrying about the boogie man of “lock in”.

And I really hope that there was some better technical reason than just saving $6 million dollars a year for a multibillion dollar company to go through the migration.

[gtirloni]

Thanks for the insights. So in the case that it's actually more expensive to migrate your own tech stack somewhere else than, say, migrate from AWS proprietary to GCP proprietary, it seems there might be other reasons.

[scarface_74]

The difficulty would be worse of course if you depend on anything proprietary from the cloud vendor.

But the main question is, once you do all of this work and spend time to be “cloud agnostic”, does it add business value?

In the case of Dropbox, it made sense to move from the cloud. In the case of Netflix, they decided to move to the cloud.

But you can’t stay completely “cloud agnostic”.

Let’s take a simple case of using Kubernetes and building the underlying infrastructure using Terraform.

The entire idea behind Kubernetes is to abstract your infrastructure - storage, load balancers, etc.

But eventually, you still have to deal with what’s underneath. I used AWS’s own Docker orchestration service for years - ECS. But I just learned Kubernetes last month.

I still had to know how to troubleshoot problems with IAM permissions, load balancers, view CloudTrail logs for permission issues, know how the underlying storage providers worked, make sure I had the right plug installed for K8s to work with AWS’s infrastructure etc.

Once I got all of that figured out, then I could go through the tutorials and mind map the difference between ECS and AWS’s Kubernetes implementation - EKS.

But I had years of experience with AWS. I could have never easily troubleshoot the same types of issues with Azure’s or GCP’s version of K8s. Now multiply that by an entire department.

Once everything is configured correctly, a developers experience would be the same across environments

Migrations at scale are always a pain from one system to another.

Source: I worked at AWS in the Professional Services department for three years. I’m mostly a developer and I dealt with the “modernization” side of “lift and shift and then modernize”.