...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.
I really don't get all this yadda yadda about AWS lock-in.
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.
Imagine you're an early stage startup. You have a handful of overworked, stressed-out engineers trying to ship v1.0. You don't have the time or resources for a dedicated Ops team, so you go with AWS (I think this is a great use case for AWS or any public cloud, btw--it just makes sense at a really early stage startup).
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.
Ultimately this is a good problem to have, no? Your startup is alive and growing, you can afford an ops team, your product proved itself. Most startups will have been dead for years at this point.
> 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.
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.
We've been running mostly VMs all this time on our app (Windows, SQL Server, Linux w/ Rails), but have been using more and more ACTUAL AWS services (SQS, DynamoDB, Redshift).
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."
Different problems, but vendor lock-in isn't really one of them imho. If you are skilled enough to setup pg instead of using RDS you can always move off it to systems under your control.
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.
I don't personally get the RDS value proposition, but how does it lead to vendor lock-in, much less severe vendor lock-in? I don't believe there is really any lock-in whatsoever -- backup your database and move it wherever you want, whether you're running the pgsql, Mysql, or SQL Server variants of RDS.
While of course you're correct, it's a bit like saying "you can just pack up your code and run it somewhere else". If the entire architecture and workflow are based around proprietary AWS tools (Elastic Beanstalk, Elastic load balancers, RDS, Cloud Formation, autoscaling, etc) even if your code is technically portable, you're still suffering from vendor lock-in. Arguably worse than the bad old days of the Microsoft monopoly.
RDS is just a database though. All the standard tools work with it. Unless you start dipping into more exotic services, it's pretty hard to become locked in. EC2+ELB+RDS are fairly independent. Even autoscaling doesn't lock you in.
That said, CloudFormation, SQS, Kinesis, DynamoDB, etc. are all very sticky services.
Where you see 'vendor lock-in', I see the opportunity to leverage somebody else's engineering talent to solve commodity problems that our customers don't pay for.
That's a bit of an extrapolation though, isn't it? Many people simply run VMs that connects to some arbitrary pgsql instance, which might happen to be on RDS if they want to simplify the management of that.
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.
