One of the core themes of the Microservice Architecture book my co-authors and I published with O’Reilly recently is: “Speed and Safety at Scale”. Whether you work in a large enterprise or are trying to grow a tiny startup, speed to market is equally crucial. We all operate in a global, highly competitive, digital market and race to success is fierce for organizations of all sizes.

Where things get complicated is in realization that, while important, speed is rarely the only business goal. For most businesses safety of making changes is equally paramount – sometimes even enforced by governments, e.g. in regulated industries such as: healthcare or finance. Unfortunately, speed and safety are in natural opposition - faster we move higher the chances of something falling through the cracks. The conflict between speed and safety gets further exacerbated with scale. Scale brings need of coordination. Every time we need to coordinate an activity across multiple teams, no matter how small each team is (even one person ‘team’ counts) – we inherently slow down overall progress. An assembly line-style interlinked chain of activities can only progress as fast as its slowest link.

However, once we identify cost of coordination as the killer of our speed at scale, we can design our organizational culture such that the need for cross-team coordination be minimized. Microservice Architecture is a software architecture style and the corresponding organizational culture that do exactly that: prioritize minimization of required coordination.

While it is still rare for Coordination Elimination to be explicitly called-out as THE core value of Microservice Architecture, we can successfully argue that all of the often-cited benefits of Microservice Architecture are just derivatives of this core value:

1. Technology Heterogeneity – removes need to coordinate programming languages, frameworks, libraries and technology platforms across multiple teams.
2. Partitioned Scalability and Independent Deployments – basically remove the need to coordinate deployments and operation of various parts of the system across teams.
3. Composability and Replaceability remove the need to coordinate life-cycle management of parts of the larger system, across various teams.

Which brings us to the answer for the most confusing, and controversial, question in all of Microservice Architecture: ‘how “micro” (small) should a microservice be?’

The answer is obvious once we admit Microservice Architecture is all about avoiding need for coordination:

A microservice should be small and simple enough that anybody in the organization be able to modify or rewrite it in a trivial amount of time.

“Trivial amount of time” will vary depending on the context, from hours to days, but as a rule of thumb: it should not be longer than two weeks, at most.

If this notion makes sense to you, you may also be interested in watching my recent talk at RestFest, where I discussed cultural elements of Microservices and was unapologetic about calling Coordination “toxic”.