Isn't AWS much less prone to customer lock-in? May be I don't have experience with tweaking AWS under heavy high load, but 98% of code I write for backend that I host on Amazon isn't specific to AWS or it's services in any way.
We thought we'd be okay.
But when AWS started getting too expensive and we began looking to migrate, we discovered that there was a lot of 'glue' in our stack using bits and pieces of AWS-specific services. A continuous integration was using S3 buckets and Lambda, a few clever devOps guys had found ways to create alarms with SNS and SQS.
So while 90% of it was just a matter of moving to general CentOS containers on another platform and spinning up new Postgres and MySql and Mongo instances, that 10% of AWS specific code still causes issues that had to be remedied.
If I were in charge of a large infrastructure on AWS, the first thing I'd do is absolutely lock down every service that wasn't explicitly whitelisted, and open them as needed. Not wait till half your operation depends on dozens of AWS services that, while make things easy initially, lock you in to their platform.
The ones that should be 100% motivated to develop these tools (the Apache ones are ... meh, and terraform/ansible/config management always gets hard-wired to your cloud) are obviously Google and others that are also-rans.
Google might not be doing it to keep Amazon out of their roadhouse.
There's still meta-tooling for admin and management that are hard to abstract, but come on. K8s is the opportunity to do this, and also serverless to a lesser degree.
Just because AWS spent years both creating an alternative to Oracle and millions migrating, doesn’t mean that your company is.
No matter how often some bushy tailed developer tells the CTO that they used the “repository pattern and standard sql”, they aren’t going to move away from their six figure+ Oracle installation. The risk of regressions are too high and the benefits are usually not worth it.
You see patterns like this from “architects” who want to avoid “lockin”:
- A DBFactory that creates an instance of an OracleRepository that they access through an IGenericRepository interface just in case later on they decide to use a different database and then they don’t take advantage of any Oracle specific features for fear of “lock in”.
- A StorageManagerFactory that you call to create a S3StorageManager that implements an IStorageManager just in case later they decide to move from S3 they can “migrate easily”
You’ll find people who will spin up a bunch of EC2 instances and host their own logging, queueing, messaging servers to avoid using AWS specific services. Now they are spending more for hosting than just going to a colo and spending just as many man hours babysitting infrastructure.
I’m saying that once you choose your foundational infrastructure pieces, no matter what they are, it usually makes sense to go all in instead of creating layers of abstraction.
Things listed as lock in with AWS usually have easy migration paths. E.g. DynamoDB integrates with Database migration service and Lambda functions are easy enough to expose by shifting code to dedicated servers.
A lot of the lock-in is historical. Before there was Kubernetes, there was ECS. I am sure a lot of people embraced containerization and not managing individual machines early, and are now stuck on Amazon's proprietary platform.