Séparation de l'application Rails monolithiques en microservices

À mesure qu'une entreprise grandit, elle a besoin de plus de fonctionnalités et vous ne pouvez donc pas vous empêcher d'ajouter de nouveaux modèles/contrôleurs à l'application Rails existante et celle-ci devient parfois un monolithe. Si vous êtes confronté à une application monolithique devenue impossible à maintenir et difficile à déployer, vous devez connaître quelques moyens de la gérer. Si votre équipe doit parcourir des milliers de lignes pour comprendre le projet et apporter des modifications, il est temps de les diviser.

Quand diviser la demande

• Lorsque vos tests durent plus de 20 minutes.
• Modèles portés à plusieurs centaines ou milliers.
• Fonctionnalité indépendante.
• Lorsque les développeurs ne peuvent pas travailler de manière indépendante pour développer/déployer leurs propres modules.

Différentes façons de diviser une application monolithique

• Utiliser des microservices.
• Using ‘faster’ technologies.
• Ajoutez un tas de serveurs.

Qu'est-ce qu'un microservice                                                                                                                                           Les microservices constituent un moyen stratégique de décomposer un grand projet en éléments plus petits et plus faciles à gérer. Un microservice est une fonctionnalité d'application remaniée dans sa propre base de code, communiquant avec d'autres microservices via un protocole standard. Pour ce faire, divisez d'abord les besoins de votre entreprise en groupes connexes, tels que la logique de gestion des utilisateurs, la logique publicitaire et une interface utilisateur Web.

Pourquoi un 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.

Avantages

• Les modules peuvent être réutilisés.
• Le déploiement se déroule sans problème, indépendamment de l'ensemble de la grande application.
• Facile à ajouter des fonctionnalités.
• Réduit le temps de test pour tester un module au lieu de tous.
• Les grandes applications ont tendance à être plus difficiles à maintenir que les petites.
• Avoir un ensemble de petites applications nous permet de nous concentrer sur le travail sur des pièces isolées.
• Nous pourrions avoir plus de chances de ne pas casser d'autres parties de l'application.
• Fiabilité et tolérance aux pannes.
• Facile à migrer ou à mettre à niveau.
• Diversité technologique.
• Si une seule fonction de l'application ne fonctionne pas, l'application entière ne s'arrête pas.
• Permet à un nouveau développeur de comprendre plus facilement les fonctionnalités d'un service.

Désavantages
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.

Monolithique vs Microservices
Le diagramme ci-dessous montre la différence entre les applications monolithiques traditionnelles et les microservices en termes de ressources humaines, de temps, de maintenance et de complexité de gestion des applications.

Comment configurer des microservices
La manière stratégique de réduire l'application monolithique consiste à diviser les couches telles que les couches de présentation, de logique métier et d'accès aux données. Une application d'entreprise typique se compose d'au moins trois types de composants différents :

• 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.
• Couche de logique métier – Composants qui constituent le cœur de l'application où les règles métier sont implémentées.
• Couche d'accès aux données – Composants ayant accès aux composants d'infrastructure tels que les bases de données et les courtiers de messages.

RailsCarma a mis en œuvre des applications Ruby on Rails dès ses débuts pour le développement, la formation, le déploiement et la contribution à la communauté Rails. Grâce à une expertise technique fiable et à un service client exceptionnel combinés pour offrir une expérience agréable aux clients, RailsCarma fournit des solutions de bout en bout. Développement Ruby on Rails,conseil, architecture, gestion et extension aux entreprises du monde entier. Contactez-nous pour en savoir plus.