Microservices show tremendous promise in enabling agility and improving resiliency. But a blind rush into a microservices architecture can also create more problems than it solves, said in the article Determining when a microservice approach is not the best architecture. We will try to sum up when the necessity of a microservice approach appears.
When you’re about breaking up a large Rails application into multiple deployable units it may lead to a large overhead in ways they had not anticipated. Before doing it try to come up with appropriate strategy: what fits big business might not be good for small one.
And keep in mind that you can create a lot of small things but they are not necessarily small services.
For instance, starting application built on Ruby on Rails and consisted of three pages that connected to a back-end legacy system, you can pursue a microservices approach in creating a new feature to support a different workflow. In the example we found company built three microservices this way. But when it came time to implement a fourth service as a microservice, the architecture was creating new problems. They found the monolithic architecture was easier to change in different ways than microservices and had less operational complexity.
When we need microservices? They make some changes easier: feel free to adopt languages and leverage different data stores to get the best performance for a particular service.
But a monolithic architecture makes it easier to make global changes that would otherwise affect every microservice. For example,if you want to add usernames, while using microservices you have to adjust the code in all services you created. And sometimes the logic is a little different across the services.
Microservices make it easier to change one service without affecting others, but they make changes to the platform more difficult. And if you try and maintain a strong consistency between services, that will really frustrate you. Compare: with a monolithic application, developers only have to change the class name and API. With microservices, developers have to change the version number of the API and maintain multiple APIs for backward compatibility.
Another important thing – monoliths can reduce operational complexity.
What are the benefits of microservice approach?
- increased fault tolerance
- independent deployments and rollbacks
- forced modularity
- ability to leverage different technology stacks
They can make it easier to break a large organization into more efficient teams.
What about monoliths? The problem you might face is when a missing index or memory leak can bring down the whole app. This could be not a problem with microservices.
You to decide.
Read also Ruby on Rails Microservices article we published in our blog.