Appfog Takes On Amazon Lock-In With OpenStack | Hacker News Reader

Appfog Takes On Amazon Lock-In With OpenStack

gigaom.com

19 pointszeroecco11 comments

I feel Amazons lock-in is further reaching then just switching providers. As plenty of vendor applications (PaaSs) have latency issues outside of ec2.

That said, OpenStack itself is pretty awesome.

I don't understand how AWS services keep being described as 'lock-in'. Shouldn't this post be titled: Appfog Offers Alternative to AWS With OpenStack?

I'm inclined to agree. The whole point to AWS, and in fact the reason for it's success in the face of determined competition from AppEngine, is the fact that the virtual hosts are "just Linux boxes" and that S3 is "just static file storage". Cloning those interfaces (or architecting an app to be portable across equivalents) really isn't difficult at all.

The rest of OpenStack is just cloning the administrativia, honestly. Only the most rigorously scaled AWS app, for instance (I'm thinking about things like Reddit here), is going to need the programmatic ability to spawn EC2 hosts, etc... At the startup scale, that's just bandwidth you'd be better off spending on your product's value, not cost savings.

So, I'm all in favor of OpenStack. But I don't think that cloning Amazon's API is going to win anyone any business. You have to beat them on price and quality. We'll see.

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.

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.

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.

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.

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.

Actually, the programmatic ability to spawn EC2 hosts is great in-the-small, for testing - you want to do an upgrade right? Spin up a fresh instance (or five), do your chef/puppet scripted deploy, load balance five percent of your users to the new one... watch for problems, don't see any? crank up the knob... once you're 100% on the new one, hold on to your rollback option for a bit, once you are confident in the new one - poof turn off the old one. Depending on how often you do releases, you can have an awesome safety net for maybe 10% more than your baseline instance cost... get a new developer? "here, run this script, now you have your own copy of the product to screw around with - when you get something working, push your changes"... basically there's a lot more value to that automation than just autoscaling.

That sounds useful. But you could do the same thing in a VM (or seven) on your desktop. It might be useful in some circumstances, but it's certainly not a requirement to deploy a working product. No one would choose to be locked in to a vendor because of that alone.

Vendor lock-in is a real issue in terms of pricing and downtime: http://gigaom.com/2011/09/24/5-ways-to-protect-against-vendo...

Reply on news.ycombinator.com