Signing on the dotted line with a cloud service provider (CSP) can lead to a dependence on that company in ways that are both observable and hidden. Walking into such a relationship with eyes wide open is essential.

As with nearly any major IT project, getting started with cloud computing creates a host of challenges. Some are obvious: security, control over data, proper infrastructure, staff expertise, compliance issues, and the impacts on the enterprise from changing routines to something new, among others. Another that should be obvious, but which isn’t always given due consideration, is the phenomenon known as “vendor lock-in.”

Lock-in has been an IT problem for years, but traditionally it’s existed in the context of relying too much on a particular piece of software to accomplish a core business function. Once an app has been put in place to, let’s say handle inventory management, it often happens that the software evolves as the vendor comes out with improved versions even as the enterprise using it also changes in response to its business environment.

Usually, these evolutions aren’t parallel. Gradually, the software remains useful to an enterprise only with some additional customization and tinkering or even modification of business practices to conform to some change in the software. The result after several years can be that the app “still sort of works” for a business using it, but the enterprise has tolerated this problem because the alternative of looking for (or building) a new solution was considered more painful and expensive than putting up with a jury-rigged “Old Faithful.”

Commoditization of software apps in recent years has altered the nature of software maintenance contracts and apps, so for a while lock-in had begun to fade as an IT concern. Cloud computing, however, has brought it back.

Reviving Traditional Problems While Creating New Ones

CSP lock-in occurs when the user enterprise thinks the cost of changing to a new provider can’t be recovered in a reasonable time, such as one to two years, and the enterprise lapses into a “better to stick with the devil I know” stance. Those costs can have a variety of sources.

Some of the concerns are “same ol’ same ol’” from the days of proprietary app-based worries. What happens if the CSP goes out of business (or more likely, gets bought out by a bigger CSP)? What if the CSP suddenly raises its rates exorbitantly? What if Quality of Service declines unacceptably? What if dependence on one vendor limits our enterprise’s ability to adapt and grow? How difficult will it be to modify apps supported by the CSP as time goes on? What if the CSP changes its service offerings in a way not compatible with our enterprise’s needs? If we did change providers/software, how many of our employees (users or engineers) would find their present skills obsolete? Would they be open to retraining, or would they depart for another company where their skills were still pertinent rather than having to learn a whole new system?

CSPs pose all these challenges even as they generate new ones unique to cloud computing, some of them deceptively subtle. A key concept to remember is that while CSPs are ostensibly in business to provide a standard service, where they really make the big money is in customizing their offerings for use by individual enterprises. Custom solutions written while relying on cloud storage or cloud access can easily be made too dependent on some underlying proprietary technology used by the CSP. Such customizations might not operate on another platform if the CSP changes some underlying service or if the enterprise finds itself wanting to use the services of a different CSP later.

There’s a similar problem with using APIs provided by the CSP. Each customization or unique API adds one more feather to the pile of problems that could suddenly appear on the balance scale if the enterprise finds it necessary to change CSPs in the future. And that’s not to mention how changing CSPs might affect user access or conveniences like Single Sign-On.

Likewise, utilities provided by a CSP to help users manage their cloud setup might be dependent on some aspect of the CSP’s virtual infrastructure and therefore won’t work in another environment. There may be some other aspect of a CSP’s virtualization environment that will make it difficult to migrate to another CSP should the need arise. Most disturbing of all is the fact that it’s still ambiguous who actually owns data that resides on a CSP’s servers or that’s in transit between the enterprise and the CSP. If a dispute with the CSP arises, it’s conceivable that the CSP might try to gain leverage by holding the data hostage. (A CSP probably couldn’t get away with this for long, but what if it were a couple of weeks until things got resolved? How’s that for feeling “locked in?”) This data problem holds true even if you have a hybrid cloud and are using multiple CSPs. In that case, who owns what data when can become even murkier.

Finally (not that we’ve exhaustively covered all the potential pitfalls), if an enterprise does decide it needs to change CSPs, there can be more hefty surprise expenses. The three major providers (Amazon Web Services, Google Cloud, Microsoft Azure) all charge a fee for transferring stored data to another provider, which can be equivalent to several months of regular service charges. On top of that, depending on the format in which the data is stored, a handoff of data to another provider might not even be possible without some kind of mass conversion of the data’s format. You can bet a CSP your enterprise is dropping won’t be doing that for free.

Unlocking the Handcuffs

