Create Macro Services

Goal: as the development team grows it is important to break the codebase into functional macro services (subsystems) to retain (or regain!) an efficient product development process.

The reason to split a large monolithic application into smaller functional macro services should not be to chase the latest fad or hype (micro services, any one?), or to achieve a nicer architecture, or to make it more scalable (although this may be a nice side effect).

Instead, the reason should be to make the development process easier to manage.

Example:

In the example above a monolith (of some company) has been split into a core application and four macro services. Each of the four macro services used to be part of the monolith.

Immediate benefits:

• A team of just 3 developers can become responsible for a complete macro service. They know all the ins and outs.
• The squad becomes responsible for the architecture, development, documentation, testing, monitoring, backlog, and deployment.
• Developers are forced to think in terms of internal APIs and loosely coupled systems which tend to improve architectures and developer efficiency.
• Small macro services are easier to understand, easier to test, and easier to refactor than large codebases.
• If a macro service is made more generic over time then you’ll even be able to make its services available to other “consumers” (read: core applications) in your company. This can reduce code, complexity and costs.
• Weak architectural spots, underperforming team members, and high defect ratios are easier to detect in smaller systems.
• The mission of each macro service is easier to define e.g. “the on-boarding & contract signing macro service must reduce the time it takes to let a new customer use the system from 5 days to 1 day”. Compare this to the mission description of the monolith.
• Generally speaking developers like to work on specialized, nimble, well-defined, properly maintained, and well-documented software. Macro services make this possible.
• It becomes easier for product owners to keep a whole subsystem in their head in terms of features and roadmap. Same for developers in terms of knowing the complete codebase by heart.
• Kanban boards, planning sheets, or whatever you use to manage your roadmap and planning becomes smaller in the number of backlog items, outstanding bugs, etc.
• Fewer meetings are necessary because the developers working on macro service A do not have to interact with the ones working on macro service B, at least not on a daily basis.