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.

<iframe width="100%" height="300" scrolling="no" frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/241912564&color=%23ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true&visual=true"></iframe>

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.

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 Computer Science.

In CS, you’re mostly focused on intent — what we call semantics. There’s no numerical measurement, no way to quantify semantics. We simply write code. If you look at physical phenomena, on the other hand, all changes are measurable and happen at identifiable scales. Much of Mark’s work has been to figure out how we can invent scales and measuring sticks for the semantics we encode (ha!) in code. 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 the agencies capable of bringing about state — machines, people, tools, services, functions. If it can create or change state, it is effectively making promises: given some context or input there will be some change or output.

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.

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. It’s also 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.

Microservices are also a great example of where humans enter the picture.

We cannot understand systems without taking into account people, 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 and Thinking in Promises.