In the beginning, there was one block of bytes that was called "the application." Perhaps you toggled it into the front panel of the computer, perhaps you handed someone a deck of punch cards, or perhaps you dragged a single EXE file into your favorite folder. But there was one thing that was the application -- one tangible, immutable, unopenable thing -- and it was relatively easy to move or duplicate.
Those days are ancient history now. Today's applications are multilayered, multitiered, service-enabled, and often as dependent on a certain server cluster as on a specific operating system version. Naturally, even as "the application" becomes more and more complex, we want to make it more and more portable. It's no longer enough to migrate the virtual machines from server to server. Now we want to move the app from one data center to another, or from the data center to Amazon EC2.
Enter two companies that are changing the game and creating one of the largest abstraction layers I've ever seen, all in the hopes of conquering the myriad layers of dependencies and making it possible to move server farms from here to there without pulling out your hair. Ravello Systems and CloudVelocity are creating the tools for juggling virtual machines from the data center to the cloud and back again.
The two companies confused me at first with their use of the word "application." Ravello and CloudVelocity are using the word to refer to something different than a pile of bytes or a collection of files (although that's what it is ultimately). They're not even using the word to describe a working group of virtual machines.
When Ravello or CloudVelocity say "application," they mean a cluster of what we used to call computers and all the information inside of them. After all, what we call a computer when we purchase it from a cloud company is just another program wrapped around your software. Together, these programs make a bigger program, and we might as well call it an application because that's closer to the reality in the cloud.
Once you have the Ravello or CloudVelocity system up and running, you can go to a website, click a few times, and clone a big collection of virtual machines all at once. Bingo -- then you can keep them running or shut them down or spin up 30 clones, all to handle failovers or extra loads or troubleshooting or testing, whatever you want. CloudVelocity focuses on migrations and disaster recovery, while Ravello leverages the public cloud for the development and testing of applications that will be deployed on-premise.
The Ravello and CloudVelocity systems -- both hosted services and both focused on Linux-based application stacks, at least for now -- take a different approach to juggling all the machines. While some folks are building elaborate rules for installing all the software in the new compute instances using tools like Puppet or Chef, Ravello and CloudVelocity just make clones, then clone them again.
CloudVelocity's One Hybrid Cloud
CloudVelocity's website offers two basic operations: watching and cloning. The company is able to do this because it has built a little tool that digs deeply into the operating system and siphons the performance statistics -- CPU load, as well as memory and bandwidth usage -- to CloudVelocity's servers. The graphs are similar to the basic results you get from the average monitoring program.
But CloudVelocity also builds a virtual machine that's an Amazon-based clone of your current machine with all the data, ready to go. It does this by copying all the files that make up your current instance, right down to the OS kernel, to an Amazon EBS volume. Then it creates a new AMI (Amazon Machine Image) with those files. The Dashboard tab lists every soldier in your clone army, while the Cloning tab lets you create a new copy in seconds.
The GUI makes it easy to specify which hosts will get new, public IP addresses -- just drag them to the "public" side of the firewall. Hosts on the "private" side of the firewall will keep their existing internal IPs.
The cloning process lets you duplicate multiple machines in one click. If you have a MySQL server, a MySQL mirror, three application servers filled with business logic, and a load balancer, you can group them together as one "application." One push of the clone button creates six new machines.
CloudVelocity automatically creates the Amazon VPC (Virtual Private Cloud) and the necessary security groups based on the services in your application. If you want to change those security rules, you can do so directly through the CloudVelocity GUI.
Thereafter, if you like, CloudVelocity can keep your Amazon clones continuously updated with any changes to your on-premises machines (but not vice versa). You can also define subsets of machines and replicate/synchronise them as needed. CloudVelocity offers a fairly elaborate way to group together your virtual machine collection, and keep the files in Amazon EBS in sync with their on-premise counterparts.
Thus, CloudVelocity also offers a way to provide disaster recovery in the cloud. The company's literature suggests this can help with failures in both the cloud and local machines. You might want to keep the main servers in-house but have CloudVelocity's clone army ready to go in case your in-house machines fail. Or you might want the Amazon clones ready for action in case your Rackspace machines go offline. After all, CloudVelocity can clone machines on Rackspace as easily as those in your data center.
CloudVelocity's cloning tool is powerful, but it's not omniscient. It won't track changes in memory, so your clone won't be an exact replica. This probably isn't important because the software should be writing anything valuable to disk in any case.
CloudVelocity integrates with MySQL to synchronise database transactions to the cloud site, but if you have your own way to create live backups of your MySQL instance or use a different database, CloudVelocity can kick off your scripts and ship the backups as required.
CloudVelocity supports the major Linux distros, including Red Hat, CentOS, Ubuntu, and Amazon. Windows is a work in progress. Of course, thanks to the magic of bitrot, my experience wasn't perfect. I tried cloning a CentOS 6.4 machine from Joyent only to have the machine lock up. Joyent uses a version of CentOS with a kernel that's been modified just enough to mess up everything. When I switched over to a Rackspace machine, it all went swimmingly.
CloudVelocity's handy discovery tool will locate all of the servers in your application. Then you determine which will be copied to Amazon and whether they will be synched with the originals for disaster recovery.