Everybody knows you risk being locked in when you migrate your apps, data, and systems from your own data center to a cloud service such as Amazon Web Services, Google Cloud, or Microsoft Azure. The thing is, cloud lock-in doesn’t bear much resemblance to the Oracle/IBM/Microsoft kind of lock-in.
For one thing, the benefits of a single provider’s resources and management/analysis tools could far outweigh any extra data- and app-migration costs. For another, new ways to export and share data break down many of the proprietary-API barriers. However, while you own your data in the cloud, the cloud provider owns the underlying code – the platform. If the company changes strategy for whatever reason, you’re affected.
When you look deeper into claims of cloud lock-in, you find that while the phenomenon exists, it is in nearly every case voluntary. The organization made a conscious decision to commit to a service’s proprietary APIs for the cost/performance/security benefits, knowing full well that doing so made switching to a competing service more difficult, more time-consuming, and more expensive.
There are numerous examples of companies that leverage multiple cloud services in a way that makes “lock-in” work for them. In a February 29, 2016, article, Forbes Alex Konrad describes the decision by music streaming service Spotify to use Google Cloud as its infrastructure provider rather than Amazon Web Services or Microsoft Azure. A big reason why Spotify chose Google was the data-analysis tools the company offered, even though Spotify was already an AWS customer.
Spotify staff will depend on Google’s proprietary analysis apps, which means switching to another system will likely entail its analysts learning to use new business-intelligence tools. Some retraining is to be expected as part of any move from on-premises data operations to a cloud service. For Spotify, the advantages offered by Google’s attentive, “engineer-to-engineer” customer service outweigh the expense of learning another new interface.
The Door to Amazon Web Services Swings Both Ways
Most of the talk about cloud lock-in focuses on Amazon, and for good reason. As Fortune’s Barb Darrow reports in an October 8, 2015, article, numbers from research firm Gartner indicate that AWS accounts for 10 times more compute capacity than its next 14 largest competitors. AWS worldwide marketing VP Ariel Kelman stated at a recent AWS:ReInvent conference that the company has no intention of locking in customers the way Oracle, VMware, IBM, SAP, and Microsoft have been accused of doing in the past.
Of particular concern to many AWS customers is “data gravity,” which is the cost and difficulty associated with relocating any data. Still, there’s little worry when using basic EC2 compute and S3 storage, according to conference attendees. It isn’t until you add workflow, messaging, databases, and other higher-level services that lock-in comes into play.
AWS’s Kelman claims the company avoids lock-in by allowing its customers to choose the services they want to use rather than insisting they use any particular combination. With Amazon Aurora, for example, companies can clone their in-house MySQL databases in the cloud, as Comcast does. Yet the ever-quickening pace of technological change means today’s behemoths are tomorrow’s dinosaurs. And CIOs don’t want to be collateral victims of the next technology extinction event.
Avoid lock-in by choosing your tools wisely
Even when you factor in the “data gravity” premium that applies wherever your data resides, it is rarely the data itself that limits your ability to migrate to other systems and services. As MapR Technologies’ Jim Scott writes in a January 20, 2016, article on the Smart Data Collective, you’re locked into a product or service not by the data but by the tools you use to manage and analyze the data. In particular, relational databases that conform to industry standards are often accompanied by the vendor’s own toolset, which likely has both standard and non-standard components. Once you depend on those non-standard tools for everyday data management, you’re locked in.
Of course, you always have the option of not using those specialized tools, whether by choosing their standardized counterparts, or by opting to go with another service. In nearly every case of lock-in, the lockee made a conscious decision to accept the locking in exchange for the cost and productivity benefits the vendor’s specialty tools provide. Perhaps the best example of this voluntary lock-in, at least in the cloud space, is the Hadoop framework.
The Apache Foundation offers an open-source implementation that features standard APIs, including the Hadoop distributed file system (HDFS). While the three leading Hadoop vendors have each created their own implementations of HDFS that are incompatible with those of their competitors, you can still use a standard Hadoop tool such as distcp to migrate your data between these “non-standard” file systems.
Scott points out that Amazon Redshift and other proprietary APIs offered by the company entail a degree of lock-in. By contrast, Google BigTable implements the open HBase API that anyone can implement. For many customers, the benefits of proprietary APIs and analysis tools in terms of cost, ease of use, and performance make any resulting lock-in a small price to pay.
New services hope to make vendor lock-in a thing of the past
AWS Lambda delivers the ability to deploy applications without having to manage server, storage, and database capacity manually – what TechCrunch’s Ron Miller calls “the world of the serverless app.” In a November 24, 2015, article, Miller writes that Lambda reduces deployment times to milliseconds by using single-action triggers that process in parallel or sequentially.
By atomizing application components into interconnected triggers, AWS Lambda reduces deployment times to milliseconds.
Triggers are flexible enough to be used for a range of purposes, and they can be created using many popular development tools. Most importantly, you pay for only the compute resources you need at any given moment. Your apps scale up or down as conditions require.
Efforts are underway to broaden AWS Lambda’s appeal by extending the service to any cloud provider, as well as to in-house data centers. One such program is Iron.io’s Project Kratos, which is intended to allow Lambda functions and Docker container workloads to be deployed in a stateless manner for porting to any platform or service. Silicon Angle’s Mike Wheatley describes the project in a February 15, 2016, article.
The project’s goal is to implement Iron.io’s RESTful API in a “runner agent” that monitors the work queue and stores data about pending jobs, including whether the jobs finish. The apps manage all other associated data manually. As Wheatley points out, the obvious downside is that rather than being locked into AWS Lambda, you’re now locked into Iron.io’s API.
It isn’t quite having your cake and eating it too, but you can realize the benefits of non-standard APIs while minimizing the degree of vendor lock-in by isolating the APIs via an abstraction layer. In a November 2015 article on Tech Target, David Linthicum describes cloud services governance as a way to enforce policy in the use of all cloud APIs and services. You do so by placing an abstraction layer between the service and the people who manage and use the service. Because the same rules apply to the use of all the services, switching between them is easier and less expensive.
An alternative to governance-specific API management is use of a comprehensive cloud management platform, which focuses on the storage, compute, and database services themselves rather than the interfaces to the services. Still, the simplest way to avoid being locked into particular vendors is to stick with the open-source OpenStack, whose APIs are consistent from distribution to distribution.
Good reasons for giving your cloud provider the boot
No matter how much time, effort, and money you’ve spent on your existing cloud services, you have to be prepared to move on once you determine that you can get a better deal elsewhere. In a March 8, 2016, article on Information Age, Ben Rossi lists four reasons to fire your software vendor.
Like any other aspect of running a business, choosing a cloud service – or more likely a collection of complementary cloud services – entails a cost-benefit analysis. It also requires that you consider your exit strategy at the same time you plan your implementation, maintenance, and upgrade strategies. Interfaces are center stage in today’s increasingly distributed networks, moving such attributes as openness, connectivity, and flexibility to the top of features list.
