Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'll be working as a development lead for a startup and I've suggested that we use VMs for development. I'm not talking about each developer having a desktop with VMs for testing/development, I mean having a server rack where all VMs are managed and have the developers work from a microPC (ChromeOS anyone?) locally, or even remotely from their home computer.

To me, the benefits are the fact that it's extremely scalable, cheaper in the long run, easier to manage and that we utilize the hardware its maximum potential. As for cons, I can't think of any particular showstoppers other than we'll need someone to setup/maintain said setup.

I was hoping that some of you might of had a similar setup at your place of employment and be able to weight in with your opinions. Thanks.

share|improve this question

closed as too broad by gnat, Giorgio, MichaelT, GlenH7, Dynamic Mar 22 at 17:01

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

7  
This is not your father's IBM VM/ESA! All the way back to the IBM mainframe. –  Vitor Aug 25 '11 at 2:49
23  
About the only showstopper for me would be multiple screen support. I couldn't develop on less than 2 screens. –  Justin Shield Aug 25 '11 at 2:53
26  
There are many exotic reasons: Sometimes you need a USB key to be plugged in to a physical computer for licensing purposes. Sometimes you are dealing with actual CDs. Sometimes you need to hard-reboot the sucker. Sometimes you need to measure performance as it would be on an actual computer. Sometimes you are developing drivers. Sometimes you need all the speed you can get. Sometimes you need to demo the product somewhere without internet access. Sometimes you need to sign-in to a system using fingerprint validation. –  Job Aug 25 '11 at 3:15
47  
Modern IDE's require dedicated, local hardware. Before even thinking about doing this, you should have a test bed and a study to see if it's even viable. You may learn a thing or two you didn't know about how people interact with machines. If you tell me you don't have the time or money to perform such a study, I will tell you that you don't have sufficient scale to justify your setup. –  Robert Harvey Aug 25 '11 at 5:29
4  
Just bear in mind that you do need physical machines as well. Our test server are almost all on VM's spread over two SAN hosts. But we do encounter problems where we want/need to verify that virtualisation is not a factor or even the culprit. Also, not all VM's support theming with glass and if you are developing GUI's you will need to check your GUI in a glass themed environment as well. –  Marjan Venema Aug 25 '11 at 8:04

17 Answers 17

up vote 94 down vote accepted

What are you hoping to save, as a fraction of the development budget? It seems to me that you are worrying about an epsilon. The cost of machines for developers is less than 5% of the total cost to keep a developer on staff. Therefore the only important question is "will it save developers time?" It could, if they don't have to spend time installing and upgrading development software. Or it could cost time, if the network goes down, or the server goes down, or, most likely, if the responsiveness across the net is the least bit lacking. Modern development depends on keystroke-by-keystroke interaction with an IDE, or at least a very intelligent editor. Delaying that interaction by even a few tens of milliseconds destroys developer productivity. There is also the cost for developers to learn this new way of working. If that takes even one day per developer, you have already spent more in labor than the cost of a new desktop.

These are not objections to VMs, but potential objections to remote development.

share|improve this answer
5  
This approach may indeed save a maintenance time. But probably not at a startup-scale. It must be 20 users or more to start being financially interesting. –  SK-logic Aug 25 '11 at 5:51
6  
If you locate the server in an equipement room you gain envronmental seperation which is better for the server and the people. Backgound noise in the office is reduced and heat can be managed better. –  mattnz Aug 25 '11 at 6:58
1  
@J_A_X: That latency would not exist when working from home if the machines are laptops. Network latency over the VPN would certainly be there, but the latency of interacting with the machine itself would not. –  Adam Robinson Aug 25 '11 at 12:39
1  
@J_A_X: the latency isn't there if the entire development environment is contained in the developer's laptop. And there could still be noticeable latency pushing screen updates across the room, when interaction occurs on every keystroke. Fifty milliseconds delay in character echo would be very painful. Maybe it would all go smoothly, but is it really worth it to find out? –  kevin cline Aug 25 '11 at 13:22

I think you're being penny-wise and pound-foolish.

First of all, machine costs are trivial compared to the cost of a developer. You should work at maximizing productivity, not minimizing machine cost.

Second, latency (not bandwidth) is the key to many programming tasks -- especially text editing. For every dollar/pound/euro you save on machines for your developers, you'll spend at least ten on network upgrades to maintain even a semblance of productivity -- and even then, they'd probably be more productive if you economized by supplying them with Pentium III's you found in a dumpster somewhere.

I also think there's a substantial benefit in having your developers use an environment at least reasonably close to that expected of the target end user. Regardless of official performance targets in a spec and such, most programmers base quite a bit on how the code "feels" when they test it. When they're using a completely different environment from the end user's, they're likely to waste time on trivialities while completely overlooking major problems.

As attractive as a homogeneous environment sounds from a viewpoint of support and such, you should generally encourage as much variety in the developers' machines as possible. Developers rarely need much support anyway, and knowing immediately when you have code that's going to fail with a different graphics chip, CPU, network adapter, etc., more than repays the minimal investment.

Bottom line: if you're writing code that's intended (at least primarily) to be used in a virtualized server environment, you just about need to provide that for your developers. If you're doing it anyway for testing, it can (but doesn't necessarily) make sense for development as well. Likewise, if you need (or at least have) a severely over-speced server and network anyway, it might make sense to take advantage of that by using what you already have available.

Under most typical circumstances, however, it seems to me that this is likely to introduce more problems than it solves.

share|improve this answer
4  
I know it wasn't meant to be taken seriously, but I'd absolutely take a decent virtual environment over some "Pentium III's you found in a dumpster somewhere" –  Davy8 Aug 26 '11 at 18:52

We use on-demand amazon ec2 instances as developer machines. This has nothing to do with cost. We have a "pool of developers" working on several projects, and we need the ability to move across projects quickly.

In general, the VM saves initial setup time. But longer term, it wastes time due to loss of productivity. Cost is a non-axis, because developer cost is much more than machine cost.

Productivity costs include - time taken to start a VM image (several minutes), poor responsiveness, and resource/memory constraints. These are not much initially, but over time they get annoying.

On one of our projects we refactored the code to simplify initial setup to "download code and run maven". With this change, it was simple for a new developer to start working on the project -- and now nobody uses the amazon VM image. We are looking to emulate this on other projects as well, but its going to take time. Till then, we have our ec2 images.

share|improve this answer

That was one of my ideas in the past: having a high performance server which has all the required software, and a bunch of low performance desktop PCs which would be used only to connect to the server through Remote Desktop.

The benefits would be:

  • The solid backup. Some developers may not want to backup their desktop computers regularly, so a central solution would be more reliable,
  • The possibility, for every developer, to work from anywhere. By this I also mean working from any PC in the company. Let's say in the morning, the developer wants silent work conditions. He goes to his own room and works there. Then he wants to do some pair programming or to work in a more social environment. He just shuts down his desktop PC, goes to another room where there are ten computers, and connects from there. No "I must reload all my apps again".

Well, there are several serious problems with that, making me think that I will never use the thing like this the next years.

  • Specificity of remote solutions. What about working distantly using several computer screens at once? I mean, is it easy? Is it obvious? Are shortcuts I use daily enabled when working distantly? I'm not so sure. What if I press Ctrl+Shift+Esc to see the list of programs currently running? Oh yes, it doesn't work, so now I must remember doing it in a different way.

  • Performance hit. I'm not sure there will be no performance decrease at all. And remember, a programmer who uses a slow computer is an unhappy programmer. And the company who makes their programmers unhappy with crappy conditions will never produce high quality software.

  • Higher impact of a disaster. Will you host the solution on a redundant server? Do you have redundant network in your company? Let's say the router goes down, and is not redundant. It means that all the developers are now unable to work. At all. Because they don't have software installed locally. Because they don't even have source code: it's on the server. So everyone stops, and you're paying all those people per hour just to wait the router to be replaced.

  • Hardware costs. If it's one and one only server, how much will it cost? If you have, let's say, twenty developers, would 64 GB of RAM on the server be enough? Not so sure. Would quad-core solution with two CPU be enough? Again, I have some doubts. Otherwise, what do you think about? Some sort of cloud? Or do you have a scalable solution which works on several servers? Are you ready to pay the cost of Windows Server (if you use Windows) per machine?

  • Electricity cost. If you work completely remotely, it means that you spend nearly the same amount of power server-side as if you were working locally, plus the amount of power wasted by the local machine and the network.

  • Licenses. I'm not sure if I must put it as a benefit or a problem, but I feel like the cost of software licensing in this case will be much higher.

And again, think about all the costs of management, support, deployment, maintenance. With a custom solution like this, it may easily become huge, not counting that every time something will fail, you'll see every developer NOPing around, waiting to be able to continue his work.

share|improve this answer
1  
Thanks for the information. Very informative. –  J_A_X Aug 25 '11 at 4:31
4  
@Rudy: In most shops, if the server goes down, you can't really work locally either (no DB acces for testing, no checkins, no checkouts, no bug tracking access, no email,...) –  sleske Aug 25 '11 at 8:35
4  
@sleske agreed with DB, email and stuff, but with DVCS you can at least checkin/branch/... –  mbx Aug 25 '11 at 9:57

