Monolith Vs Microservices : Pourquoi Les Entreprises Font Des Allers-retours?

Les microservices ne sont plus une tendance, mais une architecture de pointe. En tant que l’un des premiers à adopter l’architecture, nous l’avons observée passer d’une tendance émergente à une approche de pointe dans le développement de logiciels. La liste des entreprises qui ont adopté les microservices s’allonge chaque année – Uber , Netflix , Payoneer sont parmi les plus importantes.

Pour autant, cela signifie-t-il qu’une approche monolithique n’est plus pertinente ? Définitivement non. C’est une architecture de développement par défaut, intuitive et facile à conceptualiser. Bien qu’on ne pense plus qu’elle convienne à tous les projets, l’architecture monolithique reste le meilleur choix pour de nombreux concepts.

Dans cet article, nous aborderons les principaux avantages de l’ architecture monolithique par rapport aux microservices , ainsi que leurs défis et cas d’utilisation respectifs.

Qu’est-ce qu’une architecture monolithique ?

Une architecture monolithique est une approche traditionnelle du développement logiciel. L’application se compose de trois couches principales : interface utilisateur, logique métier et accès aux données. Ces composants de l’application sont régis par la même hiérarchie, et non comme des services autonomes. La signification du monolithe se résume à avoir une seule base de code et une seule couche de données pour l’ensemble de l’application.

Interface utilisateur

Composant de l’architecture responsable de l’interface du logiciel, de ses interactions avec les utilisateurs et des fonctionnalités visibles. Il existe de nombreuses approches pour créer une interface utilisateur, mais la plus courante est Model-View-Controller .

Le modèle stocke les informations que l’interface utilisateur affichera. Model est responsable du stockage des données personnelles, des détails du compte et des paramètres des utilisateurs. Souvent, ces données sont stockées dans l’objet texte du champ pour un accès plus rapide, et non dans la base de données.

View est responsable de l’affichage des données du modèle. Il contrôle la position des données à l’écran, leur style et les interactions avec l’utilisateur. View rend les contrôles des utilisateurs, collecte les entrées des utilisateurs, réagit aux actions et produit la sortie. Il gère essentiellement les données du modèle.

Le contrôleur est chargé de réunir les deux composants. Il supervise l’action de la vue, envoie des demandes de mise à jour et gère le stockage des données. Si une information doit être transférée au modèle, c’est au contrôleur de s’en occuper.

Logique métier

Ce composant de l’architecture monolithique est responsable des interactions entre les objets métier et les méthodes dans lesquelles ils sont manipulés et mis à jour. La logique métier décrit la route pour accomplir des tâches utiles particulières.

La logique métier gère les objets métier réels – inventaires, prêts, comptes. La logique métier de l’application définit si la fonction est utile ou non. C’est une expression des objectifs commerciaux . Pour avoir une meilleure idée, regardons quelques exemples.

Un utilisateur devrait recevoir une notification après avoir terminé la commande ;
Tous les utilisateurs enregistrés sur le site Web doivent pouvoir accéder à une version de démonstration du service.
Les transactions financières sont traitées avec une commission particulière.
Les utilisateurs doivent valider leur inscription par e-mail.

Ces spécifications représentent la logique métier car elles relient les spécifications techniques à des objectifs commerciaux et financiers tangibles.

Couche de données

La couche de données définit les règles et les méthodes utilisées pour stocker, récupérer, traiter et transférer les données. Il comprend une base de données et un système de gestion de base de données. Ce composant d’une architecture monolithique est conçu pour fournir des informations à tous les autres composants.

Qu’est-ce qu’une couche de données monolithique ? Il décrit l’opération de traitement, les critères d’utilisation des données, leur état et leur sécurité. Ce composant doit fonctionner de manière stable et sécurisée. Les problèmes liés à l’architecture de la couche de données entraîneront une baisse des performances, des fuites de données, une incapacité à traiter un grand nombre de demandes et à stocker les données nécessaires.

Quand utilise-t-on une architecture monolithique ?

