Once you eliminate your number one problem, number two gets a promotion.
Rudy’s Rutabaga Rule, Jerry Weinberg
This week I've been thinking about agility and configuration drift, and of course how the two relate to each other.
Let’s start with my definitions, so we don't get into a kerfuffle.
- Agility. The ability to move quickly and easily. In technology this is to do with being able to add a dependency, or take one away, for example, without it taking six weeks. It’s about being able to switch to Java 8 without having a meeting with the CIO.
- Configuration drift. The phenomenon whereby small, sometimes gradual, changes to software and hardware creates unknowable differences across environments. For example, a production server may ‘drift’ so that what works in development may no longer work in production. Some production-only failures can be caused by configuration drift.
I spoke to someone this week who wanted their teams to be agile. That is, he wanted his teams to get ideas from their product people's heads and into production as quickly as possible. To support that, this person told me they'd picked a good stack of technology and locked all environments down using Virtual Machines. If, for some reason a certain machine was ‘corrupted’, they’d throw it away and start again.
The logic here was reasonably simple: the development teams could work as quickly as they liked, could make all their own decisions, but they couldn’t, for example introduce new technologies. They certainly couldn’t change from one version of Java to another or swap out their old SQL database for something like MongoDB.
The problem with solving the configuration drift problem like I just explained is that it is the team who will drift. Specifically, their minds will drift. Imagine you are a developer in an organisation where you can’t easily change your working environment. Imagine that you can solve a lot of your problems with a new technology but you can’t introduce that technology because it’s not compatible with those Virtual Machines. This is literally a hopeless situation.
Hope is ‘a feeling of expectation and desire for a particular thing to happen’. Locking down technology stacks leads to problems associated with hopelessness, namely low motivation and a desire to drink at lunch. Locking down configurations in this way takes away a team's autonomy. And therefore it takes away their ability to think and move quickly. I.e. it takes away their agility.
Docker containers allow developers to ship their configuration along with their code. Docker claims to let you 'build, ship and run any app, anywhere'. They are trying to solve the problem of shipping code to a server, which is difficult but should be easy.
Docker containers are, however, not a panacea. They have problems associated with security and networking, to name just two. However, there is a reason why Adrian Mouat says, ‘The future is containerized’, and I think the reason is because containers (Docker or otherwise) make the promise of solving configuration drift without killing agility. This, in my opinion, is problem number 1 for a lot of ogranisations. I want to help them solve it because I simply can't wait to see which problem gets promoted.
Previous article