Development on virtual machines can work quite nicely, but only if done right:

  • Just because using VMs allows you to have a single computer for your entire team rather than one per developer doesn't mean that it is a good idea
  • Rebooting should not require opening a support ticket with a 24 hour response time
  • Development VMs should not be in a datacenter 5000 miles away from the developers.
  • While VMs may be managed by developers and therefore unsupported, that does not mean that they should be unable to access network services such as source control.
  • The remote desktop connection should be standard, not some custom "high security" applet that converts any quotes typed into umlauts.
  • Getting a new VM or rebuilding an existing one should take minutes, not weeks

I have seen all of these issues, and don't particularly enjoy working with them. However I also have a VM setup at home which I use by choice. That runs faster than a local install would and allows things like separate environments for different projects and fast rebuilds when an environment becomes unstable.

share|improve this answer

I work with VMs, but I do not recommend it for your main project.

The reason I use VMs for development is because I have to support legacy projects (e.g. VB6, .NET 1.1, etc...) and I don't want to dirty my main machine by having to install VS2003/2005/vb6/etc... It works out OK, but there are intermittent issues here and there.

In addition, the interaction is slower, VMs take a while to start/shutdown, do not have native UI effects (like Aero in Win7), etc...

Whatever you are going to save in terms of money you'll waste and more by the hassle you are about to impose on your team. Plus, as someone here mentioned, no multi-screen support. I need at least 3 screens to be as productive as possible.

share|improve this answer

The #1 rule of development is to keep your developers happy. You will find that near-impossible to do with remote VMs. Multi-monitor support is spotty, network lag and blips are troublesome, and cost savings are generally minimal.

Work on VMs, sure, but allow for local VMs too, and make the physical computer a ridiculously fast beast too.

I telecommute 100%, and between my personal ISP and the VPN--despite high reliability--they have enough blips that would drive me nuts if I couldn't work in offline mode.

I generally just spin up a variety of VirtualBox images and work from them. Copying a few hundred MBs over the wire isn't too time-intensive if you need a new one locally either.

share|improve this answer

VMs for development are worth looking at, but financial cost is the wrong reason.

This was covered briefly in Marc Holmes' Expert .NET Delivery using NAnt & CruiseControl.net - in short the argument for developing on a VM is that it discourages any aspect of the work from becoming dependent on the developer's particular configuration. You nuke your VM at the start of every project, and unless you actually need a particular tool, it doesn't keep kicking around. This minimises the likelihood that changes you make will be breaking on anybody's machine but yours. Developers might cry at having their toys taken away - but ultimately, reliance on tools is a weakness and anything you can't do intuitively in a clean environment is a smell.

Note that I don't necessarily believe the arguments presented above. I understand and to a certain extent align with them, but I'm making them for arguments' sake, to generate discussion.

share|improve this answer
7  
That is why you have a build engine - continuous integration should catch such dependencies. Developers, however, need all the tools they can get. –  user1249 Aug 25 '11 at 18:06
3  
Yeah - don't take my toys away. They make me productive to get stuff done. Building for deployment, and testing in a target environment are different problems to be solved. –  quickly_now Aug 26 '11 at 11:09

I have worked on VMs before for development, both local VMs (running on the local PC) and remote ones. The local ones were much nicer to work with than the remote ones.

Remote VMs, which we were connecting to by RDP, had a small amount of lag between every keystroke and action. It's possible to develop under such conditions for a short time but day-in day-out it became very frustrating.

I happily developed under a local VM on VMWare because I needed to run Flash Builder on a Linux machine, and was quite happy with it as long as it had enough memory - it was quite usable.

share|improve this answer

At my last job, we did quite exactly that:

We used a Windows Terminal Server, where every developer had an account. The developers still had regular PCs (because they were already there), but the PCs only ran the RDP client.

We did Java development, so the software used where Java compiler + IDE (mostly Eclipse), plus web browser, DB query tools, version control client, and occasionally office sw (OpenOffice.org in our case).

We did not encounter any real problems, and performance was quite decent.

The only real problem was that you really need to take care not to disrupt others in some situations, because you are sharing one system. When IT operations needed to do large file copies or run backups on the server, performance degraded for everyone. When we identified and solved this (by copying with low priority, or overnight), everything performed well.

So the caveat is: Evaluate performance as soon as possible, and plan your hardware and its use accordingly.

share|improve this answer

Lack of dual screen support has always been the deal killer. I just can't imagine doing significant development work on a single screen.

Now, they do rock for testing/deployment/fiddling, so I don't think they should fall off the stack either.

share|improve this answer

TL;DR: I've done it at multiple jobs and I now prefer it.

Cost is the wrong reason to focus on. Here are some better ones.