Une seule équipe travaille sur le projet depuis longtemps ;
L’application n’est pas grande et s’intègre facilement dans trois couches principales ;
L’équipe est petite et il n’y a aucun moyen de laisser les développeurs se spécialiser, en construisant une fonctionnalité particulière ;
La rapidité de livraison et les faibles coûts du projet sont une priorité.

Quel est l’avantage de l’architecture monolithique par rapport aux microservices ?

Intuitif pendant le processus de développement : l’application est vue dans son ensemble et décomposée uniquement en couches essentielles ; il n’y a pas besoin de modulation excessive ;
C’est une approche standard du développement logiciel. La plupart des outils, des cadres et des informations pédagogiques sont encore adaptés aux projets monolithiques ;
Peut être construit par une petite équipe.

Inconvénients de l’architecture monolithique

Fonctionnalité couplée : toutes les fonctionnalités et couches de l’application sont étroitement liées ; s’il y a un problème avec un composant, toute la base de code peut être compromise ;
Le code a beaucoup de dépendances et d’intégrations qui diminuent sa réutilisabilité : les fonctionnalités ne peuvent souvent exister qu’en combinaison avec d’autres ;
Évolutivité réduite : lorsque les développeurs introduisent une nouvelle fonctionnalité, ils doivent modifier toute la structure de l’application ;
Il n’est pas conforme au principe de responsabilité unique : une règle selon laquelle chaque composant doit être responsable de sa propre exécution. Chaque partie doit être incluse dans un module ou une classe indépendante. Une architecture monolithique n’isole pas les fonctionnalités, il n’y a donc pas de responsabilité unique.
Tests et maintenance compliqués. Une architecture monolithique doit être testée et mise à jour dans son ensemble. Au lieu de simplement jeter un coup d’œil à une fonctionnalité, les développeurs doivent toujours revenir à l’ensemble de la base de code et voir s’il n’y a pas de modifications indésirables – une différence majeure entre les microservices et les monolithiques .

Architecture de microservices

Les microservices sont une réponse aux problèmes créés par les monolithes. Le code est décomposé en modules indépendants, où chaque fonctionnalité est un service autonome. Chaque composant est dédié à l’exécution d’une seule tâche.

Les principales caractéristiques des microservices sont les suivantes :

les microservices sont des services indépendants qui communiquent entre eux ;
les développeurs peuvent créer des microservices indépendamment et même utiliser différentes piles technologiques ;
les microservices sont organisés autour de processus métiers ;
les microservices sont très isolés : lorsqu’il est temps de mettre à jour le service, il suffit de modifier une seule fonctionnalité ; l’ensemble de l’infrastructure ne sera pas affecté.
les développeurs sont libres d’utiliser différents matériels et bases de données en fonction de l’objectif du service.

Les microservices sont petits par définition, mais ils peuvent fonctionner comme des outils indépendants et même être déployés sur le serveur. Pour créer un logiciel de microservice, les développeurs doivent décentraliser la fonctionnalité, en la décomposant en dizaines de modules autonomes. Il n’y a pas de hiérarchie claire – tous les services peuvent agir indépendamment ;

Il est courant d’utiliser le cloud et l’informatique sans serveur pour l’architecture de microservices. Les microservices sont souvent enfermés dans des conteneurs pour une isolation élevée et une facilité de développement – Docker est une solution leader.

Quand utilise-t-on les microservices ?

La plate-forme doit être hautement évolutive, s’étendre à différents créneaux et marchés ;
Les innovations de haute technologie sont au cœur du produit. Le logiciel utilise régulièrement l’ IA, le ML , l’ IoT et d’autres technologies ;
Une équipe de développeurs utilise différentes piles et outils technologiques, et il n’y a aucune possibilité d’embaucher des experts avec une expertise unifiée ;
L’entreprise souhaite créer immédiatement un code propre et lisible et éviter la dette technique ;
L’entreprise dispose de ressources humaines pour le développement des microservices : l’architecture nécessite plusieurs unités de développement qui travailleront indépendamment sur un microservice ;
L’entreprise privilégie les gains à long terme aux avantages à court terme.

Quelle est la différence entre SOA et microservices ?

L’idée de décomposer l’architecture en composants n’est pas nouvelle. Avant cela, nous avions une architecture orientée services, une approche similaire aux microservices, mais avec quelques différences essentielles.

