Monsters' essay - The monster of cloud vendor lock-in

1. Abstract

Cloud vendor lock-in could occur with the technologies of large public cloud service providers, without affordable breaking out possibilities for clients. Author's opinion is the phenomenon is plausible but will not significantly slow down expansion of public cloud adoption. Author attempts to cut the cloud vendor lock-in monster into pieces and provides concrete actions for management and mitigation, one being App In The Sky fixed-price cloud strategy creation service. This is a 1 hour read.

2. Backdrop

Initially I thought to avoid this topic since it’s already addressed on the web. The other articles left me with an impression vendor lock-in is seen as a or even the monster which slows down the unstoppable seeming public cloud business model. I don’t buy that, but cloud vendor lock-in is still worth an examination.

I’ve worked for CA, Cisco and HP so I definitely know what vendor lock-in is, lol. During the time working as a CEO of a small reseller company I got to work with EMC. As you might know, they were formally called EMC2. It was said EMC2 stands for “Extra Money Charged twice” - perfect capture what vendor lock-in means.

3. Methodology

I’ll ask four questions and then try to answer them:

• What is vendor lock-in?
• What are, if any exist, the likely circumstances or situations of cloud vendor lock-in?
• What would be the impact of such lock-in, meaning why should you even care?
• How do you in practice avoid vendor lock-in for public cloud?

4. What is vendor lock-in really?

There is theory and academic thinking put into cutting of this elephant. Suggest to visit Wikipedia page on the matter at https://en.wikipedia.org/wiki/Vendor_lock-in.

A vendor lock-in simply means you are dependent on a vendor, and you are unable to use another vendor since you would incur substantial switching costs, but there are several facets to vendor lock-in.

Vendor lock-in can be monopolistic in nature, meaning only one provider controls the market. Within IT, monopolistic vendor lock would be especially nasty to work around if it would be held up by something abstract or difficult to work around. Key to the monopolistic definition is to be locked into the vendor, not into technology.

The other form of vendor lock-in is collective. There you would be locked in together with somebody else. In economic theories, you would have a cost to resist the dominant choice. The somewhat contrary to cost to resist could also happen to you - you might witness positive network effects where you see the value increasing according to the number of others using the same thing such as a certain public cloud.

A technology lock-in is a circumstance where it’s not about scarcity of vendors or monopolistic situation, but rather you end up in a lock-in as a consequence of your own actions. You might have chosen Microsoft Skype since so many others are using it. If you’d want to get a rid of Skype, you might lose contact or have some hindrances in contacting others. According to The Independent’s definition, the more society adopts a certain technology, the more unlikely users are to switch. An economic concept of sunk cost might have an effect on your decision, and that is typical with IT – you have sunk cost in your investments to server hardware, that makes you locked-in into onprem technology.

Table 1. Vendor lock-in types.

5. What are the circumstances of cloud lock-in?

I find it useful to identify possible vendor lock-in aspects on the macro or industry level, as well as in a micro, per-client view. I’ll copy with pride judgment from TV show “Mythbusters”, so my vendor lock-in situations are either “Busted”, “Plausible” or “Confirmed”. Here are first the findings crystallized in a table and then same in written format.

Table 2. Public cloud lock-in circumstances.

5.1 Monopolistic view

As for the monopolistic vendor lock-in on macro level, I think we’re in the clear for public cloud. There are several large providers on the marketplace. There is also a sense the governmental watchdogs would prohibit corporate mergers and acquisitions which would create a single dominant player. How true that is if it would be tested against some nation state interests, we don’t really know, but still I call this “Busted”. I’ll get back to the biggest players when I discuss technology vendor lock-in.

Two non-visible vendor lock-in monsters on macro level are patents and IPR infringement disputes. Some public cloud item could get patented and you are asked for a fee to use it, or you get to use the item free of charge in service A but need to pay dearly on the same thing in service B. These situations are difficult to foresee and mitigate, not much empirical. You can find articles on the net with some concerns on this, hence it's “Plausible”.

