Seth Vargo is an open source programmer and graduate of Carnegie Mellon University. He specializes in Ruby development and has worked for Chef, CustomInk, and HashiCorp. At this year's All Things Open conference, Seth will speak about Vagrant. But, what is Vagrant and why should you care?
Find out more in this interview.
What is Vagrant?
Vagrant is a tool for creating and configuring lightweight, reproducible, and portable development environments. Vagrant provides a unified interface for controlling the life cycle of one or more virtual machines using the command line. Because Vagrant is platform-agnostic, you can share the same Vagrantfile with anyone; it does not matter if they are using Windows, Linux, or Mac.
Vagrant supports a number of virtualization technologies, including VirtualBox and VMware. The pluggable nature of Vagrant has allowed the community to curate support for additional virtualization technologies including Parallels, Amazon Web Services, and libvrt.
How does Vagrant help with Ruby development? Is it useful for other kinds of development?
Because Vagrant is written in Ruby, users often assume Vagrant is only useful for Ruby development. This is not the case. Vagrant is useful for almost any development environment.
According to the agile cost curve, the estimated cost of fixing a bug in production is 150 times that of fixing the same bug in development. While software (algorithmic) bugs are easy to identify and write a quick test, they are not the only kind of bug that occurs in a production environment. The second most common bug lies in the configuration of production systems, specifically the differences in configuration between production systems and development environments. Even with perfect and precision engineering, a difference in the version of a package or operating system can cause disastrous outcomes at deployment time. For this reason, there is often a push between increasing the parity between development and production environments.
Vagrant is the perfect tool for this because it enables developers to use the same tools and editors they are familiar with on their local machine but uses the same operating system and packages as production at the virtualization layer. Combined with a tool like Packer, it is possible to achieve near-perfect production parity without sacrificing local development techniques. To put it another way, there is no interruption to the developer workflow.
Even when production parity is not a concern, Vagrant is still an incredibly useful tool. Projects typically have a number of dependencies that need to be installed and configured before development can occur. Docker has gained increasing popularity in this space; users just run Docker with a pre-configured Dockerfile in a project repository. Vagrant works very similarly, but provides an additional layer of isolation since it lives at the virtualization layer. If you need virtual hardware (such as USB ports, audio, or advanced networking), support for operating systems other than Linux, or the additional layer of isolation that virtualization provides over containerization technology, Vagrant is an excellent choice.
In fact, they are not mutually exclusive. Vagrant has support for building and running Docker as both a provider and a provision. This means Vagrant can create Docker images and then run them automatically. If you are on a system that cannot run Docker natively, Vagrant will automatically configure a virtual machine capable of running Docker and setup all the proper connections back to your host machine. In this way, you get the isolation of virtualization, but the flexibility and speed of containerization.
Finally, Vagrant has deep integration with tools you or your organization may already be using. For example, Vagrant has first-class support for almost all major configuration management providers, including Ansible, CFEngine, Chef, Puppet, and SaltStack. If you are already using Chef to configure your infrastructure, for example, simply add a few lines to the Vagrantfile and Vagrant will use the same cookbooks that configure production infrastructure in your local development environment.
What was the moment that you were "sold" on Vagrant? As a user, did you see its value straight away, or has it grown on you?
When I first started learning software development, I routinely messed up. I think it is human nature to mess up; it is a great learning technique. The unfortunate part is that sometimes you mess up your local system beyond repair. When I entered the configuration management space, the probability for disaster increased significantly. On one hand, I was really excited to learn about a new technology and explore it. On the other hand, I was incredibly fearful that I would need to re-image my laptop for the 50th time that day because of a simple typo or misunderstanding. This fear eventually got the best of me, and I stopped innovating and iterating. Even though I was working alone, my feedback times increased, my cycles dropped, and I was quickly unproductive; the fear of messing up my own machine had outweighed my willingness to learn.
That is when I met Vagrant.
Vagrant provided me the ability to quickly iterate on entire systems without touching my own. Being a poor college student at the time, Vagrant and VirtualBox were both completely free and open source. This fit my budget ($0) really well!
As I further explored Vagrant, I started using it for my software projects as well. As I started working in a team, the Vagrantfile proved to be invaluable. Designers could bring up a website without needing to install anything. Quality Assurance (QA) could test beta versions of the site without needing to know how to set it up. New developers could be onboarded in hours instead of days. It was an amazing moment to realize that all of this was made possible by software.
What are your preferred programming languages?
This is a tough question. My first answer would be "all of them." I am a polyglot software engineer, but I work most closely with Go and Ruby at the moment. I never let my experience or current technology dictate future technology use. Given a new project, I like to try new programming languages.
What's your workflow for managing vagrant dev machines?
I have a Vagrantfile that creates the configuration for the virtual machine. I usually use a shell script, but for more complex scenarios I will use a Chef cookbook with the built-in Chef provision. All the code lives on my local machine and I use Sublime Text, iTerm, and five years worth of shell shortcuts and customizations. My local machine shares a folder with the virtual machine created by Vagrant. The code is executed in the VM, but the source files are controlled on my local machine.
What version control system do you use?
I primarily use Git, although I have used SVN and Mercurial in the past.
What's the top mistake new Vagrant users make?
More of a misunderstanding than a mistake, I think many Vagrant users assume it is too heavy for their use case and they defer to a shell script or instructions in a README. The problem with this approach is that it quickly becomes outdated, it's operating-system specific, and it tends to lead to the phrase "it worked on my machine."
When should new users start using Vagrant? Right away, or is it an advanced tool that one should work up to?
Vagrant is designed for beginners, but powerful enough for even the most experienced developers. Vagrant defines a happy path for new users that tunes all the knobs to the most likely configuration. This may not always been the fastest, most secure, or performant configuration, but it is the configuration that is most likely to work without the user needing to customize anything. The workflow for Vagrant should always be:
$ vagrant up
Power users have the ability to tune those knobs to make Vagrant more secure, more performant, and more customized. Vagrant exposes almost all configuration options as part of the Vagrantfile DSL, and they are all documented.
This is all to say that Vagrant evolves with the user. As development needs change, Vagrant is capable of adapting, so there's no harm in adopting Vagrant early and having it grow with the project.
How did you get involved with open source?
When I was an undergraduate at Carnegie Mellon University, I had two professors who were proponents of open source: Professor Larry Heimann and Professor Jeria Quesenberry. I worked on a number of open source projects and gave back to the community. One of my first internships was at the T-shirt company CustomInk, who were also proponents of open source as both consumers and producers. I had the ability to work on a number of open source projects during my tenure there. Since then, I have only worked for organizations that produce open source software.
Speaker Interview
This article is part of the All Things Open Speaker Interview series. All Things Open is a conference exploring open source, open tech, and the open web in the enterprise.
3 Comments