Don't Get Locked Up Into Avoiding Lock-in (martinfowler.com) 63
Gregor Hohpe: A significant share of architectural energy is spent on reducing or avoiding lock-in. That's a rather noble objective: architecture is meant to give us options and lock-in does the opposite. However, lock-in isn't a simple true-or-false matter: avoiding being locked into one aspect often locks you into another. Also, popular notions, such as open source automagically eliminating lock-in, turn out to be not entirely true. Time to have a closer look at lock-in, so you don't get locked up into avoiding it!
Who is this guy and... (Score:5, Insightful)
why is he writing this junior pr crap? Shouldn't this be down in the bottom of hackernews? The reason we/anyone tries to dodge lock in is not to eliminate vendor contracts, it is to have alternate means and pricing of those contracts. Bugs can theoretically be fixed in open source for 'some amount of money or effort', however you are limited to the resources and whims of a single vendor if 'locked-in'.
I am glad slashdot is getting paid to publish articles, but you guys should be more objective or at least smell BS when you see it.
Re: (Score:3)
Fowler seems a reasonably sensible fellow... which is kind of rare. I've not come across a profession where people have their heads so far up their own asses as in IT Architecture. Solution Architects tend to be sensible, but the higher up you go the worse it gets, right up to
Re: (Score:2)
As one of the dreaded architects, I can assure you that I know some areas of expertise better than the people that work in that area, and have context and understanding beyond other areas of expertise that lets me add value to people who genuinely know what they're doing.
I'm sorry that you haven't had the pleasure of working with good architects.
Re: (Score:3)
Fowler's bloody excellent, but this article on his site wasn't written by him.
It does though explore multiple types of lock-in, and that is a useful little checklist.
This guys is.... (Score:5, Insightful)
from the article:
Formerly a technical director with Google Cloud
Does the content of the article surprise you?
Re: (Score:2)
Re: (Score:2)
Kind of weird, as a loser in the cloud wars, Google should be advocating interoperability, to give them a chance to catch up.
The interesting thing is that one of the big reasons for migrating to Kubernetes is that it puts a huge amount of what you are doing cloud-agnostic.
Re: (Score:1)
Thank you for not making me say it. I would not have been as eloquent or restrained.
Re: (Score:2)
Re:Who is this guy and... (Score:5, Insightful)
The reason we/anyone tries to dodge lock in is not to eliminate vendor contracts, it is to have alternate means and pricing of those contracts. Bugs can theoretically be fixed in open source for 'some amount of money or effort', however you are limited to the resources and whims of a single vendor if 'locked-in'.
I'm not sure if you read the article, but one core point the author is trying to get across is that Vendor Lock-in is just one type of lock-in. It is simply the one IT folks think about the most, to their detriment. The article mentions product lock-in, architecture, platform, skills, legal and mental. Open source really only helps you in one minor aspect of lock-in.
What we should be thinking of is implementation lock-in. How hard is it to change your implementation significantly? If you need to move to a new CRM, ERP, ESB, etc. whether or not your last platform was open source or closed source will hardly matter at all. How modular was your architecture, how well documented was it, what partner contracts must you support, etc. will be far more important.
Most of the implementations I work on would be considered in the "Accepted Lock-in" section of the author's matrix. Much of my work would have significant switching costs (PaaS solutions) but those platforms provide significant utility. If we moved off of Salesforce, our industry specific accounting platform, or MuleSoft each of those would have high costs, but our IT department moves so much quicker than when we were a C# shop that the decision to live with higher switching costs was a no-brainer.
Re: Who is this guy and... (Score:3)
The oroblem is not that the article is or is not worthless. The point is that the summary here on slashdot fucking SUCKS. Unless I was already a follower of this gentleman's writing, the summary promises absolutely nothing to me. Fuck that. I'm not wasting my time clicking through to every article.
Re: (Score:2)
Au contraire, the summary very accurately describes the article.
That it didn't entice you to read the article suggests that your interests lie elsewhere. That's fine.
Re: (Score:2)
It uses the phrase "lock in" as an assumed term; in fact, it uses it so casually that it seems to be meant to make you feel like an idiot if you don't already understand the use of the term. Now perhaps that's a term that is as obvious to you as "tree" or "IDE", but I'd never, ever heard of it before in the context of information technology, and I've been in the industry since 1987.
I submit that making assumptions limits your audience and makes the summary suck.
Re: (Score:2)
If only there was a web page somewhere that describes lock-in, what it is, and the many forms it can take.
Oh, wait.
Re: (Score:2)
At some point, though, isn't everything some level of lock-in because there are always switching costs and at most close-in levels of resolution there are no substitute goods.
Re: (Score:2, Insightful)
Choosing a programming language is a lock-in, according to the too-broad definition of TFA. Guess what, in RealLife(TM), every choice you make is a lock-in too. It's called committing to something and it is very different from being held hostage against your will.
Re: (Score:2)
Choosing a programming language is a lock-in, according to the too-broad definition of TFA. Guess what, in RealLife(TM), every choice you make is a lock-in too. It's called committing to something and it is very different from being held hostage against your will.
In RealLife (TM) the type of lock-in you are defining as too-broad is just as restrictive as anything a vendor can do to "hold you hostage." I have done nearly complete re-implementations of custom .Net/Java solutions and Oracle/SAP/Salesforce solutions, and custom software solutions were no easier to re-implement than the vendor specific solutions. The custom solutions gave us more flexibility, but they also usually had more poorly defined architectural boundaries. The vendor solutions more commonly had m
Re: (Score:2)
Yes, at some level. What the article is trying to get you to consider is that this isn't a black and white situation where all lock-in is bad. Rather, these choices have up-front costs and advantages as well as potential switching costs and potential problems. It's important to quantify and weigh these rather than trying to reduce it to an over-simplified rule.
This is true at a feature level as well. I've told people that they can't use a certain feature because of problems the feature introduces for one of
Re: (Score:2)
lock-in is alway bad unless they are paying you to do it. Even then you should think it through and make sure you can back out of it down the road in case some other investor comes in.
Re: (Score:2)
what a surprise, indeed! (Score:5, Insightful)
I'm putting my best surprised face:
An article that puts vendor lock-in (as in companies that want to prevent you from going elsewhere) to the same level as invested skill/dev-time/etc.
He's equating :
not being able to move away from google = not being able to switch away from some opensource solution because now all your assets depends on config files specifically written for the open-source software.
yeah right.
(bonus point, his 2x2 grids puts messaging app - of which google makes some - in the "easy to switch away from" category.
You know, because network effect is totally not a thing).
Re:what a surprise, indeed! (Score:5, Insightful)
"(bonus point, his 2x2 grids puts messaging app - of which google makes some - in the "easy to switch away from" category.
You know, because network effect is totally not a thing)."
If you do not use any of that crap then you cannot be locked in. Seems to me this guy is an airy-fairy cloud farkwad and everything that he says should be taken with a gigantic planet-sized boulder of salt. But then again if you are trying to "architect" something using only a hammer, you would tend to only use nails.
Re:what a surprise, indeed! (Score:4, Interesting)
I was surprised iPhones were considered "Acceptable" with a high switching cost but "Unique Utility". Really? Apple has strong vendor lock-in with both hardware and platform lock-in while Android only has platform lock-in. I'd even argue the platform lock-in is weaker thanks to things like LineageOS. The hardware lock-in is completely unnecessary and easy to avoid by not using iPhones. I think it is the very definition of stupid, knowingly accepting an unnecessary risk for no benefit. Stupid is not acceptable.
Re: (Score:2)
Yeah, his summary of different types of lock-in is interesting, but his 2x2 grid is facile and his quoted examples very much detract from the rest of his article.
I'd rather work with architects that can demonstrate innate understanding of the trade-offs without needing to misapply a model.
Costs of overengineering to overcome lock-in (Score:2)
I recently was in a project with what an "architect" divided into three major pillars, of which I was pulled in to drive one of them.
It so happens my team had work in that pillar and so I proposed using that, however, the architect declared that we should use external software. Ok, fine I suppose, which one?
The answer was that they wanted my team to create an abstraction layer to provide a common api to make our product be able to "swap" between any of about four open source projects in the field.
Now this
Re: (Score:3)
It's not that hard (Score:4, Funny)
A significant share of architectural energy is spent on reducing or avoiding lock-in.
It doesn't really take that much effort. There are only a couple of principles needed:
- Make sure that every room has at least one door
- Only install door locks with at most one keyed side
- Make sure that all of the locks are installed in a direction such that it is possible to get from any point in the building to the outside without needing a key
Your jurisdiction may require a few additional measures for safety, such as exit signs and doors that open outward.
Re: (Score:3)
And yet, despite this, at least 94% of development teams will somehow manage to find themselves in the basement with the lights off, behind a door they've nailed shut themselves, demanding additional funding so that they can add a window.
They'll blame the architect anyway of course.
Re: (Score:2)
- Ensure that fire escapes are never blocked or obstructed in any way
Re: (Score:2)
Don't laugh too fast, or too hard:
* Door locks to critical infrastructure that fail-locked when the power goes out.
* Halon (or other inert) gas fire suppression systems.
These have been put together in the past. People have died because of the combination in data centers.
Kinds of lock-in (Score:2)
The article really misunderstands what the issue with vendor lock-in is. If, say, you need a really big database and you have, say, scability requirements, then you probably want an established product rather than trying to develop the same in-house. If you choose poorly you might get stuck with a particular vendor and pay dearly in the long run. That's a matter of being lazy or careless in choosing the product, which is different from needing a software or hardware solution that can meet certain quasi-r
Re: (Score:1)
Lock-in is still bad for all the same reasons, but you might simply not have the choices you'd like.
Did you even read the article? Despite the awful summary here, it's pretty much along the same lines as your comment (as far as I could understand), meaning that lock-in has many different flavors, and is not a black-or-white choice -- sometimes lock-in can even be the best choice, as long as you choose it for the right reasons.
Stochastic correlation (Score:4, Funny)
However, based on my experience, when someone says "we don't need to worry about vendor lock-in," you can be certain that their project is over-engineered, and filled with every third-party library/gem/module/package/database they can find. Don't be surprised if they are using both MySQL and Postgresql, with Vertica and MongoDB on the side. It becomes so much of a load that they then need to hire a full-time engineer just to keep the codebase up to date as all the packages they depend on keep changing. Is it more work than writing the code yourself? Why not import all of Lodash, just so you don't have to write a single 'for' loop? No, it's not, and then everyone who joins your company has to learn Lodash or Yarn.
Re: (Score:3)
I'm curious what you see as the architectural costs of avoiding lock in.
"Architecture" is a metaphor that people sling around without being quite sure what they mean. There's actually an ISO definition of architecture, but it's super-abstract; what most people mean when they say "architecture" is design patterns and practices, and most sources of vendor lock in are actually anti-patterns.
Re: Stochastic correlation (Score:2)
Re: (Score:3)
Designing software is a continual tug of war between the concerns of the present and the future, isn't it? It seems to me the main cost of avoiding lock-in is taking time to think about it in advance -- and time is admittedly precious.
Unless the principles of operation of a system are somehow proprietary, or the particular way a concern is addressed requires unique vendor capabilities, vendor lock-in doesn't seem to be an architectural matter at all.
For example Oracle uses its database management system's
Re: Stochastic correlation (Score:2)
Re: (Score:2)
Re: (Score:3)
Sounds a lot like a failed startup project I worked on recently, the thing was a stupendous fractal pattern of complexity better suited to be run by a Silicon Valley megacorp than a couple of dudes moonlighting.
Re: Stochastic correlation (Score:2)
Lock-in avoidance can also stifle innovation (Score:3)
How convenient (Score:1)
How locked into anything are you really? (Score:2)
In the days when apps are almost a dime a dozen, why is lock in really that dangerous?
You can simply move to some other platform and spend maybe $20 to re-buy the handful of things you use that still cost money.
Interestingly this could be the one benefit of a subscription model to software, that way its easy to pay for a subscription to an app that you can use on any platform - so the more apps move to subscriptions, the less you would have to re-purchase at all! Someone was just discussing with me a way t
Re: (Score:3)
For an end user getting locked into a mobile platform perhaps it doesn't really matter...
How about getting locked into a messaging platform all your friends are using?
How about a corporate getting locked in to a system with terabytes of data and thousands of users?
Re: (Score:2)
I use three or five different messaging platforms that I deal with. Aside from miserable support of phone plus tablet on most, it isn’t that big of a deal. Certain people only use one of them, but being flexible makes it easier to segment things and keep options open.
Re: (Score:2)
Data portability.
Funny, a lot of buyers LOOK for it (Score:5, Interesting)
I worked for a large bureaucracy for 3 decades; while unwritten, the #1 rule of IT was clearly: seek lock-in with the biggest vendor you can find.
They loved IBM and clung to it to the bitter end. They kept buying actual IBM brand PCs, apparently out of a general feeling that it was better to be under Big Daddy's wing. Discovering Microsoft, the new rule was that if Microsoft had an offering in some product area, that was the automatic buy unless proven otherwise in triplicate.
Re: (Score:3)
No no, you misunderstand. That's not vendor lock-in.
That's a "strategic partnership".
It's like vendor lock-in but involves 'benefits' to senior managers.
Re: (Score:1)
Re:Funny, a lot of buyers LOOK for it (UGH - MS) (Score:2)
I was at a company that touted their long-standing gold-level partnership with MS. We had an enterprise platform for hospitals - full MSstack, IE-only, winforms, vb6, .net, SQL Server, etc. etc. Even drank the delicious Silverlight kool-aid.
Fast forward to when MS announces EOL for Silverlight. Meh, that's 2021 we'll figure it out by then. Then comes 2018. What will it take to rewrite our Silverlight app? 2 YEARS?! That can't be right... let's re-evaluate next year.
Heads in the sand. To date they st
Re: (Score:2)
Whoever decided Silverlight has a future was an idiot. Silverlight was always obviously a "we have that too" bullet-point filler to compete against Flash. Anyone who developed a serious internal app on either Flash or Silverlight deserves what they get. If it was trivial enough to replace, that's fine. But, to build your silo on top of either of those is pure short sightedness. Here's what I find interesting - how much business logic got baked into the front end? That's seems to be the root of the problem.
Re: (Score:2)
Whoever decided Silverlight has a future was an idiot. Silverlight was always obviously a "we have that too" bullet-point filler to compete against Flash. Anyone who developed a serious internal app on either Flash or Silverlight deserves what they get. If it was trivial enough to replace, that's fine. But, to build your silo on top of either of those is pure short sightedness. Here's what I find interesting - how much business logic got baked into the front end? That's seems to be the root of the problem. Putting a modern web UI in place of a Silverlight UI shouldn't be a big deal. Converting from Silverlight to WPF should be downright simple.
"Vendor support" is pretty irrelevant in the Microsoft stack outside of bug fixes. Ignore the fact the Microsoft supports SQL Server and hire someone who knows what they are doing. Consider your support money sunk in bug fixes and new versions. Once again, anyone who thinks otherwise doesn't have the experience to be in charge.
I don't know who decided it, but they are long gone. And this was not an internal app, it is the one-and-only platform that the company builds and sells, with 300+ hospitals as customers.
TONS of business logic built into the front-end. Of course, the platform was started 15+ years ago. Short-sighted things happen, as hindsight is 20/20. Someday we'll all be talking about how stupid it was to move everything to the cloud. It's just the evolution of software development, IMHO. The real danger is in not r
Avoiding vendor lock-in? It's just another cost. (Score:2)
The goal is to reduce the potential cost of vendor lock-in relative to the cost savings you gain from vendor lock-in.
For example, you've used spring to avoid database lock-in. Now you've locked yourself into spring, which is infinitely more difficult to get out of than database lock-in. Wrong choice.
You can always choose when lock-in is not in place (Score:3)
Unavoidable (Score:1)
This is something that's appreciable. Sometimes lock-in can't be avoided and isn't that bad.
The worst forms of lock-in I've seen often come about from avoiding lock-in.
Someone uses some magical mega portable abstraction layer to be able to use any database, except now they're locked into that abstraction layer which offers portability by providing a very limited subset of features, adds massive complexity on all fronts, adds uncert
Cost? (Score:2)
What good is quantifying lock in without actually quantifying cost, which I'd expect to be done for each project phase.
Example: we choose a language A for our product. ( in choosing langue A it is perfectly reasonable to assess the actual cost of implementation in language A)
Will it take twice as long? Do you have to pay developers with that skill twice as much? What if it takes 1/3 as longer but developers get paid half as much?
Which also ties into , how important is your timeline?
AFTER all the code is de