In the recent years microservice architectures have seen some hype in the software industry.

As always with hypes, engineers should ask themselves what is behind certain buzzwords and whether implementing them makes sense. It's always advisable to look into new technology and methodologies. It's not necessarily advisable to apply them immediately.

The reasons for using microservices are the same as for using distributed systems in general. There are technical reasons, such as applications that need independent deployment life cycles.

There are also reasons that are driven by the business requirements and situations in teams and project working modes.

Scalability is an often-cited motivation behind microservice architectures. As we have seen in event-driven architectures, monolithic applications aren't able so scale infinitely. The question is whether scalability is effectively an issue.

There are big companies that handle business logic for huge amounts of users using monolithic applications. Before considering distribution as a relief for scaling issues, performance insights and statistics should be gathered.

Engineers should avoid to use microservice architectures solely because of believing in a silver bullet approach. It can easily happen as a result of buzzword-driven meetings and conversations, that solutions are chosen based on limited or no evidence supporting the requirement. Microservices certainly provide benefits, but also come with a price in time and effort. In any way, the requirements and motivations whether to split up responsibilities into multiple applications should be clear.