Cloud patents are not yet looking you in the eye but you'll find articles on the net with some concerns on them. There are already some patented items around cloud file storage services.

In a per client monopolistic investigation the picture is different, there are three circumstances which I discuss:

• the provider changes its offering to cloud only delivery method
• latency or other telecommunications specific circumstance
• the higher level of cloud nativeness, the higher probability of vendor-lock in

Gartner and others are saying many ISVs (Independent Software Vendors) will soon have a cloud-only delivery model. If it’s a small ISV, the situation doesn’t really constitute a vendor lock-in, you simply choose another provider. This would be “Busted” - although I recognize some clients’ difficulties in finding enough SaaS providers for smaller niche solution areas. Public cloud is not a plentiful bazaar for you if you’re an airline and if the consumer-oriented though excellent FlightRadar24 app (we are planespotters at home so this is really our household’s ERP system) won’t satisfy all your needs, so a lock-in within vertical-specific context is “Plausible”.

But what if it’s Microsoft, IBM or SAP? I would be surprised if there is by some contract or agreement a promise from these companies they would continue forever to sell you software as a license. It would not take much to seriously limit your choices. Microsoft has been developing all sorts of Active Directory resources into Office 365 and Azure and the company has several offerings already which are cloud-only, isn’t the writing already on the wall for AD? Another example is the yet-still-to-come RDmi Remote Desktop modern infrastructure by Microsoft, that seems to be all cloud based. I mark this as “Plausible” for vendor lock-in.

The latency / telecoms specific aspect has not been a consideration for us Finns, since all big players have been equally non-existent from Finnish soil - until now. Google is supposed to open Hamina datacenter within few weeks. I’m originally from Kotka which is the neighboring city to Hamina, and even have relatives living in Hamina.

Google is to open their Hamina, Finland datacenter for public cloud use within few weeks, that's public knowledge. But did you know they’ve attempted many times to merge the neighboring cities of Hamina and Kotka into - Kotham City.

Suppose you build an application with less tolerance for latencies and get it up and running in Google Hamina datacenter. Then if, and only if, Amazon and Microsoft don’t build a datacenter in Finland, you’ve managed to create yourself a monopolistic cloud vendor lock-in for Google. Latency is difficult to circumvent since it’s about light speed. There’s a belief the payable public cloud direct connections ExpressRoute and Direct Connect would solve the latency issues, but generally they don’t, they only make the pipe even-quality and dedicated. If the application just barely works from Google Hamina as far as latency is concerned, it might not work at all from AWS Frankfurt or Azure Dublin.

And the telecoms making a possible vendor lock-in don’t apply to Google alone. For Azure Backup, Microsoft does not charge on the downstream traffic from Azure. Downstream traffic from Azure Backup downstream traffic would be restore traffic, potentially a customer in peril, so no charge. But if you install another backup software to Azure, then it’s just ordinary downstream traffic, and you will get charged on it (unless you have Unlimited ExpressRoute costing an arm and a leg). This does not necessarily mean a complete vendor lock-in to Microsoft-provided backup, since this is just a single use case. You would probably tolerate this vendor lock-in since you’re anyway backing up artefacts in onprem with your existing backup software and would adopt Azure Backup separately for artefacts in public cloud. But extending your existing backup software to Azure would be a busted choice.

As soon as you opt for higher value Platform as a Service components, your options to move off later get much more limited. I come to a “Plausible” conclusion on lock-in for that. Especially if you require the new AI, ML, cognitive or even quantum computing APIs and capacities from public cloud, then it’s surely a “Confirmed” situation since you’ll have technical hindrances quite difficult to work around. You probably can’t even afford to procure AI, ML and those things from two CSPs just for the sake of vendor lock-in avoidance.

5.2 Collective view

