Hacker News new | ask | show | jobs
by bmelton 5156 days ago
Some people are using EC2 far beyond 'hosting a website'. If you're leveraging the EC2 interface to stop and start instances on demand (say, to power per-user instances for an application) then you're 'locked in'.

DynamoDB could be equated to Mongo or Redis, but it isn't either one of those exactly, so the switching cost is slightly higher than if it were.

SES is basically there to replace standard SMTP, but it isn't standard SMTP, so the switching cost just went up a little more.

Beanstalk is (as I understand it, could be way off here) similar to Glassfish or Weblogic (for Java), but again, isn't quite, so your switching costs go up again.

Etc., etc.

I don't necessarily disagree that lockin doesn't just happen, you get there by choosing to leverage non-standard components, vs. standing up another instance and running Mongo or SMTP, etc., but it's hard to make the decision not to leverage those things when they're there, available, and look and feel similar to the tools you need, but aren't.

2 comments

Isn't this like saying by choosing Oracle as your database you are 'locked in' to it vs. MySQL? I'm locked-in to OSX right now typing this on my Macbook Air.

I think the phrase lock-in should apply only when a vendor makes it purposefully difficult to get your data out of their system only so you keep paying them, not when you freely opt-in to their service since it is the best choice for you at the time.

Lock-in is a function of the time and effort it takes to move to an alternative solution, not just the data but the entire system.

Think of beanstalk, think of the dependence on proprietary queuing systems. The more services you use, the more locked-in and the harder it is to decouple your systems from AWS.

The lock-in is not visible if you think of AWS as EC2, the lock-in is how hard it is to build your apps dependent on all the AWS services and try to move anywhere else.

To an extent, but I don't know of too much development happening these days that aren't done with some sort of framework (at least for web apps), and I don't know of any frameworks that aren't built to at least support an SQL abstraction layer.

The one big app I have on EC2 isn't 'locked in' to Oracle because we're using Django + Oracle, though in testing it out, there is a non-zero effort to migrate to another database.

That said, you're not entirely wrong either, which is why such abstraction layers exist, and even despite how good many of them are, migrations are still non-trivial.

Some people are, no doubt. And those are Amazon-only solutions that produce lock-in. But the vast majority of AWS users are just on vanilla EC2 and S3, and could fairly easily port to any "virtual linux box" solution, or even to physical hardware, if the need arose.

They're on AWS because they like it, not because they're locked in.