Why should you use microservices?

Original photo: https://unsplash.com/photos/RdGHGmUWslU

If you are a backend software developer, I’m pretty sure you heard the word microservice. You probably also heard the word monolith, which is used in contrast. So, when should you use microservices? I’m going to provide several reasons for it.

First, let’s make a definition of the microservice. Microservices are independent software components that could work together to provide required functionality. In this context the word independent means services communicate to each other by API or middleware, e.g. like queues and topics (see Kafka). They don’t share data with each other: every microservice has its own database or cache.

As for monolith, it has a lot of functionality in one big software (application). One microservice can be supported by only one team, in contrast, one monolith usually supported by several teams. That leads you to several reasons for using microservices.

Reason 1. Easier roll out.

In monolith a lot of teams could make changes in different places of source code so every new version could have several changes in different functionals. Therefore, when you roll out a new version, you could have side effects and break down the whole system. However, if you introduce one particular microservice, you can’t directly break down other microservices. Yes, there is probability that service could provide incorrect requests to other microservices, but it’s a different story. So, you could easily roll out a new version, and if there are any problems, you could easily roll it back.

Reason 2. Time to Market.

With microservice architecture, new features could be introduced more frequently than with monolith . From my personal experience when you have monolith, you have to provide release dates, and all teams should be ready for it. And there should be a release manager who is responsible for taking all features from all teams, discussing any probable side effects that may appear. However, with microservices you have much more freedom to release your new features on the date when you’re ready.

Reason 3. Responsibility.

With microservice architecture, it’s possible to split responsibilities between teams. One particular service should be owned only by one team. In monolith, it’s harder to split source code on independent teams. It’s possible by making submodules, but there is opportunity to make changes on other submodules. With microservice architecture, the support team could easily understand which team they should ask when there are problems with a particular service.

In conclusion.

So, should you always use microservices? The final answer to this question is more complex, as it depends on your case. If it’s painful to support a monolith, if every new release of monolith is a pain, then you should. But it requires additional support on infrastructure where your microservices should be situated. How to organise this infrastructure — the subject for the other articles. So, look at mentioned reasons, review the design of your system and make a coffee session for your colleges. What is “design with coffee” sessions and how to drive your teams by them — the theme of my next article. Happy coding!




🚀 Marvelous Senior Backend Software Developer 📚 Like to share my knowledge 🎤 Beginner Public Speaker 🏠💻 Live and work in London https://github.com/oleg-sta

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Perfachhi Product Update — April 2020

How to Set Up a CI/CD Pipeline for AWS Lambda With GitHub Actions and Serverless

Is There Any Way To Convert Documents To Speech?

Why You Should Take On The Fintech Sector And Use A Forex API

Oceanbolt Python SDK Lesson 1 — Fleet Utilization

Oceanbolt Python SDK

Force redirect Http to Https to secure NGINX Web Server

Lora Soil Moisture Sensor V3 — What Upgraded?

Announcing the Conclusion of the Closed Alpha Mainnet

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Oleg Stadnichenko

Oleg Stadnichenko

🚀 Marvelous Senior Backend Software Developer 📚 Like to share my knowledge 🎤 Beginner Public Speaker 🏠💻 Live and work in London https://github.com/oleg-sta

More from Medium

How to Create a REST API — Spring Boot and Ballerina

Communication Best Practices — Giving and Receiving Feedback

Splitting monolithic systems into microservices

Microservices #Circuit Breaker