> The second issue with starting with microservices is that they only work well if you come up with good, stable boundaries between the services - which is essentially the task of drawing up the right set of BoundedContexts.
> The logical way is to design a monolith carefully, paying attention to modularity within the software, both at the API boundaries and how the data is stored. Do this well, and it's a relatively simple matter to make the shift to microservices.
This is the big take-away to me -- for a long while now I've seen this whole monoliths-vs-microservices debate as a red herring. Whether your conduit is functions in shared virtual address space, HTTP or a Kafka topic the real problem is designing the right contracts, protocols and interface boundaries. There's obviously an operational difference in latencies and deployment difficulty (i.e. deploying 5 separate apps versus 1) but deep down the architectural bits don't get any easier to do correctly, they just get easier to cover up (and don't sink your deployment/performance/etc) when you do them badly when there's less latency.
What we're witnessing is a dearth of architectural skill -- which isn't completely unreasonable because 99% of developers (no matter the inflated title you carry) are not geniuses. We have collectively stumbled upon decent guidelines/theories (single responsibility, etc), but just don't have the skill and/or discipline to make them work. This is like discovering how to build the next generation of bridge, but not being able to manage the resulting complexity.
I think the only way I can make the point stick is by building a bundle of libraries (ok, you could call it a framework) that takes away this distinction -- the perfect DDD library that just takes your logic (think free monads/effect systems in the haskell sense) and gives you everything else, including a way to bundle services together into the same "monolith" at deployment time. The biggest problem is that the only language I can think of which has the expressive power to pull this off and build bullet-proof codebases is Haskell. It'd be a hell of a yak shave and more recently I've committed to not spending all my time shaving yaks.
Another hot take if you liked the one above -- Domain Driven Design is the most useful design for modern software development. The gang of 4 book can be reduced to roughly a few pages of patterns (which you would have come across yourself, though you can argue not everyone would), and outside of that is basically a porn mag for Enterprise Java (tm) developers.