Further Thoughts on AWS Lock-in

In the last blog post, Bob Winding made some excellent points about the risk vs reward of building a data center in AWS.  For a more specific, non-ND perspective on this topic, take a look at this blog post, which actually categorizes AWS products by their degree of lock-in risk. It makes the very relevant point that most Amazon services are based on open standards, so lock-in is minimal. For example, Elasticache can easily be swapped for another hosted or even in-house hosted memcached server, and the only change required is to point application configuration URLs to the new location.  In the few cases where lock-in risk is greater, a consideration of the value of the service vs the likelihood of actually needing to migrate away may still make one inclined to proceed.

As Bob alluded, lock-in only becomes a problem when the service provider is either going away or imposing an egregious / unexpected financial burden.  Historical evidence indicates that neither scenario is likely to occur on AWS.  In fact, AWS Senior VP Andy Jassy stated in his Reinvent 2013 keynote that Amazon has reduced service prices 38 times since 2006.  Watch that video, and you’ll also see that they have a program that analyzes customer accounts to identify unnecessary spending and contacts those clients to recommend ways to reduce their footprint and save money. Amazon is looking to profit from economies of scale, not from gouging individual clients.

Furthermore, a concentrated move towards DevOps practices will naturally decouple us from our IaaS.  When it comes to building infrastructure and deploying custom apps, the more we automate with tools like puppet and capistrano, the less beholden we are to AWS.  Those scripts can be deployed as easily on a VM in ITC as they can in AWS.  This is why I’m taking pains in my boto scripts to separate configuration files from the scripts that deploy them.  The boto part may be Amazon-specific, but the configuration can travel with us wherever we go.

If we take a smart approach, we should be no more tied to Amazon for infrastructure than we are to AT&T for cell service.  And unlike AT&T, Amazon’s service is a lot more reliable, with no contract to sign.  There are many gains waiting to be realized with IaaS in terms of cost savings, operational efficiency, repeatability, and reliability.  Let’s not leave those benefits on the table for fear of vendor lock-in.

Comments are closed.