BitCan/Morpheus: How to Avoid Cloud Lock-in

[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:

1. They provide your applications with such advanced capabilities as auto-provisioning, auto-scaling, and direct database access.
2. They improve performance by avoiding abstraction layers and the need to translate platform-specific calls to access storage and compute services.
3. They offer native security, compliance, and management services, albeit in a proprietary manner that can conflict with internal processes and established links to partners.

Linthicum lists three ways to avoid being locked into a vendor’s proprietary APIs:

1. Apply specific policies to your use of APIs and services by adopting cloud-services governance, which creates an abstraction layer between APIs and the app-management team.
2. Implement a cloud-management platform that complements the governance layer by focusing on specific resources (rather than the interfaces to the resources): storage, compute, and database services.
3. Use an open-cloud platform such as OpenStack, which ensures that subsequent API releases will be consistent with their predecessors.

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:

1. Buyers get access to and use of the service’s functions, but the underlying code belongs to the service, which means buyers are at the mercy of the service’s decisions whether to alter or enhance their offerings.
2. As time passes, it becomes more difficult and expensive to switch service providers, in large part because you can’t always export the business processes instantiated in the vendor’s environment.
3. Vendors who are initially motivated to attract new customers by offering great deals grow complacent over time, particularly as a greater percentage of their customers’ data is migrated to the cloud.

Wang lists six components of the software ownership lifecycle as it applies to cloud contracts:

1. Customer experience: What the client expects from the vendor
2. Selection: The options that will be available to the client
3. Deployment: The level of service the vendor will provide as the client implements and uses the service
4. Adoption: The level of support the vendor will provide the client as the service is extended throughout the organization
5. Usage optimization: How the vendor will support the client’s changing needs through the duration of the contract
6. Renewal: How changes and extensions to the contract will be accommodated and implemented

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:

1. Use services whose API supports a range of cloud providers.
2. The services should provide an abstraction layer between your code and its custom APIs.
3. Keep your apps as plain-vanilla as you can to make it simpler and less expensive to switch services.
4. Ensure critical apps are always available by taking a hybrid-cloud approach that moves non-critical apps to the public cloud while keeping your most important operations in-house.

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.