Resolving these potential issues starts with a single idea: No matter what CSP your enterprise chooses, your relationship with them will not be permanent. At some point, even if it’s years from now, you’ll likely have to switch, so you need to plan on that. This has numerous implications.

Right off the bat, there needs to be an internal CSP exit plan from the very start, and enterprise stakeholders need to understand it, even if it’s not used, because it might be.

You’re not going to want to sign a standard service contract. You’ll want a unique one that includes most or all of the following.

Avoid a long-term agreement. Two years is probably plenty. Yes, the CSP will use that as an excuse to raise prices, but they can more or less do that anyway, and you’ll have some leverage at renewal time if there’s some aspect of service you’re not using that you’d like to stop paying for or something you’d like to add.

This agreement, being blatantly temporary, needs to include language that spells out how and why you can make an exit. The CSP needs to pledge to support your enterprise’s migration away from it and define what services the CSP will provide to facilitate this migration when it occurs. Define who owns what data under what circumstances and what data cleansing might be needed how often at what price. Ask for standard rather than proprietary features and avoid as much app customization as possible. Include the costs and procedures for all add-on services, and specify all system requirements. Ask for a pay-as-you-go pricing model.

Be sure you’ve explored all the services a CSP offers and specify only those necessary. The process of screening CSPs needs to be ongoing in tracking market developments so your enterprise can best take advantage of opportunities it has with a window of flexibility not that far away. Consider the ramifications of leaving a particular CSP before you even sign up. In fact, it would be best if you had an acceptable alternative CSP in mind even before you actually sign with someone else.

On the Technical Side

Make your apps and data as portable as possible. Use open-source code so apps can interface more easily with other cloud-based code and app functioning isn’t so dependent on anything proprietary to the CSP. Use an abstraction layer to interface to any proprietary technology so that if migration becomes necessary, only this interface needs to be modified. Break apps into modular form so that if changes are needed to migrate, there are likely to be fewer places in which app code needs modification.

Strongly consider using a multi-cloud deployment. This will mean you have more CSPs to interact with over the long haul, but it will also help make your enterprise less dependent on a single service provider. As much as possible, have apps use generic functions that are more likely to be interchangeable no matter who your CSP is. Overall, you shouldn’t let your search for a CSP be dependent on the idea you might be using just one provider. Best serving your enterprise means finding the best apps for your situation, even if they are offered by different CSPs.

Urge the programming staff to use container technology, for example Docker, which enables bundling together of the app itself with its associated libraries and configuration files, as well as letting app components share a single OS kernel and other benefits. Open-source containers will need a platform for orchestrating and managing them, such as Kubernetes. This would be an additional expense, but it will likely be less than emergency remediation efforts if your environment isn’t optimized for probable later migration. Keep data portable and store it in open-source formats so it can be ported more easily to another environment. Consider using DevOps to better integrate software development and operations teams and Infrastructure as Code (IaC), which enables IT infrastructure management via configuration files.

Similarly, you’ll want to use an open-cloud architecture because it best supports a hybrid cloud approach (which will by definition be using multiple CSPs). A hybrid cloud also helps keep your data local. Back your data up to a local server, keep a copy of the latest backups on hand, and move data to the cloud only when it’s needed to support a particular cloud app.

Branching Out

Depending on your enterprise’s app and data needs, further investigation of some additional technologies might be in order. Snowflake offers data-warehouse-as-a-service for cloud environments, particularly if your cloud data storage needs are extensive, as does Amazon’s Redshift. Amazon’s Kinesis Data Firehose is a means of delivering streaming data in realtime to multiple destinations. Flexera One creates visual displays that help in planning cloud strategies, controlling IT assets, and other functions. HashiCorp’s Terraform is a different IaC from DevOps that helps users build, alter, and manage infrastructures. Scalr works with Terraform to manage cloud platforms. Snow Software’s Embotics is a cloud-management platform for hybrid clouds, as is Morpheus Data. If Kubernetes is in your future, Giant Swarm can help manage that environment, as can Rancher, as well as Cloud Foundry. If artificial intelligence is a plan for your enterprise, check out DataRobot.

Cloud computing is still morphing into what it will become later. If you set your initial CSP contract to two years, likely by that time there will be an even larger universe of alternative strategies and products that can serve your enterprise’s cloud app management needs. Don’t let yourself get locked in to a single provider by inadequate consideration of alternatives and too much hurry to find a solution that seems to work for now but may incidentally make you too dependent on a single service provider.