By Steve Bradshaw | September 12, 2012
As a guy who has spent almost three decades in the IT industry working with legacy applications and VMware vSphere, I have to admit that because of my initial assumptions I had a hard time transitioning to an IaaS cloud as offered by Eucalyptus Systems or Amazon Web Services. Maybe I am not alone.
Ten years ago, my transition from running legacy applications on physical machines to those on virtual machines was not that difficult. Since a virtual machine is designed to act just like a physical one, the conceptual leap from physical to virtual was pretty easy.
My move from vSphere virtualization to the cloud proved to be a lot tougher. Most of us use what we already know as a bridge to help us learn something new. That often involves trying to find the similarities between the “new thing” and the “old thing.” In this particular case, my underlying assumptions were not enough.
I incorrectly assumed that Eucalyptus and vSphere would function in similar ways because they both were based on virtual machine technology. Sure, Eucalyptus calls its virtual machines “instances,” but they are still a virtual machine. Given this, I assumed the primary difference would be the user’s self-service provisioning interface. In sticking with the theme of this post, you can probably imagine, I was wrong.
Additionally, I kept expecting the Eucalyptus-powered cloud to work like vSphere virtualization. For example, I expected Eucalyptus instances to have the same CPU, memory, network, storage, and I/O features as vSphere virtual machines. I also expected Eucalyptus to protect my individual instances just like the vSphere infrastructure protects individual virtual machines. It quickly became clear that my underlying assumptions were not leading me down the right path.
Seeing the Light
What helped me finally make the transition from virtualization to cloud was understanding that vSphere and Eucalyptus are fundamentally designed to solve very different problems and do different things. Because of these differences, my earlier attempts at a feature-by-feature comparison were not helpful, but hurtful. Both Eucalyptus and vSphere are designed to do different things, and as a result, have different features that behave in different ways.
Based on my experience, it’s my view that vSphere today is not about the cloud, elastic computing or storage resources. vSphere is designed to run legacy applications on virtual machines. Running legacy applications designed for physical machines, on virtual machines, leads to design decisions that are evidenced in vSphere. First, a vSphere virtual machine must provide all the features of a physical machine that a legacy application might expect to see and use. This means providing multiple CPUs, expandable memory, multiple network interfaces and disks, a CD/DVD player, a floppy disk drive, and serial, parallel, and USB I/O ports. Second, the vSphere infrastructure must also do all that it can to protect the virtual machine and its application using various backup, high availability, and fault tolerance techniques. Some of these high availability techniques depend on the ability to live migrate both the virtual machine and its storage.
Eucalyptus, on the other hand, is all about the cloud, elastic computing and storage resources. The Eucalyptus approach is about the future - providing a “greener field” where you can leave your legacy applications behind. This begins with an infrastructure architecture that is as scalable as the modern cloud applications that run on it. While the majority of legacy applications were not designed to scale horizontally on demand, modern cloud-aware applications are built with this principal at the core. While this does not mean all legacy applications must be left behind in order to move to a Eucalyptus cloud, not all will be able to run and fully utilize the power and scalability of the cloud.
For this reason, Eucalyptus instances are not designed to be replicas of physical machines. Eucalyptus instances should be viewed as “units” of compute, storage, and network resources that are designed to be used collectively to provide scalable capacity for modern cloud applications. “Units” can be dynamically added and removed as an application’s workload changes over time.
Based on this understanding, Eucalyptus instances do not need to provide functionality such as CD/DVD players and multiple types of I/O ports. Compute resources, network connectivity and access to storage somewhere in the cloud are the basic tenants of cloud software. In fact, with an application that horizontally scales across multiple instances and saves its data to non-instance-based storage, the need to protect, back up or migrate individual instances is not that important anymore. If an instance dies, customers can simply start a new one. In fact, monitoring software can automatically start a replacement instance. What matters most now is not necessarily the instance, but protecting the cloud infrastructure that both runs the instances and also stores the application data. Eucalyptus High Availability is designed to do just that.
Others Seeing the Light Too
During my personal quest to truly understand the IaaS cloud, I found others who discovered the benefits of migrating from legacy applications to cloud applications running in a scalable IaaS architecture. A great example was a case study involving the United States Department of Agriculture’s National Resource Conservation Service. It perfectly illustrates the benefits of migrating legacy applications to web services designed to run on a scalable cloud. Deployed on Eucalyptus, they developed a state-of-the-art system that served as a development platform, facilitating the migration of existing scientific modeling applications within NRCS to the EC2-compatible IaaS cloud environment.
The NRCS had 100+ modeling tools, written as legacy applications, that they distributed to 12,500 computers (desktops?) individually. Each application had its own interface, database and other unique requirements. Adding multiple versions, updates and other complexities made the maintenance of these valuable environmental modeling tools extremely costly and time-consuming.
To overcome this complexity, the NRCS created the Object Modeling System (OMS). The OMS is a computer framework that takes legacy environmental modeling applications and turns them into a Web service that can be run in the cloud. With Eucalyptus, the NRCS developed an efficient and scalable system for running its new Web services applications in the cloud, called Cloud Services Innovation Platform (CSIP). The NRCS’s CSIP has demonstrated the real-world benefits for both administrators and end-users when migrating legacy applications to cloud-based Web services. These service are even accessible from laptops and Android phones.
So while it took me a bit of time to figure out all this new IaaS cloud stuff, I am happy that I finally did. I don’t feel so much like the old guy in the datacenter anymore. Apparently you can teach an old dog a new trick. Woof!