Lock-in: Using cloud-neutral technology to avoid it

In this guest post, Gary Bloom, CEO of database software supplier MarkLogic, explains why adopting a cloud-neutral strategy is essential for enterprises to avoid lock-in.

Not so long ago, choosing a single cloud provider seemed a sensible approach. But as the market has matured, enterprises are realising how easy it is to become locked in to a single provider, and the downsides that can bring.

According to market watcher 451 Research, some organisations are mitigating the risk of vendor lock-in by adopting the operating principle of ‘AWS+1’.

The analyst firm believes 2017 will be the year CIOs move to adopt cloud services from Amazon Web Services (AWS) and one other competing provider to ensure they are not locked into a single supplier or location.

This approach offers greater flexibility to match applications, workloads and service requests to their optimal IT configurations.

But even playing two providers off each other might not allay the risk of lock-in, as Snap’s public filing revealed in February this year.

The company, which owns of the messaging app Snapchat, plans to spend an eye-watering $2 billion on Google Cloud, its existing provider, as well as a further $1 billion on AWS over the next five years.

In its regulatory filing, Snap exposes the real impact of changing cloud providers with words that should send shivers down the spine of any CIO.

“Any transition of the cloud services currently provided by Google Cloud to another cloud provider would be difficult to implement and will cause us to incur significant time and expense,” the document states.

“If our users or partners are not able to access Snapchat through Google Cloud or encounter difficulties in doing so, we may lose users, partners or advertising revenue.”

This alarming note demonstrates the risk of lock-in even with two cloud providers. Snap is also considering building its own cloud infrastructure but this presents similar risks.

The creep of cloud lock-in

IT departments may be wary of lock-in, but it can happen without them realising it. It starts as soon as someone decides to use the cloud provider’s proprietary APIs to reduce the amount of coding required to launch an application in the cloud.

For example, when developers write software for Amazon’s DynamoDB database they are being locked into AWS.

Although it is unlikely that you will want to move workloads back and forth between clouds, there is a high chance you will want to deploy it in another cloud at some point. At this point, it can prove a lengthy and expensive process to rewrite the application.

The solution is to design cloud applications with cloud neutrality at their core, underpinned by cloud-neutral database technology that works across every cloud provider and on-premise.

With a cloud-neutral approach, you are not tying your fortunes to those of your cloud provider, and you are also able to play vendors off against each other to get a better deal.

In a sign that cloud neutrality is coming of age, SAP recently announced that it is making its HANA in-memory database available across all the major public cloud platforms, as well as its own private cloud, to give its customers the opportunity to switch providers.

Other enterprise ISVs are likely to follow suit in time, but none of us can predict how the cloud market will evolve long-term and cloud neutrality keeps the door open. So, when an alternative vendor launches a new service or specialty that is more suited to your needs, you can switch with relative ease.

Being cloud neutral is an effective insurance policy in an age when it seems that nobody is immune from the threat of cyber attacks. If your cloud provider has a breach, you want to be able to move to another provider quickly.

CIOs have not forgotten the dark days when datacentre outsourcers held enterprises to ransom and nobody would willingly make the same mistake in the cloud. With cloud neutrality at the heart of your strategy, you can have the peace of mind that comes from future proofing your business.