Cloud lockin is here to stay, so learn to love it
With all the gleeful finger-pointing over which cloud provider is the least (or most) generous with open source code, it’s worth remembering that all cloud providers essentially fail when it comes to open source. Why? Because the very nature of their platforms means that their best code remains closed even when openly licensed.
All of which makes your favorite cloud “probably the most proprietary software in the history of software,” as Dremio CMO (and former MongoDB exec) Kelly Stirman says. What to do?
You can’t check out of the cloud any time you like
No one likes lockin, but if you take a quick glance around the industry you’ll find that most every category is dominated by a vendor or two that exercises outsized lockin. What started out at Microsoft with its Windows and Office hegemonies moved to Apple’s iPhone, and at the enterprise infrastructure level we’re currently cozying up to Amazon Web Services, Microsoft Azure, and Google Cloud.
“Not to worry!” you say. After all, these companies L-O-V-E open source! Well, they do, but what does that actually mean in the cloud context?
For example, in response to Google’s Miles Ward extolling the openness of Google Cloud Platform, Cloud Guru co-ounder Ant Stanley asked an uncomfortable question: “Can we talk about Big Query and Spanner customers then? Great tech platforms but huge lockin.” Ward, nonplussed, responded, “Apache Drill and ANSI SQL. Next?”
In so doing, Ward sidestepped the gaping void between platforms like GCP and the raw technologies that comprise them. Apache Drill isn’t a real substitute for Google’s Spanner. Sure, at some level, it might replicate some of the features or functions, but to derive value from Spanner you need, well, Spanner—and all the infrastructure behind it.
Again, Ward tried to give the open source response: “:| split writes to newdb. SELECT * at olddb. INSERT * at newdb. Repeat, move reads to new database. I get there are quirks, but there’s no lock.” Yet, again, it doesn’t work, because, as he ultimately admits, the only real way to get the equivalent to Spanner is to “just lay a few thousand miles of fiber, snag a few atomic clocks, get GPS sorted, and, yeah, you’re cool.”
In other words, on-premises, server-based lockin forced you to buy new cloud software to get out of lockin. In the cloud world, you have to buy a new datacenter and all the network infrastructure to go with it. The cloud, in short, has perfected lockin, and open source doesn’t really help.
Worse, even if you have the code and the datacenter, it’s still not enough, because you’d need the experience running that code as Google, AWS, or Microsoft would. As Expedia’s vice president of technology, Subbu Allamaraju, highlights, open source absent a cloud-scale feedback loop tends to fail over time. But to get Spanner to run like Spanner, you need to not just have the resources of Google, you actually need to be Google.
Talk about lockin.
How I learned to stop worrying and love the cloud lockin bomb
One obvious response is “Who cares?” Given how fast enterprises are shoveling cash into the clouds, this also seems to be the popular response. The reason, as with the old world of proprietary software lockin, is that the benefits largely outweigh the risks. If a developer can significantly increase her productivity by running AWS Lambda or other proprietary services on a particular cloud, she’s going to do it, even it means tying herself long-term to that cloud platform.
As for whether this is a wise course of action, Allamaraju offers an emphatic yes: “You can’t take advantage of all the new capabilities to innovate for your business while staying agnostic to the platform.” Enterprise IT innovation is being driven by the clouds, and the more of that innovation you imbibe, the more you dig deeper into lockin to this or that cloud. There’s simply no way around it (absent buying your own datacenter, but even that won’t give you Google Spanner, AWS Lambda, etc.).
You can mitigate lockin by exercising what Allamaraju dubs “change agility.” This isn’t a way to avoid software licensed in any particular way, but rather to ensure developers can bounce among cloud services: He says, “Embrace techniques like service orientation, asynchronous and decoupled communication patterns, micro-architectures, experimentation, failing fast, tolerance for mistakes, chaos engineering, constant feedback, and continuous learning.” In other words, you embrace lockin but evade it (somewhat) by flitting among services.
A perfect solution to lockin? Nope. But it may be the best we’ve got. It’s not that open source is irrelevant in the cloud context, but rather that it’s not a panacea.
Source: InfoWorld – Cloud Computing
Recent Comments