It’s contemporary to rely on ecosystems, in another words, on a set of interconnected providers. This can be viewed from both angles. If you’re the client, you are locked in if the ISVs you use play a certain public cloud exclusively. Or if you’re the ISV, you could be tied to the public cloud choice of your client. I find the collective form of vendor lock-in “Plausible”. For an IT department, forcing decisions on an ecosystem which typically spreads over diverse internal interests and stakeholders could really be a pain even if it would be for common good. The decision you might need to force upon the ecosystem is the result of your RFP you held between Amazon, Microsoft and some others.

In these ecosystems, it’s obviously less about the fear of vendor lock-in and more about enjoying the gains, these positive network effects. I do believe in their existence, up to some point, their softness and non-contractual non-measurability nature is what bothers me. As I’ve written in other long reads, fun is good business and if an IT ecosystem makes at least a bit of fun out of the day to day IT, then it’s good enough for me. But for an organization, fun might not be sufficient to cover for the tangible adverse effects from a collective vendor lock-in if they take place. Whilst it provides some protection via access to skills, the ecosystem won’t completely shield the client from vendor lock-in, therefore I call it “Plausible”.

5.3 Technological view

The technological vendor lock-in myth I “Confirm”. Clients are keen to go for the dominant choices in general, but that’s especially true in the case of public cloud. Many enterprises endorse AWS and Azure, but if it’s some other CSP, the “foreign” CSP has a substantial burden of proof.

For a recent internal public cloud concepts training I did some work on trying to understand how clearly (or badly) the public cloud is concentrated on few hands (or onto two pair of hands), and here’s how it plays out according to mid-2018 data.

• As a whole for public cloud, Gartner stated in April 2018 they expect the top10 CSPs to account for 70% of the IaaS market by 2021, which is up from 50% in 2016.
• Synergy stated in July 2018 that the top5 control 75% of the market, and that the sequential growth is at the hands of just four providers (AWS, MS, Alibaba, Google). IBM’s hanging in there, these four mentioned ones are growing at an enormous pace.
• Synergy also states there are only three medium sized cloud providers who are growing, but none of them have broken the 1% market share threshold.
• If we believe the latest Rightscale 2018 State of the Cloud Report and why shouldn’t we, 68% of enterprises have adopted Amazon and 58% Azure - all other CSPs are below 20%.

This paints picture of a four-horse race where the two last are already one lap down. Maybe we’ll have a duopoly for public cloud, and that’s then really via our own choices.

6.?How is the monster banished?

Here’s first a table of what I propose as remediation and mitigation, and then some further vendor lock-in exorcism in wording.

Table 3. How to avoid / mitigate the identified vendor lock-in scenarios.

You should lay out a cloud strategy and include in it how you are going to avoid vendor lock-in. While doing that, the most important thing is not what the Amazons, Microsofts and Googles of the world do, but what you do. You always have the choice to just accept the vendor lock-in, but even that ticked in a box in a document is good practice.

Seek to understand the cloud contracts within this vendor lock-in context. Try to understand your rights and provider responsibilities when the contract ends and what technology or artefacts you can assume to be able to use afterwards. Even if you think you can’t get anything changed, think of it as your due diligence. You might deal with smaller CSPs with which you can negotiate.

For IPR and patents, your and CSPs responsibilities for them are often in the “Indemnification” section of the contract. I’ll use Google as an example, take their Google Cloud Platform Terms of Service section 14 “Indemnification”. It states in 14.1 “By Customer” that you will defend and indemnify Google in “any Third-Party Legal Proceeding to the extent arising from: (i) any Application, Project, Instance, Customer Data or Customer Brand Features; or (ii) Customer’s, or Customer End Users’, use of the Services in violation of the AUP.” On their part, 14.2 “By Google” “(a) Google’s technology used to provide the Services or (b) any Google Brand Feature infringes or misappropriates the third party’s patent, copyright, trade secret, or trademark”.

