Dr. Strangecloud
You’re in an architecture review meeting. The whole engineering team is here, and various sub-teams are presenting their plans for the next sprint of work. Finally it’s your turn to present. You start talking about the elegant design of your service: it will consume data from kinesis and store intermediate results in dynamoDB, using the guarantees of those services to ensure at least once data processing and robustness against outages. Feeling very proud of yourself for such an innovative and clever design, you don’t expect any pushback. Then a lone hand goes up…
It’s one of the technical leads. This guy has been around the company since the beginning and as such many defer to his judgement in these meeting. He starts, “Cool, very clever design. But I’m worried about relying on kinesis and dynamoDB. After all, what if we want to switch cloud providers down the road? We’ll be locked in to AWS and the migration will be that much harder.”
This is a common enough story. Hell, I’ve even been the person to argue this point in the past. After all, it sounds logical. No one likes lock-in, especially not senior engineers who’ve dealt with the painful lock-in of vendors like Oracle and Microsoft in the past. But is this the same sort of lock-in?
On Ownership
“The things you own end up owning you.” — Chuck Palahniuk
Two years ago I was visiting with a customer who was gearing up for a big splashy launch event. We’re talking about a classic first tech bubble style launch with a superbowl ad and everything. And just like in the first tech bubble they had insisted on building out everything themselves. They were running on bare metal servers with multiple datacenters, multiply redundant F5 load balancers, the works. They even had a full time network engineer on staff. All of this supposedly so that they could handle the massive scale of the launch, yet they still ended up having some very high profile availability problems during their launch.
The cost of not being locked into a platform is ownership: you have to own the physical build out of servers, the configuration of the network, the OS compatibility with your hardware, everything. You wind up owning a ton of non-essential complexity for very little, if any, payoff in terms of flexibility or performance.
And except for the rare case most people understand this, at least when it comes to bare metal servers vs. virtualized instances. But for whatever reason, as soon as you begin talking about adopting services higher in the stack, like ECS, kinesis and dynamoDB you start to see pushback that “oh no, we can’t get locked in to their platform!” The only problem is that it has already happened.
On Migration
If you’re reading this odds are that you have some kind of infrastructure online, perhaps it’s hosted in AWS perhaps not. As a thought experiment, think what it would take to migrate from your current environment to something else. Ostensibly the code doesn’t care whether it’s running on virtual machines in AWS, Azure, or even bare metal. So it should be no big deal, right?
Except there’s all the tooling that’s grown up around your current environment. Oh and there’s all the process and culture that your team has accumulated for operating inside of that environment. Oh and there’s all of your customer data that needs to be moved. Oh and we can’t take any downtime so data must be replicated to the new environment until it’s ready to cut over. Oh and we can’t slow down on feature velocity so we’ll be deploying to both environments for the foreseeable future.
(As an aside: if this sounds a lot like hybrid cloud strategies, that’s because ultimately it is. And hybrid clouds are a transitional phase at best)
So you aren’t going to be migrating any time soon. And if your company gets bought by a large entity enforcing a migration, you’ll be in for a multi-year slog regardless of the services you’ve adopted or even the color grade of your holacracy.
How I Learned To Stop Worrying And Love Lock-In
So next time you’re in a meeting and someone is trying to pick holes in your project by questioning the wisdom of relying on proprietary AWS services, ask them for their migration plan and how that’s going to fit on the product roadmap. Or ask them if they want to personally take responsibility for the installation, configuration, and operation of an open source equivalent to the service, assuming one even exists. Odds are they’d much rather make it Amazon’s problem after all.
Opsee is application monitoring designed from the ground up to work with how you build apps in AWS. We keep an eye on all your backend services, letting you get back to doing what you do best: shipping code. Sign up today.
