Entries in AWS (5)


VMware and AWS - Is this the road to hybrid cloud?

After being away on holiday for a few days, I came back to see this article, quoting Raghu Raghuram of VMware making some interesting statements about AWS, and implying that there's more going on in the background than most of us imagine.  OK… but no credit unless and until we have hard announcements, and full credit only when we have production services.

VMware and Amazon clouds: not as far apart as you think — Tech News and Analysis:

VMware EVP Raghu RaghurIn an on-stage Q&A with Gartner Analyst Chris Wolf, Raghuram also reminded attendees that vCloud Automation Center — based on VMware’s DynamicOps acquisition — already lets them deploy their VMware virtual machines to AWS.
“That’s a significant component of our on-prem solution today and we’ll continue to enhance that. Our goal is to enable our customers to take full advantage of hybrid cloud with choice. OpenStack is one dimension of choice and being able to deploy to multiple clouds is another dimension of choice,” he said.
The bottom line, he added, is that customers want to “deploy applications based on well-defined governance and policy rules to any one of multiple locations — it could be AWS, it could be Azure, it could be vCloud Services, it could be your on-premise data center,” said Raghuram, executive VP of cloud infrastructure and management. He leads VMware’s software-defined data center push.



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.



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.



AWS re:Invents Workflow and Hybrid Storage

While the news about AWS RedShift had the 'drama' and novelty, it implies an attention to enterprise customer requirements that is ALSO found in an important, but less heralded, service and a ground-breaking partnership. 

Data Pipeline: The workflow services with which users can create a variety of reasonably straightforward data processing workflows, with all of the major AWS services and their 'manageable' objects, are now capable of being included in a work flow.  While it won't be the tool of choice for the expert DBA, it will be appropriate for the work-group user that signs up to use AWS rather than the Corporate IT resource.  Over time, this will become more sophisticated.

NetApp Private Storage for AWS: This 'joint infrastructure' offering allows customers to utilize both private and public cloud resources, and is one of the only services I have seen that builds on the AWS Direct Connect capabilities announced last year.  This starts to address a set of requirements that have been called out by enterprise IT related to safe and performant data storage (and data transport) from on-premise data center to managed data center to AWS.  It begins to take into account the data residency and data privacy issues about which enterprise IT has been most vocal.

That said, as important as the AWS private storage services is the way in which AWS must now address the issues of contractual responsibility and liability of AWS data 'stewardship.' Similarly, AWS owes 'the enterprise' some clarity about the respective contractual responsibilities of AWS and its enterprise customers when using AWS' multi-tenant resources.   When these issues are addressed to the satisfaction of enterprise IT hard-cases, the compliance auditors, and PII regulators, the resulting explosion of cloud usage in hybrid environments by enterprise customers will dwarf the last two years' growth of AWS… and that's saying something.