Entries in OpenStack (3)


OpenStack: Enterprise Cloud or Service Cloud?

It's instructive to look at the various schools of thought within the OpenStack community on the role of OpenStack in both enterprise and service environments.  

Consider the Rackspace view of OpenStack as the 'alternative to cloud lock-in'.  

Then witness the industry's discussion of OpenStack and its embrace of Amazon APIs that erupted around an open letter from Randy Bias of Cloudscaling, who recognized the importance of hybrid cloud solutions.  

In fact, it is precisely this hybrid cloud solution that Randy calls out as vital to OpenStack's future which "… is predicated on driving hybrid cloud compatibility with the major public clouds, and those are AWS and perhaps GCE." In other words, OpenStack with active and full support of AWS APIs, is best suited as the infrastructure of choice for the enterprise. 

It's as interesting to note how OpenStack is 'acknowledged' by its competitors in both the services (IaaS) and the enterprise infrastructure realms.  Today, we have Pat Gelsinger, VMware's CEO, with a VERY different future in mind for OpenStack -- one so different from that espoused by Randy as to cause whiplash.  

VMware CEO: OpenStack is not for the enterprise - Network World:

VMware CEO Pat Gelsinger says he doesn’t expect open source cloud project OpenStack to catch on significantly in the enterprise market, instead he says it’s more of a platform for service providers to build public clouds.
It’s a notion that others in the market have expressed in the past, but also one that OpenStack backers have tried hard to shake. 
“Where is OpenStack, we believe, going to be adopted?” Gelsinger said in an interview with Network World. “We don’t see it having great success coming into the enterprise because it’s a framework for constructing clouds. People have largely adopted and have extremely large deployments of VMware and the switching costs and so on of that are not particularly effective. Where we see it being effective though are very much in cloud providers, service providers, an area where VMware hasn’t had a lot of business in the past and thus, our strategy, we believe opens a whole new market for us to go pursue.”

I'm now waiting to find someone 'official' from AWS to weigh in on an 'appropriate' future in which OpenStack plays a part.  That ought to be just as interesting -- in an academic sort of way.  Anyone have an enlightening quote from AWS about OpenStack?


More on the OpenStack - AWS Conversation

Last week, Randy Bias, the interim CEO of Cloudscaling and an outspoken advocate for cloud computing infrastructures of various flavors, published an open letter to the OpenStack community.  It caused something of an uproar and a lot of 'digital ink' was spilt as a result.  (I personally found it rather unsettling that some cloud-literate readers made the interpretations they did, based on what must have been a very cursory reading of the letter.  That said, it was a bit of a Jeremiad.) 

This week, Randy responded to his own letter, taking much of the response he received into account, in an attempt to get the message across with a reduced generation of affect in the readership.

Looking in the Mirror: A Response to My Open Letter | Cloudscaling:

In fact, a lot of discussion was created, and I feel pretty good about that. Surprisingly, much of it was supportive of the general thesis with only a minority of dissenters.
Miscommunications & Misunderstandings
Among the dissenting responses were four general categories of reactions that were categorically incorrect:
  • Randy is calling for the removal of the Nova API (incorrect)
  • Randy is calling for only Amazon compatibility at the expense of OpenStack innovation (incorrect)
  • Randy doesn’t want the OpenStack community to control their own API (incorrect)
  • Randy is calling for slavish replication of AWS APIs *only* in OpenStack (incorrect)   
Just to be clear, what I’m saying is:
Nova should have its own API that is controlled by the community
That API should be a low-level API without an “opinion”
The Rackspace API is NOT the right low-level API or abstraction layer
Amazon compatibility must happen in addition to all other OpenStack innovations
OpenStack can and should innovate in parallel with efforts around AWS compatibility
I don’t think any of this is actually counter to how most people feel. The only problem I see is that folks tend to have a lot of feelings about moving the current Rackspace (Nova) API elsewhere. I’m not really certain why since it is no more “native” to OpenStack than the EC2 API. Both are relatively alien. Both have an opinion that limits innovation on some axis.



IBM's embrace of OpenStack and 'open source': OSLC, TOSCA and ...?

David Lindquist’s post in IBM’s Thoughts on Cloud blog (made in conjunction with the IBM OpenStack announcement), is an excellent high-level explanation of the rationale behind IBM’s decisions.  It is telling for at least two reasons, and notable for what might be construed as missing pieces.

Along with the whole-hearted endorsement and embrace of OpenStack, IBM has called attention to two open initiatives.  Open Services Lifecycle Collaboration(OSLC) is an initiative of which I personally was unaware until Sunday’s presentations at the IBM Pulse Open Cloud Summit. The objective of the initiative is to standardize the way that software lifecycle tools can share data.  Not just an admirable goal, but one of the necessary preconditions of a truly open, multi-vendor approach to operations, administration, management and provisioning of cloud components.

Lindquist calls out the IBM support of OASIS Topology and Orchestration Specification for Cloud Applications (aka TOSCA).  IBM has started (and will no doubt continue) to make a strong case for the use of LinkedData and OSLC in combination with TOSCA to ease the job of integration and federation within the cloud ecosystems.   Again, it’s nothing less than what one would expect from IBM, a company with a long history that values systems management.  

From David Lindquist, For cloud computing, open means agile

Together with the OpenStack FoundationOpen Services Lifecycle Collaboration (OSLC) and OASIS, we are helping to lead open cloud standards and open source initiatives. Creating an industry rallying point to drive interoperability is accelerating delivery and lowering costs, while optimizing the infrastructure layers and enabling management of the entire lifecycle to support agility with integrity. Further, workload portability and optimization supports scale, security, recovery, resiliency and agility in the development and delivery of new business applications and business models.

Further, to support the interoperability and portability of workloads across clouds we are contributing and supporting the OASIS Topology and Orchestration Specification for Cloud Applications known asTOSCA. To drive the full lifecycle of design, development, and delivery we architect our cloud solutions with Linked Data and OSLC. By leveraging OSLC we are creating an open environment to easily integrate and federate our capabilities as well as third-party tools to support DevOps, Continuous Delivery pipelines, orchestration and automation.

By opening access to data though OSLC, we can quickly pull together solutions that span the complete lifecycle, provide dashboards with insights driven by analytics, and link information across applications and infrastructures to support subject matter experts, all with a compelling user experience. With OSLC we have been able to leverage the extensive capabilities and data across our products to provide consumable interfaces. These examples include storage management, application and infrastructure monitoring, and control desk solutions. With this architecture and these interfaces, users can easily access information across systems, using mobile access, and compose dashboards with the insights their businesses need.

What seems to be missing, however, is a less well-known, but arguably vital initiative known as the OASIS Cloud Application Management for Platforms (CAMP).  As expressed in its charter, 

CAMP defines interfaces for self-service provisioning, monitoring, and control. Based on REST, CAMP is expected to foster an ecosystem of common tools, plugins, libraries and frameworks, which will allow vendors to offer greater value-add.

That seems to be a logical addition to the effort by IBM. As important, perhaps, is the adoption and recognition of the LinkedData and OSLC work within the CAMP TC.  I know, after a number of informal conversations with participants in both OASIS TCs that the IBM emphasis has created new energy around OSLC for CAMP, and increased interest in seeing IBM attend to the work of CAMP.  

(Truth in advertising:  I am a participant in the CAMP Technical Committee and an observer in the TOSCA TC.)