Our position that OpenStack is dead, both as a public cloud platform and as a private cloud platform, provoked a discussion with Eucalyptus CEO Marten Mickos about Eucalyptus’s role in the public cloud–hybrid cloud–private cloud continuum. Following is an edited transcript of our email interview with Mickos.
Eucalyptus is a open-source cloud management offering designed to allow an enterprise customer to implement an Amazon Web Services–compatible cloud on-premises, thereby delivering to that customer a seamless private/hybrid/public cloud environment based on the Amazon API and Amazon-compatible services.
The Virtualization Practice: The point of being API-compatible with Amazon Web Services (AWS) is for applications (images) to be able to move back and forth between a Eucalyptus private cloud on-premises and the AWS public cloud, correct? If that is true, then you need not just API compatibility, but you also have to provide all of the underlying services that Amazon provides under its API. How can a company your size possibly keep up with Amazon, and aren’t you, even in the best of all worlds, always going to be lagging behind them?
Marten Mickos: There are three main points (or benefits) of API compatibility:
- Apps: Application workloads can move back and forth without change.
- Tools: The same tools can be used for managing the public workload and the private one.
- Skills: Skills developed for one will be useful for the other.
In my estimation, each one of the three points above can, on its own, bring massive savings and improve the productivity of an organization. It’s about more than just app mobility.
Yes, you are right that compatibility is more than just syntax. We make sure that not only the syntax is the same, but the underlying behavior is as well. (This is, by the way, why it is today practically impossible to make OpenStack compatible with AWS without adding or replacing significant portions of software.)
How can we keep up with AWS? We can do it because that’s our stated focus. Our team has been honing its skills for six years by now. Nobody knows the art of cloud API compatibility as well as we do. We can even add another cloud standard if we want. And my guess is that we will be doing so at some point. Relevant candidates are Google and Azure.
Note that we are not saying that we will march in lockstep with AWS. A certain lag is useful. For instance, AWS introduced Kinesis late last year. We will implement that service when it is mature and popular.
Today we already support eight major AWS services. They cover the vast, vast majority of all AWS usage (i.e., well over 90%). The ones we support are EC2, S3, EBS, IAM, ELB, Auto Scaling, CloudWatch, and CloudFormation. In summary, our support for AWS services is already at a level where the most popular and relevant use cases can be handled.
But it’s a good question, and I would also turn it around. If people worry that Eucalyptus may not be able to keep up with AWS, shouldn’t they worry even more that other cloud platforms cannot keep up? We at least have the help of AWS in doing this, and we have perfected the art. (It’s VMware and OpenStack that will be left behind.)
TVP: What is your story and your value proposition to enterprise customers who already have a substantial investment in on-premises data center virtualization and cloud management software from VMware or Microsoft? Assume that a customer has already implemented VMware vCloud Automation Center. What do you bring to the table for these enterprises?
Mickos: Practically, we believe that customers with substantial pre-existing VMware and Microsoft investments will continue with them. Even with a superior Eucalyptus value proposition, the cost and risk of dismantling an existing data center infrastructure that is good enough is not negligible. But those same customers are seeing their own business units ramp up their use of AWS at an astonishing rate. That’s where Eucalyptus comes in. We are the only viable on-premises complement to AWS. We are the only cloud platform that the business units and the IT organization can agree on.
All the above said, we do have the ability to replace VMware. Eucalyptus supports VMware’s hypervisor layer. We therefore can protect customers in two ways: We protect their existing VMware investment by supporting it. And we protect customers against further VMware investment by being a layer on top of VMware—and notably, a layer that can also run on KVM. In essence, we bring customers a unified cloud platform underneath which they can run both ESX and KVM. That means a strong negotiation position for the customer when the VMware or Red Hat contract is up for renewal.
One more note: VMware vCloud Automation Center (vCAC; formerly DynamicOps) is essentially a multicloud management layer. Although we have no product integration today, it shouldn’t be difficult to make vCAC support Eucalyptus too, in case this would be of interest for customers.
TVP: Let’s drill into the question of compatibility with both VMware and AWS a bit. Obviously, VMware runs on its own hypervisor: ESXi. AWS also runs on its own hypervisor, which is its variant of the Xen hypervisor. Can customers run what they already have on Eucalyptus?
Mickos: The quick answer is yes—VMware artifacts can be converted into something that Eucalyptus can easily consume. Such conversion (to EMI, metadata, CloudFormation templates, or a combination thereof) requires some manual work. It also is dependent on the originating artifacts’ (VMDK/OVF/vApp) being within the bounds of AWS semantics. So, it’s a yes with some additional conditions.
TVP: If someone has a VMware VM, a VMware virtual appliance (an OVF file), or a vApp (an encapsulation of multiple VMs in an OVF), do all of those run on Eucalyptus when you are running on ESXi?
Mickos: Users running Eucalyptus on VMware or KVM can take existing VMDKs (VMware VMs) and import them into Eucalyptus. Eucalyptus saves them in an image format known as Eucalyptus Machine Image (EMI), which can also be easily converted to Amazon Machine Image (AMI) format. An EMI can encapsulate the operating system as well as the application stack. Any other metadata associated with the VM instance is handled in an AWS-compatible manner. Orchestrating across multiple VM instances and other resources in the cloud is handled via CloudFormation templates. AWS CloudFormation templates encapsulate an entire application suite (VM instances, storage, security, images, applications, user data, etc.) and can be used to deploy applications on Eucalyptus or on AWS interchangeably.
TVP: Do they, by some act of magic, run when you are running on KVM? Can someone copy an Amazon AMI over to your private cloud running on either ESXi or KVM and just run it?
Mickos: Yes. We provide convenient image conversion tools for our users to move images from KVM/VMware/AWS to Eucalyptus and from Eucalyptus to AWS. These image migrations hold true when Eucalyptus is running on KVM or on VMware ESXi.
TVP: Looking down the road, what role do you see Docker containers playing in making the problem of workload compatibility across clouds easier for people?
Mickos: What the application-portability Docker, or in general container technology, brings is orthogonal and complementary to multicloud compatibility. Docker images allow you to encapsulate stacks and move them around to different environments. But the applications themselves that are running in these containers will continue to need AWS-compatible services and APIs on-premises. Any third-party tools or SDKs that the applications within the Docker images utilize will look for similar and compatible services on-premises, as they see on AWS. Docker is bringing a new level of portability for application workloads, which in turn is making the operational compatibility between private and public environments more important than ever before. In fact, users can and do run Docker on top of Eucalyptus VM instances and host applications in these containers running in Eucalyptus instances.
TVP: Both VMware and Microsoft are going to leverage the fact that they have a substantial on-premises installed base and a public cloud offering that is compatible with that installed base. Neither Amazon nor Google have an on-premises installed base, although it is clear that you intend to fill this role for Amazon. How do you see this evolving over the next five years, and where do you think we will be with private/hybrid/public cloud computing five years from now?
Mickos: My belief is that hybrid will be the grand battlefield of IaaS. Amazon and Google are approaching it from one direction: from public cloud. VMware and OpenStack are approaching it from the other direction: the data center. Microsoft is coming to the battle from both sides, which is a huge strength.
It’s difficult to predict the outcome of the battle. But it must worry those who come from the data center direction that public cloud is encroaching on the data center but the data center is not really encroaching on the public cloud. I find it likely that great firms will go under in this battle.
Then, when the dust settles, everything will be hybrid, and we won’t be so obsessed with what percentage runs on what deployment model. We will have clouds of all sizes: three clouds with tens of millions of servers each, tens of millions of clouds with just a few servers each, and everything in between. We will need clouds in vehicles, ships, buildings, base stations, and so on. Symmetry on the API level and commonality of orchestration will enable smooth workload mobility across the various deployment forms.