How DevOps is Like Painting

art, code

This week I am doing a client presentation The presentation is about basic devops practices and why they are important, how the client is adopting them in certain areas and where there is room for improvement.

DevOps is something that I am actually very passionate about. In the early days of programming there was a distinction between the creating of the software (software developers) and the deployment of the software (the system admins). This created for software development a two culture system as well as a linear system.

In dev ops, deployment is part of software development process – there is no more sys admin. This is a small distinction but it has outsized ramifications. Often times small changes in a system can have the largest impact. I think of it akin to accupuncture or accupressure or various martial arts where you make small subtle movements but they have massive impacts on your ability to be effective.

Why is this the case?

Well we can talk about systems, and with systems everything is interconnected so instead of finding the biggest problem point we need to find the most salient or impactful point.

We can also talk about inner systems (like inner martial arts) or invisible systems. This is the idea that there are some processes that are not apparent until we begin to perturb the system then we realize they exist indirectly and we can learn to control or exert pressure on these systems.

We can also talk about

With DevOps we move from a linear mode of working to a cyclical way of working. Why is this? What is really happening? Well we move from a sort of fordist conveyor belt notion of manufacturing that centers on the belt, to a pipeline notion of manufacturing that focuses on the widget. Rather than have pieces on a conveyor belt that different workers apply functions to. Someone introduces a new widget (an artifact) into a system… the system is a gigantic statemachine that applies tests to the widget. Depending on the result of the tests the state of the widget changes – from dev to testing to security to deployment… Depending on the state, different tests are applied. If the widget fails a test then the developer creates a new widget (artifact) and it goes into the system.

What we are doing is changing the state of something that is immutable… the software artifact. It is cyclical in the because a state machine is an infinite loop. It never ends. A conveyor belt has a beginning and an end.

Immutability is core to dev ops, but really cloud native computing. With cloud native devops there is no longer the sense of editing. When I deploy something I deploy the software along with the infrastructure – I create everything all at once. If I redeploy I remove the old environment (and artifacts) and then redeploy the newly created infrastructure with artifacts. Nothing ever changes. We just create or destroy.

Painting is similarly immutable. I was in a crit session, and someone brought two versions of a painting. This is impossible, said the crit leader (or she said something like that). Paintings can only have one state. This is different than say a novel or the written word, or something with versions. And while I can have different versions of code artifacts, with immutable infrastructure I only have one deployed version. Redeploying the a new version creates a new state of affairs in a way that is similar to painting, or overpainting, on a painting – AND different from editing a poem, story, essay, or book.