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: Author
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
IW Pick
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
IW Pick
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
IW Pick
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
IW Pick
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 Agile Archive
The Agile Archive
When it comes to managing data, donít look at backup and archiving systems as burdens and cost centers. A well-designed archive can enhance data protection and restores, ease search and e-discovery efforts, and save money by intelligently moving data from expensive primary storage systems.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Elite 100 - 2014
Our InformationWeek Elite 100 issue -- our 26th ranking of technology innovators -- shines a spotlight on businesses that are succeeding because of their digital strategies. We take a close at look at the top five companies in this year's ranking and the eight winners of our Business Innovation awards, and offer 20 great ideas that you can use in your company. We also provide a ranked list of our Elite 100 innovators.
Video
Slideshows
Twitter Feed
Audio Interviews
Archived Audio Interviews
GE is a leader in combining connected devices and advanced analytics in pursuit of practical goals like less downtime, lower operating costs, and higher throughput. At GIO Power & Water, CIO Jim Fowler is part of the team exploring how to apply these techniques to some of the world's essential infrastructure, from power plants to water treatment systems. Join us, and bring your questions, as we talk about what's ahead.