Well that made people angry.
But amidst all the hoopla, some people did make some really good points about me coming across as a childish nincompoop. Also, I sounded too condescending and derogatory of the incredibly valuable field of devops, and didn’t judge fairly. All fair accusations.
This didn’t upset me. I mean, such a dousing of founded criticism is always a little hard to stomach. But it didn’t upset me a lot, not really. Maybe if I had written the article recently it would have. But I wrote it a year ago! So I sort of watched this all roll in from a distance. People were displeased with past me! But hey, so am I.
However, I am not displeased with my decision to stop using Vagrant. I think that was definitely the correct decision for our team, at the beginning of 2014. I think I wasted a lot of time in 2013, trying to keep our Vagrant hobbling along.
This coming from the only person on our team to ever push for Vagrant! I championed it for years. I still think of it fondly. (I certainly overstated the title of the last article. I tried to make the whole thing quite sensational. Perhaps people reacted against my sensationalism. Fair enough.)
Maybe someday we’ll return to it. But not now. And here’s why.
When I started at PipelineDeals, the first thing I did was set up vagrant for our main app (our only app, at the time). It took most of a week. I thought it would be worth the time, because now we could all share the same environment. But no one else started using it.
Maybe, I hypothesized, that was because I hadn’t really made it
infrastructure as code. Maybe I should learn Chef, I thought.
Instead I learned Ansible, which I found much easier. And, with my 20% investment time, I dug in. I didn’t have a ton of sysadmin experience, but I had some. Enough to automate an acceptable dev env in Ubuntu (or on EC2, which I toyed with for a month or two).
Every time we created a new app to interact with our main one, I set up new Ansible-built VMs for them. We had three separate apps at the end of 2013, all with READMEs saying,
to install, first you need VirtualBox, these python dependencies, and Ansible, and then just `vagrant up`! (At the time, there was no
homebrew package for ansible, so the python dependencies had to be installed separately. Also, unlike Chef+Vagrant, to use Ansible with Vagrant, one needs Ansible installed on their host machine.)
But still, no one else bought into it. Probably because all of these apps were Rails. And everyone already had Ruby, Bundler, and the necessary DBs installed. Installing unfamiliar python dependencies and the large&slow VirtualBox seemed harder & longer than a standard
bundle install rake db:setup
Or maybe they never bought into it because when I would screenshare, people could see my environment was ~150% slower than theirs. (This was with NFS. Without NFS, my environment was about 600% slower.) We have a (slowly shrinking) huge monolith Rails app, still running Rails 2.3 (which we’ll finally have upgraded to 3.0 soon). It’s slow. Vagrant exacerbates the problem.
Maybe there were ways to make it faster, though? I’m sure I spent lots of time researching that. I wasted so much time fiddling.
xvfb and all that stuff. Circle CI does this stuff without a GUI. It shouldn’t be hard. If I were a real developer…
And then it hit me: If I were a real developer, I’d stop wasting so much time. Fiddling with Vagrant when no one else demonstrated a desire to use it—that wasn’t a good use of company resources. Real engineers know how to balance technical elegance with economic efficiency.
So I realized the error of my ways. I joined the rest of my team in doing the simplest thing that works. For now, for us, that means not playing with shiny fun Vagrant.