How OpenStack differs from Amazon and must rise to the occasion | Opensource.com
How OpenStack differs from Amazon and must rise to the occasion
This is a condensed version of the blog post: A tale of two expanding clouds: Amazon and OpenStack. Read more there about the OpenStack Summit in Hong Kong. Comments welcome.
The OpenStack community is an awesome software factory which has an awe-inspiring process for managing releases with a continuous integration, source code management, and peer review tools so much so that one of its community members has packaged up the process itself as a product offering. Each new initiative gets announced in mailing lists, makes rounds at unconference and in lightning talks, gathers steam, builds a wiki page or two, finds support, gains a GitHub repo (or two), develops a blueprint, and if it manages to find a little sunlight and fertile soil, it might just make it into incubation and eventually (if not quite as rapidly as Amazon’s process) be accepted as an official OpenStack project.
There is an open design and development process, and it works. It can and does support integrating new projects, the process for vetting new ideas, and growing a stronger portfolio of new services. The sunlight of transparency only makes the design and vetting process stronger. Continued innovation is critical. Expanding cloud competitor, Amazon, recognizes this, and the OpenStack community needs to embrace this ethos as well.
The difference between these two cloud giants is that everything OpenStack does, it does in the open. All of our successes and failures are in the open. So, we must beware to believe the OpenStack processes cannot support growth beyond the core IaaS feature set. If we do, we fail to grow OpenStack’s own portfolio of features, and we risk quickly becoming irrelevant as Amazon continues its proprietary quest for cloud market domination and saturation. In order to have a competitive open source offering for building clouds, both public and private—we need to add new services and features to the OpenStack portfolio to mature and stabilize the 'core' projects.
A good example of a newish feature is the Ceilometer project, that aims to become the infrastructure to collect measurements within OpenStack. Its primary targets are monitoring and metering, but the framework should be easily expandable to collect for other needs. To that effect, Ceilometer should be able to share collected data with a variety of consumers. This project’s existence covers a very real use cases, and I am sure, has uprooted a few community members initial business plans—but a cloud without a framework for monitoring and metering would be deemed useless by most enterprises.
Sometimes OpenStack will cannibalize a market, but more often than not the vendors in that space adapt and help grow the project, because that’s how open source collaboration works. If your IP (intellectual property) isn’t significant or unique enough to fend off a little community competition, it’s a good sign that you need to look elsewhere for your value-proposition. If you are spending cycles worrying that OpenStack is eating your market space, you ought to be watching Amazon.
The companies and individuals backing OpenStack for the most part seem to understand the OpenStack process—even if the pundits don’t. Most OpenStackers tend to take a longer term view of the market space and see the bigger picture. OpenStack’s focus should be on ensuring that its processes and culture remain open to innovation and are not reigned in by fear of overstepping our mandate; our mandate is open and will change as the technology evolves.
As much as we love Amazon and stand in awe of Netflix’s agility to take advantage of new technology and techniques, we’ve all been burned way too many times by software monopolies to ever go back to a world dominated by a single cloud and that certainly would not be a world that helps others cultivate their own gardens.