En novembre, OTUS lance un nouveau programme éducatif «Architecte logiciel» . Dans ce cadre, nous avons préparé une série de publications pour les futurs étudiants du cours et les lecteurs de notre blog.
Créer un nouveau produit est toujours risqué. Et choisir la bonne architecture est une étape importante sur la voie du succès. Si vous choisissez entre une architecture monolithique, orientée services, microservice et sans serveur, ce billet vous aidera à faire le bon choix.
Architecture monolithique
Monolith est un mot ancien désignant un énorme bloc de pierre. Bien que le terme soit largement utilisé aujourd'hui, le point de vue reste le même dans tous les domaines. En génie logiciel, un modèle monolithique fait référence à une seule unité indivisible. Le concept de logiciel monolithique est que les différents composants de l'application sont combinés en un seul programme sur la même plate-forme. En règle générale, une application monolithique se compose d'une base de données, d'une interface utilisateur client et d'une application serveur. Toutes les parties du logiciel sont unifiées et toutes ses fonctions sont gérées en un seul endroit. Examinons en détail la structure des logiciels monolithiques.
L'architecture monolithique est pratique pour les petits groupes, donc de nombreuses startups choisissent cette approche lors de la création d'une application. Les composants des logiciels monolithiques sont interconnectés et interdépendants, ce qui aide le logiciel à être autosuffisant. Cette architecture est une solution traditionnelle pour la création d'applications, mais certains développeurs la trouvent obsolète. Cependant, nous pensons que l'architecture monolithique est une solution idéale dans certaines circonstances.
Malgré le fait que nous ayons eu une expérience positive de l'utilisation des microservices chez Google, nous [chez Scaylr] avons suivi une route monolithique, car avoir un serveur monolithique implique moins de travail pour nous en tant que deux ingénieurs.
Stephen Cherwinski, responsable du design, Scaylr
Pour savoir si cette solution convient à votre entreprise, examinons ses avantages et ses inconvénients.
Les avantages de l'architecture monolithique
Développement et déploiement simplifiés
Il existe de nombreux outils que vous pouvez intégrer pour faciliter le développement. De plus, toutes les actions sont effectuées avec un seul répertoire, ce qui simplifie le déploiement. Grâce au noyau monolithique, les développeurs n'ont pas besoin de déployer les modifications ou les mises à jour séparément, car ils peuvent le faire immédiatement et gagner beaucoup de temps.
Moins de problèmes transversaux
La plupart des applications dépendent de nombreuses tâches inter-composants, telles que les pistes d'audit, la journalisation, la limitation de vitesse, etc. Les applications monolithiques sont beaucoup plus faciles à prendre en compte ces problèmes en raison de leur base de code commune. Il est plus facile de connecter des composants à ces tâches lorsque tout fonctionne dans une seule application.
Meilleure performance
Lorsqu'elles sont correctement assemblées, les applications monolithiques sont généralement plus productives que les applications basées sur des microservices. Par exemple, une application avec une architecture de microservices peut avoir besoin de faire 40 appels API pour 40 microservices différents pour charger chaque écran, ce qui conduit évidemment à de mauvaises performances. Les applications monolithiques, à leur tour, assurent une communication plus rapide entre les composants logiciels en raison du code commun et de la mémoire.
Inconvénients de l'architecture monolithique
La base de code devient lourde au fil du temps
Au fil du temps, la plupart des produits continuent d'être développés et développés et leur structure s'estompe. La base de code commence à paraître très volumineuse et devient difficile à comprendre et à modifier, en particulier pour les nouveaux développeurs. Il devient également de plus en plus difficile de trouver des effets secondaires et des dépendances. À mesure que la base de code grandit, la qualité se détériore et l'IDE est surchargé.
Difficile d'introduire de nouvelles technologies
Si vous devez ajouter une nouvelle technologie à votre application, les développeurs peuvent rencontrer des obstacles à la mise en œuvre. L'ajout de nouvelles technologies signifie la réécriture de l'application entière, ce qui est coûteux et prend du temps.
Flexibilité limitée
Dans les applications monolithiques, chaque mise à jour mineure nécessite un redéploiement complet. Ainsi, tous les développeurs doivent attendre que cela soit fait. Lorsque plusieurs équipes travaillent sur le même projet, la flexibilité peut être considérablement réduite.
En fin de compte
Le modèle monolithique n'est pas obsolète et, dans certains cas, il fonctionne toujours très bien. Certaines sociétés géantes, comme Etsy, restent monolithiques, malgré la popularité actuelle des microservices. L'architecture d'un logiciel monolithique peut être utile si votre équipe est au stade initial, que vous créez un produit non vérifié et que vous n'avez pas d'expérience avec les microservices. Le monolithe est idéal pour les startups qui ont besoin de mettre le produit en service le plus rapidement possible. Cependant, certains des problèmes mentionnés ci-dessus vont de pair avec une architecture monolithique.
SOA
L'architecture orientée services (SOA) est un style d'architecture logicielle qui implique une application modulaire composée d'agents logiciels discrets et faiblement couplés qui exécutent des fonctions spécifiques. SOA divise les composants en deux rôles principaux: fournisseur de services et consommateur. Ces deux rôles peuvent être joués par des agents logiciels. Le concept de SOA est le suivant: une application peut être conçue et construite de telle manière que ses modules sont facilement intégrés et peuvent être facilement réutilisés.
Avantages de SOA
Réutilisation des services
En raison de la nature autonome et faiblement couplée des composants fonctionnels dans les applications orientées services, ces composants peuvent être réutilisés dans plusieurs applications sans affecter d'autres services.
Légèreté accompagnée
Étant donné que chaque service logiciel est une unité indépendante, il est facile de mettre à jour et de maintenir sans affecter les autres services. Par exemple, les applications de grande entreprise sont plus faciles à gérer lorsqu'elles sont décomposées en services.
Fiabilité supérieure
Les services sont plus faciles à déboguer et à tester que d'énormes morceaux de code, comme dans les monolithes. Ceci, à son tour, rend les produits basés sur SOA plus fiables.
Développement parallèle
L'architecture orientée services étant en couches, elle prend en charge la simultanéité dans le processus de développement. Des services indépendants peuvent être développés en parallèle et complétés en même temps.
Inconvénients de SOA
Difficulté à gérer
Le principal inconvénient de l'architecture orientée services est sa complexité. Chaque service doit fournir une livraison de message en temps opportun. Le nombre de ces messages peut dépasser un million à la fois, ce qui rend difficile la gestion de tous les services.
Coûts d'investissement élevés
Le développement SOA nécessite un investissement initial important dans les ressources humaines, la technologie et le développement.
Charge supplémentaire
Dans SOA, toutes les entrées sont validées avant qu'un service n'interagisse avec un autre service. Lorsque vous utilisez plusieurs services, cela augmente le temps de réponse et réduit les performances globales.
En fin de compte
SOA est le mieux adapté aux systèmes d'entreprise complexes tels que la banque. Le système bancaire est extrêmement difficile à diviser en microservices. Mais une approche monolithique ne convient pas non plus au système bancaire, car une partie peut endommager l'ensemble de l'application. La meilleure solution consiste à utiliser l'approche SOA et à organiser des applications complexes en services isolés et indépendants.
Ceci conclut la première partie de la traduction, et nous parlerons des microservices et de l'architecture sans serveur dans la
deuxième partie du matériel.