Virtualization
It's not a big surprise anymore -- virtualization is coming and it's coming in a big way. What I don't think is nearly as appreciated is quite how fundamental of a shift this is going to become. The separation of resource to application is a huge change in how IT, especially in networking, works.
One of the more interesting elements of virtualization is the notion of a shared processor pool. Rather than having one CPU per application instance or per user, a pool of processors is made available. As a user needs to do something, their virtual machine is instantiated on an available processor. For example, if there is a shared pool of 10 CPUs in a company, a group can use them as necessary so that idle cycles don't go to waste. So if finance only really needs heavy CPUs at the end of the month, they can run their reports, use the CPUs, and then return them to the pool for others to use. Product development can then use these same CPUs during the day for heavy computational use. Since everyone's virtual machine is separated, there is no security concerns of engineers getting into finance servers, etc. If the 10 CPUs starts becoming thin, the pool can be expanded without changing how anyone works.
This concept has been best demonstrated in "lab management" software such as VMware Lab Manager. The traditional problem of machine hoarding so that other user's don't change configurations has been the root cause of significant server farms that largely sit idle because there are only so many testers doing so much at one time. The last time I was involved with creating a lab environment, we had 4-5 servers per-engineer. The heat and power consumption was off the charts and I know for a fact that most of the servers sat idle most of the time. A package like VMware Lab Manager would have reduced the total server count by a factor of 10 without sacrificing any of engineering's ability to work.
Virtualization... big fun on the horizon. :-)
One of the more interesting elements of virtualization is the notion of a shared processor pool. Rather than having one CPU per application instance or per user, a pool of processors is made available. As a user needs to do something, their virtual machine is instantiated on an available processor. For example, if there is a shared pool of 10 CPUs in a company, a group can use them as necessary so that idle cycles don't go to waste. So if finance only really needs heavy CPUs at the end of the month, they can run their reports, use the CPUs, and then return them to the pool for others to use. Product development can then use these same CPUs during the day for heavy computational use. Since everyone's virtual machine is separated, there is no security concerns of engineers getting into finance servers, etc. If the 10 CPUs starts becoming thin, the pool can be expanded without changing how anyone works.
This concept has been best demonstrated in "lab management" software such as VMware Lab Manager. The traditional problem of machine hoarding so that other user's don't change configurations has been the root cause of significant server farms that largely sit idle because there are only so many testers doing so much at one time. The last time I was involved with creating a lab environment, we had 4-5 servers per-engineer. The heat and power consumption was off the charts and I know for a fact that most of the servers sat idle most of the time. A package like VMware Lab Manager would have reduced the total server count by a factor of 10 without sacrificing any of engineering's ability to work.
Virtualization... big fun on the horizon. :-)
posted by Steve Shah at 9:31 AM
0 Comments:
Post a Comment
<< Home