We were unable to load Disqus. If you are a moderator please see our troubleshooting guide.
You mention the trajectory of private clouds and then propose a change that will very badly harm private clouds. I can't change AWS's API. I can't extend it. I can't even propose changes to it.
From an evolutionary point of view, making AWS the primary API is an innovation dead end. We're stuck only implementing features that AWS has, in the way that AWS does it. We'll always trail AWS because it's actually impossible to surpass them.
OpenStack *is* its APIs. Take that away and we're just another clone.
I don't think that is accurate. You are promulgating the zero sum game theory of OpenStack which is harmful. OpenStack can have its own APIs and support the AWS APIs as first order components.
OpenStack will never win the public cloud race. It's not even close. Hybrid clouds are a reality today where customers are asking for real solutions. OpenStack artificially limits itself by saying no AWS APIs. What possible logical reason can there be for not supporting both or even more APIs?
Also, sure it's chasing AWS but those APIs have been exceptionally stable. Actually much more stable than the OpenStack APIs. Stable APIs are good.
How can OpenStack be a clone of AWS? It's like saying that the BSD kernel is a clone of RedHat Enterprise Linux or Ubuntu. AWS is a complete online service. OpenStack is software that can be used to build such a service.
OpenStack will be used to build many kinds of clouds of which some will be AWS compatible. Some will be for other special purposes.
This is OpenStack's strength and weakness.
I think it's a huge mistake to believe OpenStack is some kind of monolithic complete solution with a standardized reference architecture. It's not even close. It's just a cloud OS kernel not the cloud OS itself.
I support embracing other major cloud APIs, assuming they are properly maintained and their inclusion doesn't limit OpenStack's behavior. The approach you suggest, however, supports those non-native APIs at the expense of the native one.
I'm unsure why you recommend the renaming of Nova's API to a vendor specific name, as it's used by a number of different organizations and it's community maintained.
I also don't see why this focuses on Nova. OpenStack is a set of components, and any AWS bridge really needs to sit outside of all of them. It would make more sense to have an API bridge service that talks to the various OpenStack components using their native API (which would be your low-level API). Then we could completely rip out any non-native APIs from projects, to reduce their complexity.
In that scenario, if you only ever want native APIs, you'd just not install the API bridge service.
The Nova API is a direct copy of the Rackspace Cloud Servers APIs with all of the good and bad that implies. It is not a "native" API. It was adopted in the same way as the EC2 APIs were adopted. It's selection was deliberate on the part of Rackspace because it served their corporate interests. Given that the EC2 APIs existed in Nova first it would have been just as easy to fork those and move forward with an OpenStack derivative of the EC2 APIs.
Nova has no native API. if it had one it would be something smarter than what exists. The Rackspace Cloud Servers API is decent but has its own baggage. We swapped one opinion (EC2) for another opinion and what we should have done was sit down and figure out what Nova and its user community actually needed instead of using the RAX opinion which is ONLY in Rackspace's interests.
Take a proprietary API and fork it? That would just confuse things. We'd have an API that is incompatible with EC2, but confusingly looks a lot like it, then we'd need to create a bridge for proper EC2 support.
Rackspace gave their API away. The fact that they designed it doesn't really give them any advantage now since they don't control the future of it.
If you dislike the Nova API, you should participate in the process for designing new versions of it. The beauty of having our own API is that we can iteratively improve it.
It's not about disliking the Nova API. It's interesting how much you continue to deliberately misunderstand me.
This is about OpenStack end users having choice. Hybrid clouds are important. Compatibility with major public clouds is critical to that end. The Rackspace Cloud Servers API does not help with this.
The AWS APIs are critical to OpenStack's future because consumers of OpenStack clouds want them to facilitate migration on/off AWS and running hybrid clouds. Period.
I'm not misunderstanding you. Being compatible with other cloud services is an admirable goal, and one that would be great to support, if there's organizations that are willing to support these implementations. You seem to be suggesting CloudScaling is willing to maintain the AWS compatibility and that's great!
My point, though, is that your suggested approach doesn't properly address the issue.
There's no single component that covers all AWS API calls. Service groups, floating IPs, etc. are handled by Nuetron. Compute services by Nova. Block services by Cinder. Heat provides autoscaling and orchestration. Etc. etc.. That's why I was saying that limiting this to Nova makes no sense.
It makes a lot more sense to remove any non-native API from many of the OpenStack services (to simplify them) and to have a translator service that sits on the outside. It lets OpenStack keep control of the APIs while still allowing a compatibility layer for a number of other APIs.
I don't actually disagree with any of this. In fact, in some ways it's what I'm advocating. The difference is that you think that the current Rackspace (Nova) API is "native". I do not. This API is just as limiting as the EC2 API, just in different ways.
For example, I was talking to some Foundation folks with more direct experience with the Rackspace API than me. They felt that the password reset functionality did not make a lot of sense. What if the community wanted to remove this functionality and the Rackspace public cloud is dependent on it? What if they had to re-factor to push this into extensions.
The Nova API should be something other than it is. It should be owned and driven by what the community wants to add as features. It should have little or no opinion such that it can provide a great way for us to add more and more features over time. I think we all agree on this.
Where we don't agree is that I simply think that the current Rackspace (Nova) API does not belong as that abstraction layer. I mean, just look at how much networking control still runs through the Nova API vs. Neutron.
My suggested approach is a common low level API and then a series of bridged APIs that talk to it. It sounds like we're in alignment on that already.
Indeed. This is of course why the APIs are versioned. It's possible to modify the Nova API as much as the community desires in the next API version and Rackspace can continue to use the older version until they have time to move to the new one.
Rewriting from scratch is almost always a bad idea. We already have the code written, let's just incrementally improve it via API versions.
We're just going to have to agree to disagree. I don't believe this is the right approach. I've read Joel's piece before. The only absolute is that there are no absolutes.
Put more simply, none of the EC2, Rackspace (Nova), or GCE API code is rocket science. It's very simple and the line count is relatively small. Re-factoring out into a simple low level API would be low effort, high value. All of the existing APIs would map more cleanly to a lower level API with less of an "opinion" rather than the Rackspace API. New APIs could be added more trivially (e.g. Azure and vCloud Director) if they talked to a lower level API.
It's not really a re-write anyway, it's just moving the Rackspace (Nova) API up a layer and adding a clean low level abstraction. This is done all the time in software development. The Rackspace API is not designed as an abstraction layer.
Right. I get your point. Makes sense.
Why are you having this fringe discussion rather than just submitting a pull request? If the line count is low, and this is all simple, then contribute it.
Another strong incentive to having an API bridge service is that it could be used both ways. You could have drivers that take native OpenStack calls and post them to AWS/Google/Etc.. That would be an effective mechanism for Hybrid clouds for customers that prefer the OpenStack APIs.
I think OpenStack has been incredibly successful at solving the "Operations" problem of how to turn datacenters into clouds - automated hardware provisioning etc. The permutations and complexity of doing this across many vendors has sunk many previous attempts over the last decade. There is a lot of value and revenue in selling this solution to CIOs.
The argument about APIs is about the "Developer" problem of how to turn clouds into applications. This is where OpenStack has fallen short and is the area where AWS has built a big ecosystem. Depending on how end user companies are setup, the CIO may be optimizing for developer productivity, or for low cost, or may not even have a seat at the table for the discussion of what technologies the developers use to deliver applications.
My thoughts on this from almost two years ago still seem relevant: http://perfcap.blogspot.com...
The release of NetflixOSS has made it easier for me to measure progress in this area. NetflixOSS is roughly based on the AWS 2009 era feature set, and so far Eucalyptus have shown that it's possible to implement this in a useful way. There is work going on in both the CloudStack and OpenStack communities to close the functionality and compatibility gaps, and other cloud vendors are also showing interest. You can look on NetflixOSS as a collection of things that Netflix found useful or wished that the cloud already did, that made us more productive at developing our applications. It can also be used as part of a compatibility test.
I think this gets it exactly right. To complement this, we need a post (from Randy, or maybe over at http://speakingofclouds.com ) which spells out the implications for OpenStack in terms of architecture, functional constraints, and what constitutes the core of the project.
See also Rob's timely series of blog pieces on OpenStack core and the dependency situation:http://robhirschfeld.com/20...This analysis would definitely be affected by a commitment to AWS API compatibility.
UPDATE: Let's start with this: http://www.speakingofclouds...
Here's one functional constraint: Rackspace doesn't have anything like availability zones.
This issue is covered well in the following video: http://www.rackspace.com/bl...
There's a lot right in Randy's analysis, conclusion and call to action, imo. But what there isn't is a lot of science. And that's what the cloud folks, in all their incarnations (even the ones making money) seem to have forgotten, the science.
I realize this may be uncomfortable for some people, but..
Not all tech is science. Not all software is computer science.
I'm not blaming anyone. After all, today's thought leaders are the same folks who were tricked into believing extortion is okay if it's in a licensing agreement (and no one goes to jail), that GUI and OS are synonyms, that an OS is a revolution because its authors weren't paid (and the price tag is 0) and that it's okay for programmers to hardcode decisions into software (because they always have).
The good news is, help is on the way. How can I be so sure? Throughout history, when science doesn't lead, it catches up. Always has and always will. :-)
In fact, I feel so confident that help is on the way that I predict we will witness a truly rare phenomenon in the next year or two - a 2.0 of a thing will wipe out the 1.0 of a thing (and its head-in-the-sand advocates) before it ever really fully takes hold.
Randy, commenting on "...the idea that a set of public clouds based on OpenStack will arise to serve one half of this equation. The likelihood of such public clouds seems low to miniscule at this point" - HP Public Cloud is based on Openstack, right? If so, then we have at least one case of above. Agree, being only one and so fresh is not enough, but still.
It would have been more accurate for me to say "successful public clouds based on OpenStack." I apologize for that. I may update the blog posting. HP Cloud is minuscule compared to even Google Compute Engine, which in turn, is dwarfed by AWS. I believe AWS is north of 200K servers, but some folks estimate AWS is closer to 500K. HP Cloud is a few thousand. It's really an altogether different scale and the chances of HP Cloud catching up seem remote. How exactly do you catch up to something like AWS at 200K servers when they are still growing ~100% year over year? At 5,000 servers you would have to growing at more like 500% year over year to catch up in 2 years. That seems improbable, but I'll give HP Cloud full props if they make that happen.
Great post. No point trying to fight the unstoppable force. Instead, figure out the best way to leverage their strengths in a complementary manner, and dominate areas (hybrid cloud) that AWS chooses not to play in
In discussions with colleagues, compatibility with AWS APIs is a significant factor. OpenStack having clear support for those APIs would make it a much more attractive option. Otherwise, we face "lock-in".
I have translate this articles into Chinese. Maybe there will be more discussion about OpenStack's future.http://duyujie.org/post/563...
Good open-letter, Randy. I'm just not convinced that any API effort should try to adopt another API internally. And, besides, it's not a battle of APIs. The war here is waged on the infrastructure behind the APIs and the price policy of the vendors.
I wish the debate included: 1) Using the Cloud infrastructure as a software app deployment mechanism, and 2) enabling apps that run on local and remote Cloud services (the "hybrid"). My company, Appvance (formerly PushToTest with TestMaker), intends to release its next software performance testing infrastructure using Eucalyptus tech. Our Ant build scripts output AMI and EMI files!
Is there a reason not to adopt Eucalyptus in OpenStack?
Eucalyptus is an EC2 workalike written in Java, while OpenStack is written in Python. One of Eucalyptus' early shortcomings was its' inability to handle accounting which is necessary for a public cloud provider and for many is necessary in private clouds, so that departments can be billed out of the IT budget.
Companies using AWS to the greatest advantage have little choice but to marry its' API a bit, and there's no good reason for OpenStack to try to 'innovate' in such a manner that actually makes Rackspace's (unimpressive) API the de-facto.
This is similar to a debate I've had with members of the GIMP team a number of times that adopting the same menu items and hotkeys as PhotoShop would be advantageous and is upheld by a court decision, but most professional designers I know have a reaction to GIMP that's something like, "It's wierd". Having it work like the system they're trying to move away from is the obvious answer to that.
Noone sold an electric car by making it a substantially different experience to the type of cars people grew up being taught to drive.
Thank you Justin. Great reply. Yeah, I want the gas pedal in the same location too. Think we'll ever get that far with the Cloud?
A reason not to adopt Eucalyptus in Openstack is highly incompatible open source licensing. Openstack is Apache. Eucalyptus is GNU V3. This is a non-trivial issue.
They are overlapping solutions. eucatools already works with OpenStack. OpenStack already supports both the EC2 APIs and the Rackspace APIs.
Thanks, Randy. So lets say I am an electronics retailer and I run my marketing campaign apps on a combination of internal (Grid/Datacenter) and external (Cloud) servers. Euca EMIs seem like a good deployment mechanism. Same true for OpenStack?
Can be argued that GovCloud and the yet-to-be-settled CIA Cloud are "private regions for" Someone who wants one (and can pay)
No, but they may build AWS-in-a-box.
And arguably there's a reasonably-sized constellation of organizations that can consume enough compute resources to warrant a private region, especially if it's stripped-down in feature set (for instance, having only reduced-redundancy S3).Or consortiums of community clouds.
1) +1 to Bori's comments
2) AWS APIs are a developer's nightmare and Amazon has shown no indications to fix it. By aligning with these, we are missing the only opportunity to standardize.
3) If someone counter argues that developers are not worried that AWS APIs are poorly designed, but only for the capabilities it provides, then why bother with embracing at all. Some end developer anyway is going to write code to enable hybrid cloud. There is no question of standardization or embracing at all then.
1) See my comments on Boris note2a) Bad or poor APIs win all the time, bad technology wins all of the time; only market adoption really matters 2b) It's not about standardized APIs; it's about a standardized reference architecture or architectures and OpenStack is miles away from this, if it's even possible 2c) One standardized reference architecture for OpenStack could be about AWS compatibility; what possible downside is there? None. 3) Because AWS is going to be north of 10M VMs under management in another few years? I think it's short sighted to assume that end developers are going to write some kind of magical code that enables hybrid clouds. That isn't the problem. The problem is that the two connected clouds have to look somewhat like each other. It's like saying you are going to wire together IPX and TCP/IP into a united global network. The closest we got were the crappy Novell gateways and IPX eventually lost. OpenStack could be the next IPX if we aren't careful.
There is no credible reason for not embracing Amazon and the AWS APIs. Asserting that the APIs are "poor" is a developer argument, which has nothing to do with market forces and dynamics. The best technology or APIs *rarely* win. It's a miracle when that happens. You shouldn't bet on miracles. Pragmatism over ideology, please.
Randy, thanks for the replies - I agree with you on best technology rarely ever wins. But with rest of the comments, No. Blog post seem to talk about APIs, and comments are about standardized architecture. Your comments seem to mean that the interfaces can be different, but the connected clouds need to look the same. Asking to implement my private cloud like AWS is like having hammer as the solution for all my carpentry needs. I get that your customers need AWS compatibility. That doesn't mean all of them would want it or need it. In fact, most of them wouldn't want it.
Credible reason for not embracing AWS is, it is not enterprise ready (not the usual FUD people have on 'cloud security' but about enterprise workloads). AWS Private Cloud/ regions is like VmWare's cloud strategy built on top of vSphere and other components.
Yes, it's not about APIs, it's about standardized architectures, which require the APIs: http://www.cloudscaling.com...And I think you missed the point. I'm not advocating that all OpenStack clouds mimic AWS. I'm advocating that the community stop treating AWS like the enemy and instead treat them like a partner, including making certain OpenStack can be as compatible as possible. OpenStack is very flexible. You can use it to build all kinds of clouds. One major flavor that needs attention is AWS compatible clouds. I'm sure there will be many other flavors. All of those can exist too. Again, this is NOT a zero sum game. It's not about AWS loses or OpenStack loses. It's not about OpenStack having to be like AWS or vCloud or anything else. It's about not pretending that there is a mythical reference architecture for OpenStack. There is none. There is not one common reference architecture for OpenStack anywhere. Which means that it's very flexibility should be used to support a number of different reference architectures of which AWS is a key one in order to support hybrid cloud deployments.
Oh OK. That explains! This comment clarifies your stand. I agree, thanks!
I'll play devil's advocate, as always...
The question I have is this... how much value to the end user is there in being able to interact with OpenStack via an EC2 API? Nova lags behind EC2 on feature-function and is quite different inside. Because of that, today and in the near term OpenStack EC2 API will only expose a subset of functions that EC2 offers. So if you are used to EC2, Nova with EC2 API emulation over it is a questionable substitute. My gut feel is that the vast majority of those that started out on Amazon and adopted native EC2 APIs are unlikely to switch over or start using OpenStack... it almost seems to me that the value is rather in allowing one to access EC2 (and GCE and vCloud) via an OpenStack API and baking that into Nova rather than the other way around. What am I missing?
This isn't what we are seeing. Many of our customers want this compatibility and it has been key to buying decisions. With regards to the architectural gap in OpenStack, it's not very large. We did significant work on OCS to make it the most AWS compatible system out there. In fact, we would be happy to contribute some of this back. Cloudscaling could also publish a guide to configuring OpenStack for maximum AWS compatibility.
OpenStack was originally designed as an AWS knockoff so it's not nearly as different as many think. And it's very configurability is what has allowed Open Cloud System to be configured to maximize AWS compatibility.
Randy to Boris point above if there are missing features in the current NOVA API wouldn't it be simpler to fill in the gaps under the current (Rackspace driven) implementation and use that as the Native API and add the API gateway ontop of that?
Also in your suggestion do you suggest that the "Native API" would be underlying substrate that support ALL the aggregated features of all the supported API's?
Anyone writing code to interact directly with APIs of popular clouds is probably doing something wrong (and certainly wasting effort). There are a number of cloud abstraction libraries which are doing a great job in providing a unified interface to multiple clouds. Fog (Ruby) is a great example - sponsored by Heroku no less - of how a community/ecosystem is developing around multi-cloud interaction.
Heck, we even use Fog in our own CLI to interact with our own API!
Are your customers filling out the user survey? Can you please encourage them to do so? All the information they provide is private unless they mark them as public. Only aggregate statistics are given.
Our survey statistics show that the compatibility APIs are not strongly represented in deployments (~30% EC2, %25 S3). It would be great to get better statistics on this.
: https://www.openstack.org/u...: http://www.openstack.org/su...
It is also worth remembering the Netflix OSS.