Microservices, or How I Learned To Stop Making Monoliths and Love Conway’s Law

By Cliff Moon on 08 27 2014

After reading this post I can’t help but feel that the author has missed the point of having a microservices architecture (he misses other things as well, particularly the fact that there’s a lot more folks out there writing software than just neckbeards and hipsters). Especially considering the suggestion of service objects as a way to implement microservices. Most importantly, the reason to prefer a microservice based architecture is not for encapsulation, data locality, or rigid interfaces. Microservice architectures are embraced because of Conway’s law.

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

—M. Conway

An important corollary of Conway’s law, in my experience, has been that teams will tend to scale about as well as the software that they create. Teams working on a monolithic codebase will inevitably begin stepping on each other’s toes, which requires more rigid software engineering processes, specialized roles such as build and release engineering, and ultimately a steep decline in the incremental productivity of each new engineer added to the team.

The OP claims not to know of a good definition for microservices. I’d like to propose one: a microservice is any isolated network service that will only perform operations on a single type of resource. So if you have the concept of a User in your service domain, there ought to be a User microservice that can perform any of the operations required to deal with a user: new signups, password resets, etc.

This definition jibes well with Conway’s law and the real reasons why microservices are good. By limiting services to operating on a single type of resource we tend to minimize the interaction with other components, which might be under parallel development or not even implemented yet. Every dependency must be carefully considered because it adds overhead for the implementor, not just in code but in communications. Indeed a microservice architecture resembles what your team actually is: a distributed system composed of mostly independent individuals.

And to the claim that microservices introduce a distributed system into what was once a non-distributed environment, all I can say is this: anyone building software delivered via the web who doesn’t think they are working on a distributed system fundamentally misapprehends the nature of what they’re doing. We’re all distributed systems developers now, whether we realize it or not.