06
JAN
2014

Vendor Behaviors

Cloud computing has clearly been disruptive to certain vendor business models.  This section is targeted to people who seek insight into vendor behavior.  Sometimes a vendor business model benefits the community (themselves, partners, customers and the industry) and sometimes it does not.  It can be important to distinguish between the extremes.

Vendor lock-in is when the purchase of a vendors products essentially locks you into continuing to purchase – literally – everything – that vendor sell forever.  But you already knew this.  Everybody understands the phenomenon.  The damage is that a vendor can command outrageous product margins at the buyers obvious expense and suffer minimal competition.

Vendor lock-in should be avoid at nearly all cost!

What is interesting to me is that there seems to be three kinds of suppliers in the world:  those that enjoy total lock-in but claim they don’t and that lock-in is evil; those that wish they had lock-in yet denounce it when others have it, and open source solutions.

To be clear, there are two vendors in the space of interest that have an immense degree of lock-in.  Their strangle hold on the user community is so profound that it should make John Maynard Keynes and Adam Smith roll over in their graves.  More on this follows.

Server-side lock-in and some useful history

Servers used to be a lock-in industry.  Sun Microsystems – ’nuff said.  This lock-in is centered on the tight binding between Sun hardware and Solaris.  Together, they prevented an easy switch to a different product and commanded monster margins.  As Linux grew in popularity, it was most cost effective to run it on an already commoditized x86 server.  Therein lies the genius.  If you separate the hardware and software, you gain choice in each.  Even today Linux runs on many, many hardware platforms.  Similarly, those hardware platforms all support multiple operating systems.  Either there is meaningful choice or there is lock-in.

In the nineties and early parts of the 21st century server side lock-in prevailed.  It was broken by open source efforts and hardware competition when hardware was no longer able to exploit proprietary elements of an operating system.

However server side lock-in still exists.  Specifically, ESXi, Hyper-V, KVM and Xen are 95%+ equivalent.  However the costs are different by several orders of magnitude.  VMware management tools allow custom scripting in other integration mechanisms which have locked-in anachronistic automation.  Further, because of history, people just know vCenter.

Data-centers cannot just flip hypervisors,  This is done one server, one rack, or one pod at a time.  Doing so involves reworking automations tools, Chef and Puppet recipes, and custom tools.  The essence is that swapping out VMware is not easy – and this is of course, by design.  The cost penalty, as shown in Hypervisor economics, is devastatingly material.

This is also among the largest impediments to the adoption of OpenStack.  How can VMware and KVM be co-resident in a truly meaningful way?

One answer, as we have previously mentioned is Hotlink.  In our opinion they are the potential killer of the VMware’s lock-in.

Network lock-in; the greatest lock-in coup of the past two centuries

Cisco’s innovation in maintaining and advancing the cause of their vendor lock-in is nothing less than spectacular in my opinion.

Cisco lock-in algorithm # 1: when you see a standard under development that may level the competitive playing field over time, then develop a competitive proprietary product, stall the poop out of the standards effort, get everyone hooked on the proprietary solution, then adopt the standard; often years later than necessary.  At the same time release the proprietary solution to the open as a standard.  Lather.  Rinse. Repeat.

Don’t take my word for it.  Check out http://en.wikipedia.org/wiki/Category:Cisco_protocols.  This is a wikipedia list of such protocols.  This is an old list but 28 times makes a pattern in my opinion.

Cisco lock-in algorithm #2:  If someone opens a new market segment that Cisco hadn’t thought of, buy them.

Cisco lock-in algorithm #3:  If someone opens or exploits a new market segment and that market segment threatens a different market segment dominated by Cisco, then buy the company and dissemble the encroaching company.  Bury the bodies.

Ultimate Cisco lock-in algorithm ever:  I mean ever.  Insieme Networks.  This is a proprietary TOR, a proprietary Spine, a proprietary distributed vSwitch, a proprietary application defined automation mechanism, and proprietary management stack.  Cisco claims it is “open” because it may share some software components with other proprietary partners, and it touts “open APIs.”  This last claim is laughable.  Microsoft opens APIs as well but no one on earth (that I know of) considers Windows to be open.  Cisco has also done a truly masterful sleight-of-hand trick as well.  It joined an open source community called Open Daylight whose solutions “compete” with Insieme, yet Cisco claims to be an open source networking and hypervisor vendor implying Insieme and Nexus products, when there is really only open daylight – a competitive trick at best.

The economics of vendor lock-in

The your vendor makes 60% – 90% margins on products with apparent competition, the competition is either not real or shut out.

It is painful to switch from an incumbent proprietary solution to one that is new and requires new learning, integration, etc.  Often the pain of the change to open solutions is worse than the pain of doing nothing or staying the same.  However, one must pay the cost of doing nothing every year in the form of extraordinarily high prices (not a little higher – we mean HIGHER).  It’s just a choice.  We try not to let our customers reach a point where they need make such a difficult choice.

Open-source business models and vendor lock-in

I don’t think that because software is open source, it is open in the market.  It’s not free either; but it is far better than the closed forms of lock-in described above.  Take Redhat for example,  With RHEL you pay an annual fee.  That fee gets you (excellent) support for one year, and it gets you a binary distribution that you may use (typically on one socket), and you get a piece of paper saying that all software used to compile the binary distribution is available freely on the net.  But Redhat does not tell you/help you find out where that open source software is, in how many repositories, if there are open source build tools, etc.

The major value to open source is that if Redhat were to cease support for RHEL or go out of business (both massively unlikely), someone would be able to pick up the slack.

This is not open in the pure sense – but there is a lot that is close, and there is little to no trickery or misleading arguments.

Author Dave Butler of Under-Thunder

About the Author

Leave a Reply

*

captcha *