we are using slow developer notebooks. They come equipped with vista and 2 gb rams, which slows down everything. Someone decided a good resolution would be to use vmware clients instead of faster pc hardware. VMWare clients would run on dual core xeon cpu's. What do you think of that and what backdraws will probably result out of it?
|
|
Be VERY careful here. I was recently deployed to a customer where everyone in the IT department had their VM essentially for the same reason - to enable them to have lower end PCs on the desk and then to remote into the VM and do their normal work. The experience there was not pretty. At least once per week we were running extremely slow for various reasons. Generally, we could tell when someone on the team was running a set of processor intensive SSIS packages. They did eventually move a few of us off to different servers, which helped some, but performance was never right. I think if you are going to do it - do your due diligence into server power, your processing needs, how many machines you are going to serve up, etc. It could save you some money, but if not implemented correctly, can cause LOTS of headaches. Please note: this is NOT a flame of VM architecture - just a warning for folks who are looking into it - make sure you have your ducks in a row before implementation. |
|||||
|
|
My team successfully implemented a "slow PC/Fast VM server" configuration. For a team of 20 developers, we had a 8 processor, 256GB RAM server connected via fiber to a very fast SAN. It was expensive, but cheaper than giving each developer a workstation with similar performance. For a small team (4 developers) I'm not sure the economies of scale would kick in and actually save you anything. |
|||||||||||||
|
|
Potential drawbacks
IME, it's a good solution and it does work, but you need some decent hardware on the host and when bad things happen, they happen to everyone. |
|||
|
|
|
This fails one of the most important criteria of the Joel test. I make sure all my developers have at least an i3 or better laptop or desktop with as much RAM as it can possibly hold. 8GB is what I strive for. It makes them more productive, and they can actually run Virtual Box on their local machines for development and testing, instead of on expensive to maintain servers. They can snapshot their Virtual Box install crazy stuff and test different browsers and installers and everything and in seconds be back to a known good configuration without any need to contact "IT" services. Developers need the fastest machines in the company, with the most RAM and root permissions on their local machines. End of story. |
|||
|
|
|
We do that for our remote machines and it works fairly well. Most rarely work from home (normally only for an emergency fix here and there) so we just use fairly lowend netbooks, remoted into our speedy desktop machines at the office. They are definitely still slower (probably limited by the network more than anything), but work for short tasks every now and then. This would really not be acceptable for a full time work horse, however, since VM can frequently cause a bit of lag that even with the best hardware, IMHO, is a bit distracting. |
|||
|
|
|
On a slightly different tack - have you given your managers/accountants a spreadsheet highlighting the cost of using these slow machines? Point out to them that a VM solution (unless done right, and that ain't easy) might simply put the developers and therefore the company in the same boat. |
|||
|
|
|
This will depend on how much adminsitrative power you have over the VMware install, if you are put into a low priority subpool then you will have slow machines depending on the activity of other subpools. |
|||
|
|
|
Hardware is cheap, programmers are expensive. Why would you want your programmers to be frustrated by giving them slow development machines? The cost of upgrading hardware pales compared to the performance benefit they will gain. Ask for better machines. At the very least ask for 4 gb ram. Adding another 2gb tablet will be earned back in less than a week. |
|||
|
|
