I started my professional career as a general-purpose "computer guy" for a small office. I wore many hats in this job including desktop help desk, server administrator, webmaster, network administrator, security engineer, and in general, if it plugged in, I was probably responsible for it. This was back in the era where, although Linux was making some inroads in the web server market, Microsoft absolutely dominated both the desktop and the corporate server markets. It was expected back then that offices of any size from ten to a thousand people would not only be running Windows on the desktop, but also that the back office would be running Windows servers.
These Microsoft services weren't necessarily better than the alternatives, but they won out anyway because of vendor lock-in. The domination of the desktop market meant that Microsoft could develop proprietary protocols like SMB (file sharing) and MAPI (email client syncing), and add them to Windows and Microsoft Office. Once SMB was baked in to Windows, it became easy for the boss of a small office to turn his or her desktop into the office file server without adding any extra software. As the company grew, that desktop was replaced by a standalone Windows server, and when you found out that your ISP (which you were using for corporate email up to this point) didn't support the shared calendar feature you saw in Outlook, you found out that Exchange and its MAPI protocol did.
People pick single-vendor solutions often not because they are better, but because they are easier. There's a built-in assumption that if you buy two products from the same vendor, they will work together better than if one of the products were from a different vendor. Yet when everything is from the same vendor, that vendor can develop proprietary protocols that have special features just for their products that competitors either can't use or have to pay a steep licensing fee to use. Beyond Microsoft, this can be found in routing protocols that work only on Cisco equipment or flavors of SQL that work only on Oracle databases. In all these cases, there is a built-in incentive to enhance their proprietary protocols and ignore bugs, performance issues or compatibility problems with the open standards they support.
It's this embracing of proprietary protocols and standards that leads to vendor lock-in. When two different vendors interoperate, they generally pick open standards and public protocols. If you don't like one of the vendors, you can replace it with a different vendor that supports the same standards and protocols. With vendor lock-in, you end up using features that exist only in proprietary protocols, and it becomes much harder to replace them with another vendor. No matter how good the competitor's solution is, the time and effort to switch away from proprietary protocols becomes too great.
When Linux entered the server scene, its stability and free (as in cost) nature started nibbling away at the UNIX web, application and database servers in data centers. With tools like Samba, it also started quietly replacing unstable Windows file servers. Linux's strong support of open standards highlighted some of the problems with proprietary protocols, and it's largely because of it (and UNIX before it) that the internet we use today relies on open protocols like TCP/IP, DNS and HTTP. There was a point when that wasn't a sure thing.
I bring all of this up because we are repeating the same exact mistakes from the past, only this time in the cloud. I chalk it up to a combination of younger engineers who didn't live through the last wave of closed standards, Linux geeks who are still so focused on ancient enemies like Microsoft that they never noticed the giants who took their place, and senior engineers who know better but are happy to trade vendor lock-in for ease, because after decades in the industry they are starting to get tired. When you consider just how much of the modern internet runs on one of only a few cloud providers (and let's be honest, most of it runs on only one of them), this complacence is creating a monoculture that puts far too much control in one organization's hands.
Monocultures can work great up until the point that there's a problem. Farming monocultures, such as cotton in the South and potatoes in Ireland, were prosperous up until there was a boll weevil and a blight. With the cloud, you have your entire business on one infrastructure, and there's this assumption that the infrastructure as a whole never would have a problem, at least until it does. At that point, you find out not only that the cloud provider had a fault, but that its fault was actually your fault for putting all of your eggs in one basket. Maybe the basket was a single server, maybe it was a single availability zone, maybe it was S3 in a single region. The point is, no matter how big the outage, it's your fault, because if you back up one step, you will always find that when all your eggs are in a single basket, fault tolerance is on you—at least until that basket is the cloud provider itself.
At this point, most people find solace in two things. First, if their cloud vendor were to have a major systemic problem, it wouldn't just be down—a huge swath of the internet would be down. Their cloud vendor is too big to fail, you see, so why plan for an event that probably will never happen? Second, they already are all-in with their cloud provider and are using too many proprietary services. It would be too difficult, too time-consuming and too expensive to develop an architecture that could run on multiple cloud platforms. It also would mean throwing away some of the really easy-to-use new features their platform just announced this year that may not be as great as competitors but that integrate so easily into their existing services.
The bigger risk—the reason I'm writing this article—isn't your company's services, which although I'm sure are fantastic, let's be honest, we probably could live without for a few hours or even days of downtime. The bigger risk is what happens to open standards on the internet and our ability to use the internet freely if almost all of it is run by proprietary services on a handful of cloud vendors. We Linux users are so proud of how much Linux has dominated cloud infrastructure servers, yet many engineers who truly use cloud infrastructure to its fullest never touch Linux or anything related to it. They simply interact with layers of abstraction on top of a proprietary API—if you dig down far enough, you'll find some Linux software, but that hardly matters to many people at that point.
In fact, plenty of people see only having to interact with their cloud vendor's API as a feature, and if the current trends continue in this direction, cloud infrastructure will turn into the ultimate proprietary OS where it honestly doesn't matter whether there are any open standards or software under the hood, as that's all hidden from you anyway. Individual containers or server instances take the place of processes, cloud services take the place of applications, and you as the engineer interact with it all using either their GUI, or a special language defined and controlled by your vendor.
If we get to that point, there's nothing stopping vendors from replacing any open standards behind the scenes with their own proprietary ones perfectly suited for their platforms. The question is whether those standards will start to supplant the open standards that exist outside their networks. Second- and third-place competitors will try to add interoperability features to get customers to move over, but will have a harder and harder time as these new protocols become more closed. With less competition, the winning vendor will have less motivation to innovate and more motivation to increase lock-in. Of course, you won't see those changes anyway, so there's nothing to worry about. After all, it would be too expensive for you to switch by then anyway.
I'm not writing this to say you shouldn't use the cloud. Cloud infrastructure has helped Linux and some open standards grow in a number of ways up to this point, and it has spawned a great many innovations from the speed at which we can create server infrastructure, its overall resiliency and countless open-source tools that help manage the overall ephemeral nature of its services. What I'm trying to do is remind you that vendor lock-in is actually a bad and dangerous thing. It's important to remember the lessons we learned in past eras of proprietary standards battles between vendors. Those battles threatened Linux, open standards and ultimately your freedom to control your own software. If it happened in the past, it can happen again. So think twice before you go with a single cloud vendor for everything just because it's easy.
Kyle Rankin is a Tech Editor and columnist at Linux Journal and the Chief Security Officer at Purism. He is the author of Linux Hardening in Hostile Networks, DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks and Ubuntu Hacks, and also a contributor to a number of other O'Reilly books. Rankin speaks frequently on security and open-source software including at BsidesLV, O'Reilly Security Conference, OSCON, SCALE, CactusCon, Linux World Expo and Penguicon. You can follow him at @kylerankin.
