On Cloud Lock-in, Standards, Decoupling and why SaaS does not scale

With security and legal concerns being slowly addressed by the industry, lock-in and standards are rapidly becoming the biggest concerns regarding cloud computing. If the cloud industry is to make good on its promise, these will need to somehow be addressed. Let’s examine some recent developments.

Interesting to see how, just a week after my blog on “The Principles and Perils of Vendor Lock-in” *1 several vendors made announcements seemingly supporting my suggested approach. For example, after hinting at the potential benefit of decoupling SaaS and PaaS from its underlying Infrastructure (IaaS) layers, Microsoft announced it is making Azure available as a PaaS platform to several large IaaS providers *2. Now I am sure this had nothing to do with my blog on preventing lock-in and all to do with a desire in Redmond to increase market share for their PaaS platform, which ironically - if too successful – may even increase lock-in. But the move will offer customers who select Microsoft’s PaaS platform a choice of vendors for the underlying Infrastructure services (IaaS).

At the same time NASA and Rackspace announced they are joining forces around an open source platform for Private Clouds called OpenStack *3. Rackspace’s initiative is no doubt as commercially motivated as Microsoft’s’. If Rackspace –in my view correctly - expects that many private clouds in the foreseeable future will start to source additional capacity (cloudburst) from public clouds, then having these private clouds be based on the same architecture as their public cloud offering will help Rackspace. NASA's motives stem from the US governments cloud stimulus approach *4 , a specific stated goal of which is “to accelerate the creation of cloud standards”. If history is to repeat itself, we can expect to first see industry standards lead to a “plug compatible cloud market”, before a serious “open standards cloud market” will take shape. As NASA is determined to have workable cloud standards a lot faster than the decade or so it took to get a man on the moon, it is understandable they see the Rackspace route as a viable shortcut. This is also understandable because agreeing on open cloud standards today would be as difficult as agreeing 3D TV standards back in the days of the black & white moon landing broadcasts. (And, reader beware, if there ever was a time to keep options open and not lock yourself into what looks to become an early standard , it would be today).

A decoupled cloud

For many readers my recommendation to prevent lock-in by decoupling the choice of application (SaaS) and platform (PaaS) vendors from the underlying choices of infrastructure (IaaS) vendors was pure heresy. Their logic was this: if you want control over underlying layers you should not embark on cloud computing because the whole idea of cloud computing is that someone else is responsible for the underlying layers. But that’s like saying that: if you don’t want to buy clothes that were made by under aged children; you should get a sewing machine and make your own clothes.

Others struggled with imagining what such a decoupled cloud would look like in practice. Luckily, also last week (it was indeed an eventful week for cloud computing) a first real live example of such a decoupled offering went live. Skygone Inc. announced they were offering a choice of GIS (Geographical Information System) services *5 by aggregating solutions from several GIS software vendors across a choice of infra-structure platforms and vendors. Companies in need of such geographical information – which is a complex and specialized area, beyond the expertise and interest of most internal IT departments - can now simply source this without locking themselves into a specific vendor or platform. (Disclosure: Skygone uses as underlying platform Applogic from 3Tera, now owned by my employer CA Technologies.)

Several analyst firms predicted early on that this type of “brokering of cloud services” would become an important market force. But in recent months –maybe under the influence of several self-proclaimed 100 pound gorilla’s entering the cloud market – the analyst community became very quiet about the concept, which is a shame because it also addresses the fact that in an enterprise context “SaaS does not scale”.

• SaaS does not Scale?
• Now before readers get all wound up (again), with “SaaS does not Scale”, I do not mean that SaaS applications cannot scale to service millions of users. They do already, although some more successful and reliable than others. I mean that the average enterprise or government organization, which typically has a portfolio of several hundreds or even thousands of applications, can simply not afford to source these from a similar number of SaaS providers. The mandatory auditing of the infrastructure and processes of all these providers would simply not be feasible, also as a leading analyst firm just pointed out that a SAS70 certificate is no replacement for such mandatory due diligence *6a. They did so at about at the same time they suggested that for many a SaaS vendor it would make sense to partner with IaaS vendors for delivery of their services *6band that the traditional SaaS market may not grow to be as big as many initially expected *6c (shows once more that predicting developments and/or placing customer bets in a brand new area like cloud computing continues to be a risky business).

A better way

Summarizing the described mix and match approach of a decoupled, brokered cloud aims to allow enterprises to select the applications they need from several SaaS vendors, pick the platforms they like from a choice of PaaS vendors and deploy these across their choice of selected and audited IaaS vendors, without running into lock-in or scalability issues.

Now it is important to understand that this approach does not in any way, shape or form resemble the old way IT used to work. Let’s use an analogy from the consumer IT market to describe the difference:

• IT, the old way: As a consumer you would go to a computer store to pick a software package, let’s say a cooking application. From the 20 available offers you pick one (likely the one with the nicest picture on the box), only to arrive home and discover your PC has a release of the operating system / database / browser that is not supported. After fixing this (there goes the weekend), you still cannot get it to run. You solicit some consulting from your neighbor/nephew/colleague; while your spouse remarks that at this rate you will be eating take out for another month (no pressure!). Finally during week 3 you get it to work, although printing still has it quirks. You learned a lot more about your PC, but little about cooking. One month later you buy a new PC and strangely the whole thing stops working again. Luckily the vendor sends you an email in which they offer an upgrade that runs on your new PC. Comparing it to the cost of takeout, you decide to buy the upgrade.
  
• IT, the new way: You feel hungry, without leaving your seat you visit the appstore on your phone, they offer 60 cooking applications, you pick the one most downloaded (after reading some of the user comments). You prepare your first dish. It is too salty. You blame the application, remove it, and pick another one. That tastes better. You decide whether you use the free version (that includes a automatically printed shopping list for the supermarket chain sponsoring the app) or you pay 20 cents per recipe cooked.

The decoupled cloud experience we are aiming for should of course feel like the second scenario. Also note how in the first example we talked mainly about technology and in the second mainly about cooking. Somehow we in IT moved from talking about what our companies do (selling soup, soap or insurance) to mainly discussing technologies (like SOA, SOAP and yes: Cloud).

In other words we need to change from being mainly Supply Driven, with IT in the role of factory managers running production of services, to a Demand-Driven IT organization with IT in the role of a supply chain manager, finding the best way to source the functionality for the business, preferably without locking our company into a dead-end street. End goal is being able to deliver the 20% that really differentiates our company, while at the same time being able to source the 80% that is pretty much the same for all companies.

That type of agility is the real promise of cloud computing.

This post originally appeared on July 26 at ITSMportal.com  

Notes:

*1 The Principles and Perils of Vendor Lock-In

*2 Microsoft announced it is making Azure available as a PaaS platform to several large IaaS providers

*3 NASA and Rackspace announced they are joining forces around an open source platform for Private Clouds called OpenStack

*4 The US government investments in cloud computing could be seen as a modern day industry stimulus package. In my view current efforts of NASA and the like may have as deep an impact on cloud computing as the cold war DoD budgets had on the development of computer networks and the Apollo project had on technology advancement in general.

*5 Skygone Inc. announced offering a choice of GIS (Geographical Information System) services

*6a SAS 70 is Not Proof of Security, Privacy, or Continuity Compliance

*6b Public Cloud Infrastructure Helps SaaS Vendor Economics

*6c Organizations Need to Re-Evaluate the Rationale for SaaS

Vendor lock-in and cloud computing

This blog originally was published at ITSMportal.com on July 14st , 2010

IT vendor lock-in is as old as the IT industry itself. Some may even argue that lock-in is unavoidable when using any IT solution, regardless of whether we use it “on premise” or “as a service”. To determine whether this is the case, we examine traditional lock-in and the to-be-expected impact of cloud computing.

Vendor lock-in is seen as one of the potential drawbacks of cloud computing. One of Gartner’s research analysts recently published a scenario where lock-in and standards even surpass security as the biggest objection to cloud computing. Despite efforts like Open Systems and Java, we have managed to get ourselves locked-in with every technology generation so far. Will the cloud be different or is lock-in just a fact of live we need to live with? Wikipedia defines vendor lock-in as:

In economics, vendor lock-in, also known as proprietary lock-in, or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs. Lock-in costs which create barriers to market entry may result in antitrust action against a monopoly.

Let’s examine what lock-in means in practical terms when using IT solutions and how cloud computing would make this worse or better. For this we look at four dimensions of lock-in:

Horizontal lock-in: This restricts the ability to replace a product with a comparable or competitive product. If I choose solution A (let’s for example take a CRM solution or a development platform), then I will need to migrate my data and/or code, retrain my users and rebuild the integrations to my other solutions if I want to move to solution B. This is a bit like when I buy a Prius, I cannot drive a Volt. But it would be nice if I can use the same garage, loading cable, GPS, etc. when I switch.

Vertical lock-in: This restricts choice in other levels of the stack and occurs if choosing solution A mandates use of database X, operating system Y, hardware vendor Z and/or implementation partner S. To prevent this type of lock-in the industry embraced the idea of open systems, where hardware, middleware and operating systems could be chosen more independently. Before this time hardware vendors often sold specific solutions (like CRM or banking) that only ran on their specific hardware / OS etc. and could only be obtained in their entirety from them. So a bit like today’s (early market) SaaS offerings, where all needs to be obtained from one vendor.

Diagonal (of inclined) Lock-in: This is a tendency of companies to buy as many applications as possible from one provider, even if his solutions in those areas are less desirable. Companies picked a single vendor to make management, training and especially integration easier but also to be able to demand higher discounts. A trend that let to large, powerful vendors, which caused again higher degrees of lock-in. For now we call this voluntary form of lock-in diagonal Lock-in (although “inclined”- a synonym for diagonal - may describe this better).

Generational Lock-in: This last one is as inescapable as death and taxes and is an issue even if there is no desire to avoid horizontal, vertical or diagonal lock-in. No technology generation and thus no IT solution or IT platform lives forever (well, maybe with exception of the mainframe). The first three types of lock-in are not too bad if you had a good crystal ball and picked the right platforms (eg. Windows and not OS/2) and the right solution vendors (generally the ones that turned out to become the market leaders). But even such market leaders at some point reach end of life. Customers want to be able to replace them with the next generation of technology without it being prohibitively expensive or even impossible because of technical, contractual or practical lock-in.

The impact of cloud computing on lock-in

How does cloud computing, with incarnations like SaaS (software as a service), PaaS (platform as a service) and IaaS (infrastructure as a service) impact the above? In the consumer market we see people using a variety of cloud services from different vendors , for example Flickr to share pictures, Gmail to read email, Microsoft to chat, Twitter to Tweet and Facebook to … (well, what do they do on Facebook?), all seemingly without any lock-in issues. Many of these consumer solutions now even offer integration amongst each other. Based on this one might expect that using IT solutions “as a service” in an enterprise context also leads to less lock-in. But is this the case?

Horizontal: For the average enterprise moving from one SaaS solution to another is not so different from moving from a traditional software application to another, provided they agreed whether and how their data can be transferred. What does help is that SaaS in general seems easier and faster to implement and that it is not necessary for the company to have two sets of infrastructure available when migrating.

For PaaS it is a very different situation, especially if the development language is proprietary to the PaaS platform. In that case, the lock-in is almost absolute and comparable to the lock-in companies may have experienced with proprietary 4GL platforms, with the added complexity that with PaaS also the underlying infrastructure is locked-in (see under vertical).

Horizontal lock-in for IaaS may actually be less severe than lock-in to traditional hardware vendors as virtualization - typical for any modern IaaS implementation - isolates from underlying hardware differences. Provided customers do not lock themselves in to a particular hypervisor vendor, they should be able to move their workloads relatively easy between IaaS providers (hosting companies) and/or internal infrastructure. A requirement for this is that the virtual images can be easily converted and carried across, a capability that several independent infrastructure management solutions now offer. Even better would be an ability to move full composite applications (more about this in another post).

Vertical: For SaaS and PaaS vertical lock-in is almost by definition part of the package as the underlying infrastructure comes with the service. The good news is the customer does not have to worry about these underlying layers. The bad news is that if the customer is worried about the underlying layers, there is nothing he can do. If the provider uses exotic databases, dodgy hardware or has his datacenter in less desirable countries, all the customer can do is decide not to pick that provider. He could consider contracting upfront for exceptions, but this will in almost all case will increase the cost considerably, as massive scale and standardization are essential to business model of real SaaS providers.

On the IaaS side we see less vertical lock-in, simply because we are already at a lower level, but ideally our choice of IaaS server provider should not limit our choice of IaaS network or IaaS storage provider. For storage the lesson we learned the hard way during the client server area –for enterprise applications logic and data need to be close together to get any decent performance – still applies. As a result the storage service almost always needs to be procured from the same IaaS provider as used for processing. On the network side most IaaS providers offer a choice of network providers, as they have their datacenter connected to several network providers (either at their own location or at one of the large co-locators).

Diagonal or inclined: The tendency to buy as much as possible from one vendor may be even stronger in the cloud than in traditional IT. Enterprise customers try to find as single SaaS shop for as many applications as possible. Apart from the desire for out of the box integration, an - often overlooked - reason for this is that customers need to regularly audit the delivery infrastructure and processes of their current SaaS providers, something which is simply unfeasible if they would end up having hundreds of SaaS vendors.

For similar reasons we see customers wanting to buy PaaS from their selected SaaS or IaaS vendor. As a result vendors are trying to deliver all flavors, whether they are any good in that area or not. A recent example being the statement from a senior Microsoft official that Azure and Amazon were likely to become more similar, with the first offering IaaS and the second likely to offer some form of PaaS soon.

In my personal view, it is questionable whether such vertical cloud integration should be considered desirable. The beauty of the cloud is that companies can focus on what they are good at and do that very well. For one company this may be CRM, for another it is financial management or creating development environments and for a third it may be selling books - um, strike that - hosting large infrastructures. Customers should be able to buy from the best, in each area. CFOs do not want to buy general ledgers from CRM specialists, and for sure sales people don’t want it the other way around. Similar considerations apply for buying infrastructure services from a software company or software from an infrastructure hosting company. At the very least this is because developers and operators are different types of people, which no amount of “devops training “ will change (at least not during this generation).

Generational: As with any new technology generation people seem to feel this may be the final one: “Once we moved everything to the cloud, we will never move again.” Empirically this is very unlikely - there always is a next generation, we just don’t know what it is (if we did, we would try and move to it now). The underlying thought may be: “Let the cloud vendors innovate their underlying layers, without bothering us”. But vendor lock-in would be exactly what would prevent customers from reaping the benefits of clouds suppliers innovating their underlying layers. Let’s face it, not all current cloud providers will be innovative market leaders in the future. If we were unlucky and picked the wrong ones, the last thing we want to be is locked-in. In today’s market picking winning stocks or lotto numbers may be easier then picking winning cloud vendors (and even at stock picking we are regularly beaten by not very academically skilled monkeys).

Conclusion
My goal for this post was to try and define lock-in, understand it in a cloud context and agree that it should be avoided while we still have a chance (while 99% of all business systems are not yet running in the cloud). Large scale vertical integration is typical for immature markets – be it early-day cars or computers or now clouds. As markets mature companies specialize again on their core competencies and find their proper (and profitable) place in a larger supply chain. The lock-in table at the end, where I use the number of padlocks to indicate relative locking of traditional IT versus SaaS, PaaS and IaaS, is more meant for discussion and improvement than as an absolute statement. In fact our goal should be to reduce lock-in considerably for these new platforms. In a later post I will discuss some innovative cross cloud portability strategies to prevent lock-in when moving large numbers of solutions into the cloud, stay tuned.

PS Not that I for a minute think my blogs have any serious stopping power, but do not let the above stop you from moving suitable applications into the cloud today. It’s a learning experience that we will all need as this cloud thing gets serious for serious enterprise IT (and I am absolutely sure it will, as the percentage of suitable applications is becoming larger every day). Just make sure you define an exit strategy for each first, as all the industry analysts will tell you. In fact, even for traditional IT it always was a good idea to have an exit strategy first (you did not really think these analysts came up with something new, did you?).

Might the cloud prove Thomas J. Watson right after all?

In 1943 former IBM president Thomas J. Watson allegedly *1 said: “I think there is a world market for maybe five computers". Will cloud computing prove Watson to be right after all?

Anyone who visited a computer-, internet- or mobile-conference in recent years, is likely to have been privy to someone quoting Watson. Most often to show how predicting the future is a risky endeavor. But is it? Maybe five for the world is not so crazy after all?

Now don’t get me wrong, I am not suggesting there will be less digital devices in the future. In fact there will be more than we can imagine (phones, ipads, smart cars and likely several things implanted into our bodies). But the big data crunching machines that we - and I suspect Mr. Watson - traditionally think of as computers are likely to reduce radically in numbers as a result of cloud computing. One early sign of this may be that a leading analyst firm – who makes a living out of publishing predictions - now foresees that within 2 years, one fifth of business will own no IT assets*2.

Before we move on, let’s further define "computer" for this discussion. Is a rack with six blades one computer or six? I’d say it is one. Same as I feel a box (or block) hosting 30 or 30000 virtual machines, is still one computer. I would even go so far that a room with lots of boxes running lots of stuff could be seen as one computer. And let’s not forget that computers in the days of Mr. Watson were as big as rooms. So basically the proposed idea is: cloud computing may lead to “a world market with maybe five datacenters”. Whether these will be located at the bottom of the ocean (think we have about 5 of those*5), distributed into outer space to solve the cooling problem or located on top of nuclear plants to solve the power problem, I leave to the hardware engineers (typical implementation details).

Having five parties hosting datacenters (a.k.a. computers) to serve the world, how realistic is this? Not today, but in the long run, let’s say for our children’s children. It seems to be at odds with the idea of grids and the use all this computing power doing little or nothing in all these distributed devices (phones, ipads). But does that matter. Current statistics already show that a processor in a datacenter with 100.000 CPU’s is way cheaper to run than that same processor in a datacenter with 1000 CPUs. But if we take this “bigger is better” (Ough this hurts, at heart I am a Schumacher “small is beautiful” *6 fan) and apply it to other industries, companies would logically try and have one factory. So Toyota would have one car factory and Intel one chip factory. Fact is they don’t , at least not today. Factors like transport cost and logistical complexity prevent this. Not to mention that nobody would wont to work there or even live near theseand that China may be the only country big enough to host these factories (uhm, guess China may be already trying this?).

But with IT we theoretically can reduce transport latency to light speed and logistical complexity in a digital setting is a very different problem. Sure managing 6000 or 600.000 different virtual machines needs some thought (well maybe a lot of thought), but it does not have the physical limitations of trying to cram 60 different car models, makes and colors through one assembly line. If instead of manufacturing we look at electricity as a role model for IT - as suggested by Nicholas Carr - then the answer might be something like ten plants per state/country (but reducing). Now we need to acknowledge that electricity suffers from the same annoying physical transport limitations as manufacturing. It does not travel well.

So guess my question is: What is the optimal number?
How many datacenters will our children’s children need when this cloud thing really starts to fly.

• A. 5 (roughly one per continent/ocean)
• B. .5K (roughly the number of Nuclear power plants (439))*3
• C. 5K (roughly 25 per country)
• D. .5M (roughly/allegedly the current number of Google servers)*4
• E. 5M (roughly the current number of air-conditioned basements?)
• F. 5G (roughly the range of IP4 (4.2B))

Please post you thoughts / votes / comments below

*1 Note: Although the statement is quoted extensively around the world, there is little evidence Mr Watson ever made it http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote
*2 http://www.gartner.com/it/page.jsp?id=1278413  
*3 http://www.icjt.org/an/tech/jesvet/jesvet.htm
*4 http://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/  
*5 http://geography.about.com/library/faq/blqzoceans.htm
*6 http://en.wikipedia.org/wiki/Small_Is_Beautiful