Micro And Macro Software Architectures, Why You Need Both

Micro And Macro Software Architectures, Why You Need Both

While it's not a new concept in the broader software development industry, I feel that the topic of micro and macro software architectures doesn't get enough attention in the software developer community. In my opinion, both have their pros and cons. Let's have a closer look!

The need for micro and macro architecture

As software companies grow, senior engineers want to ensure that overall the system is decoupled, services can individually scale as needed, and work together to form the overall system. All this, while giving engineers the freedom to be creative and innovate in their roles.

In order to maintain this balance between standards and rules while giving them room to innovate, software companies should clearly document their micro and macro architecture decisions.

What is macro architecture?

Marco architecture refers to overarching architecture decisions for all software produced by the company. If a company chooses a single programming language as a macro architecture decision, this can slow down growth, and really block engineers from choosing the best technology for the job. Such decisions usually lead companies to be stale and lose their competitive edge. Such decisions also affect hiring.

A good example of a macro architecture may be the technologies for the data lake, logging infrastructure, authentication and authorization mechanisms, etc. Such decisions will allow companies to reduce redundant work, make sure the overall system can work together, and conform to any compliance issues.

What is micro architecture?

The micro architecture is the set of decisions that can be made individually for each microservice. These are typically technical decisions (made by the team) like language and framework, but could also include things like database choice or message bus if they are not part of the macro architecture already.

How does this help?

Let's say your company's software uses micro-frontends. The decisions for integration and security may have been taken at the macro level, but by using micro frontends, each individual team can build their applications independently, with their choice of technologies and expertise! They can choose to deploy in the manner they prefer, their own git branching and releasing strategy, without affecting the bigger application as a whole.

There is much to consider in the process of choosing macro and micro architectures for your company. Keep in mind, however, that not every decision will have a perfect solution. Sometimes you may have to pick the "least bad" option and know that you'll likely have to revisit it in the future. Regardless, it should be a discussion with your entire team from the very beginning so that no one feels like they're left out of the process. When it all comes down to it, as long as everyone is on board with the decisions being made, there are no wrong answers. Try your best to make two-way decisions and fail fast.

Thanks for reading

Subscribe and follow me on Twitter