Une architecture orientée services est une approche modulaire du développement logiciel. Il est composé de composants faiblement couplés qui communiquent entre eux via des protocoles. À en juger par la définition, SOA peut sembler à première vue identique aux microservices, mais ce n’est pas le cas.

Chaque service dans SOA est déterminé par une fonction métier particulière . C’est la base de plusieurs différences avec les microservices. D’une part, les tâches commerciales sont de tailles différentes : la vérification d’une commande est plus petite que la création d’un accord commercial. Ainsi, les services dans SOA varient en complexité.
Granularité : les SOA peuvent effectuer non pas une, mais plusieurs tâches. Vous pouvez réduire le nombre de composants, mais d’un autre côté, si l’un tombe en panne, le système ne fonctionnera pas aussi bien.
Les composants partagent l’information : les microservices sont basés sur la logique de partage le moins possible, alors que les composants des SOA réutilisent le même code. Les services dans SOA sont généralement plus lents, mais prennent moins de temps à construire.

La SOA est-elle monolithique ? Non, car l’architecture est décomposée par modules. D’une certaine manière, il pourrait être défini comme une combinaison de certains principes d’architecture monolithique et de microservices.

Avantages des microservices

Les microservices ont été créés comme une alternative aux microservices par rapport au monolithe, il n’est donc pas étonnant que les avantages de l’architecture soient directement liés aux inconvénients d’un monolithe. Beaucoup de choses qui ne fonctionnaient pas avec la méthode traditionnelle ont été corrigées avec les microservices.

Pas besoin de comprendre l’intégralité de la base de code : les développeurs impliqués dans le processus n’ont pas à apprendre les spécificités de chaque fonctionnalité du logiciel. C’est important pour les grands projets évolutifs, où les équipes ne peuvent pas suivre des milliers de fonctions.
Isolement : les microservices communiquent entre eux, mais ne sont pas dépendants. Si un service échoue, il est possible d’étendre les fonctionnalités de ceux de gauche ou d’ajouter un nouveau service. Dans cette architecture, d’autres composants peuvent reprendre ce que certains ont laissé.
Évolutivité : les microservices se développent rapidement et facilement. Les développeurs peuvent intégrer un nouveau service dans une plate-forme à tout moment et attribuer certains des protocoles populaires tels que HTTP ou gRPC.
Efficacité : les développeurs n’ont plus à s’en tenir à la même solution pour conserver une pile technologique unifiée. Dans les microservices, ils peuvent choisir les technologies qui répondent le mieux aux besoins de services particuliers, combinant de nombreux langages, frameworks et intégrations.
Des équipes plus petites et plus gérables : les développeurs créent des unités de 3 à 5 personnes, où chaque groupe a l’entière responsabilité de 1 à 2 microservices.
Convient parfaitement aux projets d’externalisation : les propriétaires de produits peuvent inviter des équipes d’externalisation à rejoindre un projet à n’importe quelle étape car il n’est pas nécessaire qu’un nouveau fournisseur comprenne toute la complexité des fonctionnalités existantes.

Inconvénients des microservices par rapport au monolithe

Lorsque les monolithes et les microservices sont comparés, ce dernier est généralement considéré comme un gagnant définitif. C’est une généralisation, cependant. L’architecture des microservices est excellente, mais elle n’est en aucun cas parfaite. Examinons les défis auxquels la plupart des équipes sont confrontées lors de l’adoption des microservices.

Les équipes doivent changer d’état d’esprit : les changements doivent être mis en œuvre non seulement au niveau du développement, mais également de la gestion , de la communication et de l’intégration ;
La fonctionnalité doit être modularisée : avant de créer un service, les développeurs doivent comprendre comment décomposer la fonctionnalité globale en modules. S’il est mal fait, le logiciel ne fonctionnera pas correctement.
Les équipes doivent bien communiquer : bien que le développement de microservices implique une grande liberté, il nécessite également que les équipes publient des mises à jour régulières de l’état et gardent une trace des charges de travail globales ;
Différentes piles technologiques rendent l’automatisation difficile : vous devez trouver des outils adaptés à différents langages et environnements d’exécution ;
La communication et les transferts de données entre microservices nécessitent une puissance de calcul supplémentaire.

