Recently, I saw a really cool study of the costs that companies incur when using public clouds in a "Big Data" context. The cost data is certainly interesting, but I was more intrigued by what the presentation had to say about cloud usage, particularly with respect to big data. For example, on slide 11, it looks like 89% of the monthly public cloud instance usage is at relatively small scale. That is, along with "Big Data" there must be a little code.
I'm happy to see Release 3.2 of Eucalyptus see the light of day because it signals an important shift in the adoption cycle. Users and IT administrators now depend on Eucalyptus for their businesses and, as a result, it needed to be easier to use and with which to live. In the 3.2 release, Eucalyptus includes a number of features that make it friendlier to its users and and administrators.
As one might expect, I spend quite a bit of time talking to prospective customers about the joys of ownership that will accrue from the decision to install an on-premises cloud. To those who are charged with the operation and management responsibilities for a data center, the self-service notion is appealing, but for many of them, it is not new. What is new is the speed with which such requests can be filled by an on-premises cloud automatically, without system administrator intervention. We at Eucalyptus sometimes take for granted that the enterprise cloud must be fast.
The release of Eucalyptus 3.1 marks the end of the beginning for Eucalyptus 3. In February of this year, we released Eucalyptus 3.0 -- a fairly extensive re-factorization of the Eucalyptus platform to support features, such as high availability, identity management, and bootable storage volumes, all of which required intrinsic changes to the implementation of the cloud fabric itself. We also needed to change the way Eucalyptus is modularized to allow easier more "pluggable" deployments and smoother integration and deployment for Linux.
In the last post on HA I tried to provide some of my perspective on the "what" and "why" of the High Availability (HA) feature in Eucalyptus. This follow-up post is intended to focus on the "how," and, as a result, delves into some of the implementation details, albeit at the architectural level.
Eucalyptus 3 includes, as one of its new features, the option of enabling "High Availability" or "HA" (pronounced as the two letters and not as the first part of a chuckle). This functionality was overwhelmingly the most frequently requested improvement over Eucalyptus 2 by the community and, at the same time, the one over which the most confusion seems to persist. I'll try and shed some light on the "what," "why," and "how" of HA in Eucalyptus.
In March, we announced an agreement to collaborate with Amazon Web Services (AWS) to ensure API compatibility between AWS and the Eucalyptus open source on-premise Infrastructure as a Service (IaaS) platform. Beyond the details of the news, I'd like to shed some light on how I think this agreement helps customers focus on the larger discussion of the policies and business logic that govern application workloads.
With the agreement between Eucalyptus and Amazon to cooperate on ensuring API fidelity between the two technologies comes the question of defining what it means for two independent implementations to support the same API. The API itself consists of a large number of different "commands" or "service requests," each of which triggers many different operations within the system that are visible to the user.
It is really great to be able to welcome Greg Dekoenigsberg to Eucalyptus.
We have always been admirers of the way in which Fedora operates as a
community-managed Linux distribution. Greg's leadership is as evident in the
quality of the software as it is in the enthusiasm with which Fedora users and
contributors interact within its community.