Characteristics of microservices

Introduction

The microservices architecture can be an excellent approach for many companies developing software, but it can be very bad for others. The only way to decide whether or not this is the proper approach is to know the different characteristics the microservices have. Let's see them.

Multiple programming languages

As long as you are using HTTP calls or messaging to communicate your microservices, both of them agnostic to the programming language, you can use whichever language you want for each of them. But it is clearly a characteristic of the microservices that you won't find in a monolith, where all the monolith needs to be in the same language.

Many companies these days are willing for this characteristic, as it allows them not only to choose the best language for each use case but also to hire more people faster as they are not restricted to a given stack. But this is not convenient for all situations.

Independent deployability

This is not a characteristic that comes for free in a microservices architecture, but something you need to pursue. If you have several microservices, you should be able to deploy them one by one, without actual dependencies between them. If you aren't, then you'll have a distributed monolith, and all the advantages of organizational flexibility, simpler testability, and the kind will be lost.

When you can't deploy microservices independently from each other, then you have to coordinate deployments between maybe different teams, usually at night to avoid many users. This is not flexible not resilient. It's a nightmare for the developers.

Use proper contracts and versioning to avoid this.

Simpler testability

This is actually a characteristic of little components in general -you also may think that this is a characteristic of the Single Responsibility Principle. The little the component, the easy to test. You don't have that many dependencies, and tests run also faster.

How about the proper size of a microservice? You can read my article on this.

WARNING: Testing each microservice is easy, as I said. Testing the whole microservices architecture integration is not. But you should avoid most of the issues if you maintain the level of dependencies as low as possible.

Composability

Also a characteristic of little components and SRP; the little the components, the easy to compose big systems from them. It also helps to achieve the computer science maximum "low coupling, high cohesion".

If you create microservices, you can use these microservices for many projects, as long as these projects have the same requirements; you could even sell those microservices to other companies with the same set of requirements. Reusing a full monolith is very hard.

Organizational flexibility

When you have a big monolith, assigning responsibilities to developers or teams is very hard, as the dependencies use to be very tight.

On the other side, if you have a microservices architecture, assigning a microservice to a given team is quite easy. If you have ten microservices and ten squads, things are easy to organize.

Comprehensibility

The simpler the system, the simpler to understand. So, by definition, reasoning about a microservice is easier than reasoning about a full, big monolith. And if you have different people assigned to different microservices, you don't even need to have people with knowledge about all the microservices, so the amount of knowledge a developer needs -and the onboarding time- is lower.

Replaceability

If easier to replace a piece of a puzzle than the full canvas. So it's easier to replace a microservice with another -even an external provider service- than to replace a full monolith.

And it's also easier to add a new microservice to a microservices architecture than to add new features to a big monolith.

Scalability

When you have a monolith, you need the full monolith to be deployed to a given machine, so with the resources, you are playing a game of all or nothing: every resource to provide is for the whole monolith, always.

With microservices, you can allow more resources for those microservices that have more usage or that have more complex functionality in terms of performance, and less for those that are simple or rarely used.

Conclusion

Take a look at the characteristics of microservices to decide based on facts rather than feelings.