As your application grows in size, its complexity increases exponentially. Syndicode has already published articles to help you understand the necessity of a microservice approach and how to build an on-demand app. Now we are here to explain why microservices are the proven solution for making your applications easier to understand and scale. Let’s discover how to split your Rails application using microservices.
We devote this material to the topic of how a Rails app can grow into a microservices architecture.
If you already have a monolith Rails application and understand the necessity of making it easy to scale, this article is just what you need. The icing on the cake is our additional set of reasons and requirements for a Ruby on Rails microservice application. Here we go!
Despite there are both pros and cons of the microservices approach (you can find it in our relative materials), if you are facing a monolith application which has become unmaintainable and difficult to deploy, it’s time to split it.
A microservices architecture decouples individual components of a service, basically, each component becomes an application of its own. All microservices are connected using defined APIs, making it possible to have autonomous teams work on individual pieces of the application, mostly without breaking each others functionality.
Netflix, for example, states that it uses about 700 microservices to provide their streaming service.
Reasons why to split
- When your tests run for more than 20 minutes
- Models grew to several hundred or thousands
- Independent functionality
- When developers cannot work independently to develop/deploy their own modules
Probably, there are more reasons but those we put here you can’t ignore.
Of course, instead of using microservices you can just add a bunch of servers or implement “faster” technologies. But consider this:
Why do we suggest split your application using microservices?
Microservice-based applications are composed of smaller programs, each with a single responsibility. This allows teams of developers to work independently on different services. The inherent decoupling also encourages smaller, simpler programs that are easier to understand, so new developers can start contributing quickly. Finally, since no single program represents the whole of application, services can change direction without massive costs. If the 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 different languages, an application can be composed of several different platforms. So, we consider microservices for the next reasons:
- Modules can be reused
- Deployment goes smoothly independent of the 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 an entire application doesn’t go down
- Makes it easier for a new developer to understand the functionality of a service
But you can experience all of these advantages only in case your monolith application meets the next requirements…
Requirements for RoR application you can split using microservices
1. Your monolith application should have a clean code
If you break a monolith up into microservices, the microservices will only be as good as the original monolith application. If the application is written poorly, the microservices will run on badly written code. That will make it difficult for the microservices to work together to create the desired outcome.
2. Your monolith application should be appropriate for dividing with well-defined boundaries
When you create microservices, you will have various components. You need each component to work unimpeded, without getting in the way of other components. You can accomplish that by creating well-defined boundaries for each of your microservices. Define each task and the jobs associated with that task in order to get the best results. Make sure you can split your app into independent parts.
3. Your application should have a backup
Whenever you run a microservice application, there is a chance that one or more of the components will go down, but the app as a whole will still be up. Losing some of the app’s functionality can create a serious problem for you.
You need to plan the issues with the system so you can minimize the downtime. This is possible by making the application aware of all of the components that are needed to run properly, and then have it shut down when something isn’t working. This strategy will allow you to fix the problem before people get shut down halfway through the application.
If your application meets these requirements, you can do the split.
How to split your Rails application using microservices
The monolithic application, typically, can be split into the layers of presentation, business logic, and data access layer. This is the minimum number of components an average 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.
We recommend you also read about Syndicode’s experience with implementing complex systems using microservices architecture. Contact us if you have any questions or need a help.
Don’t forget to subscribe to our weekly newsletter not to miss anything interesting!