The Virtual Machine

I had a conversation today with a fellow I work with. He was lamenting about how when they had gone back to add a piece to the software he had developed with me six years ago, the company had not wanted to let his off shore development team have access to the development server. I told him he should have asked them to carve off another virtual server for the development team to use so that it could be isolated from other development, but still function like it would in the test and eventual production environment.

I think of virtual machines as a fairly standard technological tool now, but he looked at me like I had just spoken in Sanskrit. So it makes it a fairly good spot for me to do another blog post about a technology that you might not have heard about yet, but you will hear more and more about in the future.

One of the problems we have in IT is similar to a problem that factory managers have. I have a base overhead cost for operations. My building (or server) costs the same regardless of how much I use it. I have to heat it, cool it, pay taxes, protect it, even if I'm not really using it right now. So the way factory managers approach this problem is to try to always make sure that they are running the lines at the factory as much as possible. That's why you get second and third shifts. It's more more economical to run additional shifts then open additional facilities.

Remember that traditionally there are two aspects to a server. There is the physical box that is the computer, and there is the operating system that runs on it. I pay the hosting company for the hardware, the connection, and the security of the building and its power supply. I don't pay less if I use it less. So by applying the principles of the physical factory to the virtual one, we can see that I could be a lot more productive if I could find a way to run more than one server on a single piece of hardware. In addition, a single piece of hardware is very rarely sufficient for today's environments. You need to have backup hardware options.

So what a virtual machine does is take a pool of hardware resources, typically in a blade configuration where you can literally snap in additional processors and memory, connect it to a large shared hard disk and run a whole bunch of "server images" on a single operating system. What this does is help smooth out the spiked performance profile of most servers by basically time sharing the common resources. Each server image is to the network its own individual server, complete with network address and operating system. But the hardware behind it is shared. Since most servers don't need all of their available resources at any given time, what they don't need is shared to all of the other servers because they share the same hardware. So if server "A" isn't highly utilized right now, it can share that excess capacity to server "B" who is being highly utilized right now. If neither server is needing all of the available resources very often, you can install server "C" by configuring the software, no new hardware purchase required. If your virtual servers are totally swamping your system, you can add extra memory and processing power that they can then all share.

In some ways it's like a commune for servers. If they have too much, they can give it to others who need it. If they don't have enough, they can take more from servers that have excess capacity.

So for my colleague's issue, what he really needed was to have them carve out a new development server from the virtual hardware and hand that over to the development group. No additional hardware sunk cost, just a configuration change. Then the developers could work on their new system without impacting any of the existing systems. When they were done, you simply dissolve the development server back into the pool of other servers. No fuss, no muss.