So I saw some comments about Azure and how supposedly a lot of people seem to think that vendor lock-in is a bad thing.
I don't understand why anyone would put down vendor lock-ins as a bad thing; you're locked-in regardless of what technology you pick: you choose PHP and good luck getting asynchronous server processes to work. You forgo flash and no streaming videos for you. You abuse proprietary SQL extensions mostly because they're worth it.
I'm not saying any of these are bad, nor that they are a must have. The point is that if you're going to wait for the perfect environment, you'll never get anything done. And on a related note, if you are just finding an excuse to defend your favorite blub technology against the powers of evil, then chances are that you're not actually doing anything worth anyone's time :)
For the rest of us, the show must go on, so let's get on with the program, shall we?
I agree Leo...
ReplyDeleteThe elimination of vendor lock-in completely is impossible, but vendors of cloud products can make their systems less prone to lock-in by allowing customers to get their data out easily and constructing their platforms to be infrastructure neutral. As platform developers we do need to write special code for different cloud vendors, but our strategy has been to make that special code work other places as well so the binaries can run anywhere.
I wrote a lengthy post about the vendor lock-in issue here: http://www.qrimp.com/blog/blog.The-Open-Cloud----the-future-of-cloud-computing.html
Some things we @ Qrimp have done to help our customers leave us if they need to include the ability to:
1) Download a full Microsoft SQL Server backup of their database they can restore locally.
2) Allow customers to download SQL INSERT and CREATE scripts so they can move their data to MySQL or Oracle or any other ANSI compliant DBMS.
3) Keep customization functionality limited to standard technologies: HTML, CSS, JavaScript, and SQL
4) Allow the platform to run on nearly any Microsoft system including: laptops, cloud services like Mosso now and EC2 and Azure (coming soon), VPS, colo, even shared hosting at GoDaddy.
Of course, even with these capabilities, if they want to leave Qrimp, they'll have to re-write all the code that the Qrimp platform does for the developer natively, but they are stuck with us if they want to leave. Even open source platforms have a certain level of lock-in. If you build a site on Drupal and want to move it to Joomla, how do you do that? Are you locked-in to Drupal? You aren't paying for Drupal, but Drupal does cost you money if you have to pay someone to extend it or it doesn't do things quickly or easy enough. Time is money.
Decisions like ours to do our best to eliminate lock-in are very counter-intuitive to the business community. MBA's want lock in so customers can't leave, but lock-in prevents them from coming at all. Our strategy is to make it easy to come into and leave Qrimp, but make them love it so much they want to pay us whether they use it or not. We want our customers to want us to succeed, not resent us for making their lives harder 1 or 2 or 3 years from now.
Point is, the elimination of vendor lock-in is impossible when your cloud platform automates anything. If you leave, you have to manually do the automated features or rebuild them somewhere else.
If you love your customers, set them free. If they come back, they are yours forever.
- randall
CTO, http://www.qrimp.com
http://www.qrimp.com/blog