Micro services and Conway’s law

Conway’s law from wikipedia tells this

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.[2][3]

— Melvin E. Conway

Micro services as an architecture reflects this truly.

As is, it is very hard to debug a single function. If your monolith code is nested and twisted, you will find it a lot harder to debug. Imagine now if your logic is scattered across a hundred pods and you need to go and trace a single request across one or more of them every time to find what went wrong. And you have to repeat this a hundred times every couple of days?

Now I realize this is possible only because of Conway’s law.

If you have a fifty member team, you can pretty much maintain hundred micro services with each person fielding two of them, at least until some of them stabilize.

While I am running tests on my logic, I can assume the rest are all reachable through some automatic configuration that is pretty much handled during my build. If something goes wrong in other micro services, I get an exception, I file a bug in a common bug tracking system and the person responsible for the micro service that threw the exception can go fix that and update the status and I can retest my flow.

This is more of a “distributed process” than an architecture. The software is distributed across people of the organization as micro services with tools and framework to support the communication between them.

You can increase the number of micro services as long as the number of micro services per person is kept under a reasonable limit. If this is breached, you will find that it turns chaotic.

That’s why this model will bring great pressure if used in small teams as each person will now be responsible for more that just makes it very hard in terms of communication, as each person has to don multiple hats.

But though we are able to organize the software to mirror the process or the workflow using micro services, it still requires some thought before applying the knife. When Object-oriented programming was in vogue in the late nineties, everything was seen as an object. Even what should be classified as plain functions.

Likewise, when you dissect the workflow into micro services, there is a danger of losing abstraction ending up creating more and more. Unless all the time, someone out there with a broader view can watch over this mindless dissection, things will soon become unwieldy. This can be easily tested, when the communication between the people turns messy.

At the end of the day, no power on earth can prevent software from becoming a ball of mud. How gracefully you reach there is what we can do something about.