Picture Credit: zenoss.com
Citrix (previous CloudAve coverage) today announced that they are releasing CloudStack (previous CloudAve coverage) under Apache 2 License and it will now be part of the Apache Foundation. The project is supported by 30 ecosystem partners including NTT, Juniper Networks, Tata Communications, etc.. They also announced that they are embracing AWS API for interoperability. Already, this news has created some stir with Randy Bias of CloudScaling writing about it while media, bloggers and analysts were tied by embargo. I am pretty sure this conversation is going to continue among the Clouderati community in the days to come. This post is not about the news per se but, rather, I am going to write about what I think about this news. I am going to discuss this from three different angles.
First, CloudStack POV
This is a smart move by Citrix because it helps them on many fronts. CloudStack has much better adoption than OpenStack because they have been in the market for a much longer period than OpenStack but OpenStack has been gaining the mindshare ever since it was launched two years back at OSCON. Part of the reason was because OpenStack was positioned as a vendor neutral project while CloudStack was a vendor driven project. Developers flocked to OpenStack and pundits went gaga about the project (including myself). OpenStack could easily leverage this buzz and position themselves as a strong alternative to AWS. They could do it even when their compute project was not mature enough for production systems (now it has matured considerably). Moreover, both Citrix and Cloud.com (before the acquisition) were in a bind because they were part of OpenStack project while also owning its competitor. In short, Citrix’s cloud strategy appeared to be a complete mess. In fact, Citrix’s cloud platform strategy was one of the important questions posed by some of our clients during advisory sessions. We never had a good answer till today.
By pushing the project to Apache foundation, Citrix is clearly positioning themselves to gain the necessary mindshare while also consolidating their marketshare. The move to Apache Foundation allows them to do just that because it signals to the developers that the project is truly open (well, Apache Foundation is the mecca of open source and what other credential will anyone want?) and it also tells the ecosystem partners that they can jump in with a plan to monetize around the project. In short, it can be easily seen as the surest sign that Citrix has no interest in remote controlling the project. I think such a perception will increase developer adoption in the coming years, eventually, making CloudStack a more robust and competitive platform.
The mindshare gain is critical because it is important for the very core of Citrix’s survival. They are right now battling on many fronts. On one side, they are fighting against VMware while, on the other side, they are also trying to fend off KVM and Hyper-V in both the virtualization market and the cloud market. If OpenStack becomes the defacto open source cloud implementation, it will signal trouble for Citrix’s core business. The only way to stop the bleeding is to create another compelling open source project which will take the mindshare away from OpenStack. A move to Apache Foundation is solely done for this purpose and, If you see from this perspective, this is a very smart move.
But let us keep in mind that an entry into Apache Foundation is not a guarantee for success. I am pretty sure critics will point out to the OpenOffice example. However, in my opinion, OpenOffice is not the right counter spin against CloudStack’s move to Apache Foundation. Oracle messed up big time and pushed an entire community out before OpenOffice was donated to Apache Foundation. CloudStack doesn’t have any such problem. Moreover, there is no single cloud platform under Apache Foundation and CloudStack is a welcome addition to fill the gap. If we couple with some other open source projects already existing in the foundation, which can be a very good value add for CloudStack project, there is a potential goldmine of opportunities there. As developers begin to flock to the CloudStack project, it could turn out to be one of the successful Apache projects we have seen in the recent history. It is too early to predict victory but the cloud market is still at a very nascent stage with the larger share of IT pie yet to be grabbed by any single cloud provider or platform. Apache CloudStack has a very good chance to be a competitive player in the market.
Second, OpenStack POV
When the news came out to the media yesterday, many journalists and bloggers asked me if it is bad for Open Source, in general, and OpenStack, in particular. Many of the open source friendly pundits were disturbed by the announcement, even wondering if it is going to hurt OpenStack and let a proprietary vendor like VMware or Microsoft gain the marketshare. However, my response was “Open Source, FTW”. In my opinion, CloudStack’s move to Apache Foundation actually strengthens OpenStack than impacting it in any negative way. First, and foremost, it makes it clear that vendor neutral open source platforms are the right way to go. Second, it makes it even more abundantly clear that open source is here to stay and it is the turn of proprietary vendors to play the catch up game. Lastly, it will keep both OpenStack and CloudStack innovating hard, eventually benefitting the end users. Let us keep in mind that monopoly is bad even if it is open source. So, having a strong open source competitor to OpenStack is a good thing to happen. It will keep them honest and push them to innovate hard. Any argument that Apache CloudStack is a bad thing to happen for the open source cloud community is completely flawed.
However, this is also the clearest warning to OpenStack project. Recently, we heard some rumblings about OpenStack Foundation related to the tiered structure proposed for the board of directors. The community was working hard to sort it out but I did get some feelers that the compromise may not be satisfactory for all the parties concerned. By pushing CloudStack to Apache Foundation, Citrix has pushed OpenStack community to do it right on the OpenStack Foundation front. Now, the OpenStack Foundation will be forced to have a more democratic and more equitable solution to the problem. Any failure to do so will ultimately result in smaller players, who feel less appreciated or ignored, quietly move to the Apache CloudStack ecosystem. I think that this announcement will add considerable pressure on Rackspace and the rest of the OpenStack community to work together to set up the foundation right.
Standardization around AWS
The only thing I didn’t like about the announcement is their embrace of AWS APIs. In my opinion, any standardization on AWS API is premature. Yes, AWS has the largest marketshare in the public cloud segment with almost close to $1 Billion in revenues. Yes, it is huge if we just consider the public cloud segment alone. But it is also a very thin slice of the pie if we consider the entire IT infrastructure market. Plus, we are still in the early stages of cloud evolution and standardizing around AWS API will inhibit innovation. Any worries about API proliferation is premature too. With players like Rightscale, enStratus, etc. taking the pain out of the API complexity, we need not worry about it for quite sometime. In short, any move to standardize around AWS API (at this point in time) is short sighted at the best.
Having said that, I also want to point out that this CloudStack news and last week’s Eucalyptus news are clearest indications that there is some momentum on the side of folks who are calling vendors to standardize around AWS APIs. Unless we see large scale adoption of OpenStack in the coming years, I think standardization around AWS API is inevitable. It will also be interesting to see how VMware and Microsoft react to this drift towards AWS APIs.
Finally, some time pass stuff
Remember we heard about rumors that Tata Communications was having scaling and reliability problems with CloudStack and they are actively considering OpenStack? Some of the feelers I got from the Indian side gave me indications that Tata Communications is firmly behind CloudStack but I could never confirm it officially. Yesterday, I noticed that Tata Communications was listed as one of the launch partners for Apache CloudStack project. I am pretty sure they wouldn’t have agreed to put their name there if they were planning to move to OpenStack. What do you think?
Divide et impera
Good write up, Krish. One of the better ones I have seen. It would be nice to see more analysis around “AWS architecture” compatibility. I have pretty deep knowledge of CloudStack and I don’t think it’s architecture is AWS compatible at all (e.g. generally is deployed using VLANs with a dedicated ‘router VM’). Supporting AWS APIs without a true AWS compatible architecture underneath is just lipstick on a pig.
Nice article. The notion of “embracing AWS API” seems a bit nebulous to me. My daily work involves interacting with a lot of these API and so it made me wonder.
Here is the reference for Amazon’s API:
http://docs.amazonwebservices.com/sdkfornet/latest/apidocs/Index.html
All of this is part of the one DLL (AWSSDK.dll) and the JAVA api for AWS is actually very analogous to the .NET API. Unfortunately those are the only two I have used in AWS. So if you look at just the namespaces there (let alone the hundreds of classes/methodss beneath them), you’ll notice the “AWS API” term covers a lot of things.
Some bits that may not be part of the “standard” api providers aspire to might be these:
Starting right from the top:
These are related to Amazon Access Control Policies :
Amazon.Auth.AccessControlPolicy Namespace
Amazon.Auth.AccessControlPolicy.ActionIdentifiers Namespace
Amazon provides extremely fine grained control over every part of the infrastructure and they can be defined using access control policies and marry them with IAM credentials. None of this exists anywhere except Amazon.
Going down the list:
Amazon.AutoScaling Namespace
Amazon.AutoScaling.Model Namespace
Again, the Autoscaling provided by Amazon is very EC2 specific.
Going down the list:
Amazon.CloudFormation Namespace
Amazon.CloudFormation.Model Namespace
Amazon.CloudFormation.Util Namespace
Again, cloudformation just does not exist out side of the Aws API.
We could go on but the point is i find it hard to image anything can be standardize across clouds unless it was extremely generic to all platforms like starting an instance.
And even launching an instance in Rackspace for instance is very different from EC2 in that Rackspace does not have security groups or EBS volumes or Elastic IPs. The Azure Service management API has a COMPLETELY different model to all of this.
All these providers have a very different model of how they have designed their clouds and their APIs reflect their architecture.
Cloud providers are innovating finding many interesting and different ways of solving problems.
Even if we wanted to standardize on an AWS API, I can’t for the life of me understand how :).
How different would anybody else have done? More than what it did yesterday, it is about how different Citrix would have done in 2011. It was part of founding team of Openstack. It could have invested that $200M in openstack development and wait for it to be ready (god knows when at that point) and then hunt customers or get load of customers who are already using cloudstack in production. It choose the later. More than Cloudstack being 12 months ahead in the code, or Openstack code was buggy and no concensus on foundation, It was about how many customers are using it right now in production. Truly it got the customers and it won the developers now by going to Apache.
Krish, nice write-up. One of the things that I think is somewhat lost in the general news on this is that I firmly believe that large Enterprises — those that run complex heterogenous (both scale-out and legacy app) compute landscapes — will buy cloud services based on that cloud’s ability to meet required enterprise performance attributes and economics as opposed to them being a part of a particular Stack system and/or because they have embraced a particular set of APIs (agree with your point on the API simplification role ala the enStratus model). I see a mix of public and private type solutions and the need to actually bring real cloud (versus Virtualization 2.0) solutions to legacy apps such as intelligent/dynamic app server sizing, IOPS guarantees within multi-tenant architectures, latency sla’s, vm optimization, etc. The magic will be delivering the most suitable cloud architecture for the use case required as efficiently as possible under an intelligent software management layer. I can tell you this is the laser focus of my F500 client base right now. Rod
Good point.
I’m technical director at the Outercurve Foundation. (Think ASF or Eclipse but open source license agnostic.) All open source foundations, regardless of what they represent to their constituencies, are software IP management machines. This is incredibly important as it defines a neutral non-profit space around which organizations that care about intellectual asset management can collaborate. (The reverse historical perspective is that all successful open source foundations grow out of the needs of specific projects that were growing to the point of interest from corporations that wanted to use/contribute to the software base.) OpenStack starts with a strong story of neutrality, but in the end falls victim to the perception of Rackspace controlling the software, and being forced into the OpenStack Foundation. The true test for it will be just how neutral the foundation is allowed to be. Citrix has brilliantly demonstrated to all and sundry they are willing to be truly neutral and collaborative by going to the ASF. (Outercurve is less well known, but Outercurve or Eclipse would have been viable alternatives to the ASF.)
Well said.