The advantages of virtualization in production environments are well known: greater flexibility in deployments, reduced operating and maintenance costs, and even lower energy costs. But I have rarely seen virtualization applied in the development environment and the question arises: Can't we take advantage of it?
ELI5 Virtualization
Virtualization allows you to have several operating systems installed on a physical computer (in a computer) at the same time, working like other programs. Each of these machines is known as a virtual machine. The virtualization system allows you to switch from one virtual machine to another as if you were switching between two applications. For example, we can have in our Windows 10 desktop machine two others, a Windows 7, and a Ubuntu Linux, each one with its own applications installed.
This is possible thanks to services such as VirtualBox, VMWare, Qemu, among many others.
The idea that I propose in this post, is to use a different and independent virtual machine for each project. Let's see the pros and cons of this way of working.
Advantages
One of the (many) good things about working at Future Space is that each project is different from the previous one. Often everyone has their own environment, tools and technologies, which is an ideal way to apply this way of working.
A clean environment for every development
As you work on different projects, your team becomes full of libraries, applications and services: git and svn clients, databases, servers, etc.
There inevitably comes a point where the system degrades and a reinstallation of the operating system becomes necessary. Not only that: conflicts between different services, or different versions of the same service, can also occur.
By installing the environment for a project in a virtual machine, we isolate it, thus keeping the physical machine clean of all this software.
Production-like development environment
In reality, the environments can be identical: same versions of operating system, libraries and services. We can even simulate the number of processors and memory available in the production machines (as far as the physical machine allows).
- The move to production is less traumatic: we are using the same versions installed in the same way, even on the same operating system.
- Problems in the deployment and integration of the system will be found earlier in our development machine.
- It is easier to replicate the errors that occur in the operating system in our development environment.
Even if the final environment is composed of several machines (front-end and back-end, for example) we can replicate them as virtual machines in our development machine, connected through a network that is also virtual.
Disposable machines
Do you need to test if your application works on MongoDB and CouchDB? If your website is displayed correctly in Internet Explorer 8, and 9, and 10 and Firefox 47? Is Mantis, Redmine, or YouTrack better for incident control? Or even: Will your service work on Red Hat Linux, Windows, and Solaris?
You don't have to install and configure all that software to test your applications, at least not with virtualization. On the Internet there are several appilance repositories (literally, appliances) that are virtual machines already installed and configured with a specific software. Download and start.
- Microsoft offers us the different versions of its browser in virtual machines.
- TurnKey Linux allows us to download more than one hundred pre-installed virtual machines with the most used products in the sector.
- Bitnami gives us the same possibility, in addition to installing their own applications, but easier to use.
This post would not be complete without mentioning Docker Hub, where we can get similar appilances for Docker. The use of containers as an alternative to virtual machines is something we'll see in a future post in this blog.
Saving the game
In all developments there are complex tests. More than complex... cumbersome: You open the web application, enter some data, a process is executed and a result is generated. If during this test, in any of its steps, there is a failure, each test you run will mean repeating the process. Again and again.
You can save the state of a virtual machine, taking a picture (known as a snapshot) of its state at a given moment. After any operation, you can restore the previous state, as if it had never happened; the processes, the memory, the content of the disk, are the same as the photo. If you save the state of the database right after loading the data, and before running the test, you can reproduce the problem again and again, without having to re-enter the data on the web.
Less spectacular is the fact that with the snapshots, when you arrive at work each morning, you can pick up where you left off, with all the services turned on without having to leave the equipment on all night.
Machines in the freezer
Once the development of a project is finished, it remains in a drawer of our hard disk. After a month, we uninstall the web server because it is consuming resources for nothing, and after two months we use its data for another project, and we leave it unrecognizable.
What if, after three months, the original customer tells us that the application has failed?
We could make an effort to respect the environment of a project, especially if it is under maintenance, but it is a matter of time that we need the only port 80 of our machine, or the space taken up by the test files.
If the environment of a project, along with all its resources and documentation is isolated in one (or several) virtual machines, it is enough to save a backup when a development is finished and we can already free the space on our disk. When we need it again we can restore and boot that virtual machine, and have the operating environment as we left it.
Sharing virtual machines
A new member of the development team arrives and instead of being happy about the help, we think about the time we are going to lose. Not only will we have to update him on what the project is, how it works, how we develop, but we will also have to install the development environment, his own database for testing, the data files, the web server... That's how we technicians are.
Developing on virtual machines, it would be enough to clone our virtual machine of development, the one of data base, etc., so that the new one is operative in a matter of hours, instead of days.
Destructive testing
I remember that in one project, years ago, the client asked us for a "panic button" in an application. This button would completely erase the database from the system, even physically. If I hadn't had the database virtualized, I would have had to reinstall the server with every test of this functionality.
We can also perform less radical tests: In a virtualized environment it is easier to perform network disconnection tests, lack of disk space, running with limited hardware resources.
Disadvantages
Unfortunately, few things in this business are free, and the use of virtual machines for development has some counterpart.
Knowledge of virtualization tools
To set up and configure these environments, of course, it is necessary to know the virtualization tools. This can be complicated because, although the tools themselves are quite simple, replicating a complex environment is... well, complex.
Increased hardware requirements
The performance of a virtual machine is logically worse than that which it would offer installed directly on the physical computer. It's not really much worse, but it is something that is appreciable. Above all, what this way of working requires is a good amount of RAM memory in our computer, especially if we are going to have several virtual machines running simultaneously.
Wasted disk space
One of the biggest problems in using virtual machines is that a lot of disk space is wasted. A virtual machine (like a physical machine) usually requires (at least) 20 or 30 GB of disk space, in some cases more. And even more if we use the snapshots. This space, whether or not it is occupied in the virtual machine, is the space occupied by the virtual machine files on the physical machine's disk.
Nowadays, disk space is cheap, but this is still an inconvenience: Space is also wasted on backups of virtual machines, and the movement of virtual machines between physical machines is much slower, as larger files have to be transferred.
An improvement in the working environment
In my opinion, the advantages of working on virtual machines in development projects outweigh their disadvantages, if our job is to maintain the same service for years... maybe not. But if we need to work on different projects, even simultaneously, having isolated environments in different virtual machines is an efficient way to face development projects.
