Microservices architecture is a new trend in software development. Its main approach is to separate all functional parts of application. And it has advantages and disadvantages that you should know about.
Let’s start from some history. Originally, applications were monolithic. It means that all parts of the system were included in one module. This approach has a bunch of weaknesses.
Now imagine that you split your core app (let it be an online shop) into several independent logical micro-applications. They are usually connected using REST-services. Now you have separated systems that are responsible only for one concrete functionality: products data (C), shopping cart (1), payments (2), logging (3), comments (4), content management (5).
Why do we need to split it? Let’s look at the benefits.
Microservices architecture benefits
- Select the perfect tool for each module. If your web parts are written in PHP and you know that payments module should be implemented in Scala – go ahead!
- Easy replacing. If you decided to switch the payments module, you can simply replace it with no need to stop the whole system.
- Fault tolerance. If your application has got a huge unexpected activity in your comments module, it will fail. But the whole system will not shutdown. Your clients will forgive you the absence of comments section.
- Performance tuning and monitoring. When your modules are independent it’s easy to track the loading for each of them. You can easily determine weak spots and prevent bottlenecks.
- Horizontal scalability. You can use specific environment for needs of each module.
- Development simplicity. Comprehensive project are not easy to develop. You will need a lot of people that will hardly know the whole structure of the project. It changes a lot when you have small teams for each functional module.
Microservices architecture disadvantages
- The “cost” of sending data between microservices.
- Administration is harder than with monolithic applications.
- Consistency issues could appear because of distributed model.
There are a lot of cases when monolith application fits greatly. Even if your business will grow up, you will be able to split some parts. And you will do it right in time when you need it.
As a conclusion – microservices are a good way to create a scalable and fault-tolerant app. But it’s not a cure. You should use it only if you expect the real need of its benefits. Otherwise you will have a lot of problems while implementing much more complicated system than your business needs. Don’t let the trends affect the architecture. It is a well-known situation when people create projects with microservices only because they think it’s cool.
Now you know some microservices architecture basics. If you want to go deeper there’s a great book for you – Building Microservices by Sam Newman.