Part II of the series, "Architecture, Agile, and personal re-invention"
This has required an intensive round of updating my skills. I've an odd grab-bag of hands-on experience, most of it well outside the current mainstream. (PeopleTools? VB6? SQL Server?) But tools are tools and the hands-on cycle of frustration and victory is always the same.
I think now is an ideal time to re-skill, and recommend it to others in my position (10+ years to go, needing to stay career relevant). There is always a danger in being too quick to follow fads, but we are at a tipping point with open source, Linux, Github, lightweight virtualization, and infrastructure as code.
And, as noted earlier, broader dynamics emerge from the new style of IT with its product-centricity and tight feedback loops. I don't intend to apply for jobs as an entry-level developer, but knowing how they are working today is essential. I have benefited greatly from these investigations.
What is Vagrant? It's a simple yet powerful virtualization controller that makes it dead simple to run one or more virtual machines (VMs) on your personal workstation. It's distinguished by its library of pre-configured open-source VMs free for download. This is an important friction reducer -- essentially, trading network bandwidth for configuration time. Ten minutes to download that first Ubuntu image (then cached locally), "vagrant up" and you are the administrator of a newly configured VM, or 6.
Both Vagrant and Virtualbox are well behaved on MacOS, Windows and Ubuntu. On a maxed-out late 2012 Mac Air (8gb), one can run a cluster of 8 nodes or so (doing simple stuff, nothing demanding). For my choice of operating system, I settled on Ubuntu after frustrations with CentOS (selinux among other things) and am happy with how my legacy HP/UX skills came back.
In fact, I'm a far better sysadmin now after 6 months with Vagrant than I ever was back in the day. The power of virtualization and Vagrant is that one can take chances in learning things. Last time I was hands-on, the sysadmin ruled. Even an ERP technical lead had limited scope.
My more cutting-edge friends will be saying "What about Docker?" Docker is another form of lightweight virtualization, akin to Vagrant in the existence of a public image registry, but a quantum leap beyond in other respects. Docker containers spin up in milliseconds as opposed to 15-20 seconds for Virtualbox VMs. I've just gone through the tutorial but it's likely I'll be using it in the next year, given my simulation goals.
Vagrant and Docker empower architects. We get criticized for not being hands-on, unfairly. Access to servers for experimentation hasn't been easy. Servers have been expensive, fragile, and burdensome pets, time-consuming to build and reconfigure. Labs? For senior infrastructure engineers, not enterprise architects.
Now, our laptops can run clusters of ready-to-go images. Servers are cattle and if you want to experiment, go right ahead (ever wondered what sudo rm -rf / would do?).
If you see issues, destroy the server and re-create it, including what you installed on it. Document your configuration as code, not as a set of half-remembered manual procedures. In Calavera, I do this through a Vagrantfile as a master control script, referencing various Chef cookbooks and recipes, under source control on GitHub.
Even the most casual observer of Agile and DevOps notices the centrality of source control. In a world of continuous technological transformation, source control is invariant. The latest incarnation is the emergence of DVCSes (Distributed Version Control Systems) such as git, which Linus Torvalds created to support Linux development.
Git + cloud hosting + social = Github. If you take one action after reading this post, it should be to familiarize yourself with Github. It has proven an ideal platform for hosting Calavera, and my lab exercises for St. Thomas.
Note, the version control wars still rage. Git and DVCSes are not the final word. But with software eating the world, including infrastructure as code, getting up to speed on modern source control approaches is time well spent. A workflow in one modern shop I know:
2. Create a new git fork and associate it with the story ID.
It's very different from the practices in effect when I was a developer. Source control -- an after the fact thing. Merging -- a thing of nightmare. The times they are clearly a-changin'.
Next: Reinvention part III: current Calavera status