Cloud Virtualizers - Is virtualizing the virtual worthwhile?
Cloud computing is all the rage, and for very good reason. The economics of everything within cloud computing - Software-as-a-Service, Platform-as-a-Service, Infrastructure-as-a-Service, Storage-as-a-Service, basically anything "XaaS" - are just way too compelling to ignore. Unless you are: so big that you cannot gain any more economies of scale, e.g. GE or JPMChase; dealing with such sensitive data that you must host it on your own, e.g. Bank of America or anyone processing credit card transactions; or dealing with such flows of data in-house and on-location that doing it offsite makes no sense, e.g. Merck's corporate HQ in Whitehouse Station, NJ; then cloud computing makes all the sense in the world.
Of course, every new business model creates new business opportunities. For years, CIOs worried about "vendor lock-in." If I use an Oracle database, how painful is it for me to move to MySQL or MS-SQL if business dictates I need to? If I use ADP to process payroll, how difficult and expensive will it be for me to migrate to Paychex? Every vendor decision a business makes, and especially one in the IT realm, comes with a certain amount of loss of control. The level of difficulty in and cost of switching vendors to perform the same service or process, is what is known as vendor lock-in.
With the advent of cloud computing, wherein entire chunks of my infrastructure may be running on Google App Engine, Amazon Web Services, SoftLayer or any of dozens of cloud players, CIOs are, justifiably, concerned about vendor lock-in. In order to address this problem, several companies have either expanded their offerings to include or been formed explicitly to offer "cloud virtualization," and become, in my own words, "cloud abstractors" or "cloud virtualizers." In short, these companies will become your interface to cloud providers. You contract with them, they will "abstract" out for you from the cloud providers. You deal with them, they will handle your back-end, whatever your provider. Want to move from Amazon EC2 to SoftLayer? They will do it. Prefer Joyent over SliceHost? They will take care of it. Some even offer to migrate on the fly, in real-time. Essentially, these companies are offering to virtualize the virtual world, adding one more layer of indirection or abstraction. A significant player in this space is RightScale, the cloud management software and service company, who now have a "Cloud Portability" offering.
The question is, will they make it? Will cloud customers move en masse, or at least in large enough scale, to make these offerings viable? I believe that they will not, for two key reasons.
- Downline Lock-In: Let us say I buy a Cloud Abstractor's offering so that I am "liberated" from Amazon Web Services. Sure, I am no longer locked into AWS, but now I am tied into that Abstractor. Now, in theory, I could avoid it by dealing with two Abstractors, but then I am doing all the engineering and business work anyways, so I might as well go to the source and deal directly with AWS and one other. Additionally, if I am going to get locked into any one vendor, I certainly would prefer it be a solid, stable, committed company like Amazon than some other smaller player. This is somewhat reminiscent of how load balancers, like those F5 market for tens of thousands of dollars, were first deployed. First, you had one Web server, serving data. All was great, until it crashed, so you put in two of them. That is great, except one is doing all of the work, while the other sits idle, a pretty expensive waste of resource. Along came F5, sold you a load-balancer, and now you have protected yourself from one Web server crashing, and you had both serving data, a pretty good scenario... until the lone F5 load-balancer crashed. Easy to solve, they say, just buy two (very expensive) F5 boxes. So now you have two F5s and two Web servers. All you have really done is push the "vendor lock-in" (or, in the Web server case, point of risk) further down the line. It would be much better to solve it at the source, with your Web servers. None of this is to dump on F5, who have some pretty good products, but rather to point out that sometimes solving a problem with another solution just pushed it down the line. Same thing with Cloud Abstractors and vendor lock-in: if you solve it by pushing it down the line, you have just locked into a different vendor, when you might have been better off at the source.
- Timing of Expense: In order to avoid vendor lock-in, if it is desired and possible, requires ongoing expense. By contrast, if you want to move and already have vendor lock-in, it requires a much higher one-time conversion expense. Most situations of vendor switch, especially of locked-in products, are likely to occur infrequently, at most once every several years, and in many cases never, since by the time the switch occurs, new technology - infrastructure and applications - are likely to replace the old that was locked into the vendor. Given the infrequent costs and the even greater likelihood of technology refresh by then in any case, very few businesses are likely to invest in an expensive service or product that reduces vendor lock-in in the cloud computing space.
- Compensation: CIOs are compensated for what they deliver, not what they do not. Vendor lock-in, in a cloud computing situation (or almost any long-term investment), is not a problem for today, but rather one for several years down the line, at best. The CIO will get paid for delivering performance at a good price to his business, enabling the business to grow profitably. Cloud computing gets him/her there; worrying about lock-in just increases today's costs without bringing any short- or medium-term benefit to the business. Higher expense today to avoid a possible challenge in the future is a recipe for negative IT budgets, and thus works directly against the firm's - and the CIO's - direct financial interest.
In summary, I believe most CIOs will complain about vendor lock-in, wish it weren't so... and then move ahead anyways, for very good reasons.