The pyramid architecture

After more than a decade in the software industry, there are few conversations that never seem to get resolved, monolith vs. micro-services, or vi vs. emacs.

The micro vs. macro services thing is something I want to try to offer a different perspective on. I've noticed recently that the teams I work with have a hard time to estimate work, and set expectations with stakeholders, and I think that maybe we're missing a tool to help us frame the conversations.

Before getting into the details, I want to make an honorable mention for the OSI model, it defines a pyramid of layers that were instrumental in helping the build-out of the early internet and subsequently the world wide web.

The layers are:

1: Physical Link: Literally physics, electro-magnetic or mechanical transmission of signals.
2: Data Link: Transferring data point-to-point using Layer 1.
3: Network Link: A network of machines, packets, retransmission, etc lives here.
4: Transport Layer: Variable length, and bi-directional communication, etc on top of the packet/frames abstraction.
5: Session Layer: The concept of presence, correlating transport layer activity into coherent streams, or sessions.
6: Presentation Layer: The protocol layer, e.g MySQL connection activity look different to TLS sockets.
7: Application Layer: Applications don't need to know anything about how data gets from A/B, they get the socket read()/write() metaphor, and in theory, it "just works".

🛈 If you've ever heard terms such as "Layer 5/7 Load Balancer", then this is people referring to the OSI model, such a load balancer would be aware of application or session layers, "sticky" load balancers, for example that route all a user's HTTP requests to the same back-end server have to have a concept of sessions, and not care only about the network, or transport link layers.

This isn't an essay about the OSI model, but the key message I want to transmit is that this abstraction is so clean, that it "just works", most of us (humans for sure, but also engineers) can ignore the existence of this concept, and when we work with it, we intuitively gravitate to the appropriate level of abstraction.

The top of this pyramid (sometimes also shown as a stack) just says "application", but of course, inside application we have architectural concerns too. Maybe the logical "application" (e-commerce website, logistics platform?) comprises a database, and one or more services, some APIs, etc.

You see hints of this kinds of split in the regular team arrangements in most companies, we have developers who build software, operations people who run the infrastructure; even within the software developers, you can easily separate into "back-end", "front-end" and "mobile", easily different aspects of an extended stack.

OSI would group these all into the top one or two layers, so we leave our venerable friend behind, and invent a concept for ourself.

We can adopt a similar model in within the "Application Layer", and it can help us figure out where to "put" work, whether a feature we're building in a cross functional team, is actually risking their timeline by crossing "layers".

Looking at my own team, I came up with this, which I think fits, but you will need to discover what is right for your organization.

We can use this to answer some questions:

How should teams be organized? Is it reasonable for us to have a "cross-functional" team ship features across the top three layers?
Do lower-layers get handled by "service teams"? Feature teams campaign for the service/platform teams to provide infrastructure

We can also use this to avoid some pitfalls:

Cross-functional feature teams shouldn't plan to build a feature relying on new infrastructure until it's in place. You wouldn't build house on shaky foundations, the same applies here.

There's some risks involved with model, too. If you don't have a good mutually beneficial relationship between platform teams and feature teams, the feature teams may avoid building useful features, because the infrastructure just isn't there, or worse yet, those feature teams start introducing their own "infrastructure" that maybe isn't as aligned with the company philosophy or standards as it could be.

Hopefully too, this helps put to bed some of the arguments about microservices vs. monoliths, as long as your stack is cleanly arranged, you can figure out whether introducing a division in the "Application layer" unduly affects the layers on top, or whether it can be a smooth integration.

The biggest red-flag, should be when your architecture discussions start to devolve into this: