To J_Brandt, yes, both APIs and service "abstractions" matter and both are needed. Wolski's stance reflects a larger debate within the OpenStack community over whether it should "follow" Amazon APIs or diverge and do the best job it can on its own. (Wolski's Eucalyptus is not part of OpenStack.) OpenStack board member Randy Bias charges the OpenStack community in the past has included representatives who irrationally fear and loath Amazon's growing power and won't touch its APIs. That debate has sorted itself out, I think, to say OpenStack will develop its own APIs but will be willing to include the APIs of other clouds. Wolski is saying, among other things, that won't be enough for compatibility. How deep are open source developers willing to go to structure OpenStack services to function like Amazon's? Would Amazon ever come around and say it will follow a shared blueprint for services with OpenStack? Right now, I would bet that thought hasn't occurred to Amazon.

Yes -- you will always need *an* API for the abstractions. The trouble is that with respect to cloud computing we seem to be obsessing on *the* API. Which API (or APIs -- there can be several for the same abstractions) is far less important than what the abstractions themselves do. So when you hear "We'll just bolt this API onto that cloud" such a statement only makes sense of the underlying abstractions are the same. If not, changing the API won't produce compatibility becasue the underlying abstractions will need to be changed as well.

I think I am missing something. Aren't you always going to want APIs in addition to the abstraction? I may not care which piece of hardware my VM runs, but if I want to read and write to the OS user accounts based on data from my HR system, I'm going to need an API. The more hybrid your solution, the more need for APIs?

Interoperability is key but unless the abstractions are the same, simply having the API be the same doesn't ensure interoperability, regardless of whether the "standard" is open or not. Back when POSIX was defining standards, for example, there were lots of implementations of the standard that were not compatible but were technically compliant.

Right. A bad API to a good abstraction is a killer. However, it is the abstraction that is usually harder to change than the API. If the API is clumsy or confusing, but the underlying abstraction is valuable, building a new API for the abstraction is usually easier than the other way around.

I agree that the API itself (the detailed function calls, variables, etc.) exposed but the real service behind it. I think the key message here is about cloud interoperability - can we seamlessly port a SaaS application made for Cloud A to Cloud B? No matter how you do it - by using certain kind of cloud API open standard or through proper abstraction on top of API, the application should provide consistent end user experience.

I think this piece fails to hit head-on what is probably the most important aspect of APIs and abstraction layers--specifically, the abstractions above the API layer, not those below or inherent in the API. Wolski is right that APIs don't matter much, but the reason why they don't matter is that you can abstractions above the APIs. Increasingly, this is done in one of two ways: using orchestration software (sometimes SaaS) with a built-in abstraction layer to cloud APIs like RightScale/ServiceMesh/enStratius/SaltStack, or heavy use of a PaaS like CloudBees/Appendra/OpenShift that makes whatever integration you're doing with cloud APIs fairly easy to port (as long as you're making sure to use only the basic, reusable units).

So cloud APIs don't matter in the same way that variants of SQL don't matter for most application development: we have abstraction layers (like ORMs) above them.

The part that makes me sit up and take notice is the assertion that you could have two of the same API calls to two different services and end up with two different results. That's the part that makes me think this is more than just semantics. It would help to have more examples, though.

To learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.

Is DevOps helping organizations reduce costs and time-to-market for software releases? What's getting in the way of DevOps adoption? Find out in this InformationWeek and Interop ITX infographic on the state of DevOps in 2017.

Chances are your organization is adopting cloud computing in one way or another -- or in multiple ways. Understanding the skills you need and how cloud affects IT operations and networking will help you adapt.