“Don’t Repeat Yourself”. Every developer has already heard this principle.

Yet, in my experience, most of us didn’t get it. At least not how it was intended.

Software engineers, testers or product managers use mental models to reason about the systems they work with.

These different roles use architecture diagrams to build their own mental models.

People will make assumptions based on their understanding. And how you craft these diagrams will have a tremendous impact on the correctness of the assumptions.

Architecture diagrams are like text documents. It’s easy to create one. But it’s hard to create a good one. I would argue that for technical documentation, diagrams are even more difficult.

Drawing boxes and arrows is easy.

Sketching out the boxes and arrows is the easy part to put down on paper. The arrangement of these notations and the contents they represent is much harder to convey to the reader.

How do you make sure the reader will understand it as you do?

Today’s paper is Informed Privilege-Complexity Trade-Offs in RBAC Configuration by Jon Currey, Robbie McKinstry, Armon Dadgar and Mark Gritter. They introduce OnPar, the algorithm they created to power Vault Advisor.
The main problem here is well known to anyone managing some RBAC system: finding the right balance between fine-grained policies, applying the least privilege principle, and fewer more generic policies making it easier to manage.

Administrators must generate roles which reasonably tradeoff overall configuration complexity and least privilege, negotiating these conflicting objectives while respecting organizational constraints and ensuring continuity of necessary privilege.

The goal of OnPar is to help the administrator find the most appropriate policies to get the best acceptable trade-offs between least-privileges and configuration complexity in the context of their organization.

An explicit goal here is to try to help the administrators with their objective of eliminating unnecessary privilege. This implies each configuration needs to be evaluated against metrics relevant for both the configuration complexity, and for the security risk. To do this, the authors introduce the minimization of unnecessary privilege as a new metric.

The two objectives of minimizing unnecessary privilege and minimizing configuration complexity conflict with one another.

On May 30rd, I started the #100DaysOfCode challenge to learn more about formal methods and see how much we could use them in our daily software tasks. 100 days of code: Day 0 of learning TLA+ for regular software development will give you the introduction into this journey.

As with my regular notes, I’ll share the surprising or thought-provoking discoveries I make.

I’ve been contemplating the idea of ramping up on formal specification for a long while.

But the learning curve always felt like «it’s going to be a learning cliff». I saw it as a curiosity, but not something really useful for the day-to-day job.

Then this morning, I watched Marianne Bellotti’s Formal Specification and Taming Other People’s Tech talk from Strangeloop last year.

This talk made me consider it again.

Today’s post covers an unusual book: Distributed Control Systems, a Pattern Language Approach, by Eloranta, Koskinen, Leppänen and Reijonen ¹.

This book is not the software design book we’re used to: it’s focused on control systems for industrial systems. Industrial is the key differentiator here. Think of forest harvester, log truck, mining drills and machinery like that.

These systems have a different set of constraints than the ones we see in classical back-end software design.

That’s why I started with ‘unusual’.
Unusual implies a context: it feels unusual for me, as I spend most of my time working on back-end systems. I haven’t touched low-level hardware or electronics for many years. The last time was when building kiosks and early multi-touch tables for museums. Almost another career and another life, on another continent.

Every time I use ‘we’ hereafter, I think of colleagues and other people working on similar systems.

But when I read it, I understood why it was highly recommended: although the application domain is quite different, the parallels we can draw are apparent, and it’s refreshing and thought-provoking to see some of our shared problems presented from a different standpoint.

The patterns illustrated are often very similar from some we are used to, but with a different presentation, and the focus might not be on the same properties.

I’ll show examples of that below.

It introduces us to some less-traditional (for us, back-end developers) way to see the challenges, and forces us to step back and revisit some patterns from a different angle.

It’s very refreshing!

This post covers an interesting paper released last week by Heidi Howard and Richard Mortier: Paxos vs Raft: Have we reached consensus on distributed consensus?

Why would you want to read this paper

If you want to have an example of how to explain (or understand) Paxos easily, I believe it’s one of the best attempts I have read.

For two reasons.

The use of a Raft-like language removes a lot of abstraction, which makes it easier to understand. And the focus on the differences between Paxos and Raft help the subtle specifics of Paxos.

NGINX is awesome… but I found its documentation on rate limiting to be somewhat… limited. So I’ve written this guide to rate-liming and traffic shaping with NGINX. We’re going to: describe the NGINX directives explain NGINX’s accept/reject logic help you visualize how a real burst of traffic is processed using various settings: rate-limiting, traffic policy, and allowing small bursts As a Bonus, I’ve included a a GitHub repo and the resulting Docker image so you can experiment and reproduce the tests.