Notes on vendor lock-in
Vendor lock-in is an important subject. Everybody knows that. But few of us realize just how complicated the subject is, nor how riddled it is with paradoxes. Truth be told, I wasn’t fully aware either. But when I set out to write this post, I found that it just kept growing longer.
1. The most basic form of lock-in is:
- You do application development for a target set of platform technologies.
- Your applications can’t run without those platforms underneath.
- Hence, you’re locked into those platforms.
2. Enterprise vendor standardization is closely associated with lock-in. The core idea is that you have a mandate or strong bias toward having different apps run over the same platforms, because:
- That simplifies your environment, requiring less integration and interoperability.
- That simplifies your staffing; the same skill sets apply to multiple needs and projects.
- That simplifies your vendor support relationships; there’s “one throat to choke”.
- That simplifies your price negotiation.
3. That last point is double-edged; you have more power over suppliers to whom you give more business, but they also have more power over you. The upshot is often an ELA (Enterprise License Agreement), which commonly works:
- For a fixed period of time, the enterprise may use as much of a given product set as they want, with costs fixed in advance.
- A few years later, the price is renegotiated, based on then-current levels of usage.
Thus, doing an additional project using ELAed products may appear low-cost.
- Incremental license and maintenance fees may be zero in the short-term.
- Incremental personnel costs may be controlled because the needed skills are already in-house.
Often those appearances are substantially correct. That’s a big reason why incumbent software is difficult to supplant unless the upstart substitute is superior in fundamental and important ways.
4. Subscriptions are closely associated with lock-in.
- Most obviously, the traditional software industry gets its profits from high-margin support/maintenance services.
- Cloud lock-in has rapidly become a big deal.
- The open source vendors meeting lock-in resistance, noted below, have subscription business models.
Much of why customers care about lock-in is the subscription costs it’s likely to commit them to.
5. Also related to lock-in are thick single-vendor technology stacks. If you run Oracle applications, you’re going to run the Oracle DBMS too. And if you run that, you’re likely to run other Oracle software, and perhaps use Exadata hardware as well. The cloud ==> lock-in truism is an example of this point as well.
6. There’s a lot of truth to the generality that central IT cares about overall technology architecture, while line-of-business departments just want to get the job done. This causes departments to both:
- Oppose standardization.
- Like thick technology stacks.
Thus, departmental influence on IT both encourages and discourages lock-in.
7. IBM is all about lock-in. IBM’s support for Linux, Eclipse and so on don’t really contradict that. IBM’s business model is to squeeze serve its still-large number of strongly loyal customers as well as it can.
8. Microsoft’s business model over the decades has also greatly depended on lock-in.
- Indeed, it exploited Windows/Office lock-in so vigorously as to incur substantial anti-trust difficulties.
- Server-side Windows tends to be involved in thick stacks — DBMS, middleware, business intelligence, SharePoint and more. Many customers (smaller enterprises or in some cases departments) are firmly locked into these stacks.
- Microsoft is making a strong cloud push with Azure, which inherently involves lock-in.
Yet sometimes, Microsoft is more free and open.
- Office for Macintosh allowed the Mac to be a viable Windows competitor. (And Microsoft was well-paid for that, generating comparable revenue per Mac to what it got for each Windows PC.)
- Visual Studio is useful for writing apps to run against multiple DBMS.
- Just recently, Microsoft SQL Server was ported to Linux.
9. SAP applications run over several different DBMS, including its own cheap MaxDB. That counteracts potential DBMS lock-in. But some of its newer apps are HANA-specific. That, of course, has the opposite effect.
10. And with that as background, we can finally get to what led me to finally write this post. Multiple clients have complaints that may be paraphrased as:
- Customers are locked into expensive traditional DBMS such as Oracle.
- Yet they’re so afraid of lock-in now that they don’t want to pay for our vendor-supplied versions of open source database technologies; they prefer to roll their own.
- Further confusing matters, they also are happy to use cloud technologies, including the associated database technologies (e.g. . Redshift or other Amazon offerings), creating whole new stacks of lock-in.
So open source vendors of NoSQL data managers and similar technologies felt like they were the only kind of vendor suffering from fear of lock-in.
I agree with them that enterprises who feel this way are getting it wrong. Indeed:
- The management of even NoSQL DBMS is a big issue, and help in that area has high cash value for customers.
- Serious users need support.
- Support and management tools happen to be synergistic with each other.
This is the value proposition that propelled Cloudera. It’s also a strong reason to give money to whichever of MongoDB, DataStax, Neo Technology et al. sponsors open source technology that you use.
General disclosure: My fingerprints have been on this industry strategy since before the term “NoSQL” was coined. It’s been an aspect of many different consulting relationships.
Some enterprises push back, logically or emotionally as the case may be, by observing that the best internet companies — e.g., Facebook — are allergic to paying for software, even open source. My refutations of that argument include:
- Facebook has more and better engineers than you do.
- Facebook has a lot more servers than you do, and would presumably face much higher prices than you would if you each chose to forgo the in-house alternative.
- Facebook pays for open source software in a different way than through subscription fees — it invents and enhances it. Multiple important projects have originated at Facebook, and it contributes to many others. Are you in a position to do the same thing?
And finally — most of Facebook’s users get its service for free. (Advertisers are the ones who pay cash; all others just pay in attention to the ads.) So if getting its software for free actually does screw up its SLAs (Service Level Agreements) — well, free generally comes with poorer SLAs than paid. But if you’re in the business of serving paying customers, then you might want to have paying-customer kinds of SLAs, even on the parts of your technology — e.g. websites urging people to do business with you — that you provide for free yourself.
Related links
- The technology underlying packaged applications (November, 2015, but it has a historical focus)
- Topics in migration (January, 2015)
- Much of the vendor advice on Strategic Messaging.
Comments
12 Responses to “Notes on vendor lock-in”
Leave a Reply
[…] As a companion to this post, I’m publishing a very long one on vendor lock-in. […]
Nicely done as always. One interesting observation: even some open source pioneers who create and continue to develop their own fork sometimes go back to vanilla. Facebook described their carefully researched decision to do that with HBase at HBaseCon this year.
Large enough projects may get “good enough” to compete with commercial alternatives – though at Gartner we never advise customers to go commando. FB still creates and contributes code – but it uses the mainline Apache version for production. They don’t want to lock themselves in – even to their own engineering.
Thanks for the great comment, Merv.
Obviously, the open source ideal is that you develop a feature you need, contribute it back, and it eventually becomes part of the main code line.
A good alternative is that you develop what you need, and — perhaps partially inspired by your need or even your code — the community implements a different solution, which turns out to be good enough for you, and also not too painful to port to.
This all suggests careful thought both about what kinds of extensions to make and how to architect the technology to minimize future migration risks.
I would mention another “design trade-off” kind of lock-in we get from NoSQL. NoSQLs are quite different, there is no standards and each one took different design trade-offs. So it is almost impossible to take system built over one NoSQL and port to other, or, in the base case, choice will be quite limited.
David,
I think that matters only in a small minority of cases. Why? Because in most cases, people wouldn’t port even if that limitation weren’t present. To see that, please consider two generalities:
1. Most relational apps will never get ported to a second RDBMS.
2. Many customer-facing apps are “disposable”, and will be thoroughly replaced at some point rather than going through the long lifecycle internal apps have experienced over the years.
Curt,
I think situation is different for NoSQL. We are not in the stage when we customer buy application A and it is require database B.
We have customer building application A and selecting what NoSQL database to use. I did saw number of cases when customer users like the service but underlying technology limit its evolution and options are evaluated…
This is an excellent post, and lays out the complex factors that are often at odds when it comes to vendor/technology selection and management. I especially agree with the ending points about FB having better engineers (and a ton more of them) than the rest of us (or at least most of us), and if you have a paid SLA from your own customers, having paid SLAs with at least some of your critical vendors is important.
One thing I think you could delve more into is the lock-in from cloud services. This is very similar to an all-Oracle stack (or similar), but I fear over time the lock-in could be much worse. As the cloud stack moves “up” performing higher-level services, it does make things easier — at first — but then I have seen ways it can really make things tougher and limit your ability to innovate. Obviously AWS has the most highly evolved cloud services, but as those are evolving it can be a trap to enter into extensive use of them in an integrated way, especially early on. It’s great for small startups to get going, and yes some services work well for larger development organizations (like the database stacks you mentioned), but it really opens up the future potential for losing control of costs — and competitiveness. If your delivery depends on ongoing innovation, it’s important to really evaluate what those services do, how you can do them otherwise (and if you should), and then pick very carefully.
Thanks for the compliments about my co-workers. Enterprise open source, meaning you sign a license to get value-added non-open bits, is an interesting topic. I think MongoDB is doing a better job at this than companies that preceded them, maybe they had more time to learn and they definitely have more resources/funding. The must have non-open bit with MySQL was InnoDB hot backup. It seems like there are a few more must-have non-open bits with 10gen.
[…] I usually think that the advantages of open source are overstated, in SequoiaDB’s case open source will have an additional benefit when SequoiaDB does go […]
[…] I usually think that the advantages of open source are overstated, in SequoiaDB’s case open source will have an additional benefit when SequoiaDB does go […]
[…] I usually think that the advantages of open source are overstated, in SequoiaDB’s case open source will have* an additional benefit when SequoiaDB does go […]
[…] Open source purity. Ditto. But at most enterprises — at least those with hefty IT budgets — emphasis on open source purity either is a proxy for price shopping, or else boils down to largely bogus concerns about vendor lock-in. […]