Les microservices nécessitent une nouvelle approche du développement et de l’organisation des processus. En adoptant les microservices, l’entreprise s’inscrit également dans une évolution des processus et des priorités de travail. Établir un système dans l’équipe interne peut être difficile – bien que ce ne soit pas aussi difficile si vous coopérez avec des développeurs offshore.

Avantages des microservices et de l’architecture monolithique

Les microservices et l’architecture monolithique ont leurs forces et leurs faiblesses respectives, mais surtout, les deux architectures choisissent des approches différentes à chaque étape d’un processus de développement de produit. Examinons les principales distinctions entre les deux architectures et leur mise en œuvre.

Facilité de développement

L’architecture monolithique est plus facile à développer dans les premières étapes. Les développeurs n’ont pas à décomposer la fonctionnalité en modules ou à réfléchir à la façon dont les services communiqueront entre eux. Le processus de développement découle naturellement d’une fonctionnalité à l’autre, en gardant tous les composants unis.

Cependant, dans les étapes ultérieures, une application monolithique devient difficile à contrôler. Au fur et à mesure que la base de code se développe, davantage de fonctionnalités doivent être mises à jour. Apporter des modifications à un seul élément de code devient problématique car il est associé à trop de fonctions.

Les microservices sont difficiles à développer dans les premières étapes. Non seulement une équipe doit penser à décomposer la fonctionnalité, mais elle doit également effectuer des changements cruciaux dans les structures de l’équipe.

Cependant, à mesure que le projet évolue, l’équipe est récompensée pour ses difficultés initiales. En comparant les applications monolithiques aux microservices , les microservices sont facilement testés et mis à jour. Les développeurs peuvent ajouter une nouvelle fonctionnalité à tout moment. Ils sont libres d’expérimenter les piles technologiques et de choisir les technologies qui correspondent le mieux à des fonctionnalités particulières.

Frais

Une architecture monolithique est une solution moins chère à court terme. Vous n’avez pas besoin de beaucoup d’unités pour faire fonctionner le projet. Les premières étapes du projet sont plus rapides qu’avec les microservices, et vous gagnez finalement beaucoup de temps. Lorsqu’il s’agit de construire un petit outil, un monolithe est une approche plus rentable.

Les microservices , cependant, sont sans aucun doute meilleurs au niveau de l’entreprise. Bien sûr, il n’est pas nécessaire de découpler une petite application, mais si vous construisez une plate-forme ambitieuse, la décomposition est indispensable. Les grandes plates-formes sont composées de milliers de fonctionnalités, et leur gestion dans une seule base de code sera problématique. Grâce à leur isolement et leur flexibilité, les microservices permettent d’accélérer la mise à l’échelle et le développement du projet même après plusieurs itérations.

Dépenses en temps

Avec une architecture monolithique, un projet est plus rapide dans les premières étapes. Les développeurs doivent faire moins de recherche et de planification, et il n’est pas nécessaire de planifier la communication entre les services individuels ou d’isoler chaque composant. Que signifie monolithique pour les grands projets ? Généralement, des difficultés de mise à l’échelle et de croissance : lorsque le nombre de fonctionnalités augmente, chaque mise à jour suivante prend plus de temps.

Les microservices représentent la courbe de distribution temporelle opposée. Les premières étapes prennent plus de temps en raison des changements organisationnels et de l’analyse nécessaires, mais à long terme, les grandes plateformes de microservices sont plus rapides que les monolithes de même taille.

Compétences en développement

Construire un monolithe est difficile car toute une équipe dépend fortement de l’expertise de ses membres. Tout le monde doit comprendre exactement comment fonctionne l’ensemble de la base de code, c’est pourquoi le remplacement d’un développeur peut être problématique. Les principaux défis du développement monolithique découlent d’une structure monolithique unie.

