FastScale Takes a Different Approach to Virtualization and Provisioning

Published: April 24, 2007

by Timothy Prickett Morgan

It would be hard to find a single person in any IT organization in the world that didn't think that the enterprise software stack--different virtualization hypervisors, dozens of operating systems, myriad database management systems, disparate middleware layers, and untold homegrown and third-party applications--is not too complex and too costly to support. There are a lot of ways to try to fix this problem, and a Silicon Valley startup called FastScale Technology, which has just come out of stealth mode, thinks that it has come up with a new way to make infrastructure simpler and easier to maintain.

The ideas behind FastScale Composer, as the company's product is called, are so simple that once you hear it, you will think, "That was obvious." But like many obvious ideas, no one has thought of them yet, and it took a lot of pain and a new way of thinking outside of the box to come up with the ideas embodied in the product.

Those ideas are the product of FastScale's three founders. Lynn LeBlanc, FastScale's CEO worked at IBM for a decade in the 1980s, and then worked at Cadence Design Systems and Octel Communications, and Scyld Software (that latter company, which sells a commercialized variant of the open source Beowulf clustering software for Linux, is now owned by Penguin Computing. Stevan Vlaovic, FastScale's chief technology officer, was a system architect at Sun Microsystems in its Advanced Processor Architecture Group and has also been involved in systems design at Intel (in the Microprocessor Research Lab) and Silicon Graphics. Richard Offer, FastScale's vice president of engineering, has two decades of managing software projects and has had stints at SGI and Scyld as well.

FastScale was founded in January 2006, and only 11 months later received $6.5 million in its first round of venture capital funding. The company has 16 employees, and will more than double as 2007 progresses and it goes from stealth mode to marketing mode, with lots more development.

The target of FastScale's desire is the same one a lot of vendors are shooting at these days. Somewhere between 70 percent and 80 percent of the IT budget is burned up supporting existing applications, not creating new applications to chase new business opportunities. Server utilization is in the 5 percent to 10 percent range for most of the 25 million or so boxes out there in the world. And it takes anywhere from $500 to $3,000 a month in administrator labor to maintain a single application server these days. The root cause, according to LeBlanc, is that software is both bloated and fragile. General purpose operating systems, middleware, and database stacks have so many components and modules, and they all have to be patched and updated. Often, when software is updated, it has to be taken offline, and even when that is not the case, the myriad interdependencies between pieces of software (and the elements within it) make it brittle.

To date, companies have kept software stacks on separate pieces of hardware to get around the brittleness problem, which has driven down utilization on servers that might otherwise be running multiple applications. And they keep libraries of so-called "gold images" of working software stacks, which they deploy onto physical or virtual machines as more processing capacity is needed for workloads. Operating systems--particularly Windows and Linux--do not have enterprise-grade workload managers, like mainframes, proprietary midrange, and Unix boxes have, and that is why virtualization is set to take the X64 market by storm. Companies are excited about virtualization hypervisors because they can be used to isolate software stacks, like separate physical servers have been, while also driving up utilization, because multiple virtual machines can be added to a physical server. Still, virtualization can excise a 5 percent to 30 percent performance hit, and not all workloads--particularly those with large amounts of I/O--can be virtualized. So this is not a perfect solution.

Gold images and virtualization are all well and good, but they do not, according to LeBlanc, really fix the problem. "We have taken a fine-grained look at hardware and software architectures to see where the bottlenecks are," says LeBlanc. "We have focused on the mass proliferation of servers, which has been an exponential problem for the past five years. It is not unusual for a company that is only a few years old with around 100 employees to have more than 1,000 servers. There is an unbelievable amount of infrastructure out there, and many companies are struggling to keep up."

The root cause is software bloat, as far as FastScale is concerned, and by fixing this problem, companies can cope with the issues of server sprawl. No, FastScale is not creating a streamlined operating system or software stack that fits a rigid set of needs. Rather, FastScale Composer aims to change the way bloatware is actually deployed. Today, when you want to deploy a stack of software, you load up an operating system and its middleware, database, and application code on a physical or virtual server. Then you provision that software onto a server or a VM, and let it rip. This process can take anywhere from three days to three weeks, depending on the complexity of the software stack and the skills and tools of the administrator doing the work.

What FastScale Composer does is load all of your software into a repository and then pick and choose all of the software elements you use in that stack. Rather than deploy that stack in a persistent manner--meaning that it is tied directly to the a specific server or VM--Composer watches what elements of the software are actually needed--down at the code module level--and then only provisions the elements that are used onto the physical server. The elements that are used in a FastScale provisioned server are determined by something called an application blueprint, which is used to discover, at runtime and in only a few seconds, what parts of the software stack actually need to be deployed on a server by watching the software run. These pieces of code are deployed in a new kind of virtualized environment called a dynamic application bundle, or DAB, which can include real operating systems or virtual machines--FastScale Composer doesn't care, since it is all just software modules as far as it is concerned. The bits of the software that are needed in a working stack of software are deployed in a non persistent way--meaning, they are loaded into the memory of the physical server where the application is running--and are not deployed on a disk drive and then loaded.

If any piece of software in the FastScale repository is updated, then next time a DAB is initiated, if any of the code snippets used by the DAB are updated--drivers, operating system kernel, libraries, application modules, and virtual machines, to be specific--they will be updated in the production environment residing in main memory. Perhaps equally importantly, if an application is updated and now requires a new feature of the operating system, the DAB can reach into the software repository and pull the new features that are required; equally important, administrators can lock down a DAB so bits of the operating system cannot be called by viruses or trojans or any other kind of malware. An exploit in one part of the stack cannot be used to comprise another part of the stack, because only the pieces that are actually used are present in the DAB.

This is a very elegant approach to provisioning software. And the amount of compression that FastScale can get is quite impressive. Take, for example, an Apache server running on Linux. The tradition stack of software might come to 3 GB in size. Anywhere from 20 MB to 100 MB for server drivers, another 1 MB to 2 MB for the Linux kernel, then 1.5 GB or so for software libraries, and 1 GB for application code. Now, run it through FastScale Composer and deploy it in a DAB in main memory. You only need 1 MB for drivers, the same 1 MB to 2 MB for the Linux kernel, another 15 MB for libraries, and 2 MB for the application--which drops the whole stack to 20 MB.

For now, the FastScale Composer and related repository is only available on Red Hat Enterprise Linux 4 (in both 32-bit and 64-bit modes) and the CentOS offshoot of RHEL. The software repository resides in a DB2 database for Linux, and the $30,000 list price for the FastScale software includes that DB2 license plus 25 server node provisions, which sell for $500 each if a company buys 250 server nodes. (Each deployed DAB is, in effect, a virtual server node. If you buy more, the price goes down.) The software will be supported on Microsoft's Windows Server 2003 and Sun Microsystems Solaris 10 by the end of the year. Conceptually, this approach can be used on any software, and it is likely that support for Hewlett-Packard HP-UX 11i v3, IBM AIX V5.3, and Novell SUSE Linux Enterprise Server 10 will likely follow shortly.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot