Lock-in, much like the proverbial excrement of vernacular interpretation of Murphy’s Law, is unavoidable. Hopefully, the mention of lock-in should make you itch and twitch; but not all lock-in is terrible. When you boil it own, we have a few types of lock-in: linchpin, snobs, and penitentiary.
Penitentiary is what comes to mind and makes us itch. These are technologies that try to keep you in $vendor’s ecosystem. They tend to require other products from the $vendor, preclude you from going elsewhere, and tend not to play well with others. Think Exchange and Active Directory. While these technologies are pretty damn good, they make it hard to leave the ecosystem. You’re not running Exchange on any other directory service, and the legs AD grows makes it hard to have a second directory service.
Snobs only want to play their own kind, or if you’re lucky enough, those they deem worthy. While these guys keep you within $vendor’s ecosystem by being “awesome,” the don’t preclude you from playing with others. Think Cisco’s VTP. You can plug up another switch to a Cisco switch running VTP. Nothing will stop it from working, but you’re stuck managing your plans on that switch, unlike the other cool kids getting their plans managed by VTP. This might not be the worse thing. If you’re building out a datacenter fabric to last 5 or so years, it might make sense to keep all your switches from one vendor.
Lastly we have the linchpin. Linchpins are sticky because of the functionality they provide is so crucial, you don’t dare think of switching off them. Git and YAML are two that come to mind. You could move off them, but so much depends on them, you don’t want to.
No matter what you do, you’re going to get locked-in to something. Perhaps a better way to look at this isn’t as getting locked-in, but more like casting your lot with in something, Either way, when you move into building a solution, you will get stuck with something. When we do large project, we know there’s going to be constant technology, but these should be some the questions you think about:
- On whose terms am I getting locked in
- Can I leave, what would it look like
- Where does this put me from a flexibly perspective
- How well does it play others.
Let’s look at two examples of how this plays out. If your looking at two solutions for automation. One is rolling some open source combination, like Git and Ansible, while keeping your model of the network in plain text YAML files. The second is buying into $vendor’s marketechure, and taking Super Magical Automatron Suite™ 1.2, now with extra Pixie Dust™.
If you go with $vendor’s SMAS 1.2, your config and modeling is stuck in there, and you may not be able to extract it to to move it to the next awesome thing from $other-vendor on the next refresh cycle. While this may be a dismal and snarky view of the vendor’s proprietary tools; when it is the refresh cycle, moving to another $vendor, the snark becomes a cold reality as much as the floor on the cold aisle you dropped your phone on.
If we go with the open source tools and open standards, even if its front ending something proprietary, you’re “stuck” with a tool that you have full control over. If you have to change the platform your using, or the platform its managing. either way its on your terms. You may have to retool, or script foo to move out of it, or something, But regardless, you’re the master of your destiny.
If you noticed, the examples I used were around the definition “of what things should be.” More formally, we call this “The source of truth.” in an automation solution, it should be separate from “what actually is.’ Its how you get “what it is” to be “what it should be.” While this mainly is a topic for another post, for this context, you should be thinking about what holds this.
You’re always going to get stuck with something. The question is what are you stuck with and is help or hinderance? And yes, I do tend to lean towards the open source and open solutions. I think its easier to pull a Cartman and take my ball home.