Why Microservices are more complex than you think ?

Microservices are a distributed system architecture, and they have lots of problems associated with them. Nowadays, more and more companies claim they are using microservices, whereas the reality is quite different from what they claim.

The defining characteristics of microservices are

1. They are small.
2. Focused on One Task
3. Aligned with a bound context
4. Autonomous
5. Independently deployable
6. Losely coupled

They are small.

Early pioneers of microservices used to respond to the question by saying that

An ideal microservice fits inside James Lewis' head.
James Lewis was the one who popularised the idea of microservices. The rationale behind that was to compartmentalise a problem.

How to measure if the given microservice is actually micro

If you can recode the microservice in a week or two, I think you are on the right path. That's one of the ways to measure if you are on the right scale.

Focused on One Task

To segregate a monolithic architecture, we must first determine which sub-problems our microservices should be divided into.Each microservice aims to achieve one task when viewed from the outside.

Aligned with a bounded context

This idea comes from the book Domain-Driven Design, written by Eric Evans. As per Eric, "bounded context" can be defined as

A defined part of software where particular terms, definitions, and rules apply in a consistent way.

This means that if we fail to segregate our services well, breaking our application into microservices could actually backfire as it will make services tightly coupled.

Autonomy

The team handling each microservice should be autonomous in changing the implementation. The true value of microservices is that the autonomy and lack of coordination they provide enable organisations to scale quickly.

Deployable on its own

Since microservices give the team options to deploy without being constrained by other teams, it makes their progress more significant.

Now the problem arises: if you always test your service with others before release, it is not independently deployable.

The real value that microservices bring to the table is that they can be built, tested, and deployed independently.

So, in short, one can say,

Microservices are an organization's decoupling strategy.

Losely Coupled

The interface to a microservice is a public API. Therefore, it should be changed with great care. If you keep changing the API too often, this defeats the whole purpose of the microservices architecture. Also, when consuming an API, use the minimum data that you can to reduce coupling.