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.
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 =) ]
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 :)
Don't blame the people who happen to think two steps ahead for not buying a particularly shiny proprietary gadget ;)
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 ...
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.
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.
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.
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.
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.