We use microservices at my workplace with a team of 5 and have since the beginning. From reading HN it seems like we may be the only small team to have benefitted from the approach?<p>Some advantages that this article seems to ignore:<p>- Even with a small team, microservices allow us to make small iterative changes to services without touching other parts that are working as they should be.<p>- It&#x27;s easier to find and patch bugs when they can be pinned down to a smaller codebase and fixed in isolation (most can be).<p>- Local development becomes easier - you can spin up just the services you need for the feature you&#x27;re developing instead of the entire system.<p>- It&#x27;s easier to get &quot;up to speed&quot; when you need to add a feature when you&#x27;re working with small codebases (and often only need to touch one or two at a time).<p>- In our case we have three distinct sets of consumers: two fairly separate groups of end-users, and automated services (m2m). It&#x27;s quite common for any issues we have to only affect one of those three sets of groups because they are largely isolated in different services.<p>That&#x27;s not to say there haven&#x27;t been some headaches, but I personally much prefer our service approach to a monolith. I really think the key is removing operational friction of working with services with tooling.