Trouver une équipe de développeurs experts avec un ensemble de compétences correspondant . Monolith nécessite une pile technologique unique, c’est pourquoi tous les développeurs doivent être des experts dans une technologie particulière ;
Embarquer de nouveaux développeurs : familiariser un nouveau membre de l’équipe avec les complexités de l’architecture prendra beaucoup de temps ;
Maintenir la documentation : enregistrer toutes les dépendances et l’intégration prendra beaucoup de temps et pourrait devenir une distraction.

Les principales difficultés des microservices sont associées au processus de combinaison de services autonomes en un seul processus. L’indépendance que l’architecture accorde à l’équipe de développement est grande – au début – mais plus tard, des défis peuvent survenir.

Avoir une vue d’ensemble : les développeurs doivent vérifier régulièrement les exigences de leurs produits et tester les microservices, à la fois de manière autonome et ensemble. Sinon, ils risquent de se retrouver avec une liste de services qui fonctionnent bien indépendamment mais qui fonctionnent mal ensemble.
Conflits de navigation : Des approches indépendantes, choisies par différentes unités, peuvent contredire la logique globale de l’application. Si un chef de projet ne détecte pas ces différences dès le début, tout pourrait se terminer par un projet incohérent et des conflits internes.
Sécuriser les microservices : mettre en place des transferts de données rapides et sûrs doit être une priorité permanente. Les développeurs doivent toujours vérifier la sécurité de chaque service individuellement ainsi que leurs intégrations.

Transition

Il n’est pas courant que les équipes de microservices passent à l’architecture monolithique. Habituellement, cette approche est choisie dès le début du développement. Le scénario inverse, cependant, est assez courant.

Les entreprises se tournent vers les microservices lorsqu’elles doivent faire évoluer leurs plateformes. Pour Netflix , la décision de passer aux microservices a été déterminée par une grave erreur qui a entraîné des temps d’arrêt prolongés. L’entreprise est passée à AWS Cloud et a restreint l’ensemble de sa plate-forme en tant que microservices.

Désormais, l’équipe gère plus de 700 services, où chacun est responsable d’une tâche précise. Cela a permis à l’entreprise d’être plus flexible dans l’adoption et les tests d’innovation.

Entretien

Lorsque vous maintenez une structure monolithique , vous devez vous concentrer sur le maintien de l’intégralité de la base de code propre et sans dette technologique. Les développeurs doivent s’assurer que toutes les fonctionnalités fonctionnent bien et voir s’il n’y a pas de bogues cachés dans les mises à jour précédentes. L’objectif est de s’assurer que les modifications apportées à une fonctionnalité n’ont pas d’impact négatif sur le produit.

Avec les microservices, les développeurs se concentrent sur la gestion des conteneurs ( Docker , Kubernetes ). Les microservices et les monolithes peuvent utiliser des outils de déploiement et d’intégration continus.

Stockage de données

L’architecture monolithique gère le stockage et le traitement des données au niveau d’une couche de données. Les développeurs créent une seule couche de données pour l’ensemble de l’application. C’est plus rapide que de configurer un stockage séparé, mais présente un inconvénient crucial. Si une base de données tombe en panne, l’ensemble du logiciel rencontrera des problèmes de performances.

Dans les microservices, chaque service est responsable de la gestion de ses données. Deux composants ne peuvent pas partager le stockage des données. Les services ne peuvent pas avoir un accès direct aux informations privées des autres. Cette approche permet aux développeurs d’éviter les dépendances involontaires entre les services : si deux composants devaient fonctionner avec le même stockage, ils finiraient inévitablement par s’affecter.

De cette façon, même si le stockage des données d’un service est interrompu, tous les autres sont intacts et peuvent fonctionner sans problème. Si un composant échoue, d’autres peuvent le remplir, en utilisant leur propre base de données.

Cas d’utilisation

Les applications monolithiques sont une solution incontournable pour les petites équipes qui travaillent sous des contraintes de temps et un budget limité. Monolith, avec ses premières étapes rapides, permet d’accomplir beaucoup de choses dès le début, même si c’est ; pas toujours une décision durable à long terme. Voici la liste des projets qui correspondent aux concepts de monolithes.

