18

Background:

I work at a start-up company, where one team uses Virtual Machines to connect to a remote server to do their development, and another team (the team I'm on) uses local IIS/SQL Server 2005/Visual Studio installations to conduct work.

Team VM is located about 1000 miles from Team Non-VM, and the servers the VMs run off of are located near Team VM (Latency, for those that are wondering, is about 50ms).

A person high in the company is pushing for Team Non-VM to use virtual machines for programming, development, and testing.

The latter point we agree on -- we want Virtual Machines to test configurations and various aspects of the web application in a 'clean' state.

The Problem:

What we don't agree on is having developers using RDP to connect to a desktop remotely that contains Visual Studio, SQL Server, and IIS to do the same development we could do locally on our laptops.

I've tried the VM set-up, and besides the color issue, there is a latency issue that is rather noticeable, not to mention that since we're a start-up, a good number of employees work from home on occasion with our work laptops, and this move would cut off the laptops. They'd be turned in.

Reasons to Use Remote VMs for Development (Not Testing!):

Here are the stated reasons that this person wants us to use VMs:

  • They work for TeamVM.
  • They keep the source code "safe".
  • If we want to work from home, we could just use our home PCs.
  • Licenses (I don't know what the argument is, only that it's been used).

Reasons not to use Remote VMs for Development:

Here are the stated reasons why we don't want to use VMs:

  • We like working from home. We get a lot done on our own time.
  • We're not going to use our Home PCs to do work related stuff.
  • The Latency is noticeable.
  • Support for the VMs (if they go down, or if we need a new VM) takes a while.
  • We don't have administrative privileges on the VM, and are unable to change settings as needed.

What I'm looking for from the community is this:

What reasons would you give for not using VMs for development? Keep in mind these are remote VMs -- this isn't a VM running on a local desktop. It's using the laptop (or a desktop) as a thin client for a remote VM. Also, on the other side of the coin: Is there something we're missing that makes VMs more palatable for development?

Edit: I think 'safe' is used in term of corporate espionage, or more correctly if the Laptop gets stolen, the person who stole would have access to our source code. The former (as we've pointed out, is always going to be a possibility -- companies stop that with litigation, there isn't a technical solution (so far as I can see)). The latter point is ( though I don't know its usefulness in a corporate scenario) mitigated by Truecrypt'ing the entire volume.
George Stocker
  • 6,388
  • 2
  • 31
  • 55
  • Client side code can't be removed because of *latency*. Complete (remote) virtualization is just dream of stupid CEO who believes VM can send screens faster than light. Try to make him to use only Google Apps without JavaScript. – Eonil Jun 20 '11 at 06:53
  • Can't they download and run the VM's l ocally? –  Feb 28 '12 at 20:39
  • "locally" being on their own pc in e.g. vmware player. You would not need to use remote desktop then. –  Jun 25 '12 at 22:03
  • 1
    +1 LMFAO, thanks I needed that. The things people have to deal with in the work place. Next thing they will tell you is that everyone must switch their Ethernet cables from the blue ones to the yellow ones, because it matches the company colors. – Reactgular Jun 25 '12 at 23:50
  • Working from home means the company should buy you a new dev PC. If not, then I'm afraid you are working to the wrong company. Ohh btw. what are your experiences with the VMs after 5 years? Do they worth it? – inf3rno Oct 26 '15 at 01:52

11 Answers11

23

Latency is a big big No! I use VM for manual testing and automated testing, also trying to keep a VM for fallback (if main system goes down then I can just fire and continue).

IMHO RDP is a terrible idea, developers should be hassle free and every seconds matter.

dr. evil
  • 331
  • 1
  • 8
12

I think the latency alone would put me off.

Not mention a number of other networking issues: what if for some reason you can't connect to the VM (a router or link down somewhere between you and it, or the server goes down, or whatever reason).

Plus a laptop is much more portable.

Bryan Denny
  • 493
  • 3
  • 9
9

We don't have administrative privileges on the VM, and are unable to change settings as needed.

This is a big red-flag for me. I wouldn't even consider working at a company that doesn't give devs admin access. Your company machine can be locked down, but development often requires tweaking and playing with machine settings.

Andrew Lewis
  • 533
  • 1
  • 4
  • 12
8

At our shop, the way we work is as follows:

  • Visual Studio installed locally on the developers workstation.
  • VM for each developer, generally for each client they work on, running the server applications (SQL, IIS, CMS/MOSS/Commerce Server/etc).

This generally works ok for us - we map a drive to the VM on the desktop and work locally, but against the remote file system etc.

The only real pain is debugging - for VS2008 you need the Remote Debugging app running on the server and you have to connect to the process rather than just hitting F5.

I'm not sure about this arguments for using them:

  • They keep the source code "safe".

If you've got source control in place it doesn't matter if a machine dies, unless by "safe" they mean "stays on our network, doesn't get left on a train where anyone might find it".

And as for:

  • If we want to work from home, we could just use our home PCs

Unless you've got a big monitor at home, developing from there is going to be fairly painful, and if you've got a large monitor setup, you've probably got a machine to go with it that can run Visual Studio, and then my way of working will work from home - connect to the office VPN, map a drive, and you're away.

Zhaph - Ben Duguid
  • 105
  • 6
5

As stated by you and others - the issue of "free productivity" by people taking laptops home is a done deal - that with the latency is enough.

As a manager I would also like to keep the developers happy - if they want laptops and no VM for primary development - no problem.

VM has its place - but IMO not as a primary dev environment.

Tim
  • 946
  • 7
  • 9
5

The biggest argument I'd put across is that using a VM is going to adversely affect your productivity. There's a reason why we as developers have fast machines, dual monitors etc. Even working on a machine that is lacking in RAM can be bad enough to knock you "out of the zone" as you have to wait for the machine to catch up with you.

Specific arguments I'd address are:

They work for TeamVM.

Have TeamVM tried working in a non-VM way and if so, what was the productivity difference?

They keep the source code "safe".

I'm not even sure what your managers think this means. Are they referring to having the actual code out in the wild on your laptops?

If we want to work from home, we could just use our home PCs.

Surely this would make your work more susceptible to theft, viruses etc? Especially in a home environment where multiple people have access to your machine.

Licenses (I don't know what the argument is, only that it's been used).

This surely is a red-herring? If they want you working from home on your home PC's they're going to have to pony-up the money for licenses for those machines anyway?

tddmonkey
  • 171
  • 1
4

I use a combination of the two, although most of my VMs are running on my local machine. My default position is to use my base machine for performance and no VMs. However, sometimes it is just much easier to develop against the virtual environments. I mainly do this when...

  1. I need particular software or services installing that I would prefer not to have, or cannot have, on the base machine. eg. MOSS, Microsoft CRM, Exchange, Oracle, DB/2, (we are generally an MS house) third-party services that I don't trust or that are a pain to uninstall.

  2. I need to emulate a networked environment with multiple machines, especially if I need a domain controller or an Exchange server.

  3. I am testing against multiple configurations and operating systems.

3

I've done the VM development environment thing, and at first I was turned on by the flexibility of it (you could get a new developer up to speed fast by literally cloning your own development environment and changing a very small number of things, and you could have one VM for each project - we had a lot of projects on the go).

However, I really disliked the performance hit. Intellisense was slow, compiling was slow, booting was slow, and opening files was slow. It frustrated me every day.

I wouldn't use a VM as a development machine again.

Scott Whitlock
  • 21,874
  • 5
  • 60
  • 88
  • Getting a developer up and running fast can be a good thing. With some of the tweaking that engineers do, e.g. for error diagnosis, it is also a good thing even if you don't have a stream of new team members joining. However, I don't think a VM would be required to achieve the same thing. Instead, standardize the hardware and then create an image that can be used to re-initialize the development workstation. So I agree on both the rejection of VM's and the benefits of getting the environment set up (or repaired) quickly. – Manfred Nov 02 '11 at 22:53
1

I use virtual machines for development, I just don't edit code via VNC/RDP during my normal flow of work.

I have to write three kinds of applications, Linux, Windows and Portable. So, I typically have a Linux VM and Windows VM running on my development desktop enabling me to compile and test the work on either platform. Sure, when running the program via RDP or VNC its a little fuzzy when wondering if the latency is in the application, but if I'm using a VM I'm not at the stage where I really care about that yet.

I would tell your boss that editing code via RDP is a lot like trying to drink an ice cold milkshake through a hypodermic needle. I understand the paranoia, but this is not the solution.

Tim Post
  • 18,757
  • 2
  • 57
  • 101
0

I worked in a shop where we had a VM setup for development and it was primarily due to the complexity of the configuration. We actually ran the VM locally on our systems (this company for some reason was still living in the 90's when it came to developer workstations and didn't have laptops either).

I ended up building out my own development environment on my main system and it worked much better.

As others have said, the latency and convenience is a big drawback. Someone upstairs is being pitched, probably by IT people, how much savings they will have by going this route. If you have a say, go with a 10% drop in productivity due to latency and not being able to work remotely. Average total compensation of the team is probably somewhere around $100k conservative, then take that times the number of team members and you are proabably looking at some serious money. Not to mention turnover costs because you will loose all the "good" people who will go work for a startup that "gets it" and doesn't try to let IT dictate to their shining star developers.

Bill Leeper
  • 4,113
  • 15
  • 20
0

Since everyone seems to be agreed that latency is a big killer, here's an alternative scenario that espouses some of the actual benefits when you have a server farm in-house to run the VMs with little to no latency:

1) Speed. The server allocates my VM more resources than my laptop has, meaning it compiles faster, runs faster, and my productivity speeds up.

2) Stability. Something broke? Just roll back to the last stable snapshot. Takes about thirty seconds.

3) Consistency. All the VMs are the same, a clone of the environment this code will eventually run on. No weird quirks related to customization of laptops show up when I'm working in the VM.

Yamikuronue
  • 702
  • 3
  • 13