Recently, we released our latest milestone build for Eucalyptus 3.3. Go take it for a spin. This is a big one, since it incorporates, for the first time, functional versions of the “Big Three” AWS services we’ll be releasing later this spring: Autoscaling, Elastic Load Balancing, and Cloudwatch. It also presents a good opportunity to step back and look again at our AWS compatibility story.
It’s no secret that Eucalyptus believes in the power of the Amazon Web Services API. Amazon continues to be the dominant public cloud, and they continue to widen the gap between themselves and the other public cloud providers. This is thanks, in large part, to an API that is well considered, well documented, and has therefore spawned a powerful and growing ecosystem. The rule of thumb for those who are developing code for the public cloud has thus become “make it work for Amazon first” — to such a degree that even VMware is running scared.
Such is the strength of the de facto standard. The abstractions that are now being developed by every other cloud provider are either strongly influenced by, or derived directly from, the abstractions pioneered by AWS. Every single cloud provider has their own alternatives to EC2 and S3 — but AWS, having mastered these services long ago, is now moving quickly through a set of higher level abstractions. It is possible — perhaps even likely — that the AWS API, as the continual representative of the newest and best cloud abstractions, will emerge as a dominant standard for cloud applications in much the same way that the LAMP stack emerged as the dominant standard for web applications. It will simply be assumed that if you want to provision applications rapidly at scale, you will either write an application that uses the AWS API directly, or you will depend upon a PaaS that works first and best with the AWS API.
To us, it has always made perfect sense to follow Amazon’s strong lead. To build the strongest private cloud, build the best possible complement to the strongest public cloud. And to ensure that users always have options, make sure that the private cloud in question is open source.
The next, obvious question: how do we do that, exactly?
We’ve been refining our approach for more than half a decade. Which is about a thousand cloud years. Our approach can now be boiled down to two fundamentals:
1. Implement services as closely as possible to the way Amazon implements them. Which means paying close attention to every detail of every API interaction. It means closely tracking all compatibility issues we find, and treating them as critical. It means writing tons of in-depth tests that can run against both Eucalyptus and AWS. And it means using the AWS WSDL to construct service stubs, which dramatically improves the speed with which we can produce new features, as we’re doing with this release.
2. Leverage the AWS ecosystem to define and test the limits of compatibility. Which means relentlessly testing third-party tools and libraries against Eucalyptus, and being satisfied only when those tools work as well against Eucalyptus as they would work against AWS. Compatibility is a journey, and we will consider ourselves “compatible” when our users can treat Eucalyptus as their own personal region of AWS. Think of it a hybrid cloud Turing test.
All that said, we strongly encourage the diversity of tools to create a high-level compatibility between AWS and other public cloud services, and we see some value in tools like AWSome and Deltacloud and CloudBridge and the like. Over time, as other cloud vendors continue to refine their own versions of the AWS abstractions, it will be easier to make common high-level tools that encompass actions across all various public and private clouds, and that may make it a bit easier for developers to write code that is truly portable across many different clouds. (Then again, maybe not.) In the meantime, though, we will let others focus on Broad Compatibility, while we continue our laser focus on Deep Compatibility, and the advantages that we will provide to our users as a result.
Anyway. Go install the latest milestone build for yourself. We’ve also got some great demo scripts that will allow you to try out the latest and greatest functionality. Don’t hesitate to drop by on IRC (#eucalyptus on freenode) and let us know what you think.
Greg DeKoenigsberg Speaks 