LinkedIn Twitter
Director, OpenShift Strategy at Red Hat. Founder of Rishidot Research, a research community focused on services world. His focus is on Platform Services, Infrastructure and the role of Open Source in the services era. Krish has been writing @ CloudAve from its inception and had also been part of GigaOm Pro Analyst Group. The opinions expressed here are his own and are neither representative of his employer, Red Hat, nor CloudAve, nor its sponsors.

17 responses to “Analysis: CloudStack Goes To Apache Foundation And Embraces AWS APIs”

  1. Dmitriy Samovskiy

    Divide et impera

  2. Randy Bias

    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.

  3. Ameer Deen

    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:

    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 :).

  4. Ranga

    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.

  5. Rodney Rogers

    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

  6. Stephen Walli (@stephenrwalli)

    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.)