The micro-services vs monoliths battle is heating up. The latest munition is Amazon Prime Video article Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%.

At Adobe Experience Manager Cloud Service we are running the whole range from tiny micro-services to big Java monoliths. So I’ll try to give you my personal balanced view on the topic.

Any reasonably sized product with a bit of history is going to have a mix of micro-services and monoliths. Micro-services are not about the code, but the organization. This is the most valuable selling point. You cannot have velocity when multiple teams and lots of people making decisions and synchronizing multiple codebases. So to move fast you need some micro-services (for some definition of “micro”).

On one hand we have monoliths that are easier to understand or follow as everything is in the same place, contributed to by multiple teams. They require synchronization and locking around code, releases, tests, etc as multiple teams need to be involved. As time passes these monoliths can grow increasing the synchronization issues. But they are fast and efficient as all the calls between modules happen in-process and the overhead is minimal as much functionality is put together.

On the other hand we have micro-services that are harder to grasp as there are calls between multiple of them that are typically spread out across multiple git repos. The spreading of compute causes more inefficiencies, network latencies, more overhead as common functionality is duplicated in each micro-service, etc. But the responsibility is clearly delimited through APIs and interfaces that makes it easier to understand who is responsible and identify where problems are.

There is a lot of talk about teams owning one service, but I don’t think this is realistic. As time goes by services are developed and then move into more of a maintenance role that requires less engineering time and the team moves own to create other services that provide value. So any team will own multiple services, as (if) functionality grows.

For our teams splitting the monolith brings several benefits that steam from two: full ownership and faster iterations

• the service is owned by a team
• independent testing and release cycles mean faster time to market
• pick the right tool/language for the job (or the prefered one by the team, not necessarily the best 😉 )

Some problems I have seen:

• knowledge is limited to the owner team, there is no motivation for other teams to understand a service
• duplication of efforts, multiple teams doing the same things (release management, logging, monitoring, etc). This is where Platform teams and Developer eXperience are supposed to jump in to make things easier
• duplication of infrastructure and tooling around it. For example each micro-service should have their own image registry, databases, etc
• interactions between services are in a bit of a limbo