Mike Fratto over at Network Computinghas a blog that declares the need for standards in Cloud Management APIs is non-existent or at least premature. Now Mike is a smart guy and has enough experience to have a clue what he’s writing about, unlike many cloud pundits out there, but like all smart people I like to read information from, I reserve the right to completely disagree. And in this case I am going to have to.

He’s right that Cloud Management is immature, and he’s right that it is not a simple topic. Neither was the conquering of standardized APIs for graphical monitors back in the day, or the adoption of XML standards for a zillion things. And he’s right that the point of standards is interoperability. But in the case of cloud, there’s more to it than that. Cloud is infrastructure. Imagine if you couldn’t pull out a Cisco switch and drop in the equivalent HP switch? That’s what we’re talking about here, infrastructure. There’s a reason that storage, networks, servers, etc. all have interoperability standards. And those reasons apply to Cloud also.

If you’re a regular reader, you no doubt have heard my disdain for Cloud Storage vendors who implemented CLOUD storage and thereby guaranteed that enterprises would need cloud storage gateways just to make use of the cloud storage offerings. At least in the short term while standards-compliant cloud interfaces or drivers for servers are implemented. The same is true of all cloud services, and for many of the same reasons.

Do not tell an enterprise that they should put their applications out in your space by using a proprietary API that locks them into your solutions. Tell them they should put their applications out on your cloud space because it is competitively the best available. And the way to do that is through standards.

Mike gets 20 or so steps ahead of himself by listing the problems without considering the minimum cost of entry. To start, you don’t need an API for every single possible option that might ever be considered to bring up a VM. How about “startVM ImageName Priority IPAddress Netmask or something similar? That tells the cloud provider to start a VM using the image file named, giving it a certain priority (priority is a placeholder for number of CPUs, memory, etc), using the mentioned IP Address and Network Mask. That way clones can be started with unique networking addresses. Is it all-encompassing? No. Is it the last API we’ll ever need? No. Does it mean that today I can be with Amazon today and tomorrow move to Rackspace? Yes. And that’s all the industry needs – the ability for an enterprise to keep their options open.

There’s another huge benefit to standardization – employee reusability/mobility. Once you know how to implement the standard for your enterprise, you can implement it on any provider, rather than having to gain experience with each new provider. That makes employees more productive, and keeps the pool of available cloud developers and devops people large enough to fulfill staffing needs without having to train or retrain everyone. The burden on IT training budgets is minimized, and the choices when hiring are broadened. That doesn’t mean they’ll come cheap – it’s still going to be a small, in-demand crowd – but it does mean you won’t have to say “must have experience programming for Rackspace”. Though the way standards work is that there will be benefits to finding someone specialized in the vendor you’re using, it will only be a “nice to have”, not a “requirement”, broadening the pool of prospective employees.

And as long as users are involved in the standards process, it is never too early to standardize something that is out there being utilized. Indeed, the longer you wait to standardize, the more inertia builds to resist standardization because each vendor’s customers have a ton of stuff built in the pre-standards manner. Until you start the standardization process and get user input into what’s working and what’s not, you can’t move the ball  down the court, so to speak, and standards written in absence of those who have to use them do not have a huge track record of success. The ones that work in this manner tend to have tiny communities where it’s a badge of honor to overcome the idiosyncrasies of the standard (NAS standards spring to mind here).

So do we need standardized cloud APIs? I’ll say yes. Customers need mobility not just for their apps, but for their developers to keep the cost of cloud out of the clouds.

And it’s not simple, but the first step is. Let’s take it, and get this infrastructure choice closer to being an actual option that can be laid on the table next to “buy more hardware” and considered equally.

Connect with Don:	Connect with F5:

Related Articles and Blogs:

• Standardizing Cloud APIs is Useless
• Cloud, Standards, and Pants
• Will devops Fork?
• Approaching cloud standards with end-user focus only is full of fail
• The Inevitable Eventual Consistency of Cloud Computing
• Cloud Needs Context-Aware Provisioning
• Cloud computing is not Burger King. You can't have it your way. Yet.
• I Have a Dream
• Microsoft Hops Into Infrastructure 2.0
• The World Doesn't Care About APIs
• Cloud Balancing, Cloud Bursting, and Intercloud