There have been multiple discussions of how the microservices movement did more harm than good, how a modular monolith can be a much better option.<p>I wish there was a comprehensive book (ideally) that is practical, pragmatic, doesn't advocate the use of microservices just because it is cool, etc.<p>Some books that are often recommended have "microservices" in their names which is a pretty bad start.<p>For example, I am thinking of how two services should communicate (I am unfortunately guilty of having more services that I really needed). There are multiple options and the choice depends on factors like synchronous vs asynchronous so I would like to read a detailed analysis of all tradeoffs and considerations. Ideally, from authors that really know what they're talking about.
So much is wrong with your starting point.<p>a) Microservices are a 20+ year old concept and for the right use cases are a better choice than monoliths. Likewise the reverse is true. Being successful with your architecture is all about being pragmatic and choosing the right tool for the job.<p>b) Don't fall into the trap of being obsessed about what is cool or not. No one really cares other than you and it isn't going to affect your career prospects despite this being a popular myth.<p>c) What does affect your career is being narrow minded, acting like you're smarter than other engineers and being closed off to other ideas. You should understand micro services, monoliths, 90s style SOA etc. You should understand everything. Why they were invented and their relative strengths and weaknesses. Being able to articulartly defend your architecture is a fundamental aspect of working in IT.
The Architecture of Open Source Applications has some great lessens learned. It's also free: <a href="https://aosabook.org/en/" rel="nofollow noreferrer">https://aosabook.org/en/</a> .<p>I don't think there are lots of examples of the <i>distributed systems</i> discussion though, since most of the writing is about how to structure the source code of a single program. That's not <i>unrelated</i>, since most of what you're asking about is how different interfaces or modules should interact. In a distributed system, that happens over RPCs, but it can just as easily happen within a program with separate threads.<p>Note: they've added some other books, which show up at the top of the page, but I've only read select chapters from AOSA Volume 1.
The only modern design book that seems to be universally acclaimed is designing data intensive applications. I enjoyed it and I don't remember it being too much along those lines. Martin fowlers writings were reasonably balanced on that kind of stuff although I think he was an early advocate of service bus. Our business seems to be reversing in terms of the drive for microservices and being more tolerant of medium sized systems.
This may sound like I am a complete idiot, but I sincerely think that reading works like the Tao Te Ching may help more than reading books on software architecture.<p>There are still many new ways of architecture to be found. For example, making software with an extension language could result in way better systems than a system envisioned by a customer who has no clue about computers. But unfortunately, it is often a nonsensical output constraint that determines how software evolves.<p>Knowing how to manage these constraints is key. And this requires understanding and being able to successfully communicate with people, and keeping track of contemporary hardware and software to interface with. The actual software design seems largely irrelevant to me.<p>Just use good names, and subdivide complexity into modules with a lower cumulative complexity.
Patterns of Enterprise Application Architecture, Martin Fowler, and Enterprise Integration Patterns, Gregor Hohpe.<p>both predate microservices, and both are still very useful today.
Although you wouldn't expect it, the book Monolith to Microservices presents solid arguments against microservices. The author cautions against using microservices throughout the book due to the additional complexity introduced.
Actually you should avoid splitting software into microservices by default until you really need it. It's easy to catch the moment - you will see that movement of some project part into microservice will help you to close many points and issues.<p>So:
1) Read classic books about monolith software.
2) Read decent books about microservices approach.
Maybe this is too broad of a read and too far from microservice specifics, but I find ”Joel on software” very inspiring.<p>Hopefully it will give you new perspectives.
I really enjoyed: Software Architecture, The Hard Parts.<p><a href="https://www.oreilly.com/library/view/software-architecture-the/9781492086888/" rel="nofollow noreferrer">https://www.oreilly.com/library/view/software-architecture-t...</a><p>One part it discusses is in fact communication patterns along the dimensions of:<p>- sync/async<p>- atomic/eventual consistent<p>- orechestrated/choreographed
I'm not against starting with a monolith and even keep evolving it if that makes sense but the problems with microservices I've seen were about poor design. They were mostly problems that could be avoided if people designed good DDD Bounded Contexts in the first place, regardless of being microservices or not.
To proponents of large monorepos/monoliths at larger orgs (say 100+ developers):<p>What is your build time? How long to go from PR to deployed?<p>In my experience, this is usually _hours_ at least. In my microservice shop at my previous org, full end to end regression tests included, meant code was in production in 10-20 minutes.
I think many of these debates about microserivces don’t take into account the number of responsibilities the system must offer. For simple systems of course micro services is too much. The number of books around microservices vs monolith can be seen as a function of the popularity of one approach vs the other.
If you want to learn to build software well, I can’t recommend the Eventide community enough. Eventide is a ruby toolkit for event sourced autonomous services, but the people there have a proven track record of understanding, executing, and teaching software design and architecture.