Sharing a linux desktop server for multiple users: remote desktop or virtualization?

Question

We are a small web software company (~ 10 people). At present, every dev works on his local machine (some windows, some ubuntu) using a local apache. We have a samba share for shared files and central SVN repositories.

I would like to centralize our infrastructure in the future, making everybody work on a central server. There are 2 options:

• Virtualization: everybody gets an own virtual box on a central, fat server.
  Pro: quick setup, isolation of the users, new boxes added fast.
  Con: as every user has its own OS, a little hungry for hardware. Updating software (new Eclipse versions etc.) does not affect everybody unless they start to use a new vm, which leads to fragmentation or lost working time again. Potential security issues due to missing security updates and users using the box as root.
• Remote Desktop: everybody connects to a central ubuntu server, using a remote desktop from there. Options are a real X client, xrdp, VNC and the like.
  Pro: easy to use, central data storage, software updates effective immediately, central control easy. Does not need as much hardware. Users are not root. SVN repositories might be local, meaning speedup.
  Con: users are not isolated (potential security issues inside of the team), an apache restart etc. hits everybody.

Both solutions need a fast network and a fat server. At the moment, I would tend to use xrdp as remote desktop access. What experiences do you have? Any downsides to one approach over the other? Options I've missed? Is there anybody out here that successfully virtualised a software dev team?

Solution

The cons you described are not really actual, in the modern IT world. Hardware is pretty cheap, and the ROI seen when virtualization is used is high and quick. Software updates and management are easy to manage using chef or puppet. Security issues are localised to a single VM, and not to an entire terminal machine, and if you pick the right solution, security, at the update level, is handled by the vendor. BTW, to speed up repository access, use git - your developers will fall in love with it, once they get over the initial shock

With a terminal machine, resource management might end up being pretty hard, with VMs, you not only get better resource allocation, you also get a better justification to get better hardware.

Comments

[hey]

a chroot jail might solve the non isolation part of it en.wikipedia.org/wiki/Chroot

[pauska]

having developers on terminal services is not something I'd highly recommend. It's a great deal slower than personal (powerful) desktops. Remember that happy developers produce happy code.

[安辰 anchen]

The way we takle this is to let devs keep their preferred environment and use them for testing, But then we use a central repository and bug handling system. this because as you stated an apache restart affects al, but also if someone accidentally makes an infinite loop, or needs a tool that will break most of the other code there will be a lot name calling to say atleast

[Steffen Müller]

Good point about performance testing, although I think we would rather use a staging server for this, as we do now. The cluster management would apply to the thin clients as well as to the virtual machines, eliminating the software version problem... also a good point. So many options! So little time ;-)

[Steffen Müller]

I think I'll try xrdp first and come back to NoMachine if I see that we need all the bells and whistles it provides. Do you have any experience with xrdp, comparing it to nomachine?

[ewwhite]

No, I only have experience with NoMachine in this context. The bonus was the free solution and the strong support for Mac, PC and Linux clients... They were also promising a replacement for Windows RDP, but that's not in place yet.

[sumar]

Memory sharing efficiency is not a big concern if you enable KSM with KVM virtualization technology