July 19, 2016

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:

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:

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:

Thus, doing an additional project using ELAed products may appear low-cost.

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.

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:

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.

Yet sometimes, Microsoft is more free and open.

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:

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:

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:

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

Comments

11 Responses to “Notes on vendor lock-in”

  1. Notes from a long trip, July 19, 2016 | DBMS 2 : DataBase Management System Services on July 19th, 2016 9:36 pm

    […] As a companion to this post, I’m publishing a very long one on vendor lock-in. […]

  2. Merv Adrian on July 20th, 2016 4:39 pm

    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.

  3. Curt Monash on July 20th, 2016 5:07 pm

    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.

  4. David Gruzman on July 21st, 2016 4:56 am

    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.

  5. Curt Monash on July 21st, 2016 5:16 am

    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.

  6. David Gruzman on July 21st, 2016 5:43 am

    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…

  7. Cory Isaacson on July 21st, 2016 9:09 am

    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.

  8. Mark Callaghan on July 22nd, 2016 10:05 am

    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.

  9. Introduction to SequoiaDB and SequoiaCM | DBMS 2 : DataBase Management System Services on March 12th, 2017 2:19 pm

    […] 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 […]

  10. Introduction to SequoiaDB and SequoiaCM – Iot Portal on March 12th, 2017 7:33 pm

    […] 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 […]

  11. Introduction to SequoiaDB and SequoiaCM – Cloud Data Architect on March 17th, 2017 8:45 am

    […] 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 […]

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.