Early and late binding are often discussed in terms of symbol resolution in programs that have symbols loaded from shared objects and static libraries, so what does this have to do with configuration? It turns out that a lot of the pitfalls and concepts that have to do with symbol resolution also apply to configuration management. IN a traditional systems management environment, configuration binding is typically performed very late. The binding happens either by a tool such as Ansible writing config files into place, or a package containing configuration files being installed, or even an admin logging into a machine and writing the config data.

Just over 8 months ago I wrote about running the complete HashiCorp stack on top of Alpine Linux. Since then, the entire production workload of my work has moved over to this cluster, and through a handful of upgrades we’ve learned a lot about how it works and how to maintain it. This article is a followup to the original, which if you haven’t read, you should take a break and do so.

I am too young to remember the first day of eternal September personally. The idea goes like this though: in September 1993, an engineer at AOL flipped a flag and granted UseNet access to all AOL subscribers. It was a clever marketing move, UseNet was easily the largest online gathering at the time, spanning university and company networks, and containing a wealth of knowledge. If you’ve never used the service before, try to imagine a web forum with every topic you can possibly think of in a neatly arranged tree structure.

Those who are near me for any length of time know that I like open source. To me it speaks of a kind of engineering purity that I don’t see in a lot of places. I thought I’d take some time and write down what open source means to me, and what I look for in projects that I work on. First, I think its important to define the two kinds of source that there are and the degrees of openness I’m referring to.

I was recently talking with some people from the open source world about what it means to own a project and this got me thinking about some of my own projects. What is my stake in them at this point? Really for me the question is less of “is this my project” and more “do I need to take this more seriously now”. Let me explain. For my own projects, they are things that I do that are really just for me and if they fail or die its not an issue because after all they were just my own projects.

I often get asked about why I am always so frustrated with the code that people tend to write. This discussion came up recently between some friends about why NetAuth is both in production with Void, and not 1.0 yet. For me, this has to do with the expectations of quality I subject most software to and my expectations for the risks an organization should be willing to put up with.

Recently at work I’ve been setting up a Nomad cluster to take over the production workload in our primary serving cluster. This process has taken several months at this point to prototype and develop, and along the way I’ve learned a lot about cluster operations with Nomad. Coming from the world of Google and Borg I had a pretty good handle on how cluster level schedulers work, but I’m still amazed at some of the things that are either dramatically more elegant in the HashiCorp stack, or less enthusiastically, things that make me want to pull my hair out.

I’ve just gotten back from the Apollo 11 movie, which I saw in IMAX. The film is a documentary that is all about Apollo 11 and steps you through in a very linear view the progress of the Apollo 11 mission. The story is told without narration or interviews, and features many segments that are shown in real time. Some of the things that I think are so incredible about this film are that it shows the people behind the mission.

I was recently asked by a few different people about why I have such strong feelings about Python in production on Void’s infrastructure. I’ve also been asked at work about why I’m unhappy with using Ansible even though it ticks all the boxes for being a pretty good host management tool. I figure its high time to look at why I care about languages in production. So at first this doesn’t seem like it should matter.

I recently decided to try the Caddy webserver project’s implementation of a webserver written in Golang. It had many interesting things going for it, including automagic certificate renewal via ACME and Let’s Encrypt; “plugins” written in a sane language; dramatically simplified configuration; and perhaps in one of the most boastful statements I’ve seen of any software recently, it claims to be “Production-Ready” (features page, right hand side). Given that it took me the better part of a day to get a functional Caddy role for Ansible, I really question this claim.