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

Posted by on August 27th, 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.

  1. I think that you and Stuccio are talking past each other here.

    When he says that there are issues with the definition of microservices, he’s 100% right. What you describe and, say, what Fred George describes in his talks are quite different, so we have a problem of definitions. What you describe does not cause harm: It looks a whole lot like SOA from a decade ago. Things like expecting services to be 100 lines or less, and creating tiny, badly modeled concepts so that everything fits in tiny pieces of code that we do not edit, but just completely rewrite instead, are what sound bananas, and what cause headaches in the field.

    So what his argument is really about is not about having one big monolith, but about saying that the major dangers to excessive modularization get far worse when the little modules also come attached to large network penalties.

    We are all distributed developers, to a point, but the more you distribute, the more lag and error handling you force upon yourself, the worse it gets. There are tradeoffs to consider, and depending on where you look on the Microservices proponents, it sure seems that people want to forget the tradeoffs.

    Also, take into account that not wanting to have 1000 little services does not mean that one prefers a true monolith. There’s plenty of space in the middle, where most applications actually are. Painting things as if not using microservices will lead you to need a build team, and developers running all over each other, does not strengthen your argument, as you are just beating on a strawman.

    And besides, I have seen developers having trouble breaking each other’s code in a microservices architecture. Just change your definition of what one of the resources means. Interface changes cause trouble no matter what architecture you use.

    So it sure seems to me that the conversation on microservices would be far more civil, and far more productive, if instead of it being lead by people promoting their brand on talks and books, it was really about practical experiences and design tradeoffs. It’s really what those people spout that really causes the backlash, not some sensible modularization that just happens to involve independently deployable services.

    Comment by hibikir on August 27, 2014 at 8:56 am

  2. “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….”

    Indeed, Allan Kelly talks about the homomorphic (structure-preserving) force between a system design and its parent org. Check out this excellent presentation on the topic:

    Conway’s Law and Organizational Change

    Comment by 4johnny on August 31, 2014 at 8:36 pm

  3. I don’t disagree with anything you’re saying, but I wanted to ass that the main promise of a Service-Oriented Architecture is, well, the promise. The promise that the API will remain the same. Which simplifies reasoning about the system as a whole and therefore makes it more stable and scalable, simplifies maintenance, reduces the number defects, and so on and so forth. Simpler is better than more complex. So, of course there is a sweet spot for the size and number of services. I mean, you obviously wouldn’t put every single function in its own service. But we’ll have to build a proper mathematical model to have any reasonable discussion about where that sweet spot is.

    Comment by George Sudarkoff on September 1, 2014 at 7:14 pm