Too many versions of PHP on your system? MAMP got you down? Can’t find that .ini file? Don’t fret, go Vagrant! Many Drupal developers use a web developer stack such as WAMP, Acquia Dev Desktop, or MAMP to host their projects locally. When working with multiple clients, your hard drive can turn into a dorm room nightmare of multiple copies of PHP, MySQL, and Apache in order to assure compatibility with the client. Instead, simplify and standardize your workflow — and your team’s — by using freely available virtualization tools. This week we have a 5-part blog series that explores each of these components.

What is virtualization?

Imagine you are playing a flight simulator. If you’re like my dad, on screen you’d find yourself in the cockpit of a Piper Seminole with control wheel, altimeter, direction finder, and all the other indicators necessary in order to fly. The controls in the game are programmed to respond just like an actual aircraft. If the simulation were more perfect and you could get “inside” the game, you may never know that you weren’t flying a real plane.

This is how virtualization works. The pilot is playing the part of server software such as Linux, Apache, PHP, and MySQL. The plane itself is the server hardware. Like the flight simulator, the server hardware is itself a simulator called a Virtual Machine. To the LAMP stack, it doesn’t know that it’s not running on real hardware. It’s “inside the game”. The simulator itself runs on real hardware, often called a host OS or a virtualization host.

Why Virtualization?

There are several advantages to using VMs. All the software, configuration, and files are stored hard disk image files. Cleaning up an unused environment is simply a matter of deleting the entire VM. No dangling configuration files. No multiple versions of PHP left behind. VMs are also isolated from each other such that runaway processes and crashes do not affect other VMs running on the same host (which is rather unlike when my dad attempts to land a Piper Seminole, much to my terror). This allows your workstation (the virtualization host) to remain as untouched as possible as you go from client to client.

VMs are also portable. A standard VM can be created for your entire development team with all the server-side tools, configuration, and software. Just import the VM, and the workstation is ready to code. If a bug appears due to server configuration, you no longer have to play whack-a-mole across each developer’s unique workstation, but only troubleshoot the VM itself.

Aren’t VMs Slow and Heavy?

First generation virtualization had a reputation for being slow and resource heavy. This is because the core piece of the virtualization, the hypervisor, emulated both the physical hardware and the CPU. This was necessary because AMD and Intel CPUs did not support virtualization in hardware. Today, however, most hypervisors pass CPU instructions from the virtual machine directly to the host machine’s CPU with no emulation. Hardware support for virtualization in modern CPUs makes this secure and fast.

VMs, however, do incur an additional overhead in another way. In addition to the operating system your running on your workstation, the VM itself has another operating system that’s running on top of your hardware. While there’s no way to avoid this with virtualization (containers hold promise but aren’t yet mature for developers) we can minimize it by using a stripped down Linux VM with no GUI. This drastically reduces the resources required by the VM bringing it down to hundreds megabytes instead of thousands.

Summary

Virtualization has matured a lot since it first became popular. Today running a VM on your desktop is fast, free, and secure. The VM’s innate encapsulation of software and configuration makes cleanup and sharing a VM as easy as managing a file. Next time we’ll get started with VMs and vagrant, a command line tool that makes using virtualized development environments easy.