The Majestic Monolith
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'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're developing instead of the entire system.<p>- It's easier to get "up to speed" when you need to add a feature when you'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'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's not to say there haven'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.