I want to take a minute to address a challenge that comes into many of our customer discussions. The challenge is that of perceived Cloud Provider Lock-in, it usually comes up in an interaction like this:
Me: “Walk me through the design of your application and services.”
Customer: “We are building all of our systems on EC2 and we want to avoid vendor lock in. We want the flexibility to change cloud providers at anytime,” or “We want the option of using any cloud provider we want, whenever we want.”
Me: “Are you using something besides AWS today?”
Customer: “No, but we want the option to switch.”
Me: “Tell me about your application, how is it built?”
Customer: “We install and configure our software using a bootstrap…blah blah blah…”
At this point a customer has described the process of building and installing software to function like ______ (fill in the blank with any number of managed services from AWS).
In my experience Vendor Lock-in is created by:
- People and their skill sets – People like to use what they already know.
- Data – Databases and data are like planets in a solar system they have gravity.
- Source Code – To some, lines of code are etched in stone or punched like holes into a strange card based system and impossible to change.
- Operations tools – Asking an operations team to change their monitoring tool is as risky as feeding a gremlin after midnight.
- Contracts – Signed documents influence behavior.
I have never heard a customer actually want to avoid Cloud Provider Value.
A customer has NEVER said to me:
- “We want to receive the lowest possible value from our cloud provider.”
- “We prefer to manage all the heavy lifting (and associated costs) of running our systems.”
- “We don’t want to automate anything.”
- “I automated something once; it was terrible.”
Let me put this misconception in a different light. I want to talk about a technology challenge without talking about technology. In February of 1998, I walked into my local Honda dealership and bought a brand-new Accord. I paid just over $20k for my car, and almost 19 years later the odometer shows over 300,000 miles. I have driven that car the equivalent of the Earth’s circumference about 12 times.
If I think about it, I was locked-in to that car when I bought it. To avoid being locked-in, I would have had to lease a new car every year and keep it in tow in case of failure. In addition, I would be paying the associated expenses, despite the original purchase being efficient at getting me where I needed to be at a much lower cost.
Many arguments can be made about new vs. used, buying vs. leasing, fixing vs. replacing cars, but for this purpose, you can see my point: why pay for something you don’t need in order to avoid an inaccurate perception? That kind of logic doesn’t make sense when applied to a non-technical solution, so why do we allow the Vendor Lock-in argument to make us take drastic measures to avoid lock-in in technical realms?
We live in a world that openly embraces agile methods that call for value-driven decisions. Agile methodology calls for doing the most valuable thing first. Why would you avoid getting the most value from a cloud provider as quickly as possible by building your own infrastructure on top of the cloud ecosystem just to avoid something that may never matter?
After 19 years of driving my Honda Accord, I’m glad I didn’t have to pay for extra car insurance, maintenance, and servicing of a new car every year for two decades just to avoid auto provider lock-in.
Let’s move beyond anecdote and into a real customer experience. The customer, Mark, (name changed) works for a large Fortune 500 company. His team was running a workload on EC2 using Kafka, MongoDB, and Compute services. Their monthly bill for this existing environment was just over $7k a month. This didn’t include the staff of three people to install, run, and monitor the systems running on EC2. We had a conversation almost identical to the dialog above about running their own systems on EC2. We agreed to run a real-world workload in a new AWS account for one week, then compare costs.
I proposed a bake-off to Mark, a test to see if their workload was a good candidate for the AWS managed services like Kinesis, DynamoDB, and Lambda. After the week was over, I got a concerning phone call from Mark telling me the test results couldn’t be correct. Our conversation went something like this.
Mark: “We reviewed the test traffic and this can’t be right, there has to be something wrong.”
Me: “What makes you say that?
Mark: “There is no way these costs can be correct.”
Me: “What is the daily cost?”
Mark: “The workload costs about $2 a day.”
Me: “That’s great news!”
Mark: “You mean to tell me, for about $60 a month, I can run the same workload that currently costs us more than $7,000?”
Me: “Mark, I am not telling you anything, your results are telling you that.”
Mark decided to look for the most agile approach and now uses Kinesis, Lambda, DynamoDB, along with many other AWS managed services.
Is this a case of Cloud Provider Value or Cloud Provider Lock-in? You be the judge.
Rich Uhl
CTO/Founder of 1Strategy
About the Author/Disclaimer: 1Strategy is an AWS specific consulting company. I have personal experience running production in a multi-cloud deployment including three different cloud providers (AWS, Azure, Tier 3/CenturyLink). Before starting 1Strategy, I worked at Amazon Web Services as an Enterprise Solutions Architect, where I had seen the cost associated with this tactic many times and saw customers spend millions of dollars trying to avoid Cloud Provider Value. My personal assessment of the leader in the Cloud Providers aligns with the Gartner magic quadrant.
Appendix A:
Actual Screenshot of the customer bill for the months testing:
