Ever since I joined CloudSigma there has been lively discussion of creating standards for cloud computing and within the Infrastructure-as-a-Service (IaaS) sector. There does seem to be precious little discussion regarding what a standard is actually meant to achieve. Whether a standard is really desirable or whether it is the the best way to achieve those ends. I’m going to look at each of these three in turn and present a counter-argument.
So first off, why are people looking to create standards in cloud computing and more specifically IaaS? Individual opinions vary but it seems clear that the main motivating factor is to make it easier to switch between cloud vendors and to simplify in general the IaaS space. On the face of it these both seem to be very laudable aims, reducing friction between clouds will increase competition, bring down prices and accelerate cloud adoption. How are these standards looking to be imposed and who is setting the agenda?
How are we going to achieve friction free cloud computing?
The biggest discussion now focuses on creating a ‘standard API‘. With a standard API users could sign up for numerous clouds, write the same piece of software/scripting and it would be compatible with all of them. Again, it would seem that this would benefit the overall sector but scratch the surface and you begin to see some problems.
One of the main problems I see is that there isn’t necessarily one way to create an IaaS offering. Clouds differ wildly from each other and are structured in many cases in fundamentally different and incompatible ways. This isn’t a bad thing either, depending on what kind of computing you are doing. Different cloud architectures are more suited than others. .So problem #1 is that there may not be actually a compatible structure to begin with. That’s a pretty major problem.
Mi
Lets assume the industry pushes on however with the creation of a standard API. To be meaningful it would need to work with at least the top five (or maybe ten) global players. Given problem #1 what does this mean? It means that any standard API becomes reduced down to a least common denominator API. Interesting and useful features of one cloud which perhaps take full advantage of that cloud’s particular architecture get excluded because they aren’t appropriate for another cloud.
What we are left with is some very plain vanilla core functions which are a poor sub-set of what is actually possible with a full API from a vendor. In fact those core functions become so simple that it wouldn’t actually be that difficult to code for each of the clouds themselves with such a small range of functions. So a standard API becomes a sub-set of core common features and not that useful for power users. Lets chalk that up as problem #2.
Moving on, lets assume that a standard has been adopted, who will be setting that standard? Well incumbent providers of course and they will likely be adopting a standard not too dissimilar to their own existing way of doing things for obvious reasons. So, the creation of a standard will likely mean the creation of a standard API that looks very much like a small number of large incumbents. This is fine but do these incumbents have the best structured and full featured API that we want to set as the foundation for the industry moving forward?
Mi
Virtualisation and cloud related technologies have advanced significantly in a few short years. Despite this, many vendors run legacy technologies that aren’t now capable of passing on many of the benefits to users. They have a direct incentive to set any standard to adopt legacy practices. Is that a good basis for an industry standard API? That’s problem #3.
There are a lot more problems but I’ll highlight one final one. Cloud computing and IaaS are a fast moving, innovating sector. Creating a standard will ossify the technology, slow adoption of new features or make the standard API irrelevant. For example, if you are using the standard API and a new (or existing) market participant brings out a great useful new feature/innovation. What will happen? The answer is nothing, if you are using the standard API at first nothing will happen at all. That feature will be available via the specific vendor API but not the standard API.
Mi
Worst still, the other industry participants will not have an incentive to push for inclusion of the new feature in a standard API at all until they have an equivalent (if possible). The likely result will be that the standard API will incorporate new features in months or probably years after they are first introduced. Worst still, if the new innovation is from a new market participant, they will likely fail as the majority of the market will be locked into a standard API. Using a standard API is a protectionist measure for one way of doing things and highly damaging to fluid innovation and adoption. This is problem #4 and personally the one that gives me the most concern.
Mi
Overall then, using a non-tech analogy, if we wanted to impose such a standard in the automobile industry what would it look like? For sure the automobile industry has what I call background standards, such as safety standards etc. etc. but it doesn’t have product standards. You can’t take a steering wheel from a Ford and put it in a Bentley or the bumper off a Tesla and put it on a Hummer. Product standardisation isn’t necessarily a desirable thing. One can only imagine the sort of cars we’d all be driving if the core product needed to be compatible between different vendors!
Product differentiation happens because different customers need different things. I believe the same is fundamentally true in cloud computing and the IaaS sector. There isn’t one product or way of doing things that is appropriate to all customers. We haven’t seen standards created for other similar sectors such as dedicated hosting or web hosting in general. Web hosting doesn’t have any common standard. This means changing vendor can be painful yet it has seen huge amounts of innovation and consistent price reductions. This has happened through product differentiation and innovation.
Are we looking in the wrong place?
Creating a standard API is therefore not the holy grail it is held up to be. There are some pretty major issues surrounding it and standardising a moving target may prove unworkable anyway. Personally I believe people are looking in the wrong direction to begin with. If we want to reduce friction between clouds, are the differing APIs the real culprits? I think not.
Yes developing for different APIs can be time consuming but not to a punitive extent. In reality most users will work with two or three clouds not ten or twenty. So what is the real source of friction for users between clouds? Simple, not proprietary APIs but system lock-in. By forcing users to adopt a proprietary architecture and way of working, IaaS vendors lock the user into a specific system architecture that doesn’t transport well to another cloud. Anyone using AWS that tries to move will discover this for themselves pretty quickly.
The best way to avoid this is to use IaaS vendors that don’t impose arbitrary and proprietary ways of working on their users. That is the single biggest thing that any user can do to reduce the friction they face between clouds. There are a growing number of next generation, open, flexible cloud vendors that make switching that much easier. Yes they often have different APIs but by not having to switch the way you work when you set-up in each of them (or move). In reality you save a great deal of time.
Mi
At CloudSigma we do support open standards and will be rolling out participation in OpenNedula, Libcloud and more that aim to create standardised ways of working between clouds. My opinion is that if a user wants to go this route, working through organisations and companies that create such networks is the best way to go. And we support them in this by participating in these programs. I do however think it isn’t necessarily the best way of achieving the aim of friction free movement between clouds.
Message to the IaaS sector
So I think lets all forget about trying to tie things up in a standard API. Lets get every company innovating, iterating their product and rolling out new technologies and features as soon as they can. Lets keep things open and flexible. And let people choose where they want to do their computing without relying on restrictions on users.
- CloudSigma Expands Public Cloud to Melbourne, its Second Australian Location - April 3, 2017
- CloudSigma Launches new German Cloud location with DARZ - September 12, 2016
- CloudSigma Expands its Global Footprint to the Australian Market - May 17, 2016
- SSDs gaining traction in the cloud - June 7, 2012
- Let the cloud add real value - May 28, 2012