Reasons

  • Platform consistency in the different environments (dev, test and production).
    • Why: It completely eliminates a defect vector, defects from platform differences in different environments.
  • Allows system changes like upgrades to occur first in development vms, be verified, roll up to test, be verified, and roll into production; all much easier with development (and test) vms.
    • Why: Control. I can snapshot, rollback, identify the deltas, do the change on one server and propagate a success by simply duplicating the vm, etc.
  • Sometimes the systems you develop against are only available on a secured network. Alternatively, the server your software will run on may only have limited access or different network characteristics.
    • Why: The development VM can be on the VLAN that has access to the locked down system or service. Alternatively if the dev server has the same limited access as the test and production server, there is never a question of accidentally coding a requirement on a network characteristic or access that won't be available.

Challenges

The number one challenge is remote development, especially if you have to go through a gateway or jump server. It makes it difficult, especially if the developers are not well rounded (they have some system engineering knowledge, networking knowledge, etc).

There are many variations of remote development, but they usually boil down to 2 main differences.

  • Run your development tools in the remote environment and use protocols like RDP clients, remote X11 clients, etc.
  • Run your development tools locally and use protocols to transparently sync or execute on the remote server, often using ssh as the transport layer.

Tools

There are tools that will help with remote development, and there are IDEs that facilitate it. You will have to investigate to what degree it is capable of remote development, many are not without running on the same server the code is being developed on. However there are other tools.

  • Secure Shell: Most successful remote development setups use ssh to a greater degree, using passwordless logins (using key authentication), transparent multihops (solves the jump server issue) and other configuration options to improve response time. Note: I've always had issues using non-OpenSSH implementations of SSH.
  • GNU Screen/TMUX: Terminal multiplexers. Screen is the granddaddy of them and is still going strong, but I think most people have started switching (or even starting) on TMUX.
  • Vim/Emacs: The old guard, but both work great for remote development in different ways. It's Vim so all it needs is a shell, while Emacs can run locally and use TRAMP for remote development.
share|improve this answer

If you have a mainframe with 50 SSD disks in RAID10, and only use 3-4 machines on that mainframe, then it might work.

Otherwise they are laggy, really laggy (although in some rare cases snapshoting can offset that).

share|improve this answer

I have a decent desktop machine at the office which I can connect to from my laptop over VPN using screen sharing.

It works for out of hours support incidents and the occasional forced remote working. It is certainly better than maintaining a fully configured environment on a second machine, or for developing stuff that needs low latency to the datacenter across a WAN.

However, it is frustrating to work that way for long periods. I have on occasion driven in to work for the second half of the day once whatever it was that kept me at home has been got out of the way.

Latency and screen real estate are the two killers for me.

share|improve this answer

I don't think you want to go with a remote VM solution. The network connection will be the bottleneck and even on a fast connection, it can be enough to cause frustration. We are moving away from this technique to using local development environments.

We develop on iMacs, which is really nice, but our web applications are running on a Linux environment in Production. The problem with this is that eventually, we may run into an issue that only happens on Linux and could be difficult to troubleshoot. That's where the power of virtual machines come in. However, I don't even like the idea of using a VM 100% of the time.

I recently learned about Vagrant (http://vagrantup.com/docs/getting-started/why.html) and Chef for making working with VirtualBox super easy. Vagrant gives you the ability to easily start up a VM when you need it, and tear down a VM when you don't. So I could do all my development using my Mac. Then when I'm ready to test my code, I can start up a VM to test it out, and only keep it around as long as i need it. Vagrant also gives you the ability to easily share VMs with your co-workers so that you all can be sure you are working in the same environment.

I would recommend checking out Vagrant so that you are at least aware of the options available when it comes to developing on and working with VMs.

share|improve this answer

I have been working on a legacy-project concerning 5 machines, each one has a role in a computation pipeline (machine 1 sends request to machine 2, ehich in turn will send request to machine 3 etc). The setting deployment on virtual machine saved us HUGE time however: 1. The system was undebuggable as devs were lazy/did not have time to encorporate testing in the design. 2. Too many setups were deployed on and I needed to consume time on arranging them in groups.

Now I use it because I work on too many projects at once. The main problem I have now are: 1. VMs are consuming way too much time to maintain. 2. VMs are consuming enormous amounts of memory to run

This kinda renders VMs hard to use when you try to use them to have order. Keep one main machine with your email and text, develop on dediacated VMs. Keeps your life neat and clean at a cost.

share|improve this answer

As stated by others, it really depends on what problem you're trying to solve with the VM Desktops and then weighing the benefits of resolving that problem against the disadvantages the VM environment will incur.

We're moving towards a hybrid environment where all of our onshore developers will have traditional physical machines but out offshore developers (working with a small outsourcing company right now) will use virtual desktops. The problems we're trying to solve with the remote desktops are security and performance related. The virtual environment will obviously provide us greater control from a security perspective and for performance we will be transferring only "changed pixels" rather than full source code and having to implement proxy servers and such.

Still not sure if this is the right way to go, but it's where we're headed.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.