...in exchange for a number of different problems including (in no particular order): severe vendor lock-in, mediocre to acceptable performance, and relatively high cost per unit of performance.
Which component on AWS doesn't have a OpenSource counter-part that you, having the time, knowledge (;P) and time for it, could not implement on your own infrastructure?
Really... It's an honest question from some one that works as Senior AWS architect on a full time job.
You ship your product, get some customers. Fast forward 18-24 months. You have grown enormously, you have lots of customers and revenue projections and expectant investors.
Your (now much larger) engineering team has gotten used to AWS conveniences and leveraged a lot of them in the development workflow. Your architecture consists of several layers of ELBs, you have painstakenly set up autoscaling and deployment via Elastic Beanstalk. Your server backups are AMIs. Your data lives in RDS (analytics in Red Shift). Your webservers use Elasticache. SQS is the backbone of your asynchronous job workflow. Customer email traffic goes through SES. Etc.
Now your AWS bill is something like $25-30k/month. You're at the point where the pricing differential between real hardware and AWS is getting big, and it will only get worse over time.
Now management has to make the hard choice:
- Build an Ops team capable of architecting, constructing and deploying new infrastructure on bare metal
- 3-6 months of work to go from design to final cut-over
- Risk some business interruption in the changeover (downtime, unexpected problems) and slower development iteration until the engineering team gets used to new tools/ways of pushing code out.
or
- Continue on AWS and eat the bill as cost of doing business.
This is vendor lock-in at the most basic level.
Until you're at the point where it's on par with hiring a dedicated Ops team, $25-30K/month will really feel like a drop in the bucket.
This is why so many of us are happy to accept our AWS overlords.
I can maybe see where those latter amazon specific services are a lock-in. But I still don't see it that way, really. They aren't a lock-in from the perspective of the code if you put everything behind service interfaces with different implementations. The big guys like Azure and Google Compute all have similar services for DB as a service, blob storage, VMs, etc.
But the act of migrating to something like Azure is just generally a lot of work in ensuring 0 downtime and a smooth transition. That's hard no matter what technologies we use.
And we've talked about it. But just the act of moving is, in my opinion, a multi-week migration process with load tests etc.
And the cost savings would have to outweigh the amount of engineering costs of moving.
All this to say, the real lock-in is lack of dissatisfaction in our situation. "Amazon works well enough for us."
If you don't have the skills, you can migrate to another provider like Heroku.
As far as my experience, they aren't extending PG in non-compatible ways.
That said, CloudFormation, SQS, Kinesis, DynamoDB, etc. are all very sticky services.
Those VMs can absolutely run almost anywhere, and they can connect to just about any instance of pgsql. I heavily use many services on AWS, but can quite literally move the entirety of it to my own servers, Google, Azure, or elsewhere in very short notice. People can choose to use some of the more unique services, but that is not related to RDS.