Promises, Microservices, and Intent

Last year, after a bit of wrangling and lots of editing by the fantastic Jenn Webb, O’Reilly published a discussion Mark Burgess and I had on one of his trips through the Valley as a podcast.

The audio is iffy, which is entirely my fault. I have zero experience recording for any purpose other than capturing notes from interviews for my own use later.

I’ve referenced Mark’s work before in talks and presentations like this one at O’Reilly Velocity two years ago.

The interesting thing about Mark’s view is that he approaches systems as a physicist, looking at systems as phenomena, as things that happen, as something that behaves with behaviors that can be described. My highlights from our conversation below.

Measuring Intent

It all goes back to scales, the order of magnitude we look at. When you measure, observe, and characterize the world you have to find something to measure it by. The descriptions of systems are often qualitatively different at different scales. This is not something we tend to understand in a clear way in CS.

In CS, you’re mostly focused on intent — what we call semantics. There’s no numerical measurement. We simply write code. In physical phenomena, changes in measurable things have scales. Part of my work has been to figure out how we could invent scales and measuring sticks for semantics. This is how Promise Theory came about.

A promise is a description of intent that you share with someone. Until you share it, it’s just an intent. As soon as you share it, it becomes a promise. In a promise-oriented view, you look at what are the agencies capable of bringing about state (making promises). In the most abstract sense, an agency is anything with a purpose or function with some semantics and behavior — machines, people, tools.

Microservices’ Promises

The purpose of a promise is to describe that behavior and be able to break it down into constituent parts. It provides a language for systems that allows us to describe the elements of a system and what happens when you put them together, like atoms into molecules, etc.

Microservices are a modern incarnation of this idea.

There are two ends of a promise: the offer of a service and the acceptance of it. You may choose to accept less than is offered. This is another way of talking about autonomy of the actors in a system. This is a good representation of how the world actually works. You simply cannot force your will onto another actor, or device, without attacking it in some way. Ultimately, it’s up to that agent to act the way you want.

This drives you to understand all the communications pathways in a system and exposes all the failure modes that can manifest.

Humans Feed Back

They’re also a great example of where humans enter the picture.

We cannot understand computer systems without taking into account humans, because they are an integral part providing not only input, but feedback (and modification). It’s a symbiosis. Microservices are an example of how you can break things down to smaller, more manageable pieces in order to scale the human.

If this kind of thing interest you at all, read Mark’s books: In Search of Certainty andThinking in Promises.

sizable disadvantage

In my admittedly short career (just over 15yrs) so far, every observation I’ve ever made has led me to the conclusion that size is a fundamental competitive disadvantage [though not necessarily a fatal one]. Why? Because to make size manageable, we typically arrive at a series of abstractions in the form of: process, bureaucracy, hierarchy, etc. This creates a large opportunity space for mistakes, disconnection from reality, safety from the negative consequences of decisions, general incompetence, gerrymandering, insularity, etc.