As a business gets bigger, they require more functionalities and thus you can’t help but add new models/controller to the existing Rails application and sometimes it becomes a monolith. If you are facing a monolith application which has become unmaintainable and difficult to deploy, you need to know some ways to manage it. If your team has to go through thousands of lines in order to understand the project and to make some changes, it is time to split them.
When to split application
- When your tests run for more than 20 minutes.
- Models grown to several hundred or thousands.
- Independent functionality.
- When developers cannot work independently to develop/deploy their own modules.
Different ways to split Monolithic application
- Using microservices.
- Using ‘faster’ technologies.
- Add a bunch of servers.
What is microservice Microservices is a strategical way for decomposing a large project into smaller, more manageable pieces. A microservice is a piece of application functionality re-factored out into its own code base, speaking to other microservices over a standard protocol. To accomplish this, first divide your business requirements into related groups like user management logic, advertising logic, and a web user interface.
The first force that led to the surge in microservices was a reaction against normal monolithic architecture. While a monolithic app is One Big Program with many responsibilities, microservice-based applications are composed of smaller programs, each with a single responsibility. This allows teams of devs to work independently on different services. The inherent decoupling also encourages smaller, simpler programs that are easier to understand, so new devs can start contributing more quickly. Finally, since no single program represents the whole of application, services can change direction without massive costs. If new technology becomes available that makes more sense for a particular service, it’s feasible to rewrite just that service. Similarly, since microservices communicate across a different languages, an application can be composed of several different platforms – Ruby, Java, PHP, Node, Go, etc without any issue.
- Modules can be reused.
- Deployment goes smoothly independent of whole big application.
- Easy to add features.
- Reduces testing time to test one module instead of all.
- Big applications tend to be harder to maintain that the small ones.
- Having set of small applications allows us to focus on working on isolated parts.
- We might have more chance of not breaking other parts of the application.
- Reliability and fault tolerance.
- Easy to migrate or upgrade.
- Technology diversity.
- If any single application function is not working entire application doesn’t goes down.
- Makes it easier for a new developer to understand the functionality of a service.
Because everything is now an independent service, you have to handle requests carefully travelling between your modules. There can be a scenario where any of services may not be responding.
Multiple databases and transaction management can be painful.
Productivity will be less till the microservice base is set.
Monolithic v/s Microservices
The below diagram shows the difference between traditional monolithic app and microservices in terms of human resource, time, maintenance and handling complexity of applications.