So where did open source go? Kemp IT Law has identified this “carve-out” as problematic, I just made note of it. You might also want to look into AWS Customer Agreement section 8.5 “Suggestions” which is around your responsibilities towards AWS in certain circumstances and section 10 “Disclaimer”. Difficult to pinpoint what you should or could do, just want to keep reminding you again on the need to read the contracts.

You want to avoid circumstances where the impact of vendor lock-in would be too severe. With this I mean if you’re that airline and you buy the timetable planning software from the cloud, make sure you have at least some alternatives, so you can utilize your buying power in a tender. If a single SaaS provider gets bought by another company from a country under embargo, your business might stall. Avoid desperately going to cloud within application areas where there are too few CSPs, then don’t go to cloud on that solution area or build a custom application.

For IaaS, prepare yourself on mental level that one day you’ll swap from one to the other, and think backwards what you need to do for that. A good answer on how to do the swap is to get to know some of the many migration tools out there. I’ve looked at Cloudamize and think it’s decent in providing the planning and dependency mapping on what you have. I’ve also looked at Vision Solutions CMC portal, that’s not half bad either. Just note the world is not perfect - you might need to install agents or like in CMC’s case, open whole lot of ports to make the tool work.

If the mere planning doesn’t meet your risk avoidance requirements, then procure deliberately from several similar CSPs. While doing that, avoid creating for yourself a cloud vendor lock-in with inadequate integration. Do the whole 9 yards with both of the two giants and/or possibly Google or Alibaba. Include ITSM and other system management integrations, i.e. if you are a ServiceNow shop, remember to integrate it with every chosen CSP.

If whilst your cloud planning you’re transforming or building applications from scratch, you might decide to not need containers, but they do make perfect sense from cloud vendor lock-in perspective. That’s the case not only in a cloud to cloud scenario, but also in a cloud to onprem “bare metal” scenario. Perfect would be if you have decent server and storage hardware in onprem to form an internal pre-owned “bare metal” environment. Even if it didn’t have a valid service contract, you could use it in emergencies.

I’ve heard these smaller ISVs recommending everything’s a microservice. That looks like everything is built by the ISV separately and against a particular public cloud. Suppose you then run the “everyone against everyone RFP” on the big four CSPs and the outcome is Alibaba. How do you then make the changes to all these microservices? Well, that’s easy, you always had that in the contract with your ISV, right? Can you think of insisting the microservices to be transportable between the two-three main cloud services, or at some fixed fee or at some percentage of total cost. Technical possibilities for that include mandating an abstraction layer to be created for example via the so-called IaC Infrastructure as Code tools.

7. Conclusion

Is this the monster that stops the public cloud beast from growing in an unstoppable fashion - no it isn’t. This is totally manageable and almost mitigable if you identify and take it into account in your cloud strategy. You cannot mitigate every possible business risk for your company, but it may be a reasonable expectation you identify and assess in writing risks such as this one. A big enterprise might mitigate the risk by deliberately procuring from several CSPs, and the creation of such strategy is the happy end of this long read.

Regarding patents and IPR disputes, while writing of this long read Microsoft and Salesforce released new cloud software into open source, hats off to them! The Salesforce move is around TransmogrifAI which is a key piece behind their Einstein AI product. If others follow this that cloud infrastructure software is donated to open source, there would be less monsters to be afraid of.

8.?What we sell

Consultancy on many levels, primarily on IT and business themes, is one of Tieto offerings. Our company has cloud consult capabilities both spread out to the organization at large as well as in the Business Consulting and Implementation (BCI) major organizational unit.

Cloud strategy creation is for me personally a core competency, and I’m assisting colleagues in search of reference customers around it. I’ve made a formal description on App In The Sky cloud strategy creation service. Applications are in the center of gravity in this service. App In The Sky is in limited sales for selected new logo clients at 1950 € fixed fee and it provides all necessary cloud strategy documents, workshop effort and stakeholder interviews. Also included is a ? day cloud security training. I can also be booked separately to discuss or review your cloud strategy.

Good night and sleep tight!