AWS Summit London 2013 - Why OpsWorks?

Last Tuesday I attended the annual Amazon Web Services Summit 2013 in London, at the Business Design Centre.

It was the first time I had actually been to an Amazon event, and for the most part it was good, it was interesting to hear some of case stories of what companies and what people are already doing with AWS. Likewise, the types of services and products that Amazon has begun is already shipping around AWS is what puts them as the forerunner of cloud solution providers.

Although some of the break-out sessions at the summit demonstrated that I clearly have a limit to how long I can watch someone click through an interface to show me it’s “kick-ass” features. Nevertheless, as with any product that needs to sell or expo you attend, everything was marketed with an eerie level of flawlessness and buzzwords were thrown left, right and centre, as there tla’s (Three Letter Acronym’s).

There were, however, a couple things that stuck out to me both good and bad, but one in particular stuck out like a sore thumb.

Amazon OpsWorks

Now if you’ve not heard of it, Amazon OpsWorks is suppose to be a DevOps solution for managing applications on AWS, and features configuration management, application deployment, monitoring and all the bog standard goodies that come with managing a stack in the cloud. It looks and feels like the remnants of Scalarium, which was made by a company called Peritor (that Amazon acquired back in 2012, no surprise there) and is pretty cool to mess around with. Now at first it seems like a very logical move for Amazon to do this, but thinking this through two points started to dawn on me.

• Chef works under the hood of OpsWorks and Amazon have forked an older version of Chef, and have now managed to create a non-open source proprietary, service orientated version of it.
• Amazon have now basically offered developers a choice between doing everything on Amazon via Amazon, or using 3rd party technology to manage their AWS offerings (you don’t have to be a rocket scientist to see where the majority will go).

These are the tell-tell signs of vendor lock-in, and it is clear more developers, systems administrators, managers and the like are being made to be more and more reliant on Amazon and AWS. This is clearly a problem because the more you design your application to tailor specifics of a Amazon platform, the more harder it will be to migrate away if Amazon if decides to change its system (which I’m hoping they won’t but hey, this is the world of technology).

Not to mention that by offering a service which some Amazon partners already operate if not have whole business models around, they are essentially giving them a middle finger, royally.

But I guess we’ll just have to see how this all pans out.

Must suck to be RightScale or Puppet right now.