In my last blog post, I looked at why custom software development is now experiencing a renaissance. In this new blog, I zero in on a slightly more controversial concept that’s also making a comeback: vendor lock-in.
As we all know, vendor lock-in has been around as long as commercial computer systems have been available. Back in the mainframe days, vendors like IBM and Unisys created proprietary systems—databases, languages and so on—that only ran on their own platforms. In doing so, they effectively locked their customers in to operating on that infrastructure and hardware. This had both pros and cons at the time but overtime has been largely recognized as a negative.
Memories of these vendor lock-in challenges run deep in today’s enterprises, often triggering an extreme sensitivity to the risk of getting locked in again. So much so that when I suggest a tool or asset to a client, the first question they might ask is not “How good is the tool?” but instead, “Is it open source?”
The rise of megaplatforms
This fear of lock-in was evident among most enterprise clients until quite recently. But now, we’re seeing signs that the instinctive avoidance of vendor lock-in is starting to soften. And the drivers are underlying shifts in the systems landscape.
The changes underway are reflected in recent research. Earlier this year IDC predicted that by 2022, the top four cloud megaplatforms will be the destination of choice for 70% of workloads across Asia-Pacific, excluding Japan. It added that lock-in will be avoided through multi-cloud and cloud-native approaches to achieve portability.
From what I’m seeing in the market, I completely agree that the direction of travel is towards ever greater dominance by the megaplatforms. But I’m less certain that companies will be looking to avoid lock-in.
A new calculus emerges
Why do I say this? Because a new calculus seems to be emerging among enterprises: one where they’re willing to accept a degree of lock-in as justifiable, since it’s outweighed by the cost and speed benefits of building systems on top of proprietary architectures from the likes of Amazon, Microsoft, Google or Alibaba.
The key lies in how these architectures abstract and take care of the underlying plumbing, making it so much faster and easier to build software on them. As a result, organizations of all kinds are able to create highly sophisticated applications on these platforms at unprecedented speed.
To avoid vendor lock-in, they would also need to build in extra layers of logic and code to provide workload portability. However, the cost and effort of embedding that portability would essentially wipe away much of the benefit from using a megaplatform in the first place. This is despite the fact that picking up the application once it’s written and moving it to another platform would be equivalent to a major transformation.
<<< Start >>>
<<< End >>>
Trading-off speed, cost and portability
Faced with this trade-off, more and more enterprises are throwing caution to the wind and accepting lock-in. They’re doing this by developing systems that use a megaplatform’s proprietary features without investing in creating sufficient abstraction to provide the portability to move elsewhere. It’s a price they are willing to pay because the pace of technology change demands it.
In taking this approach, they’re recognizing that if they ever actually have to move their applications from the current platform to another one, they’ll probably have to re-write or significantly re-engineer them. But they’ve calculated that the cost benefits and acceleration they gain from building systems on top of these platforms vastly outweigh the cost they would incur in making them workload-portable. So, they don’t bother.
The jury’s out
If you take soundings across the industry, you’ll probably find the jury is still out on whether the companies that are accepting lock-in are making the right call. But the initial indicators from our clients and business case analyses is that they are. The value of writing source natively on a platform, the pace of development, and the value and agility it unleashes make it worthwhile—even if the flexibility doesn’t extend to workload portability.
What’s more, the competitive pressure on the large cloud platforms has made them keep their costs at a reasonable level up to now, and there seems to be little reason why this should change. In cases where companies have decided to shift from one megaplatform to another, it’s often been because they’ve found they’re now competing with their current provider. Paradoxically, cost doesn’t usually come into the equation.
The message is clear. The era of cloud-native platforms has seen the return of vendor lock-in, and clients are going into it with their eyes open. It’s essentially a strategic choice—one that, to date, companies have no cause to regret. Whether they’ll have cause to do so in the future is another question.