code

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.

New Newsletter AND Musing about JS Frameworks

code, consciousness

Hey Blogosphere,

I am not sure why I am writing this blog post as an epistle but perhaps it has something to do with me launching a new newsletter. Newsletters are often written as epistles. Not sure why, perhaps because they are letters. In any case, I was inspired by Nitzan – he has started many successful newsletters. This is his latest – the future of agency.

Why a newsletter, I do blog (sporadically)? I have had newsletters in the past, and my companies have had newsletters? I think it is a good conversation starter, and a way to enter existing conversations.

Yesterday Nizan prompted us to think about our practices. And here is what I wrote. It is going to be the subject of the newsletter.

Globally, I am interested in understanding how the technology of computation affects our notions of the psyche, i.e., our inner life, and the mechanics of the psyche itself.

Locally, I am interested in how this manifests itself as both personal and collective actions in the world, and ways (ie projects/interventions) to highlight this manifestation.

Things I am not currently investigating, but appear relevant:  neuroscience, biology, behavioral psychology.

Things this may fall under: phenomenology, depth psychology, design, computer science, cognitive science, systems thinking.

The link is here: https://tinyletter.com/systempoetics

I am trying a new service that I have read newsletters on in the past – tinyletter.

Immediately when I saw the #! I thought – they are using angular. I have not used angular in years, so this intuition may be totally off. Anyway they are not – they seem to be using a new to me framework called velocity. Velocity does seem rad, it is suited towards motion graphics (and the ever present rethinking of the dom).  And DOM/DOMLESS could be one perhaps the first topic of my new newsletter.