Monolith First (2015)

Well for starters, each component's API can be published and versioned separately from its implementation.

The build of a component would only have access to the API's of the other components (and this can include not having knowledge of the container it runs in).

The implementation can then change rapidly, with the API that the other teams develop against moving more slowly.

Even so, code reviews can be critical. The things to look out for (and block if possible) are hidden or poorly defined parameters like database connections/transactions, thread local storage and general bag parameters.

In some languages dependency injection should be useful here. Unfortunately DI tools like Spring can actually expose the internals of components, introduce container based hidden parameters and usually end up being a versioned dependency of every component.

We did the journey both ways:

Monolith -> Microservices -> Monolith

The first monolith was so bad that microservices made sense at that point in time. The current monolith is an exemplar of why we do not use microservices anymore. Everything about not fucking with wire protocols or distributed anything is 100x more productive than the alternatives.

Deciding you need to split your code base up into perfectly-isolated little boxes tells me you probably have a development team full of children who cannot work together on a cohesive software architecture that everyone can agree upon.

> So in theory yes you could have a well modularized monolith.

I've often wondered if this is a pattern sitting underneath our noses. I.e., Starting with a monolith with strong boundaries, and giving architects/developers a way to more gracefully break apart the monolith. Today it feels very manual, but it doesn't need to be.

What if we had frameworks that more gracefully scaled from monoliths to distributed systems? If we baked something like GRPC into the system from the beginning, we could more gracefully break the monolith apart. And the "seams" would be more apparent inside the monolith because the GRPC-style calls would be explicit.

(Please don't get too hung up on GRPC, I'm thinking it could be any number of methods; it's more about the pattern than the tooling).

The advantages to this style would be:

* Seeing the explicit boundaries, or potential boundaries, sooner.

* Faster refactoring: it's MUCH easier to refactor a monolith than refactor a distributed architecture.

* Simulating network overhead. For production, the intra-boundary calls would just feel like function calls, but in a develop or testing environment, could you simulate network conditions: lag, failures, etc.

I'm wondering if anything like this exists today?

I have worked on both types of applications and what he says is very true. The startup which failed to launch because of difficulties in getting the architecture and infrastructure right. It was around 2014 and the company company eventually ran out money and more importantly missed the time frame. The second product was a massive enterprise product that had 100s of members working on it on any given day. The product was written in Java as a monolith. It was slow to develop and a pain to work on. But it worked and the product succeeded. People complained that it was slow and they were right.

So they decided to break it up into multiple services. First was a pdf report generation service which I wrote in node.js. Then more and more services were added and other other modules were ported as node apps or separate java apps. In the end it was around 12 services and all of them worked well.

The monolith was still there but it's fast enough and users were happy. That's a lesson I'll never forget and have understood that time and velocity are far more important for a product to succeed!

Most common architecture for SAAS apps is a frontend served from cdn + frontends served by app stores, an api server behind app load balancer (e.g nginx), a database cluster, and a bunch of async long lived cron jobs + on demand jobs.

In that architecture you don’t need that many Microservices. The api server is prolly the most important bit and can be served as a monolith.

Many 10B+ companies use this architecture. It works well and does the job. Mono/Microservices is really about separation of concerns. Separation of concerns mostly around what you want to deploy as a unit, redundancy and what should be scaled as a unit.

Agree with author. Start with one chunk, and split when you feel the pain and need that separation of concern. Fewer pieces are easier to reason about.