Automation won't pick up some version upgrades

Introduction

This post is about situations where software components that are commonly imported in as part of assembling production systems can slip outside of the normal expected path for detecting the availability and applying version upgrades.

A couple of examples of systems that can be set up to detect when new versions of dependencies are available are:

Renovate

Dependabot

Examples of dependency changes

When a base Docker image went distroless

When new versions stopped being released for the alpine distribution of the envoyproxy Docker image automation had nothing in place to detect that and raise it as a potential issue.

I came across this when a production issue came up in another team's core infrastructure service. Since my team was going to be blocked until the incident wsa resolved, I followed the online chat discussion, checked some logs, did some Googling and established that the error that was being seen should have been resolved by a version of envoy that had been available for several months.

It took an hour or so to join the dots and establish that the "latest" version that was being deployed was several versions behind envoy's releases because it had not been updated to align with a decision to stop support of a particular linux distribution in favor of going with a distroless approach. 

Change of maven artifact name

For Java applications maven packaging has become a de facto standard for the management of libraries that need to be brought in to support functionalities within a service or application.

An example of an artifact that changed its name as part of a major version upgrade is apache commons-lang that moved over to commons-lang3.

I can't recall any particular problem arising from running with commons-lang, but I wouldn't like to see commons-lang as a dependency in my codebase - given that it's most recent release was back in 2011, more than 14 years ago.

So how can we stay up to date?

In my view, the best way to reduce dependendency management overhead is to minimise dependencies in the first place. Carefully weigh up the value that is being added when you bring in any dependency

• Does it bring along a bunch of transitivie dependencies? Is it worth it?
• Could the same be achieved with a couple of extra classes directly in our codebase?

As software bills of material and greater attention is focussed on the software supply chain, I believe it will become more common for organisations to have centralised tooling in place to surface up the use of out of date artifacts. 

Mechanical sympathy mindset

During my time in London I socialised a bit with some of the members of the team behind the LMAX Disruptor, which is where I first recall hearing of the concept of Mechanical Sympathy and its applicattion to design of software.

Something that was intially counterintuitive to me about the Disruptor was the approach to including padding in data structures to exploit caching at the hardware level.

I'm on a break from working in tech at the moment as I keep myself available to help my family adjust to some health issues that come with aging, but my mechanical sympathy mindset is still active.

Today as I was vacuuming the floor of my living room I wondered about whether height makes a difference to the suction power of the vacuum cleaner - as taller people will typically extend the length of the pipe between the suction mechanism and the floor. Based on some Google search results, the short answer is "yes".

I was going to posit that as an explanation for why my mother always seemed to do a better job of vacuuming than me when I was younger, but I wasn't taller then, so that doesn't really apply.