IT has been dominated by the big name companies for decades, but their grip is loosening as more and more organisation see them as restrictive and poor value for money. Those IT companies who have failed to adapt to the new more flexible, lower cost ways of working, are suffering from a declining market share. Open Source has helped, by providing greater choice at a fraction of their cost, but the next generation of ‘big IT’ is fighting for the new digital market, but this time with an online, on-demand, pay-as-you-go model.

The names have changed, but are we now smart customers with more choice and therefore has vendor lock-in been cast out into the annuls of historical mistakes?

Before we explore the main topic of this article, we have to ask the BIG question: do we care about vendor lock-in?

In my working life I get to talk to a lot of decision makers, and they in turn give me a range of responses on the subject… here’re a few (and yes, they’re real!):

“It took us 10 years to get away from supplier XYZ and cost us millions, never again!”

“It’s something I’m managing on a case by case basis and I ask lots of questions before we commit to anything, but you always have a level of lock-in with a supplier”

“I know the regulator says I have to show that I’m not locked into a vendor, but it’s a risk I’m prepared to take to get to market quickly”

So, there’s a general acknowledgement that there’s a risk and there’s no prize for guessing who I think has the right approach!

The above examples are from real-life discussions around Cloud vendors and it’s this aspect of vendor lock-in I want to focus on.

The migration to Cloud is now in full swing, with many organisations opting for either a full or hybrid approach. There’s been a lot of debate on ensuring systems are ‘Cloud Ready’ and what that should mean, so here’s my contribution.

Cloud is most efficient and cost effective when systems are built out of small components, such as those found in Micro Services Architectures (MSA). This is because each service can be easily replicated when demand for that service increases and scaled back when demand subsides.

Small simple services = small compute resources = cheap and fast / easy to replicate.

Big monolithic complicated systems = lots of compute resources = expensive and slow / complex to replicate.

That’s kind of it – well, apart from managing state and sessions across your MSA based systems, but you knew that!

The big Cloud vendors provide IaaS, not PaaS, so what you get is a kit of parts you need to then orchestrate and integrate to create your platform. That kit of parts is getting very extensive, to the point where you can in theory just write your product code and let the vendor deal with all the complex platform issues around common components, scaling, availability and of course security and compliance. But there’s the rub, it’s complex to orchestrate and integrate your code with their components and when you’re done, it only works on that Cloud provider and you have to keep your fingers crossed that they don’t break stuff when they upgrade something!!

When you’ve spent all that time and effort in building your Cloud systems that’s kind of it, right? Wrong! As I said earlier, you still need to manage the impact of upgrades and updates to things like databases, messaging systems or SDKs, as well as your normal systems, infrastructure, security and compliance management and monitoring.

Ask yourself another question; what happens if your Cloud vendor loses a service you’re dependent on, which happened to users of Azure and Google recently (see here), or experiences a Cyber-attack, which happened recently with AWS (see here). What’s the impact on your business and your business’s reputation? It could be at the very least extremely embarrassing – or worse, you could get a fine or even sanctions from your regulator… To be fair, the big Cloud vendors are great at keeping things running, better than most tier 1 banks… But bad things do happen and with the increasing options provided by the Internet, bad stuff is happening more and more!

So what happens if I want the choice of running my system in my choice of Cloud provider or my own datacentre?

Good question, glad you asked it!

The MSA approach is just as valid for any Cloud service as it is for traditional hosting, but if you’ve made use of a specific Cloud vendor’s components, you will run into a significant amount of investment and effort to replicate it in another Cloud vendor or your own datacentre. Or to put it another way; congratulations, you’re locked in, time to write the three letters! (If you don’t know that joke, message me and I’ll send you a copy).

So you’re locked into one of the major Cloud vendors and again, I can feel some of you saying to yourselves, “so what?”…

Maybe with the current state of the market that’s still a risk worth taking, but do you want to bet the future of your company on the likelihood of that current state being maintained?

Technology is changing at an increasing rate and some of that change has previously brought about new opportunities for competitive advantage in terms of cost, flexibility and new capabilities. Think about the changes that have occurred in the way we consume media content such as music and video, and how rapidly some of those changes came about… Will the Cloud vendor you are locked into maintain its competitive edge in the areas you need?

My point here is that for short term gain, you put at risk your medium-long term competitiveness through loss of flexibility, differentiation and cost control. The industry has been here before; let’s learn from history!

As a company, we have been working with our clients to help mitigate the vendor lock-in risk, and as a result we have devised three rules of thumb that hopefully you will find useful;

1. Architect generically, but design specifically. If you architect to meet your availability, scalability, reliability, regulatory and of course security requirements at the logical level, ensure it can be implemented in any Cloud vendor or even a traditional datacentre. This will help to minimise the risk of vendor lock-in from the beginning. The detailed design should adhere to the architecture but be specific to the implementation – namely the IaaS type you are utilising.
2. Use a risk-based approach – For each vendor component you are considering using, plus an aggregate view across the vendor components, identify the following:
   1. Is it mature and available from internal resources/other vendors or is it proprietary?
   2. Can it be implemented in a very similar way?
   3. Does it impose any constraints on your desired implementation?
   4. If you needed to change vendor, can you quantify the time, skills and resource required to swap?

Then, with the answers to these questions in mind, simply ask yourself; is it practical to swap or is it too difficult, costly and time consuming such that other more pressing priorities would mean that it would never happen?

• Automate everything – you will never fully mitigate the Cloud vendor lock-in risk unless you use automation to minimise the impact of making a change. And it (hopefully!) goes without saying: don’t use Cloud vendor proprietary automation tools. With independent tools like Ansible and Terraform you minimise the learning curve and therefore the overall effort in swapping vendors. It’s also true that unless you have tried to do a swap at least once, say in a PoC, you can’t truly understand the real effort and impact.

If you want to work up a few examples and see how the above works in practice, get in touch – we’re happy to share our experience!