Hacker News Reader

Comment by personZ | Hacker News Reader

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.

View on HN

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.

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.

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.

Reply on news.ycombinator.com