Monolith First (2015)

The basic technique is to use modular architecture.

You divide your application into separate problems each represented by one or more modules. You create API for these modules to talk to each other.

You also create some project-wide guidelines for application architecture, so that the modules coexist as good neighbors.

You then have separate teams responsible for one or more modules.

If your application is large enough you might consider building some additional internal framework, for example plugin mechanism.

For example, if your application is an imaginary banking system that takes care of users' accounts, transactions and products they have, you might have some base framework (which is flows of data in the application, events like pre/post date change, etc.) and then you might have different products developed to subscribe to those flows of data or events and act upon the rest of the system through internal APIs.

Most likely not, the new guys were phd-types that was ultra smart but did nothing except have meetings. I think they were over-engineering it completely which made it impossible to deliver something of value.

However, I think that is often the case of a microservices architecture.

The problem with creating a dichotomy between "monolith" and "microservices" is that... well... it doesn't make any sense. You describe your "microservices" and I'll explain how it's really just a monolith.

"So let me get this straight, you have a Billing package and an Ordering package. How are these organized again?"

-> "We have a distributed system."

"So you you compile them together and deploy them horizontally across many machines? Like a distributed monolith?"

-> "No we use microservices. The two packages are compiled and deployed separately so there is no code dependencies between them."

"Okay. So if I understand this right, you develop each package separately but they both access the same database?"

-> "No no no no! Microservices are not just about code dependency management, they are also about data ownership. Each package is developed and deployed separately and also manages it own database."

"Ah, so you have two monoliths?"

-> "..."

You see the problem is that the above terms are too broad to describe anything meaningful about a system. And usually "monolith" is used to described the dependencies between code whereas "microservices" is used to describe dependencies about data. It turns out there is a lot of overlap.

Design and implement your systems according to your use-case and stop worrying about how to label them.

Sorta the purpose of the Actor model but that has other complexities.

I think a trap that many software engineers fall into is interpreting "loose coupling" as "build things as far down the binding hierarchy as possible".

You see this under various guises in the web world - "event-driven", "microservices", "dependency injection", "module pattern". It's a very easy thing to see the appeal of, and seems to check a lot of "good architecture" boxes. There are a lot of upsides too - scaling, encapsulation, testability, modular updates.

Unfortunately, it also incurs a very high and non-obvious cost - that it's much more difficult to properly trace events through the system. Reasoning through any of these decoupled patterns frequently takes specialized constructs - additional debugging views, logging, or special instances with known state.

It is for this reason that I argue that lower-hierarchy bindings should be viewed with skepticism - if you _cannot_ manage to solve a problem with tight coupling, then resort to a looser coupling. Introduce a loose coupling when there is measurable downside to maintaining a tighter coupling. Even then, choose the next step down the heirarchy (i.e. a new file, class, or module rather than a new service or pubsub system).

Here, as everywhere, it is a tradeoff about how understandable versus flexible you build a system. I think it is very easy to lean towards flexibility to the detriment of progress.