10,000 Foot Developer

It seems to me we are at this strange crossroads again for putting developers in a box, or opening the doors to allow them creative and utensil freedom. I would say nowdays, we are leaning as an industry towards less freedom and more box.

That was the feeling I got when I started to delve into Vagrant. That my control over even what text editor I use will be taken away.

For this session I went into:

• VMWare
• VirtualBox
• Vagrant

VMWare and VirtualBox run images of operating systems in their own container in your installed OS.  Vagrant is a command line OS-instance manager that manages your virtualization machine — i.e. VMWare or VirtualBox.  I ttries to give you chef-like control over setting up systems.  I spent most of my time in Vagrant because I already know how to set up VMware and VirtualBox images.

Here are a few off-the-top things I noticed about dong development virtualized:

Admin Rights Needed

To use Vagrant you need to have either VMWare or VirtualBox installed. I have had both for a while. These installations are not trivial, they require admin access and restarts. So, in this world where developers are not admins over their computers we already have a strike against virtualization for developers.  Installing, let alone updating, would be a pain unless we beg permission from people who have no idea what it is we do — network controllers, managemnet who more often than not do not have development backgrounds.

Portability of Base Applications

I rarely ever get admin rights on my box anymore, and configure my Java environments to be as completely portable as possible (meaning alos I have to do a custom extract of the jdk so I can have more than one version).  Thank goodness Eclipse is unzippable.  Configured with environment variables.  I guess if you are a .Net coder, or work on a Mac, or need OS integrated tools like TortoiseGit you are SOL.

VirtualBox *does* have a portable version.  VMWare — not.  And I was quite surprised that Vagrant did not — for Windows it comes in an MSI?  Maybe there’s a way around this but I didn’t have time to look.

Size

The image sizes are pretty big. I downloaded Fedora 20 and Ubuntu 14 for all, and we are talking about 800-1500 MBs per image.  That’s without developer stuff installed.  Not, in my opinion, light weight.

Networking

If you are going to use a virtualized system as a network server, well, the networking setup can be a pain as well.  The installation for VMWare is very machine specific and puts network device entries into your system.  I would have to say this seems less secure and more likely to be exploited.  More doors, more chances for entry.

The Glitch

No matter what I used (on an i7 notebook with 8 gbs ram and a SSHD) the parasitic OSs always seemed not quite . . . fluid.  Latency.  This would derfinitely come in play for each iteration of a Dell computer at a work place; the desktop services people would go nuts debugging problems.

SSH to 127.0.0.1

I found that in-depth knowledge of networking is needed for these kind of setups.  Vagrant doesn’t lend itself to easy UI — so I’d pick the other two for a developer over it unless only needing a server.  I think that Vagrant images can be run independently by the other two, instead of the “vagrant up” command.

Overall impressions

I don’t think these systems are quite there yet; they are difficult to set up and machine dependent.  Also, having worked with developers — especially the Linux types — customization is more likely.  Trying to force developers into a single image of IDE/text editor/tools is insane.

What seems better is making a zipped distro of say Eclipse, with all the plugins etc. needed.  This goes on now.  Since most setups are one-offs, time to set up a custom computer takes no more time than an image deployment and time lost due to host os machines hardware/os updates.   Maintenance over time could be a pain.

Also — how much of the development environment should become part of the application?  The old Java mantra — develop once, run anywhere.  Well I have been on projects where the style and setup of the IDE is so strict that it is part of the code.  Formatting for instance (which can make sense, maybe, for check in comparisons).  But even Vagrant says “checkin the config with your code.”

Vagrant tries to address the problems of updates, and I would like to think that it points to some of the future.  Already I keep different development environments for each project.  Vagrant could let you do that, and do updates with script much like Amazon servers.

My worries around this process though again are the ancillary effects of having non-developers decide what goes into some centralized development image.  Java projects can get really, really complex — several network sources (JDBC, SOAP, JSON, RMI, JMX  etc.) and one slight change in that invalidates the image right away.  Honestly — how good is your team at maintaining its wiki and development images?  Mot places I’ve been aren’t because they run at breakneck speed.

I have tried to use image appliances in the past for development.  Spin up a Jenkins/Nexus/Git server.  Keep a dev environment in an ISO.  But the operating systems are all getting larger, so is the solution really to put an OS that needs an entire machine’s hardware on top of another OS?  If you could develop on Puppy or any iteration of Damn Small Linux, maybe not.   But let’s face it, this won’t happen.

I don’t see this route to virtualization happening quite yet, not until the host OS is so slimmed down that its’ become something like GRUB.  For many of my java projects, even with Maven, I’ve noticed a fatification of a lot of setup so maybe we won’t get their yet.

Still, there are some good ideas.  Scripting images (chef or whatever), portable environments.  I am still chewing over the idea that the dev environment is part of the code/production itself.  It’s a very good idea just not sure how it should be manifest because I’ve been on that bad end of that too.

Also, the idea of Vagrant is a good idea much like yum (etc.) — command line updating and configuration.  Then it can be scripted.  I think the best option now would be managing configs with Vagrant, whilst using VMWare/VirtualBox to directly run the image after that to get easy access to the UI.

Next meeting we will go into this a bit more, hands on.

By the way, part of the intention of doing the virtualizations is as prep for making portable development environments for our upcoming stack development sessions.  I will most likely be using a Fedora/Gnome image on VMWare Desktop for myself going forward.

Tags: fedora, linux, ubuntu, vagrant, virtualbox, virtualization, vmware