Microservices are all the rage nowadays. So let’s strip the hype and figure out what this is actually about.

Microservices are about separating an application into different “services” that are maintained and deployed with low coordination. The main coordination issue is dealing with version upgrades in the API offered by the service.

The hype is about pushing those as a solution to high application complexity. Ahem.

Some guy also says that Monoliths are the future.

First, remember there are two kinds of complexity:

• Essential complexity comes from the problem you are solving.
• Incidental complexity comes from unnecessary complexity expression of the solution.

If microservices can help, it is only by reducing incidental complexity. This has been a subject of interest for the whole field of computer programming, since computers exist. The first software device to reduce incidental complexity was the function definition. Most of software craftsmanship aims at improving one’s ability to organize software to reduce incidental complexity.

What is actually being sold under the label microservices is actually three things bundled toghether:

• Separate source code repositories.
• Separate server processes.
• Separate application modules.

You can separate modules without separating processes. And you can separate processes without separating repositories.

But if you separate processes, you really should separate application modules. And if you separate repositories, you really should separate server processes. If you don’t you are in for a lot of pain and missed deadlines, because your have created incidental complexity.

So it seems to me microservices are really about separating one big application module into multiple source code repositories.

This is a great goal when the organisation is big enough that multiple, mostly separate, teams are working on the same module. Software and organisation structure should match (Conway’s Law). So, pretty please split this application in multiple repositories and let teams regain their collective grasp on the source code.

But if your application is maintained by a single cohesive team, you will have less incidental complexity by having a single repository. You can then separate functionality in server processes only as required by operational constraints. And you can organize your modules in the way that best reflect the understanding of the programmers.

Modularity is important to keep software understandable and modifiable. It is possible to have it within a single repository with good internal APIs. Within a single team, a shared understanding of the software and a code review process is enough to maintain module separation. Do not separate processes without an operational need, do not separate repositories without an organisational need. That would be adding incidental complexity, avoid it if you can.