Despite what the other Mike posting on this site, Mike Kavis, says about Moving Past the OpenStack API Debate, I still think IaaS cloud APIs matter. The problem is that the API and the features of the IaaS are bound tightly together. Over time, the IaaS layer starts to commoditize, its API gets wrapped up in an abstraction (like Libcloud or Fog), and we all use that API instead. But just now, while these features are still emerging, it’s hard to see how Amazon Web Services (AWS) competitors can gain advantage unless they have at least one API that is under their control.
So, the more interesting issue in cloud API is in the consolidation of APIs outside of AWS. Five or six years ago, it wasn’t that hard to build an IaaS layer, and a lot of people did, and each of these has its own API. It is this fragmentation outside AWS that is playing out in the marketplace as we see consolidation of the competitors to AWS. No more clear is this than in the recent announcements from IBM.
IBM has been seeking for many years to provide cloud capability to two levels of customer engagement: fully managed services and self-service platforms. The former is called SmartCloud Enterprise+, and it is really an extension of its hosting, managed services, and outsourcing business, perhaps more of a consultant-in-a-cloud than a traditional cloud offering. The latter is something that is more recognizable as a cloud offering alongside, say, AWS. It wasn’t until recently called SmartCloud Enterprise, although initially it was targeted at IBM’s definition of small- or medium-sized businesses (which are perhaps larger than small- and medium-sized businesses according to some others’ definitions).
IBM’s traction with the self-service cloud product was very limited. However, IBM has recently found itself in need of a self-service offering to bid into $1 billion US government contracts—truly IBM’s heartland and an indication of how far IaaS cloud has now come. To bid against AWS (and indeed, it was successful in at least one bid), IBM acquired an IaaS provider called SoftLayer in July 2013. SoftLayer claims over 22,400 customers and 120,000 servers under management and was a major acquisition to position IBM in the IaaS space. It has differentiation around two features: the ability to mix bare metal into the cloud to increase performance, and the ability to switch on additional network capacity in “dark fiber” to reduce the variability of quality of service.
From a technology perspective, SoftLayer left IBM with a significant headache. Its previous SmartCloud Enterprise cloud had been an internal IBM development with its own IaaS layer and API. As of May 2013, IBM was committed to moving that to the open source OpenStack, although the exact strategy still seemed a bit unclear. By July 2013, IBM was on a path to killing off SmartCloud Enterprise (which finally happened this month) but was still strategically committed to OpenStack, which was initiated by Rackspace, a SoftLayer competitor. The problem is that SoftLayer was built on a different, internally developed IaaS layer and not OpenStack. In addition, SoftLayer had been dipping its own toes into the open source IaaS through the use of the Citrix-derived rival Apache CloudStack (presumably because SoftLayer feared Citrix less than it feared Rackspace).
So we come to this month’s announcement about the direction of SoftLayer and OpenStack. SoftLayer articulated its options as follows:
- Implement OpenStack compatibility
- Hope that a third-party library like Libcloud or Fog is updated to support its API
- Go it alone and develop an ecosystem of products around its own API
- Provide middleware that acts as a compatibility layer between the OpenStack API and a proprietary API.
SoftLayer has chosen option four, which it calls Jumpgate and refers to as middleware. In truth, Jumpgate is not middleware; in any conventional sense, it is more of an API translator. OpenStack uses REST APIs (representational state transfer APIs) based around a structure of URIs that address all the objects in the cloud (servers, data, whatever) and that are manipulated using standard http verbs—GET, POST (i.e., update), PUT (i.e., create), and DELETE—with the object being described in json. Jumpgate takes in the REST API and its json payload, emits a proprietary API, waits for the response, translates it, and sends it back to the API caller in json.
Jumpgate is not a universal IaaS API bridge, but the thing that sits in the middle of Jumpgate that does the translation from OpenStack API to the proprietary cloud. API is referred to as a “driver” and is pluggable—you could build one for another proprietary cloud. For this reason, SoftLayer has offered Jumpgate as an open source project with the possibility that other proprietary cloud providers will want to plug their own drivers into the framework.
The benefits to SoftLayer are that all the community of tool builders around OpenStack will interoperate with its cloud (assuming Jumpgate, which is still in alpha version, is robust and reliable). But this does not mean that IBM will be directly using the OpenStack implementation. It remains to be seen whether this is an interim position, or whether over time IBM will find some way of swapping OpenStack underneath the abstraction provided by Jumpgate to replace its proprietary infrastructure. However, it is clear that it would still need some proprietary features in its implementation if it is to maintain its competitive market positioning in the area of dark fiber and bare metal.