Rackspace (a noted high-end hosting provider) and NASA recently announced a joint open source endeavor called OpenStack. The project aims to merge cloud computing technologies from both organizations into one common, open cloud computing platform.
The rationale behind the Rackspace and NASA teams sharing their code on a project is simple. Neither of them is really a software development shop — they specialize in different areas — and the current cloud computing software they have was grown in-house either to satisfy internal requirements (NASA) or to offer a solution in a competitive market (Rackspace).
In the case of Rackspace, they would like to see projects move away from proprietary, locked-in computing platforms (such as Amazon S3 or the Google App Engine) toward a common open standard. Hence, as long as your application runs on the OpenStack platform, theoretically you should be able to host it either in-house or with any specialized OpenStack hosting provider. It’s a typical case of wanting to make the cloud computing pie bigger and more open. Rackspace is confident its ability to provide high-end hosting will give it an edge in such a larger market.
In NASA’s case, they just want to focus on their responsibilities (processing massive amounts of data coming in from space exploration) and avoid having to maintain an in-house, proprietary processing infrastructure.
The Rackspace and NASA Parts of OpenStack
Both organizations created OpenStack by contributing key technologies that are building blocks for their vision of a common, open cloud computing platform. Each of its contributions — object computing from NASA and object storage from Rackspace — is quite mature and production-ready (NASA processes terabytes of satellite imagery data with it and Rackspace hosts probably equivalent terabytes of data as part of its custom cloud computing offering), so the effort is geared toward integrating them into one common solution and picking the best parts of each.
Although the code in both sub-projects is quite mature and deployed in production, the OpenStack platform is still very much in its infancy as a complete solution. Both are adequately described as being in a state of “Developer Preview” and are definitely not production-ready yet (unless you are very adventurous).
OpenStack Compute (Nova)
The OpenStack Compute part of this project (otherwise known as Nova) is the NASA donation. It is basically a cloud computing controller built to match the existing Amazon EC2 and S3 APIs. Its main responsibility is managing the large set of virtual machines that make up a cloud.
NASA had recently open sourced it as the Nebula computing platform and that is when Rackspace decided to partner up with them.
Nova offers the following set of features:
- Public API: allows you to send/receive commands via HTTP to the cloud controller
- Cloud controller:presumably the most important component, responsible for integration with LDAP, storage services based on the Amazon S3 API, internal node/worker management
- Nodes: workers that start instances on demand
- S3: an HTTP server that provides the S3 API
- User manager: providers LDAP integration
- Network controller: allocates/deallocates IP addresses and VLANs
The Nova developer preview code is available from Launchpad, but I suggest you start off with the documentation at nova.openstack.org.
OpenStack Object Storage (Swift)
Object Storage (otherwise known as Swift) is Rackspace’s contribution to this project. It is basically the open sourced version of Rackspace Cloud Files . The Swift developer preview code is also available from Launchpad.
OpenStack Technology Overview
The interesting aspect of Nova and Swift is that both projects are very Python-centric and both targeted at running on Ubuntu Server. The Object Storage (Swift) documentation makes heavy reference to various Python libraries, but seems to rely on the standard Linux rsync utility to provide synchronization between nodes. Of the two, Swift seems to provide the most technologically focused and clearly defined stack.
Nova on the other hand is a mishmash of various technologies, some of which make me leery. The main networking/HTTP layer is built around Python and the Tornado async I/O server, which was donated to the open source community by Facebook.
However, despite some excellent performance characteristics, Tornado has been criticized because some think Facebook more or less abandoned it and it no longer is very actively developed . The Python Twisted async I/O server (which I believe has a much larger community and is very actively developed) is used sparsely as well (i.e. just some of its libraries). However, it seems the Nova developers are aware of the maintenance issue they are facing with Tornado and looking actively at alternatives (including Twisted, Node.js and others). This very interesting blog shares the results of their initial investigation.
Due to some of Tornado’s limitations regarding large file sizes, Nova includes a second, separate Web server, the highly regarded nginx server, which is written in C++. It is known for its async I/O design and excellent performance. Nevertheless, the presence of two totally separate Web servers seems to complicate Nova’s design somewhat.
Nova also includes a messaging system based on RabbitMQ. Unlike the Web component, it is written in a totally different technology (Erlang) and is a memory-only, non-persistent message queue. In short, when RabbitMQ runs out of memory it dies — very quickly and very hard. When we evaluated it internally at my organization about a year ago to replace our creaking WebLogic JMS queues, I saturated RabbitMQ and it crashed so badly that we had to reboot the whole server to get it running again. Hopefully, it has improved since then but the lack of disk-based persistence is worrisome in such a critical component. However, it has been recently bought by none other than SpringSource (and thus indirectly VMware), so it’s sure to receive a steady stream of maintenance and new features.
Next, we have Redis, used for persistent, fast, replicated data sharing. Redis is often described as memcached on steroids. However, with the integration of Object Storage (Swift) it seems to be a redundant component that is an artifact of two separate projects attempting to merge together. I was not able to find any documentation clarifying Redis’s future in the combined OpenStack architecture.
And last we have OpenLDAP, a highly regarded LDAP provider written in C++.
As you can see, the Object Compute part of OpenStack is quite a mixture of different technologies (Python, C++, Erlang). I presume this makes maintaining and updating such a system in production more complicated.
OpenStack vs. Ubuntu Cloud
After reading up on OpenStack, it became quickly apparent that it seems to have a lot in common with Ubuntu’s cloud offering (known previously as Eucalyptus). Both attempt to emulate the Amazon EC2/S3 APIs and both run on Ubuntu Server. The difference is that the Ubuntu Cloud seems to be already complete, in production and available today. It will be interesting to see how these two will establish themselves a year from now.
Although cloud computing is still used by a minority of development shops, it may very well be the standard deployment model for tomorrow. Hence, it is good to see NASA and Rackspace’s attempt at providing an open standard that could avoid vendor lock-in. This should be good news for companies such as Rackspace, probably not so much for those pushing a proprietary model (such as the Google App Engine).
About the Author
Jacek Furmankiewicz is a Senior Java EE developer at Radialpoint. He has 15 years of professional IT experience and is a Sun Certified Java Programmer (SCJP).