Bas raised a question about vendor lock-in on Twitter and discuss it in his blog; generally if lock-in is inevitable, why moan/fret so much about it. Lock-in is one of those things I do fret about a lot.
Firstly, I think lock-in is bad in principle; in the ideal world, lock-in would not exist! Everything would interoperate and there would be no migration issues at all. You could take any application and bring it up anywhere, all features would be universal and life would be simple.
Secondly, I am pragmatic and quite simply know that this is never going to be the case. I am a pragmatic idealist!
So with those two thoughts in mind; I would like to take the discussion a little further.
Imagine one day you are sitting in your abode; the doorbell rings and a shiny-suited salesman introduces himself. He's working for a new power-company and they can supply electricity at half the cost and it will also make your house smell nice! The only catch is you'll have to replace all your wiring and none of your appliances work any more. You will have to replace everything but it will be cheaper, it will be better! And of course, you'll only ever be able to buy this electricity from this one supplier. If you ever want to change back to the standard electricity, you are going to have to change everything again!
You might think about it but I suspect you'll probably decide to stick with your standard electricity. You have chosen your lowest common denominator.
We make these kind of decisions in our personal lives all the time; now as an idealist, I really don't like the walled garden approach that Apple have taken with the iPhone and iPad but as geeky pragmatist, I've decided to compromise.
The question is where does that point come in IT? It will vary from deployment to deployment.
And there have been various attempts to build standard environments; look at the promise of Java and the Java Virtual Machine. Write Once, Run Anywhere but that rapidly turned into Write Once, Debug Everywhere; Java implementations differed slightly, different features exploited the underlying hardware. People's lowest common denominator was not quite where Sun expected it to be.
It is also entirely possible to write standard 'C' which will compile and run anywhere but you might find yourself limited as to what you can actually do.
It would also be possible to treat a storage array as a dumb JBOD and utilise none of the features that it provides.
All of these things would enable a great deal of portability between systems of all types but you would probably find that you weren't getting a lot useful done.
So perhaps there might be a better way, perhaps a hypervisor to provide abstraction between the underlying hardware and the operating system? The hypervisor could ask the underlying hardware as to what features that it can provide and then provide access to those features in a transparent method, it might even implement the missing features in software. You have removed the lock-in from the hardware but you are now potentially locked into the hypervisor upwards.
Standards might protect you, there's one for everyone.
Only you can decide where your lowest common denominator is; you might not have one and everything will be best of breed and a custom build. You might insist all applications have to run on top of a standard stack. You might insist that everything should be able to seamlessly run in the public and the private cloud. It could be that you decide that you must have company 'X''s unique feature which no other vendor has and is ever likely to have.
All of these decisions will impact how locked-in you feel and more importantly how hard it is to get out the lock-in. As I say, in the ideal world, migration would be seamless and universal.
But that'd be really boring wouldn't it!?
You decide how exciting you want your life to be!
