Give a Preference to Micro Architecture!

Macro architecture decisions: Best practices and advice #

• Specifying only a few points in the macro architecture helps with focusing. Many teams have failed when trying to implement a far-reaching unification in a complex project or IT landscape. If there are few macro architecture rules, the chances increase that the rules are actually successfully implemented.

• The rules should be minimal.

  • For example, a macro architecture rule can define the monitoring technology. However, it is not necessary to standardize how the metrics are measured in the application. After all, it is important only that the metrics are created. How this happens is irrelevant. The macro architecture rule should only define a protocol for transferring metrics but leave the selection of the library for creating and transferring metrics to the micro architecture. In this way, the teams can choose the most appropriate technologies.

• The macro architecture rules have to be consequently enforced. For example, when the metrics are not generated, the operations team cannot simply bring the microservice into production. It is important to get rid of all unnecessary macro architecture elements.

• In addition, independence is an important goal of microservices. Too many macro architecture rules run counter to this goal as they hinder the independence of the teams through central control.

• Complying with macro architecture should be in the self-interest of the teams responsible for the microservices. Violations of macro architecture usually mean that microservices cannot go into production because operations cannot support them.