5 Things you should avoid while doing Microservices

Photo by andrew jay on Unsplash

Microservice architecture is currently the talk of the town.

All companies want to replace their applications with microserives and move to the cloud.

They hope for less downtime, better scalability, faster deployment, better testability and much more.

But all these benefits are useless if developers are frustrated and development is hindered by architectural flaws. So here are five bugs that can and should be avoided when you doing Microservices.

Photo by Jan Antonin Kolar on Unsplash

Each microservice is responsible for its own data storage. For each service you have to think about how to hold, persist and provide data.

If different Microservices access the same database, they depend on each other and are no longer independent services. If one service needs a new field or change some data, the other is influenced by it. An independent deployment can no longer take place. They are therefore no longer independent.

Furthermore, it can make sense for one service to use a MySQL database, for example, while another service prefers to use a MongoDB.

To avoid conflicts, each service should use its own database and not have to use it with other parts.

Photo by Iñaki del Olmo on Unsplash

Some services believe they can make client libraries available to others, to do their work and make changes themselves. It doesn’t.

Do not do the work for others and make libraries available to them.

This does more work for everyone than it helps.

First, you have to make this library available in all possible languages (if there is only one, you have the next mistake).

Second, you now have the changes in your hands. There you’re making two more mistakes. You’re forcing the other clients to always update so that they can continue to access your service, and you’re no longer adhering to the REST interface agreements.

It’s relatively easy to change your interface, touch your library, and make everyone else responsible for their services not working, because you’ve released a new library.

Better agree on proper interfaces and stick to it. Stick to your guidelines. Extending REST is usually quite easy, removing some fields should be announced long in advance and you should be sure that no service needs the data anymore.

A change to your service should not break any other.

If you put too much into a service or bounded context, you have many fat clients communicating with each other.

But you want Microservices.

This doesn’t mean that you have to build a separate service for each function, but think carefully about what belongs in a service and what might be better packed into your own new service.

What belongs together and what should be separated.

If you have too much in one service, it will be difficult later to scale the services that are slow horizontally and you have to scale them vertically with more hardware on one server.

If you tell your developers which technology stack to use, you have totally missed the idea of Microservices.

Fearing that the service will later no longer be maintained to deselect a language, the wrong one is gone. There will always be someone who wants to develop the service further or replace it with another language.

You will miss the advantages of the different languages. It may be that for one task Kotlin is great and for the next Python or JavaScript. But this decision should be left to the team.

The team responsible for the service has to agree on the language and then go through it.

And usually not everyone from the same team goes at once. So there are always developers who can continue the language or instruct others.

We already had the topic with client libraries. But only because your services communicate via REST they are not all Microservices.

However, the services should communicate via REST. Here you can use all advantages and should not only communicate via GET. Data can be transferred with POST and deleted with DELETE.

Here one should agree clearly on interfaces and adhere to these. Also within the teams.

If a team manages several services, these should treat the services as if different teams were doing it.

So just because you have access to the code of both services doesn’t mean you can wildly change the interfaces as you like. Because others may also communicate with the service.

Conclusion

This was only a small insight into the many errors one should consider when creating Microservices. That shouldn’t stop you from working with Microservices.

Microservices are a great thing and can take a lot of work and improve your operation. Just stick to a few guidelines and you’ll see. It’s not that hard.

Thanks for reading. If you liked it, leave me applause or comment here for further questions.

☕️ →👨‍💻 // Developer @ SAP