Vendor lock-in -- it's the bane of many a cloud deployment. We all know the age-old IT dilemma: The more use an organization makes of a particular vendor's products or services, the more dependent it becomes upon them, and, in turn, the more difficult it becomes to change providers. Even when staying with an existing vendor, this leads to reduced leverage during contract negotiations; the vendor knows it's expensive and painful to transition to one of its competitors, so it raises its prices knowing it's the lesser of two evils.
The vendor knows it's expensive and painful to transition to one of its competitors, so it raises its prices knowing it's the lesser of two evils.
This reduction in leverage is problematic for a cloud deployment because many times leverage is the key (or in some cases only) "currency" we have at the negotiation table. Cloud vendor lock-in means having little or no leverage when angling for security-relevant services and features; for example, when asking for new security controls, requesting better reporting for security events, asking for adjustments to security operational processes, increasing transparency to audits or any number of other security and compliance adjustments, we're at the mercy of the vendor.
So, obviously, preventing cloud vendor lock-in is a useful goal. But there are some practical realities that can put IT at a disadvantage in doing so. First, IT may not always be involved in a cloud deployment at the outset (i.e., before a contract is signed). This means the opportunity to require that service providers employ open standards (which has a significant impact on lock-in) may already be gone. After a relationship is established, economic realities make lock-in hard to mitigate. Specifically, requesting additional budget after a deal is signed is challenging because many cloud initiatives are driven by cost savings. As a result, budgeting in the additional cost of changing vendors later can be a tough sell.
The good news, though, is that there are a few steps that you can take to proactively combat cloud lock-in at little cost. This isn't to say that there's no cost involved (there will always be, after all, soft costs like staff time to account for), but because these strategies don't require going back to the well for additional budget, they can be useful as a way to work against situations that might otherwise result in vendor lock-in.
Periodically test data export functionality
Assuming you have the contractual right to do so, the first thing you can do to prevent cloud vendor lock-in is to test the service provider's ability to export any data held in its trust. If the vendor makes the claim (either contractually or in its advertised service capabilities) that data is yours and that it will provide the data to you (on request or at the close of your relationship with them), testing this capability has a few benefits.
Periodically testing the data export functionality helps you understand the export process in practice (not just in theory). This gives you clarity on a few different operational aspects of doing this: how long it'll take, who has to be involved on the service provider side, any additional costs that might be required, what format the data will ultimately arrive in, etc. If costs will be incurred to export your data -- for staff time on their side or other professional services fees -- you may decide not to continue the exercise since you may not be ready to actually incur those costs. However, at the very least you'll know that those costs exist (and have some idea about the amount) so that you're not caught unawares should you actually decide to leave a cloud provider.
Periodically run this exercise if data exportation costs are manageable. In much the same way that periodically conducting a restore of backup tapes allows you to know that the backup process is working appropriately, any changes to the export methodology (such as a different data format, different export mechanism, operational changes, new fees, etc.) will become readily apparent.
Use open APIs
The second thing you can do is rigorously enforce open standards in new integration efforts. You may not be able to require that a vendor employ open standards internally for its offering (at least not once you've entered into a relationship), but you can enforce this when it comes time to discuss new integrations. Now, the specifics of which APIs are in scope will obviously vary depending on a few factors: the specific cloud model you employ, your use of cloud as a whole, the type of integration you're discussing and so on.
For example, if you wish to transfer virtual machine images between your internal virtual data center and an Infrastructure as a Service provider's cloud, you might require that the exchange take place using open standards like the Open Virtualization Format. This ensures (at the very least) that the service provider is capable of producing the image in a format you can import to your platform of choice at a subsequent time. In a Software as a Service (SaaS) context, you might specify the use of SPML for user access provisioning. The specific standard in scope will vary, and there are quite literally too many to mention here, but the point is that enforcing an open standard means that another vendor can more easily come in and fill the role of your current provider. This is also valuable in insulating your organization should your service provider unexpectedly cease operations.
Read maintenance updates and service bulletins
You'd be surprised how rare it is that organizations thoroughly read the service bulletins issued by their cloud services providers. It's also surprising what you can learn from them. They can be the primary vehicle for vendors to inform you about critical service changes. Aside from potentially having an impact on the security of your data generally, these service changes could also impact your ability to migrate away from that vendor.
More about cloud vendor lock-in
As an example, say a SaaS vendor decides to apply encryption to a column in its database. Chances are it would notify you of this fact via a service bulletin, release notes or maintenance update. You might have some very pertinent questions about this: Will the provider decrypt that data when it exports your data upon contract cessation? If not, will it provide access to the keys so that you can do so? Someone should be reading these notifications carefully -- and with a critical eye to how changes might impact your portability.
By no means are these the only strategies you can employ to prevent cloud vendor lock-in. However, these strategies are relatively low cost (at least, most of the time) and they're reasonably easy to accomplish. If you already have a comprehensive plan to avoid vendor lock-in (most shops don't), these can help you round out that plan. If you don't have such a plan, these strategies might help you get part of the way there while you're formulating a more comprehensive plan for later on down the road.
About the author:
Ed Moyle is currently director of emerging business and technology for ISACA. Moyle previously worked as senior security strategist for Savvis Inc. and as senior manager with CTG. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.
This was first published in June 2013