While OpenStack is primed to transform enterprise IT, enterprises still have a lot of questions today. One popular topic is how OpenStack compares with VMware. Perhaps the best analogy that I have heard to explain OpenStack to vSphere skilled staff is that of cattle and pets. vSphere servers are likened to pets that are given names, uniquely cared for and nursed back to health when sick. OpenStack servers are likened to cattle, which get random identification numbers, cared for as a group and are replaced when ill. Figure 1 below shows an excellent slide from a Gavin McCance presentation. For network technologist, another good analogy that I have seen compares OpenStack to UDP and VMware to TCP.
Is the enterprise ready for OpenStack?
In addition to asking how OpenStack compares to vSphere, many also want to know if OpenStack is ready for the enterprise. Perhaps the better question would be, is the enterprise ready for OpenStack? To get the most benefit out of an OpenStack private cloud, or a public cloud like Amazon Web Services, enterprise applications need to be optimized. Applications would need to have a cloud native architecture.
An optimized private cloud is largely regarded as the most cost effective platform and is designed typically with dynamically managed, scale out and relatively unreliable hardware. Cloud native applications therefore need to be written to handle the infrastructure platform. For example, they will have stateless components and be designed for eventual data consistency. Note that cloud native is not just about virtualizing an application and running it on cloud infrastructure to gain elasticity. Cloud native requires different application architecture. Netflix is a great example of cloud native application architecture. For more information on this new method of coding, see my previous blog post, “A technical primer on the cloud application architectures that are driving enterprise IT transformation”.
OpenStack for vSphere Admins
For vSphere admins who want to better understand OpenStack, check out this Youtube recording of a session from the Hong Kong OpenStack summit titled “Bridging the Gap Explaining OpenStack to VMware Administrators”. In that session, Kenneth Hui and Scott Lowe, architects from Rackspace and VMware collaborate to explain OpenStack to vSphere knowledgeable people. Note that they clearly state their focus is on vSphere, e.g. vCenter plus ESXi, and not vCloud. Some others have compared OpenStack to vCloud, such as is in the blog “vCloud, OpenStack, Pets and Cattle”.
In their session, Hui and Lowe review key differences in how vSphere and OpenStack manage images and storage. vSphere images typically sit on a vCenter server. OpenStack images can be placed in any file repository, even a public cloud system. So image portability across environments and locations is easier with OpenStack. Images are a key component to achieving a cloud native architecture.
Storage in vSphere is almost always represented as a SCSI disk no matter what the back end storage is. With vSphere, everything is permanent and persistent. If you kill a virtual machine, the data is still in the data store. Virtual machines think the storage is locally attached. OpenStack provides different virtual disks, either ephemeral (Nova), block (Cinder) or object (Swift). So OpenStack allows one to use the best fit storage for the use case. Ephemeral storage came first and is based on this design principle – why waste resources by keeping data around. Persistance can be provided with either block or object storage. Block storage is like a SAN that can be provisioned via API and is like attaching an iSCSI volume to a running instance – it is like going to a machine and plugging in a USB drive. Object storage includes metadata with storage and does not have the scalability limits of file systems like NFS or CIFS, and therefore can scale to handle millions of files like one might need with something like Wikipedia.
Hui and Lowe also use the cattle and pets analogy. In one example, one might customize a vSphere virtual machine for an Oracle database. Application resiliency would be taken care of by vSphere, leveraging features like vMotion and Storage vMotion. In this example, it is a problem if the virtual machine gets “sick”. In another example, one can create a virtual machine instance for MongoDB or RIAK. In this case, the application needs to manage resiliency and account for data consistency.
In one scenario, the infrastructure platform provided resiliency. In the other scenario, the application provided resiliency. What is the better approach if you consider both programming difficulty and infrastructure costs? Can developers, who typically have focused on functional requirements, adopt to account for non-functional requirements needed for cloud native applications? Should resiliency be in the hardware or the application? Many time-tested and critical applications like bank transfers and airline reservations run on super reliable mainframe hardware. Of course, it is important to note that those applications are reliable and have been time tested over decades. Their code is also are very stable.
What if the applications are very dynamic? Perhaps they are like Facebook and are constantly being updated and tweaked. Then it is very likely that the applications will fail before a mainframe would. These applications might even fail before an Amazon Web Service instance would. They likely have only been tested to work for short periods of time. For these more unreliable applications, a cloud-native design point, where application components can be restarted at any time, is probably the better choice. My two cents – it is easier to design a new application for failure than to make it super resilient.