Press "Enter" to skip to content

Avoiding Cloud Service Provider Lock-in

The case for moving IT systems to the cloud is compelling. The is due to the ability to cut the capital costs associated with purchasing your own data centre and the revenue costs associated with managing and maintainance.

Take a look at Microsoft’s recent market cap. In November 2018 it surpassed Apple to become the world’s most valuable company. This is largely due to Microsoft’s re-focus on its cloud platform, Azure. Clearly, it’s a lucrative market, so it’s no surprise that the tech giants are fighting it out for market share (Microsoft Azure, Amazon Web Services & Google Cloud). So how would a cloud service provider (CSP) look to increase market share? One strategy is to make it easy (on customers) on the way in, and hard on the way out (aka lock-in).

What can CSP customers do about this? One option is to focus on a lower level infrastructure as a service (IaaS) service model. Under this model, the customer buys low-level services such as virtual machines. At this level, it is relatively easy to buy a like for like service from an alternative CSP, hence the lock-in overhead is greatly reduced (i.e. it is possible to buy a Windows virtual machine from both Microsoft Azure and Amazon Cloud Services). However, the IaaS model is not ideal as it loads a lot of overhead and responsibility on the customer. The alternative platform as a service model (PaaS) is better for reducing overheads, but it is often hard to find a direct equivalent across CSP’s.

Under the IaaS model, the customer buys low-level services such as virtual machines. At this level, it is relatively easy to buy a like for like service from an alternative CSP, hence the lock-in overhead is greatly reduced (i.e. it is possible to buy a Windows virtual machine from both Microsoft Azure and Amazon Cloud Services). However, the IaaS model is not ideal as it loads a lot of overhead and responsibility on the customer. The alternative platform as a service model (PaaS) is better for reducing overheads, but it is often hard to find a direct equivalent across CSP’s. Therein lies the catch 22 – is it possible to get the benefits of PaaS whilst escaping the associated lock-in?

Take a few examples;

Single Sign-On (SSO);
Microsoft offers Azure Active Directory B2C, whereas Amazon offers Cognito. The IaaS equivalent is installing a product like Thinktecture’s Identity Server onto some cloud infrastructure (and managing yourself).

ESB (Enterprise Service Bus);
Microsoft offers Azure Service Bus, whereas Amazon offers Simple Queuing Service (SQS) and Simple Notification Service (SNS). The IaaS equivalent is installing a product like Rabbit MQ onto some cloud infrastructure (and managing yourself).

One strategy for reducing the lock-in to a particular PaaS solution is to try to work with standardised features. For example, if working with Azure Active Directory B2C, stick to working with known / modern authentication and authorisation protocols such as OAuth 2.0 and Open ID Connect. This will make it much easier to migrate, if you need to.

Unfortunately, sometimes it’s not as simple as that (due to lack of standards in a particular domain). Take the ESB example, although the concept of queues, topics, subscriptions and notifications would appear to be pretty universal, I’m not aware of an associated standard. No doubt, pushing a new message onto a queue in Azure Service Bus is going to look quite different to doing the same thing in Amazon SQS. In this scenario, particularly where this service will have many dependents in your solution, it is worth considering implementing a facade layer, in order to standardise the interface to dependents. This way, if you need to migrate, you only need to replace the facade, and not all of the dependent services.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *