Category: Architecture

Microservice architecture is good in forcing the implementation to have clear interfaces and clear responsibilities. Extending the system is straightforward and interruption less. The system is easy to make scalable and highly available. Updating a service can be done independently and in ways that has no impact on the rest of the system.

But microservice architecture has its downsides as well. It requires more resources than a monolith would; segregating services means duplication. For the system to operate a service will interact with other services. This means that there are dependencies between the services, but their lives are different. This is a non-trivial problem to manage.

A system with microservice architecture is also slower than a monolith, as the interaction between services is done through non-ideal channels.

The system may end up being like a puzzle where the pieces keep changing. The complexity of the system becomes overwhelming which will make operating and developing the system very hard.

One of the fundamental architectural decision when designing software is to decide how the software is delivered. Is it delivered in a single, complete, self-sufficient package or will it be delivered in multiple small packages that are independent but interacting with each other.

This is the decision between monolithic and microservice architecture. Both of the options have good and bad sides, and whatever fits some software may not be reasonable for another. The decision, which one is better for a particular software, may be non-trivial.

If it is too hard to decide or being pragmatic outweighs being dogmatic you may end up with a modular monolith, or modulith, architecture that is in between the two extremes mentioned.

Whatever you decide can be adapted later on. However, like with most architectural decisions, adjusting the existing implementation to match changes in the architecture may be too expensive task to do.

Architecture. An important, although confusing and vague, but still commonly used, term in software.

architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.¹

Every software has an architecture, whether it’s well thought or not, well defined or not, or well respected or not.

A good architecture is a great tool for the team(s) to consume to work towards a common goal, but it may or may not correlate with the end result.

And when things go south in a project, you can always crucify the architecture to settle the sins of all the rest in the project.

1. IEEE 1471 (2000 – the good old days) ↩︎