After about 16 years of using Windows as my main OS (3.1, 98, 2000, XP, and then 7), and either working around its quirks and limitations, or outright bypassing them by using Linux in VMs (or on spare computers I wasn't using for anything else at the time), I finally decided to make the switch completely. I've been using Linux as my primary OS, now, for only about 4 years, but it's been a good switch for me. Still, it wasn't a smooth transition.
Part of why I stuck with Windows as long as I did was because it was familiar, but most of it was access to software that would do what I was interested in doing at the time. Linux wasn't exactly keeping up, and Mac OSX, while more than capable of providing essentially everything I'd need, was well outside my price range. It took a long while to slowly find and learn all the different applications and other tools I would need to handle day-to-day tasks in a world that wasn't built by Microsoft. I also had to let go of some things I wanted to be able to do with my computers, because there simply wasn't a way to do them outside of Windows.
There's nothing inherently "bad" about Windows, or any Microsoft product, really. They've definitely had more than their share of issues over the years (there are reasons I skipped Windows 95, opted for 2000 over Millenium, and still only grudgingly admit that Vista was ever a thing), but that's inevitable with software as complex as Windows and its ecosystem. Still, I had reason to switch, and it was vendor lock-in that kept me from doing so as quickly as I (or my productivity) would have liked.
What Is Vendor Lock-In?
Microsoft had me trapped. Their long years of marketing to businesses, and actually building for daily office use, led to being the most commonly-used OS on the market. That, in turn, led to leading the market for computer games, which made their products even more common in the home. Since it was the most common, it was what most of us learned, growing up. And that has continued to be self-reinforcing for a long time, to the point where the vast majority of the software available today is targeted at Windows, often exclusively.
By building an ecosystem where the cost of moving to something else was higher than the cost of staying put, Microsoft had effectively locked me into using their products. I was stuck with them as my OS vendor. This is a decent enough business strategy - especially when you maintain enough competition to avoid being accused of monopoly - but it isn't so good for me, the end user. It became painful to switch out elements of my personal infrastructure as my needs changed. I try to avoid situations like this, now, and even Microsoft themselves are trying to make things more interoperable, to reduce the amount of lock-in they subject their users to.
One key to interoperability is standardization. This means not only having a standard approach for things, but sticking to it. Even while locked in to Windows, I almost never used Internet Explorer, because the weakness of its support for the web standards of the time meant some sites worked differently on it, or more often didn't work at all. At the same time, though, I used Microsoft Office fairly exclusively, because the open source alternatives were mostly guessing at the file formats I was expected to use, and the open formats weren't supported by Office itself, so I couldn't use those with people who couldn't install an alternative. It wasn't until much more recently that the Microsoft file formats were opened up somewhat so others could read and write them properly, and I was able to move more freely to something else.
Lock-in On The Web
As a web developer, I've encountered many similar obstacles to migrating from one approach to another. As I mentioned before, Internet Explorer used to be a major headache to write for, to the point where I was writing entirely separate code for IE clients. I recall using a number of government web sites over the years that wouldn't work on anything else - these sites had been locked in to Internet Explorer because it was so different from the other, standards-compliant browsers that adding support for the rest would have potentially doubled the cost. This particular example is no longer the case, as modern browsers (including Microsoft's replacement for IE, Edge) all strive to comply with the same standards for interoperability.
This means that, while there are still differences between the browsers, most of the issues we face with lock-in on today's web lie on the server side. At the most basic level, it doesn't seem like there would be too much lock-in involved, here. Server software is generally cross-platform, so what kind of lock-in could we have here? Looking more closely, the differences between the platforms themselves actually offer one answer. There are some features of, say, *NIX systems (Linux, macOS, other BSDs) that Windows simply doesn't support (process forking comes to mind). Any software that relies on such features will either not work, or be significantly impaired on systems without them.
But it goes beyond that, too. Even assuming a Linux web server, which is a fair assumption with most hosting platforms available today, numerous factors - such as distribution ("flavor"), version, and various security restrictions - will place limits on what software packages, if any, can be added to your environment, and how. And that's not to mention which ones are even available in the first place. Generally speaking, this is becoming less of an issue, but it's still a limiting factor in selecting a place to call home on the web.
The real limiting factor, in today's cloud hosting ecosystem, is less with what software you can add to your server(s), and more with what you need to do to get your application's pieces talking to each other properly and securely, as well as getting them to properly talk to the world, without opening them up too far. Each cloud provider has a completely different approach to handling these factors, and each has benefits and drawbacks that set it apart from the rest. One will probably emerge as a new standard, at some point, or more likely a standard will emerge that is a synthesis of all the best parts of each. But in the meantime, these infrastructural differences still result in the most feared form of lock-in on the web - cloud lock-in.
Overcoming Cloud Lock-in
So how do we avoid becoming locked in to any given cloud provider if they each have completely different - and incompatible - ways of setting up their environments? Well, first, we admit that their approaches aren't exactly incompatible - on the lowest levels, they all use the same technologies to get stuff done. The differences are in how they expose those technologies, and what options they allow when configuring them. Once we establish that, it's clear that we can probably abstract most - if not all - of these differences away to a single, consistent approach that should work anywhere.
This is where Nanobox comes in. (You were waiting for that, weren't you?) I've mentioned before, in other articles, that Nanobox supports multiple cloud hosting providers. At the moment I'm writing this, that's Amazon AWS, Digital Ocean, and Linode officially (though Linode support is still in beta), and at least Google Cloud and Proxmox hosts via third-party adapters. As you can guess, each has wildly different approaches to things, but Nanobox has abstracted everything down to where it can deploy your code to any of them - or even all at once!
This abstraction means that even after you first deploy, you can easily move to a different host at any time. Simply create a new app in your Nanobox dashboard using the new provider, set up the new remote, and deploy, then destroy the old app once everything has been moved over. No changes to your code, and only minimal interaction with the production environments themselves.
Standards and Practices
But it gets even better. I mentioned specifications a few times, above, and Nanobox is actually an implementation of one! It's one the Nanobox team themselves actually developed, but it's published openly (under the name Nanopack), and they hold themselves to it explicitly. These factors mean that anyone can "roll their own" implementation of this standard, and applications should be 100% interoperable between the two.
Additionally, Nanobox is designed to enforce (or at least encourage) best practices when it comes to building web apps, especially with doing so in a way that allows them to scale to meet changes in demand. By segregating data components (MySQL/Postgres, MongoDB, Redis, NFS) into entirely separate containers, and splitting web components (which respond to requests from the outside world) from background workers (which are meant to handle everything else), apps are forced to be configurable to meet a flexible, potentially-ever-changing environment. Ultimately, Nanobox's design helps encourage applications to meet the requirements of best practices such as those of The Twelve-Factor App. And that leads directly to the best anti-lock-in feature Nanobox has: you aren't even tied to Nanobox (or even Nanopack) itself.
By encouraging designs toward these kinds of best practices, Nanobox even helps keep itself from becoming a source of lock-in. If, at some point, you find that you have reason to move away from Nanobox's abstractions, and hire a full-time operations team to manage the finer details of your infrastructure in a way that Nanobox doesn't or simply can't, your apps will already be designed to move across seamlessly. The code will be decoupled from the infrastructure, allowing it to run anywhere you (or your ops team) can assemble a replacement, and it can look like whatever your needs dictate it should. Your apps won't care about any of that, because they'll already be set up to look around for whatever they need, instead of expecting it to be someplace it isn't.
That's right. Not only can Nanobox rescue you from cloud vendor lock-in (not to mention supporting practically any programming language, and running on all three major desktop platforms equally), but it can even rescue you from being locked in to itself. And that's probably the sweetest part of all.