[title 1] Don’t Get Locked into an Outdated, Unresponsive Cloud Service [title 2] Simple Steps for Preventing Cloud-Service Lock-in [title 3] Plan Ahead to Avoid Being Locked into an Outdated Cloud Service <!—short summary –>
Consider the cost of migrating your apps and data to another service before you sign up for any cloud service.
<!—long summary –>
It may not be foremost in your mind when negotiating an agreement with a cloud service, but eventually you’ll face the task of migrating your cloud-hosted applications to a new platform. The best way to sidestep the high cost of moving your organization’s valuable data resources from one cloud service provider to another is to calculate the cost of migration before you sign on the dotted line.
Application programming interfaces are the glue that bind modern computer systems together. That’s the good news. The bad news about APIs is that they can also bind you to a particular vendor’s service. Vendor lock-in can undo many of the benefits of APIs in delivering fast access to data resources by preventing you from being able to take advantage of new and enhanced technologies.
In a November 2015 article, TechTarget’s David Linthicum identifies three benefits of using API-based cloud-native services:
Linthicum lists three ways to avoid being locked into a vendor’s proprietary APIs:
The risks associated with relying on a single cloud-service provider include potential price increases and the high cost of migrating data and apps to an alternative service. Source: Dan C. Marinescu, via Slideplayer.com
Watch out for these cloud-contract gotchas
In just a few years the cloud-services industry has been transformed from simple month-to-month “user-based” contracts involving non-mission-critical “edge” applications to long-term agreements for the provision of “cloud suites” comprised of multiple data sources, workflows, and APIs. Constellation Research’s Ray Wang writes in a November 3, 2015, article on ZDNet that per-user, per-month pricing (PUPM) has given way to complex usage-based pricing set by a range of business metrics, including number of employees, revenue generated, gigabytes used, and number of connections.
As cloud-service contracts become more complex, the dangers of vendor lock-in increase due to three reasons, according to Wang:
Wang lists six components of the software ownership lifecycle as it applies to cloud contracts:
Technology isn’t the barrier – migration cost is
When it comes to cloud services, you have to consider the cost of exiting at the same time you think about the cost of entering. Linux Journal’s Jack M. Germain writes in a November 13, 2015, article that for a number of reasons – mergers, expansions, realignments – data eventually has to migrate. For example, the service may offer its own private API for use to access certain premium offerings. When you build such APIs into your code, you limit the ability to export the data to another service.
When determining the portability of your cloud data, consider being locked into a platform or a cloud vendor, reliance on proprietary tools or features, and “feature creep.” Source: Netflix, via Slideshare
On the other hand, tools are readily available for moving data and apps between Amazon, OpenStack, and VMWare. The solution is to engineer your software to exist outside any particular cloud service: Always maintain a version of your apps that doesn’t rely on any of the service’s custom processes.
Germain lists four ways to prevent vendor lock-in:
A methodology that is both simple and safe is to create a platform-agnostic layer between your apps and various services’ APIs via a management dashboard such as the Morpheus self-service app-management system. Morpheus shields you from unanticipated data-migration costs via out-of-the-box integration with OpenStack and Amazon Web Services, as well as Open REST APIs for integration with heterogeneous systems.