Thoughts on the “Simple Cloud API”

PHP developers with Cloud aspirations rejoice! Zend has announced a PHP toolkit (called the Simple Cloud API project) to abstract and access application-level Cloud services. This is not just YACA (yet another Cloud API), as there are interesting differences between this and all the other Cloud toolkits out there.

First it’s PHP, which was not covered by the existing toolkits. Considering how many web applications are written in PHP (including the one that serves this very blog) this may seem strange, until you realize that most Cloud toolkits out there are focused on provisioning/managing low-level compute resources of the IaaS kind. Something that is far out of PHP’s sweetspot and much more practically handled with Java, Python, Ruby or some .NET language accessible via PowerShell.

Which takes us to the second, and arguably most interesting, characteristic of this toolkit: it is focused on application-level Cloud services (files, documents and queues for now) rather than infrastructure-level. In other word, it’s the first (to my knowledge) PaaS toolkit.

I also notice that Zend has gotten endorsements from IBM, Microsoft, Nirvanix, Rackspace and GoGrid. The first two especially seem to have impressed InfoWorld. Let’s keep in mind that at this point all we are talking about are canned quotes in a press release. Which rank only above politician campaign promises as predictor of behavior. In any case that can’t be the full extent of IBM and Microsoft’s response to the VMWare/Cisco push on IaaS standards. But it may suggest that their response will move the battlefield to include PaaS, which would be a smart move.

Now for a few more acerbic comments:

  • It has “simple” in its name, like SOAP (as Pete Lacey famously lampooned). In the long term this tends to negatively correlate with simplicity, just like the presence of “democratic” in the official name of a country does not bode well for actual democracy.
  • Please, don’t shorten “Simple Cloud API” to SCA which is already claimed in a (potentially) closely related field.
  • Reuven Cohen is technically correct to see it as “a way to create other higher level programmatic API interfaces such as REST or SOAP using an easy, yet portable PHP programming environment”. But pay attention to how many turtles are on this pile: the native provider API, the adapter to the “simple cloud API”, the SOAP or REST remote API and the consuming application’s native API. How much real isolation are you getting when you build your house on such a wobbly foundation

[UPDATE: Comments from someone in the know:  a programmer working on adding Azure support for this Simple Cloud API project.]


Filed under Application Mgmt, Cloud Computing, Everything, IBM, Manageability, Mgmt integration, Microsoft, Middleware, Open source, Portability, Utility computing

2 Responses to Thoughts on the “Simple Cloud API”

  1. Pingback: People Over Process » Links for September 22nd

  2. Great analysis! You captured our intentions very well, and you hit on some of the biggest challenges/downsides.

    A few clarifications are in order:

    * Microsoft, IBM, Nirvanix, Rackspace, and GoGrid didn’t just endorse the API; they committed to contributing to it. All of them have made commits (well, Rackspace in their own repo for now :) ) except GoGrid, who will contribute their adapters as they roll out application services.

    * We intend to recruit more corporate contributors, along with the community that has already begun to form around the API. Stay tuned.

    * Most of the co-founding contributors were involved with the naming of the project. We came up with ‘Simple’ after considering a few other candidates. I think that we came up with something that is descriptive of the API, which captures the common features among vendors and is therefore inherently simple. It also seems to appeal to PHP developers who have warm fuzzies about projects such as SimpleXML. I’m not sure how many PHP developers could even tell you what SOAP stands for. :) Even fewer care. :D

    * I’ve never seen it referred to as ‘SCA’, and I personally wouldn’t use that acronym myself. We have referred to it internally as ‘SCAPI’, but I haven’t seen that acronym yet in the wild.

    * IMO, the technologies SCAPI (I’ll put it out there and see if it sticks. ;) ) is built on are sound: PHP, Adapters to Zend Framework, Zend Framework, the internet, remote APIs of the services, and the services themselves. But you’re correct. It could be shaky at the adapter level because of all the differences in the APIs. And I’m not just talking about method signatures. Every one of them has limitations on names, data, functionality, etc.- as well as subtle behavioral differences- that SCAPI will have to address if we can claim that it makes portability among vendors a matter of simple configuration changes. This is the hard part. And we need input on this:

    Ultimately, our goals are humble: create a PHP API that allows developers to use application services from different vendors, along with exposing the differences in cloud offerings before the developer gets burnt. But our motivations are as simple as the API itself: we have to start somewhere.

    Thanks for the write up, and we’re looking forward to more of your insight on the API and the cloud in general.