[lewaldman]

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.

[bkeroack]

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.

This is vendor lock-in at the most basic level.

[akurilin]

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.

[hkarthik]

> 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.

[gfodor]

Congratulations, you're rich and now can pay someone else to deal with this.

[bkeroack]

Do you seriously think that a two year old startup (in the scenario proposed) is "rich"?

[atonse]

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."