Petits services : si vous construisez une petite application, il n’y a guère de raison pertinente de la décomposer en composants encore plus petits ;
Produits minimaux viables : les développeurs peuvent construire leurs preuves de concepts sous forme de monolithes car c’est plus rapide et moins cher.
Sites d’entreprise : les pages Web dont le seul but est de fournir des informations sur l’entreprise ne nécessitent pas un ensemble sophistiqué de fonctionnalités. Ils peuvent être facilement développés comme un monolithe sans problèmes de mise à l’échelle futurs.

Les microservices, en revanche, ont tendance à être plus exigeants en termes de coûts et de temps lors des premières étapes de développement. Ils représentent un investissement à long terme : les entreprises qui ont adopté les microservices ont tendance à économiser beaucoup d’argent et de temps une fois le projet mis à l’échelle. Cela conduit aux cas d’utilisation suivants pour l’architecture.

Plates-formes évolutives : si vous créez une application Web ou mobile complexe qui couvre plusieurs niches, fonctionne avec de nombreux marchés et hébergera des millions d’utilisateurs, les microservices vous offriront une opportunité d’évoluer.
Vous avez une grande équipe à votre disposition . Si vous n’êtes pas limité à l’utilisation d’une petite équipe interne mais que vous pouvez embaucher de nouvelles personnes ou faire appel à des experts en externalisation, vous mettrez facilement en œuvre des microservices.
Applications multiplateformes . Si votre solution est conçue pour prendre en charge le Web, le bureau et le mobile, vous avez besoin d’une base de code réutilisable. Pour les solutions multiplateformes, l’architecture de microservice est un choix plus efficace.
Applications en temps réel . Si le logiciel gère beaucoup de données et doit traiter des dizaines de milliers de demandes d’utilisateurs simultanées, les microservices pourraient être mieux adaptés à la tâche.
Grande plate-forme de gestion . Si vous construisez une plate-forme commerciale personnalisée complexe, comme CRM ou ERP, les microservices vous permettront d’héberger de grandes fonctionnalités dans des conteneurs isolés.

Entreprises utilisant une architecture monolithique

Malgré la tendance croissante à assembler des microservices, de nombreuses entreprises préfèrent faire évoluer leur architecture monolithique. Ils ont aussi une solide motivation pour le faire. Jetons un coup d’œil aux exemples les plus populaires.

Facebook

Facebook choisit de maintenir son infrastructure unifiée au lieu de décomposer la fonctionnalité en modules. Une telle solution permet à l’équipe de simplifier sa logique métier et d’avoir une vue d’ensemble des fonctionnalités de la plateforme pf. L’équipe utilise de nombreux outils développés sur mesure dans son développement, il n’est donc pas nécessaire d’utiliser différentes piles technologiques.

De plus, Facebook doit donner la priorité à la sécurité en raison des risques élevés de violation de données. Le transfert d’informations entre microservices peut potentiellement compromettre les informations sensibles de l’utilisateur. Ainsi, Facebook a conservé sa plate-forme monolithique PHP plutôt que de passer par la refactorisation.

Segment

Segment, une entreprise qui crée des mégadonnées et des logiciels d’analyse basés sur les données, n’est pas bien connue en dehors de l’industrie de l’analyse de données. Cependant, nous les avons inclus dans la liste car ils représentent un cas intéressant de passage d’un microservice à un monolithe.

L’industrie de l’analyse de données doit gérer un grand nombre d’informations sensibles et traiter plusieurs demandes. La sécurité et la fiabilité sont une priorité. Lorsqu’un produit se composait de 140 services, les frais généraux de communication et de gestion devenaient trop importants.

Chaque service devait gérer une file d’attente de requêtes distincte, ce qui a eu un impact sur les performances de l’application. L’équipe est passée aux monolithes pour créer un produit unifié et contourner la nécessité d’une communication constante dans les deux sens.

Un site Web a été créé aux débuts d’Internet lorsque les microservices n’existaient pas encore. La société utilisait jusqu’à présent son ancienne base de code avec des mises à jour d’interface et de fonctionnalités, mais s’abstenait de refactoriser complètement son architecture.

