2019-05-01 21:19 — By Erik van Eykelen

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.


Macro services

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.

Check out my product Operand, a collaborative tool for due diligences, audits, and assessments.