Lock-In Is Inevitable – Get Used to It!

For whatever reason (subliminal messages from vendor marketing departments?), I’m constantly brooding about the vendor lock-in, its inevitability, and the way supposedly disruptive companies try to use the fear of lock-in to persuade naive customers to buy their products.

OpenFlow controllers are just one of the examples that come to mind. Sure, you can use them to control a fabric of cheapest switches you could get at eBay (ignoring for the moment that no two switch vendors offer the same set of OpenFlow capabilities), but you’ve just replaced hardware lock-in with software lock-in – try replacing NEC’s ProgrammableFlow controller with Big Switch controller or Open Daylight controller.

Umbrella orchestration products like Tail-f (now Cisco) NCS and Anuta Networks NCX are no different (see also the excellent A-B-C of Lock-In post by Massimo Re Ferre).

Other areas of IT fare no better. Try moving from Ubuntu to CentOS, or from Oracle to MySQL – the consumers of these products (application developers) rely on subtle discrepancies between the products to make their job easier (example: stored SQL procedures), inevitably locking themselves into a single product.

The only way forward is to go through the five stages of grief, accept the inevitability of lock-in, stop fighting against it (because you can’t win) and figure out ways to cope with it. The ancient Romans knew one of them: divide and conquer.

For example, don’t complain about the lock-in effect of vendor fabrics (Brocade VCS Fabric, Cisco ACI or DFA, Juniper Virtual Chassis Fabric, HP IRF, Plexxi ring … you get the idea), use them in designs where lock-in won’t hurt you – build a modular data center infrastructure where you use proprietary vendor fabrics within a single availability zone, and link availability zones with boring age-old technologies: IP routing and OSPF or BGP.

On the other hand, if you design your data center as a single vendor-specific fabric, and link multiple data centers built with this approach with vendor-specific layer-2 extension technology, stop complaining about the lock-in you deserve.

From Theory to Practice

Want to know more about data center technologies? Watch ipSpace.net data center webinars. Honing your design skills? Data Center Design Case Studies or ipSpace Design Clinic might give you additional ideas.

11 comments:

  1. Great points. You've articulated well thoughts I've had on this subject for a while.
  2. Amen. How about focusing on solving your business problems instead of worrying about being 'locked in' ?

    The business couldn't care less about 'lock in' - in fact most business people would be happy to be locked in to a technology that is solving their problems.

    It seems to be the IT folks who must appear to be the smartest people in the room at every meeting who worry about this kind of nonsense like lock in.

    Just solve the problem you're trying to solve in a cost effective, supportable, and consistent manner.

    [ Disclaimer - I work for a vendor in case you couldn't tell =) ]
    Replies
    1. I've encountered multiple cases where choosing competing vendor Y over established vendor X immediately made the latter much more flexible both in terms of pricing and support (bugfix turnaround time and new feature rollouts).

      While having multiple vendors does add operational and logistic headaches, it gives the freedom or choice and allows for finding path out of 'dead-ends' like those created by some platform Z :) This, by far, out-weights the above mentioned headaches, while minimizing risks for business, just as with any properly managed diversification.

      The general conclusion is that it's natural for a vendor to be unresponsive and arrogant when it fully "owns" the customer - just like in case of any monopoly. That's just how things seem to work after all. Could it be different? Maybe - in a perfect world :)
    2. Unfortunately those same business people often suddenly decide to go with the second vendor due to an enticing New Year Special, and blame the IT folks when they cannot do that because someone created a lock-in when trying to solve business problems with insufficient budget or when faced with clueless demands (follow-the-sun VM mobility comes to mind).

      Don't blame the people who happen to think two steps ahead for not buying a particularly shiny proprietary gadget ;)
    3. In the server world, there is "lock in", but the fact that OS's and hardware are based on a well-defined standard (the x86 PC) means that users can choose to change hardware vendors without changing software vendors, and vice versa. This significantly reduces the effect of "lock in" in many practical ways.

      Networking is going through this same transformation now with "white box" switches and standardizing on hardware designs like Open Compute Project (OCP) switches. Open Network Linux (recently adopted by OCP as an official project) will also open up an avenue for people to treat their commodity white box switch hardware like they have treated their x86 Linux servers.

      This is a very practical and real way in which "lock in" will lessen in the next few years as this disaggregation of software and hardware in networking becomes more prevalent ...
    4. In the past I worked 22 years at my country's major Telecom/ISP.

      We always used a at least 2-vendor politics in every tech. WDM, PDH, SDH, IP, Voice etc.

      Very effective to keep prices down, service up and the vendor representatives on their toes. When one got too arrogant, just mention the competitor's name, then the impossible suddenly got possible.

      Of course, keep away from proprietary solutions, or keep them at least revertible without huge impact.
    5. Strangely enough, the next step of vendor lock-in comes from your own company.
      Over time, one develops systems to maintain, administer, troubleshoot, communicate, supervice, capacity plan everything.
      Suddenly you find, that the money spared implementing a new and better vendor will be eaten several times,- because of expenses used to re-program and adjust your own tools to keep the engine running. So you're vendor locked again.

      Keep your own system open and don't let the vendors know too much about your business. They're good at smelling problems.
  3. 1) Decentralize. The more central a product to the network, the more likely it is to get ingrained and enable lock-in. The distributed internet is not locked in to any vendor. The centralized world of Telcos and OSMINE certificed OSSs was fairly locked in to the OSS vendor (Bellcore).

    Or alternately use truly open source + home grown management products in central locations.

    2) Use vendor A in zone A/ region A. Use vendor B in zone B/ region B. Threaten to increase or decrease their footprint based on performance. Now you can live with lock-in within the regions and yet have leverage against the vendor. Not all networks can afford to do this however (because it may mean two sets of admin teams unless there is frequent knowledge sharing and talent rotation).


    Disclaimer: Opinions are strictly mine alone.
  4. Your architectural guiding principal should be to adopt solutions that are open, flexible and compatible with leading vendors. You can MITIGATE vendor lock in, not eliminate it. As some have pointed out, sometimes the business is presented a deal they can't refuse. Sometimes the business demands something (let's say, automation and programmability) and the cost of going with a new solution is much higher than modifying your existing solution, even though the new solution would be far better. You then just dig deeper and become more entwined with your vendor.

    On the flipside, if you choose your PAAS stack wisely, you can transparently switch server and storage vendors (knock on wood). If you choose your orchestration wisely, you can phase new hypervisor vendors in and phase old ones out more or less painlessly, as well as burst externally.

    But if you just drink the cool aid and accept every single thing a single vendor sells you under the auspices of "holistic integration", you will find that you cannot introduce new products quickly or easily.
  5. Nice point of view, I was just recently talking to guys from Cisco who were trying to convince me that ACI is actually less of a Lock-in cause it supports various Hypervisors... but as you said - "use them in designs where lock-in won’t hurt you", everyone has their own story with the SDN...
  6. Many years ago we decided to use well-known brand of switches. Then we decided to use some unique features from this vendor. Perfect vendor lock-in!

    This year happened something even WORSE than vendor lock-in: this vendor took over another company and decided to replace its switches with newly bought toys.

    Guess what? These new switches are not compatible with the original switches we have been using for years and we need to redesign our product just because our vendor cannot deliver old features. We did not want to change the vendor BUT the vendor changed itself causing huge problems for us.
Add comment
Sidebar