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.



Hardware Solution for Cloud Data Security? Ascend

This may, in the long term, represent one way in which security for cloud-resident data-at-rest becomes manageable and cost-efficient.

Hardware Trick Could Keep Cloud Data Safe - IEEE Spectrum:

Dubbed Ascend, the component hides the way CPUs request information in cloud servers, making it immensely difficult for attackers to glean information about the data stored there. Such a hardware-reliant scheme is an unusual proposition in the realm of cloud security, which is dominated by software solutions.
The researchers assume that sensitive data on cloud servers is already encrypted—typically the first line of defense when it comes to data security. Ascend goes a step further, its designers say, by dealing with sneak attacks that can happen through various so-called side channels. In a side-channel attack, an observer measures things like computation time, memory traffic, and power consumption to infer the behavior of a program running on that hardware, and from that the watcher can glean some information.



Who Won't Have an API? Layer 7 Knows.

Dimitri Sirota of Layer 7 Technologies posts a blog entry regarding Layer 7's recent survey of enterprises regarding their adoption of APIs.  He notes that while there appears to be considerable interest and real uptake, there does not appear to be a single leading driver for API publishing programs.

API Survey & Infographic | Layer 7 - Blogs:

That’s what we struggled to find out in our recent survey of enterprises. While we failed to canvass the North Koreans, it would seem the vast majority of enterprises in the developed world plan to implement an API program in one form or another. This probably helps – at least in part – to explain the surfeit of acquisition and funding-related news coverage the API Management sector has recently experienced



Commodity Cloud Futures? Unquestioned. Performance Cloud? Still questioned.

Bernard Golden wrote a piece that appeared at the end of May, which I've (sadly) not seen until today.  He sets out the perspectives being promoted by various clouderati regarding the ultimate future of commodity cloud services like Amazon's AWS, and the role / scope of 'enterprise-quality' configuration and tuning offers of competitive service providers.  

What he comes to is less a pronouncement and more a rational observation: There will be demand … continued, serious demand… for the commodity styled class of services provided by AWS.  The growth for this form of IaaS+ will continue unabated.  

What is less clear is the degree to which (and the resulting market size for) performance-sensitive, highly tunable cloud services will be in demand. Will they represent a separate, significant class of services in their own right, a class of boutique services 'at the top of the pyramid' or a special form of 'spiffed-up' managed service hosting offers?

Thus, I believe that the article is not titled correctly.  Better put, it might be: Will commodity cloud services be supplanted by 'crown jewel' services? Answer: No.

And, while I don't share his doubts about performance-sensitive applications and their share of cloud services, I completely agree that it IS a question. whereas the future of commodity cloud services seems altogether clear as an extended, long-term juggernaut.

Can commodity cloud services handle 'crown jewel' enterprise apps? - Computerworld:

In other words, can this complex tuning capability required for a certain domain of applications truly be offered as a cloud service, or are we really talking about spiffed-up colocation or managed service hosting presented as a shiny cloud offering? The crucial question is what depth of tuning is required for the applications that reside at the top of the pyramid and what proportion of those applications' performance requirements can be served via an API.
Overall, I'm not convinced that performance-sensitive applications that require tuning represent the future of the cloud computing market.