Dealing with AWS Lock-in
Some people are concerned that, by using some of the AWS core (or for that matter, extended) services, they’re locked in to AWS for all eternity. That is to say, it will be difficult to shift an application from AWS if they use other AWS services. Though lock-in is a fair concern — and one that’s a perennial worry for IT organizations — I believe that, for most people, the benefits of using AWS far outweigh the issues presented by the potential for lock-in. This statement is true for these reasons:
✓ Acknowledge your concerns. When people use the term lock-in, mostare concerned that if they want to migrate their applications to another location, they’ll be unable to do so. My first recommendation is to accurately assess the extent to which your application is locked in — that is, how much your use of AWS services forces your application to run only in AWS. Several AWS services are useful no matter where your application runs. For example, Route 53, the DNS service, can be useful no matter where your application runs. Likewise, CloudFront, the AWS CDN service, can be used even if your application runs elsewhere. Infact, many applications that run in other cloud environments or within on-premises data centers use CloudFront. Consequently, it’s important to understand what and how much you’re truly locked in by your use of specific AWS services.
✓ Design for portability. Make it easy to migrate your application. One time-honored strategy for avoiding lock-in is to create and use an encapsulation layer rather than write directly to a provider API. That way, you can place another set of API calls within the encapsulation layer without disturbing the mainline code within your application. Given the fact that Amazon’s services tend to mimic other functionality that you can obtainby implementing software yourself (ElastiCache, for example), this strategy is fairly easy to pursue within your application, and it’s certainly far easier with AWS than with alternative PaaS offerings.
✓ Always understand both sides of the cost-benefit equation. People put up with lock-in because of the benefits an offering provides compared to the downside of a long-term commitment to the offering. Amazon offers tremendous ease of use and cost effectiveness, so perhaps incurring some lock-in is a trade-off that you’re willing to accept.
✓ Recognize the fear of financial gouging. The primary reason that people avoid lock-in is a well-founded fear of being taken advantage of,financially speaking. Traditionally, vendors, after achieving lock-in on the part of their customers, inevitably and rather ruthlessly exploited that commitment to increase their financial performance. Fees for forced upgrades, application modules that the customers had no desire for but were forced to pay for as part of a version upgrade, or arbitrarily increased maintenance fees are part of the litany of customer complaints about lock-in. Though there’s no way to predict what Amazonmay do, to this point its prices have always headed downward — people now pay roughly one-half to two-thirds for an EC2 instance than they did three years ago. Certainly, it’s always wise to be concerned about potential financial gouging, though it hasn’t been an issue with AWS.