Splitting Monolithic Rails Application to Microservices

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.

Why microservice
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.

Advantages

• 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.

Disadvantages
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.

How to set up microservices
Strategical how to shrink the monolithic application is to split the layers like presentation, business logic and data access layers. A typical enterprise application consists of at least three different types of components:

• Presentation layer – Components that handle HTTP requests and implement either a (REST) API or an
  HTML-based web UI. In an application that has a sophisticated user interface.
• Business logic layer – Components which are the core of the application where business rules are implemented.
• Data-access layer – Components having access to infrastructure components such as databases and message brokers.

RailsCarma has been implementing Ruby on Rails applications from its nascent stages for development, training, deploying and contributing back to the Rails Community. Through trusted technical expertise and consummate customer service combined to deliver a delightful experience for clients, RailsCarma provide end to end Ruby on Rails Development ,consulting, architecture, management and extension to companies around the globe. Contact us to know more.