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.
• Utiliser des technologies « plus rapides ».
• 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
La première force qui a conduit à l’essor des microservices a été une réaction contre l’architecture monolithique normale. Alors qu'une application monolithique constitue un seul grand programme doté de nombreuses responsabilités, les applications basées sur des microservices sont composées de programmes plus petits, chacun ayant une seule responsabilité. Cela permet aux équipes de développeurs de travailler indépendamment sur différents services. Le découplage inhérent encourage également des programmes plus petits et plus simples, plus faciles à comprendre, afin que les nouveaux développeurs puissent commencer à contribuer plus rapidement. Enfin, comme aucun programme ne représente à lui seul l’ensemble de l’application, les services peuvent changer de direction sans coûts énormes. Si une nouvelle technologie plus pertinente pour un service particulier devient disponible, il est possible de réécrire uniquement ce service. De même, étant donné que les microservices communiquent dans différents langages, une application peut être composée de plusieurs plates-formes différentes – Ruby, Java, PHP, Node, Go, etc. sans aucun problème.

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.