Or so I’m told. Not just once or twice, but it’s something that is written down at least once each time a vendor introduces something new or when a revision of an existing product is rolled out.
Now, you could say that this is the pot calling the kettle black and I would agree with you. It’s a thing I mentioned in my UCS post, and also in my recent post on the stack wars. And today a tweet from @Zaxstor got me thinking about it some more. I asked the following on Twitter:
I hear this argument about vendor lock in all of the time. Open question: How do I avoid a vendor lock in? By going heterogeneous?
Because, when you think about it, we all are subject to vendor lock-in all of the time. As soon as I decide to purchase my new mobile phone, I am usually tied to either the phone manufacturer or the carrier that is use. Sometimes I am even tied to both, you just need to think about the iPhone as an example for this kind of lock-in.
The same goes for the car I drive. When I buy it from the dealer, I get an excellent package that is guaranteed to work. Until I take it to an inspection with a garage that is not part of the authorized network. My car will still drive, and will probably work great, but I no longer have a large part of the guarantees that came with it when I bought it, and would have been intact if I had taken it to an authorized dealer.
Now, I know my analogy is slightly flawed here since we are talking about things that work on a different scale and use entirely different technologies, but what I am trying to say is that we make decisions that lock us in with a certain vendor on an almost daily basis. Apparently the guys in and around the data center just like to talk about that problem a bit more.
One remark was made however by fellow blogger Dimitris Krekoukias and confirmed by several others:
“It’s not how you get in to the lock, but how you get out of it.”
And I do think that this is probably the key, but fortunately we have some help there from the competition. But it’s not all down to the others! All vendors are guilty with trying to sell something. It’s not their fault, it’s just something that “comes with the territory”. They will try to pitch you their product and make your head dizzy with what this new product can do. It’s all good, and it’s all grand according to them.
And yes, it is truly grand what this shiny new toy can do, but the question is if you really need it? Try to ask what kind of value a feature will offer in your specific setup. Try to judge if you really need this feature, and ask yourself the question what you are going to do if the feature proves to be less useful then expected.
Remember that not all is lost if you do lock yourself in with that vendor. Usually others will be quick to follow with new features and this is where the help from the competition comes in. Take the example with the mobile phone. Even if you will not receive any help from your current provider, you can bet that the provider that now also offers the same package will try to help you to become his customer. If NetApp is not providing you with an option to migrate out of that storage array, you can bet your pants that Hitachi will try and help you migrate to their arrays.
Now, I’m not saying that this is the best solution. Usually exchanging solutions is also accompanied with a loss of knowledge and investments that were made. But it’s all on you to factor that in before you take the plunge, and in the end that lock that you have with your current vendor might be hard and expensive to break, but usually it’s never a mission impossible.
P.S. Just as a side note, I’m not saying NetApp will not allow or help you to migrate out of an array, I’m just using these names as an example. Replace them with any vendor you like.
P.P.S. Being part of the discussion fellow blogger Storagebod posted something quite similar, be sure to read it here
BasRaayman's Technical Take 
Bas, good post & I agree. I would like to add, however, that one of the great attributes of virtualization is unlocking the coupling of HW/SW and consequently providing the ability to seamlessly move between platforms whether compute hosts, storage arrays (with vSphere Storage vMotion), data centers or clouds (with Open Virtualization Format).
Thanks for your response Steve!
Oh yes, virtualization is a great thing and does give you these options. But what if I want to change between virtualization providers/hypervisors? If I choose Hyper-V I am locked in there and have a hard time going to VMware and vice-versa. And again, the competing vendor will usually help me get there, but I’m not really expecting VMware of Microsoft to help me get out of their lock.
Same goes for UCS for example. It solves a lot of my problems, but migrating out can be a real pain since it’s just something that a vendor will not necessarily have their focus on.
Good post, my msg was specific to VBLOCK.
Vendor lock in is inevitable in every space, however the integrated solutions such as VBLOCK and MATRIX are pitching a whole new level of lock in. Instead of being locked in by one vendor in the stack, you are defining the entire stack for the foreseeable future. In your analogy, imagine you buy a new car every month. The first time you buy a car, you are making the decision to purchase your fleet of cars from that manufacturer for the foreseeable future.
Companies need to strategically choose who they get in bed with, because those relationships are long-term. VBLOCK assumes that you want to and will stay in bed with VCE for your virtualization & cloud strategy. For me, the value of VCE isn’t there to make that commitment. Especially when my business may dictate that I move in different directions quickly.
I am a proponent of change. I would rather develop the right strategy to get to the change. A black box of vendor lock in gets me there faster, but at what cost? Lost agility? Higher acquisition cost? Reduced flexibility? I buy the end result, however I think there are multiple ways to get there. For customers that are immature in the virtualization stack, I see VBLOCK as a great way to mature the stack quickly. For customers that have been there and are already pursuing an internal cloud strategy VBLOCK doesn’t seem to offer much.
I see your point, but I am not sure I agree to that 100%. Yes, I can get a vBlock and that means that if I want to run that thing sensibly, I need to fill it up as good as I can. But I could also just purchase HDS’ “Innovative Unified Compute Platform” and work with Hyper-V for installations after that.
It will offer more complexity to manage, and I might have a hard time switching my VM’s from one block to the other, but I dare say that we will be seeing migration strategies. It’s just going to be hard on the early adopters, but I do actually see some value in the building block unified strategy, although I agree with you that it’s not the same value for everyone considering the purchase.