4 ms·

Good list! One addition? * start with a modular monolith

• perkovsky 5mo ago
  Yes. I’d add: design the module boundaries before splitting deployment. A modular monolith still forces you to name ownership, data boundaries and invariants, but without making every mistake a networking/ops problem.
• munk-a 5mo ago
  I don't want that to be limited to just architecture though - proper initial factoring of a software product is invaluable at the large and most microscopic level.
• rafael-lua 5mo ago
  This one has yet to enter my head. I read Martin Fowler's related article* a few times, and it is sound... But I still can't see microservices being so "complex" to be so avoided early on. Especially in 2026, with the level of IaC and pipelines we have. I might be naïve, but I just don't get it. (*) https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html
  • electrosphere 5mo ago
    It depends on your workload etc - but there are TONs of advantages for the monolith approach when you factor in dev environments, access to good data for testing/development, dependencies on components/libraries/services etc. Note: I'm saying microservices CAN be the right answer, just not always and we should over-engineering. sauce: I work as a product engineer where we use microservices extensively. I have also worked on monoliths. Preferred working on the monoliths overall I think.