La stratégie de Reddit consiste à apporter des changements en une étape et une fois sans faire d’investissements radicaux. C’est un bon exemple de mises à jour intelligentes qui peuvent permettre aux équipes de conserver leur ancienne architecture tout en restant intuitives pour les utilisateurs modernes.

Entreprises utilisant des microservices

Passer du monolithique aux microservices est beaucoup plus populaire que l’inverse. La raison est simple : le monolithe est une architecture bien connue et courante, tandis que les monolithes sont relativement nouveaux.

De plus, la façon dont les entreprises se développent à un rythme incroyablement rapide et une approche de développement traditionnelle ne peuvent tout simplement pas suivre. Regardons les transitions qui ont ouvert la voie à l’adoption de l’architecture et analysons les motivations des équipes.

Amazone

Amazon est passé aux microservices pour s’adapter à sa grande infrastructure technologique. L’entreprise a été à la pointe des innovations informatiques, notamment avec ses Amazon Web Services. Cela n’aurait aucun sens pour une équipe aussi progressiste de s’en tenir à une architecture obsolète. Une transition vers les microservices s’est accompagnée d’un basculement vers le Cloud.

L’équipe a nettoyé la base de code et l’a déplacée vers les serveurs décentralisés. Ils ont également créé Amazon Web Services et commencé à adopter activement des outils open source. Pour Amazon, l’adoption des microservices a marqué le début d’une nouvelle approche du développement.

Uber

Au début, les principales fonctionnalités d’Uber étaient la recherche de chauffeurs, les communications de base, le traitement des commandes et les paiements. Il ne desservait qu’une petite communauté d’utilisateurs – l’application n’était disponible qu’à San Francisco. Cependant, lorsque l’entreprise a commencé à s’étendre à d’autres villes, le nombre de fonctionnalités et de demandes a rapidement augmenté.

Pourquoi les microservices ? L’équipe d’Uber devait publier de nouvelles mises à jour à un rythme incroyablement rapide, et un monolithe, avec sa stratégie de développement tout-en-un, ne pouvait pas être durable. Dans les microservices, il vous suffit de déployer un service modifié.

Le passage aux microservices a permis à l’équipe de publier rapidement de nouvelles mises à jour et davantage de modifications, et de réduire le nombre de bogues. Les autres avantages des microservices étaient la réduction des coûts des services de développement et la diminution de la puissance de calcul.

eBay

eBay est passé aux microservices en 2011. A cette époque, l’entreprise était déjà leader sur le marché, avec 87 millions d’utilisateurs actifs et 250 milliards de recherches quotidiennes. Le passage aux microservices était une décision audacieuse car les enjeux étaient élevés.

La première étape de l’adoption des microservices a été de découpler les fonctionnalités et de diviser la base de données. Même la fonctionnalité de recherche devait être décomposée en services distincts. L’application a créé de nouveaux niveaux de fonction et a changé son approche pour créer de nouvelles fonctionnalités.

Afin de mettre à jour la fonctionnalité, l’entreprise n’a plus qu’à connecter une nouvelle fonction à un niveau approprié. Il n’est pas nécessaire de mettre à jour l’ensemble de la grande base de code.

Comme Amazon, eBay a combiné sa transition vers le microservice avec une réévaluation globale de la méthode de développement. L’entreprise s’est tournée vers les solutions open source et le cloud computing.

Tableau comparatif

Conclusion

L’architecture monolithique est un choix approprié pour les petits projets qui doivent être livrés rapidement et avec un budget limité. Il peut être facilement créé et maintenu par une petite équipe, et l’intuitivité de l’architecture permet d’accomplir beaucoup de choses dès le début.

L’architecture de microservice est conçue dans un souci d’évolutivité. Il convient parfaitement aux grandes plates-formes, aux applications d’entreprise complexes et aux entreprises en évolution. Si nous parlons d’un produit ambitieux avec une croissance rapide à l’esprit, cette architecture simplifiera le processus de croissance.

Pour choisir entre les deux architectures, contactez une équipe de développement experte qui analysera votre concept et choisira la solution la mieux adaptée. Nos développeurs travaillent avec les deux architectures et sont bien conscients de la complexité des deux. Il n’y a pas de gagnant évident – tout dépend du projet.