I just ended reading Thinking in Promises: Designing Systems for Cooperation by Mark Burgess and I want to write about it because I think that it is a good exercise for trying to grasp some definitions treated throughout the book that seems a kind of abstract.

This book was a recommendation of Juan Pablo Vergara who spoke briefly about it during our Scala meetup session in december 2016. Also I have seen mentions of this book by Jonas Bóner in his talk bla bla microservices bla bla that looks interesting seen by the point of view of microservices and distributed systems.

Promises as Contracts

When I saw the term promise the first thing that came to my mind (inevitably) was the concept associated to Futures and Promises, as seen in Scala and Javascript.

Mark states that our world actually works in an impositional way, meaning that most of the actions that rules everything are impositions rather than promises and he uses a clear example of this:

Instructions for cleaning a public restroom:

  • Wash the floor with agent X.
  • Mop and brush the bowls.
  • Refill soap.
  • Do this every hour, on the hour.

The outcome of this task is not defined, instead you have instructions that you must follow and the assessment of the result could be different, depending on the agent that evaluates it.

Changing that set of tasks by a promise approach looks like this:

  • I promise that the floor will be clean and dry after hourly checks.
  • I promise that the bowls will be clean and empty after hourly checks.
  • I promise that there will be clean towels in the dispenser after hourly checks.
  • I promise that there will be soap in the dispenser after hourly checks.

What can you see? Is the first approach clearer than this or is the other way around?

Note that in the promise formulation all the statements have a clearer and measurable outcome. Also, when you have a defined vision of what you want that makes you predictable and the results of your promises are reliable, repeatable and available.

From the book:

Promise theory is not a management ideology; it is an engineering framework for coping with uncertainty in information systems.

and:

It is a bottom-up constructionist view of the world

Makes sense?

But, why am I talking about contracts? Well, from what I understood throughout the book, thinking in promises is not only about draft statements à la promise way but reengineering how systems work in a cooperatively way.

One of the things that I can keep comparing is the microservices approach, and more generally, the approach of some service that offers you (as a consumer) some capabilities that, as you would expect, produces predictable outcomes (hello, FP concepts!). For example, if there is a microservice that offers you an API for managing a customer database (CRUD operations), you would expect a contract, that is, what is the structure that you have to give to the API for performing one of these operations, what is the structure that the service will use to answer your petition And much better: how do you describe this workflow as promise statements? Try to think how can you do this.

That example is confirmed by the book, according to this:

SOA is an example of a promise-oriented model, based on web services and APIs, because it defines autonomous services (agents) with interfaces (APIs), each of which keeps well-documented promises.

And a disclaimer here: SOA is NOT any of these vendor approaches

Definitions

Because I am trying to reinforce the concepts treated in the book, I will mention some of them and also I am going to ask some questions for further debate.

From the book:

What is a promise?

(It is) a kind of atom for intent that, when combined, could represent a maintanable policy.

It is a publicly declared intention to an audience (scope).

What is an intention?

It is a subject of a possible outcome.

What is an imposition?

It is an attempt to induce cooperation in another agent (hints, advice, suggestions, request).

What is an obligation?

It is an imposition that implies a cost or penalty for non-compliance.

What is assesment?

It is a decision about whether a promise has been kept or not.

Why I have cited these definitions? because, if you haven’t read the book yet it is important to know these concepts beforehand because they are the basis of the theory.

Let’s focus on the assessment part.

The truth is in the eye of the beholder

When you, as an agent, promise something to someone, that external entity will assess the outcome of your work. The thing that I find amazing is how an assessment could be entitled to the perspective of the beholder, even in information systems (that tends to measure everything as accurately as possible). What you see as correct other entity can see it as wrong and that’s good.

Burgess states that the beauty is in the eye of the beholder because there’s cultural norms when judging the value of something.

Depending on the entity of the system that assess something some outcome could be right or could be wrong, and that is a perspective hard to achive or to think of as a software developers because we tend to measure everything by the same yardstick, no matter the context.

Sounds trivial but that catchphrase is very very powerful because obliges us to think about the multiple perspectives, contexts, responsibilities and relationships between the agents of our system. That changes everything because that state of mind is unreachable with the standard imperative reasoning (if this, then that, no matter what).

How do promises and agents compose and interact?

Based on what Mr. Burgess presents during the entire book, I draw parallels between the actor model and the concept of promises. When you, as an individual agent promises to do something and some observer or consumer assess that work, you are:

  • Segregating responsibilities through different actors.
  • Delegating granular tasks to agents.
  • Composing outcomes for complex and long-running tasks.

Am I wrong when I say that I find a relationship between what the actor model proposes and what promise theory tries to achieve?

From the book:

Promises fit naturally with the idea of services. Anyone who has worked in a service or support roles will know that what you do is not the best guide to understanding: “Don’t tell me what you are doing, tell me what you are trying to achieve!”

Again, the interface for an actor is basically what kind of tasks are delegated to it and what the actor will do, seeing it as a piece of a greater task. That last part is somewhat validated according to this:

The goal of Promise Theory is to take change (dynamics) and intent (semantics) and combine these into a simple engineering methodology that recognizes the limitations of working with incomplete information. Who has access to what information?

“A Collective Design”

A thing that I have found very interesting is the way in which every agent has a role and how that roles forms what is said to be a collective superagent. The first part of the book (the first two chapters) treats promises as a single unit but the rest of the book focuses on how that entities have different properties that can take different roles in the system.

I see parallels with the actor model (again) and distributed systems about the consensus that every agent promises and the roles (by appointment, by association and by cooperation) that they takes.

Also, a thing that I cannot completely understand is the Nash Equilibrium for consensus. It is interesting because, being a concept that fits into Game Theory it sounds more like a competition for an “optimal” solution of a game rather than an agreement. At this point I am trying to figure out if something like consensus algorithms (like Paxos) fits somehow in this idea.

To illustrate this concept, the book offers an example about agreement:

Suppose four agents: A, B, C and D; need to try to come to a decision about when to meet for dinner. If we thunk in terms of command sequences, the following might happen:

  1. A suggests Wednesday to B, C and D.
  2. In private, D and B agree on Tuesday.
  3. D and C then agree that Thrusday is better, also in private.
  4. A talks to B and C, but cannot reach D to determine which conclusion was reached.

Sounds simple (and the book says that is a classic distributed computing problem) but I understand it only at some extent. What is remarkable is the vision that the promise concept brings to the distributed systems design and I say that because of this quote:

The lesson (of the stated problem) is that, in a world of incomplete information, trust can help you or harm you, but it’s a gamble. The challenge in information science is to determine agreement based only on information that an agent can promise itself.

Sounds like what Paxos’s (or some other consensus algorithm) aim.

Continuous Delivery

One of the things that caught my attention the most was the mention of CD and DevOps in various parts of the book and the analogy of a continuous system with repeatable outcomes. Things like containers, versioning and branching, for example, are related specifically to software development but the author brings that to the conversation as a way to think about the semantics and dynamics that each of them represents in a system in which this traits makes the results predictable.

Final thoughts

This post is more like a personal abstraction of the core concepts that I understand about the book. There is more of them that I didn’t mentioned here, but it is a start because I want to make my mind with the main ones and then make another post with my findings.

If you see a misconception about things that I have said here, please leave your comments.

Thanks for reading!

UPDATE: Yuji Kiriki pointed out a mistake when I said that consensus sounded like the CAP theorem. Clearly I was confused at that point and it was fixed.