Comments
Why Cloud APIs Don't Matter
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
J_Brandt
50%
50%
J_Brandt,
User Rank: Ninja
11/24/2013 | 4:49:15 PM
Re: Your services not like Amazon's? Forgettaboutit!.
Ahh thank you both for the clarification and education.
cbabcock
50%
50%
cbabcock,
User Rank: Strategist
11/19/2013 | 5:59:57 PM
Your services not like Amazon's? Forgettaboutit!.
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.
richwolski
100%
0%
richwolski,
User Rank: Apprentice
11/19/2013 | 4:56:12 PM
Re: The Value of Both?
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.   
J_Brandt
100%
0%
J_Brandt,
User Rank: Ninja
11/19/2013 | 12:20:51 PM
The Value of Both?
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?
richwolski
100%
0%
richwolski,
User Rank: Apprentice
11/18/2013 | 4:38:36 PM
Re: Cloud Interoperability
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. 
richwolski
50%
50%
richwolski,
User Rank: Apprentice
11/18/2013 | 4:31:20 PM
Re: Why Cloud APIs Don't Matter
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.
Li Tan
50%
50%
Li Tan,
User Rank: Ninja
11/18/2013 | 12:19:18 AM
Cloud Interoperability
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.
jemison288
50%
50%
jemison288,
User Rank: Moderator
11/16/2013 | 1:27:52 PM
Missing the point by focusing too low
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.
AndrewBinstock.
IW Pick
100%
0%
AndrewBinstock.,
User Rank: Apprentice
11/15/2013 | 3:57:56 PM
Why Cloud APIs Don't Matter
This has the feel of a strawman chosen b/c it's easy to knock down.

Obviously, if the underlying model is wrong, the API doesn't matter. Is that even controversial?

However, what the author doesn't say, is that if the model is done well but the API is poorly designed, it won't be used. Both the API and the underlying model are important.
jfeldman
100%
0%
jfeldman,
User Rank: Strategist
11/15/2013 | 1:33:03 PM
Re: Are OpenStack, Amazon compatibility possible?
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.
Page 1 / 2   >   >>


The Business of Going Digital
The Business of Going Digital
Digital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - July 22, 2014
Sophisticated attacks demand real-time risk management and continuous monitoring. Here's how federal agencies are meeting that challenge.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.