So much is wrong with your starting point.

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.

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.

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: https://aosabook.org/en/ .

I don't think there are lots of examples of the distributed systems discussion though, since most of the writing is about how to structure the source code of a single program. That's not unrelated, 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.

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.

I really like how AOSA just describes things that exist, rather than trying to push a particular way to design/architect

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.

I have already read and very much enjoyed DDIA. I also revisit some of its chapters occasionally.

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.

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.

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.

Just use good names, and subdivide complexity into modules with a lower cumulative complexity.

> There are still many new ways of architecture to be found.

Good architecture tends to break up complexity into common building blocks, and avoiding patterns that might cause instability or failure. Or seeing the cause of the instability and then fixing it. IOW, there's really no need to recreate the wheel....

Over time, as you get good at it, you'll see the exact same patterns over and over again, so rather than need to experiment with new technologies or software architectures, you can just reach into your experience and bring things out you know work already.

Patterns of Enterprise Application Architecture, Martin Fowler, and Enterprise Integration Patterns, Gregor Hohpe.

both predate microservices, and both are still very useful today.

"Patterns of Distributed Systems (2022)" https://martinfowler.com/articles/patterns-of-distributed-sy... and notes regarding: https://news.ycombinator.com/item?id=36504073

+1 for Fowler's book. Picked it up on a whim and it's so interesting to see patterns I've used for years documented in this book from the mid 2000s. He was excellent formal descriptions providing some more context than you may get organically.

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.

So: 1) Read classic books about monolith software. 2) Read decent books about microservices approach.

I would recommend Release It! by Michael T. Nygard first edition, the second edition talks about microservices

I have the first edition and thoroughly recommend it. The rules he sets out seem to adequately account for any architecture. I’m slightly surprised that the second edition covers microservices.

Have you read it? Do you know what angle he takes on them?

Unfortunately, I haven't read it, so i do not know what angle he takes.

Maybe this is too broad of a read and too far from microservice specifics, but I find ”Joel on software” very inspiring.

Hopefully it will give you new perspectives.

I really enjoyed: Software Architecture, The Hard Parts.

https://www.oreilly.com/library/view/software-architecture-t...

One part it discusses is in fact communication patterns along the dimensions of:

- sync/async

- atomic/eventual consistent

- 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):

What is your build time? How long to go from PR to deployed?

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.

Working on massive C++ monoliths here. Equally fast to test and deploy.

A friend of mine is working on a 30+ years old micro-services system. Worst piece of garbage I have ever seen in my long career.

So my conclusion is that it is the team not the architecture that ultimately decides how good the resulting software is.

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.

I'd recommend Clean Architecture by Robert Martin.

+1 … it has a great discussion of structural vs object-oriented vs functional, presenting the trade-offs, it describes different service and module decomposition patterns, with pros and cons for each, without prescribing one.

Here is a blog post from Robert C. Martin about microservices and clean architecture: https://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicros...

Fundamentals of Software Architecture is reasonable.