Why Not Microservices?

Introduction

Many organizations and teams may see microservices as the best approach to a determined problem. This post covers 5 basic concepts to think about when implementing this type of architecture. The idea is to revise some concepts that will help you question the need for this approach.

1. Communication Services

Microservices are services that attend a certain domain and are released independently. These services could then be exposed to other services through API's, Service Brokers, or other communication services.

Figure 1 - Microservices through API's

2. Independent Deployability

Many consider independent deployability the most important piece to microservices. Applying this concept is necessary to validate that applications are loosely coupled. To certify this, one should be able to make changes to a specific microservice without having to change other services.

Figure 2 - Releases

3. Databases Sharing

It is highly recommended that each microservice contains its own database. When we think of a microservice as a unique piece of software it should have independence in all levels and that includes the database. When one or more microservice share the same database one can easily fall into the assumption of shared deployment or accessing the same data between these services.

Figure 3 - Databases

4. Business Domain

With a microservice approach each microservice needs to be independent and organized. To effectively allow for independence, design techniques are commonly used like layered architecture, clean architecture, domain-driven design(DDD), etc. These approaches allows for teams to structure the code with independent contextualization efficiently.

Figure 4 - Business Domain

5. Client Communication

With the growth of business and processes within an organization the tendency is that the number of services will also grow. However the consumers of these microservices needs to be able to effectively communicate or call the microservice for the desired job. There are a couple of strategies to solve this issue. Having an API gateway is a strategy to expose, version and evolve microservices effectively.

Figure 5 - API Gateway

Conclusion

This post contains only the tip of the iceberg when it come to microservices. To develop this type of solution more situations needs to be considered like the teams experience, deployment automation, cloud computing, security, scalability, testing, resilience, observability, organization alignment, etc.

The increase in complexity and team experience when creating microservices are many times why these projects tend to fail. It is common to have less experience or reduced teams working on software projects, with the mindset of a microservice architecture.

Microservices are effective when used, planned, and executed in appropriate scenarios, but I always tend to ask myself why not microservices?

References

1. Building Microservices: Designing Fine-Grained Systems