Switching Costs and Lock-In

It’s no surprise that organizations are worried about becoming locked in to their cloud provider. After all, the history of IT is full of examples of vendors taking advantage of high switching costs to impose restrictive licensing terms and to increase prices. But I think that the cloud is different—and in fact, is making it harder and harder for software, hardware, and IT service vendors to take advantage of the leverage that they have had in the past.

This is a sensitive subject, and as an AWS employee, I clearly have some skin in the game. But it seems to me that a lot of the conversation about vendor lock-in is off target, so let me see if I can reframe the discussion by explaining how I thought about it when I was a CIO, before I joined AWS.

First of all, I was pretty clear on why I was moving to the cloud. It was unambiguously to gain speed. Our lead times for producing new IT capabilities were way too long; my transformation was not just about moving to the cloud but about shortening lead times through DevOps, through streamlining our governance and oversight processes, and through creating reusable microservices that could quickly be recombined to develop new capabilities. As the CIO of US Citizenship and Immigration Services (USCIS) I knew that major changes to immigration policy could happen at any time—and when they happened, our long lead times would be unacceptable. I did have reason to believe that the cloud would reduce our costs significantly (it wound up cutting about 75% out of our direct infrastructure costs), but speed was first in my mind.

What were my biggest obstacles? The skill sets of my employees, for one. Most of them had never worked in the cloud and were new to DevOps and microservices as well. A second impediment was our procurement process—with all of the legal work and the vendor selection process, procuring a service could take us anywhere from six months to three years. And there was a cultural impediment (OK, many, actually) in that we had a culture of exceptionalism—our government IT needs were so unique that we had to do things differently from what the rest of the industry considered to be best practices.

When I considered using multiple cloud providers for our infrastructure and platforms, I quickly backed away from the idea. I was afraid that it would slow our transformation down, when speed was the most important factor for me. Building our systems to be deployed to multiple clouds was going to cost us time, even if we used containers and cloud-agnostic tools. Since I was pushing my teams to learn to use infrastructure as code, I didn’t want the complexities of managing infrastructure in different clouds to slow them down. With a multi-cloud approach, I also would have had to hold back on using services that were specific to a particular cloud provider that could otherwise speed us up. And since skills were an issue, I didn’t want my employees to spend time learning different cloud platforms and cross-cloud compatibility. Finally, to overcome our culture of “special needs” I wanted my employees to start with the simplest and most straightforward path that other organizations were using.

For all of these reasons, I knew that hedging my bets on cloud providers would have a large cost to what I was trying to accomplish. What remained was for me to consider the risks of choosing a single cloud provider and find ways to mitigate them.

My train of thought went like this: the term “lock-in” is misleading. We are really talking about switching costs. Switching costs have existed throughout the history of IT. As soon as you commit yourself to a platform or a vendor you will have switching costs if you later decide to change. If you choose Java and then migrate to Node.js, you will have a cost. If you choose Maven and then migrate to Gradle, you will have a cost. If you decide on a mainframe and then move to horizontally scalable commodity hardware, it will cost you something. In none of these cases are you actually “locked in”—you simply have switching costs, which may be large or small depending on the situation.

And we have always factored these costs in, at least implicitly, as we have made decisions. If we choose to use Oracle as the database for a given application, we don’t usually also build the application on SQL Server to make sure we aren’t locked in to Oracle. We don’t do so simply because we believe that the costs of having two alternative databases for the same application will outweigh the benefits in risk management.

So I asked myself: (1) What will my switching costs look like if I need to leave AWS? (2) What is the likelihood of that occurring? And (3) how can I cost-effectively reduce those risks? With cloud services you pay as you go (with a few exceptions, like reserved instances), so you are leaving no money on the table if you decide to switch providers. I decided that it didn’t make sense in our case to do all the upfront work of making our applications multi-cloud; as I said before, that would be a very large cost and the probability that I would need to leave AWS, I judged, was not that high. Instead, I would accept that there would be a switching cost later on if, for some reason, we decided to leave AWS, and that we could work to mitigate it.

The first area we considered for reducing the risk of high switching costs was architectural. We used Docker containers that we expected would be deployable virtually anywhere. We built microservices, partly with the thought that we could later decide to put some services on one platform and some on another. We also knew that we could reduce the “blast radius” of changes to a single microservice and could test each one independently if we needed to start changing on a large scale. We actively worked to loosely couple our services, especially when using a service specific to AWS—essentially, we built a façade for each AWS service so that we could swap it out as transparently as possible.

One thing that we didn’t do but that you might want to consider is to write a back-out or “reversibility” plan. Depending on the level of risk you perceive, you can make this plan more or less detailed. In the plan, you can itemize what the major switching costs would be if you had to leave AWS, and what steps you are taking to manage them. You can also make a high-level project plan for how you would go about doing it, and you can estimate costs. With such a plan in hand, you can make informed decisions about the risk you are taking by committing to one vendor at a time.

As I mentioned, the cloud, DevOps, and other contemporary developments are loosening the hold that traditional vendors have had on you. If you are doing the things I described—loosely coupling, creating facades, using containers, etc.—you are not just making it easier to switch cloud providers, you are making it easier to switch any sort of platform provider. When you add in the impact of open source and the reduced costs of developing your own custom solutions, and what’s more, the AWS offerings that can be substituted for them on a “pay as you go” basis (for example, RDS, DynamoDB, and Aurora), your risks (that is, your potential switching costs and the likelihood that you will want to switch) are declining rapidly. But it is not just risk—you are also benefitting from the innovation that vendors bring when they have to compete for your business.

Enough about my decision-making process as a CIO—let me change hats and talk from my perspective as an Enterprise Strategist at AWS for a moment. When you assess the risk of working with AWS, please consider that we have deliberately built our cloud platform on open standards like Xen, SQL, and Linux, and we are increasingly a contributor to open-source projects. We have reduced prices 67 times now, largely in the absence of competitive pressure to do so. Our tools that help you migrate into AWS can also be used in reverse to help you migrate out. We have tried to make it as easy as possible if you choose to leave AWS. To be honest, that makes sense from a business perspective, because it is also in our interests to reduce your risk of working with us.

Our pace of innovation should reassure you that we intend to keep winning your business, with the knowledge that you can move to another cloud provider if you choose to do so. Ninety to ninety-five percent of our roadmap is driven by what our customers tell us they want. It was AWS that pioneered the cloud, and that continues to drive the cloud’s development.

Ok. Commercial over. But seriously, as an enterprise strategist I would like to make the following suggestions. First of all, if you believe that the risk of using a single provider outweighs the costs of using more than one provider, by all means go ahead and work with multiple providers. In that case I suggest that you reduce the costs of your decision by putting some workloads in one cloud and other workloads in another cloud, rather than trying to make a single workload deployable to multiple clouds. If you agree with my reasoning and decide to go with a single provider, I suggest that you mitigate your potential switching costs through good architecture, standard deployment practices, and a bit of pre-planning.

There are switching costs when you choose one platform rather than another, and there always have been. There is no such thing as “lock-in,” except to the extent that you agree to it contractually, but switching costs can be high or low. Through good design and some advance thought, you can reduce your costs of switching (from traditional software or from a cloud provider). Instead of pre-paying those switching costs by accepting a speed penalty and higher costs now (in going multi-cloud), you might want to reduce your potential switching costs and see whether your provider continues to serve you well.

–Mark

@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value
War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age (now available for pre-order!)