Recently I’ve heard many in the industry discussing the risks of cloud lock-in, so I thought I’d give my take on it. I hope you find these helpful, please feel free to comment below if you have had similar or contrary experiences!
The Current Talking Points
The promise of cloud is infinite scale, commodity prices, and portable workloads. As the cloud vendors compete for your business, they are competing on two fronts:
- Differentiated services
- Price
Differentiated services allow us to benefit not just from infinitely scalable hardware, but also from automation and services higher up the stack. But if these differentiated services are offered by a single cloud vendor, then by definition you will be locked in to that vendor. There is a clear trade off, and many purists will argue that in order to protect your company from being locked in to a single vendor, you need to avoid using any services that are not industry standard. After being held hostage by various legacy hardware and software providers for years, many companies are implementing this type of infrastructure policy, promising not to let it happen again.
How do we get locked in?
Before determining your strategy, it’s good to look at exactly how lock in occurs with a cloud provider.
Developing to the vendor’s API
One of the main benefits of cloud infrastructure is that you can interact with it programmatically instead of physically. You can spin up and down servers, create and destroy networks, all with a simple script. You can even integrate this capability into your application, allowing your application or your monitoring system to take these actions on your behalf. This is a very powerful capability, allowing you to guarantee service levels in a way that was virtually impossible in the physical infrastructure world. But each vendor offers their own API. Often they are similar, even identical (many open source cloud initiatives have decided to adopt the AWS API). But there is no guarantee that this will persist. If you have code and scripts that leverage a specific vendor, those may need to be rewritten if you elect to move to a different cloud.
Leveraging Proprietary Components
Another benefit of the public cloud is to leverage application components higher up the stack. Why build and manage your own message queue infrastructure? In the time it took you to do so, you could have instead been developing new features that differentiate you from your competition. Some of these components have no real risk of lock in, as they are relatively standard (email, messaging, DNS, managed MySQL / PostGreSQL), and would only require finding a like service or building one prior to migration. Other components may be proprietary, like Amazon’s DynamoDB, a horizontally scalable noSQL database. This type of offering has a higher level of risk from a lock-in perspective. But there is also a benefit. Building and managing your own highly scalable NoSQL database platform, and ensuring performance and availability across the board is no easy task. That said, no other providers currently offer a NoSQL database that is compatible with the DynamoDB API. Migration would mean selecting another product, and rewriting any application code that speaks to the database.
What else are we locked in to?
Cloud lock in is a reality, but I think it’s interesting that the topic of cloud lock in is so hot. From my perspective, lock in is lock in. So, what other things are we locked in to? We write our apps in a development language, and we are locked in to that language. That language often has a preferred application server (or a few options), and sometimes only a single operating system that can effectively run those application servers. Those operating systems run on single infrastructure architecture. And if you are not using cloud infrastructure, that hardware physically sits with a colocation provider who requires term and volume commitments.
Some would argue that in order to avoid lock in at all these levels, you need to limit your technology choices to those that comply with industry standards. So what would that really look like? Ten years ago, you’d have decided on a lamp stack. Then, after several years of development on MySQL, Oracle buys MySQL. Oops. Now what? Migrate off of MySQL? Fork the open source and maintain it yourself?
Will my cloud vendor lock me in and raise my price?
This is a possibility. We’ve covered the ways that you get locked in, and from my knowledge I don’t know a cloud provider who has promised to never raise prices. That said, I don’t think I’ve seen a cloud infrastructure vendor raise their price. What is our guarantee? Well, there are really no guarantees in life, but as an economics major I learned that competition breeds innovation and efficiency. Although Amazon has bragged of lowering prices without the competitive pressure to do so, that has changed. They are still lowering prices, but they now have competitive pressure. Their most recent price drop helped them stay on par (for the most part) with Google’s recent price drops for GCE.
From my perspective, the reality is that these vendors offer services which are similar enough that they will be directly competing with each other for new workloads for years to come. That should continue to push these companies to be more efficient and enable them to lower prices and be more competitive. These price drops to date have not been just for new workloads, they have been across the board. So all customers, whether they are locked in or not, benefit from the competitive pressure that cloud infrastructure companies are generating on each other.
Is avoiding lock-in the goal?
We usually tolerate some level of lock in because the business benefit far outweighs the associated risks. Any time we adopt a technology we are taking some risk of lock in, and we are benefiting from the value that technology is bringing our business. In order to keep up with our competition, we need to constantly innovate and differentiate our products. Time spent re-inventing the wheel or maintaining a completely vendor neutral technology environment is time that could otherwise have been spent innovating differentiated services. The biggest risk to your business? Losing your competitive advantage.
Ok, so how should this effect my infrastructure strategy?
Like all business decisions, we will weigh the strengths and weaknesses of possible strategies, and pick those that benefit our business most. For most of us, this will mean spending less time worrying about getting locked in to a cloud vendor, and spending more time evaluating the offerings, and choosing the one that most closely complements our workloads, technology stack, SLA requirements, and budget. We will look at the vendor’s past actions, and make a realistic judgement about the likelihood of how they will act in the future. Although some will limit their technology and vendor choices to only those that are truly portable, they will perhaps be suffering from a different form of lock in. Locked in to a smaller feature set, and forced to recreate the wheel in many areas and at great cost, when a proprietary 3rd party solution would make much more business sense. The rest of us will make sound decisions on where we should best spend our focus, time and capital, and accept some level of lock in for the business benefits that we receive in exchange.
