En novembre, OTUS lance un nouveau programme éducatif, «Architecte logiciel», à cet égard, nous continuons une série de publications pour les futurs étudiants du cours et les lecteurs de notre blog.
Lire la première partie
Architecture de microservice
Les microservices sont un type d'architecture logicielle orientée services qui se concentre sur la création d'un certain nombre de composants autonomes qui composent l'application. Contrairement aux applications monolithiques créées dans leur ensemble, les applications de microservices se composent de plusieurs composants indépendants qui sont collés ensemble via l'API.
Comparaison de la structure des microservices et de l'architecture monolithiqueL'approche microservice se concentre principalement sur les priorités et les opportunités commerciales, tandis que l'approche monolithique est organisée autour des niveaux technologiques, des interfaces utilisateur et des bases de données. L'approche microservice est devenue une tendance ces dernières années, de plus en plus d'entreprises devenant plus flexibles et passant à DevOps.
Les microservices sont importants simplement parce qu'ils ajoutent une valeur client unique en simplifiant les systèmes. En décomposant votre système ou votre application en plusieurs parties plus petites, vous implémentez un moyen de réduire la duplication, d'augmenter la cohérence et de réduire la communication entre les parties, ce qui rend vos parties communes du système plus compréhensibles, plus évolutives et plus faciles à modifier.
Lucas Kraus, auteur de Microservices
Il existe de nombreux exemples d'entreprises qui sont passées d'une approche monolithique aux microservices. Netflix, Amazon, Twitter, eBay et PayPal sont parmi les plus connus. Pour déterminer si les microservices conviennent à votre projet, identifions les avantages et les inconvénients de cette approche.
Avantages des microservices
Facile à développer, tester et déployer
Le plus grand avantage des microservices par rapport aux autres architectures est que de petits services individuels peuvent être créés, testés et déployés indépendamment. Étant donné que l'unité de déploiement est petite, elle facilite et accélère le développement et la publication. De plus, la sortie d'une unité n'est pas limitée à la sortie d'une autre, qui n'est pas encore terminée. Et le dernier avantage ici est que les risques de déploiement sont réduits car les développeurs publient des parties du logiciel, pas l'intégralité de l'application.
Flexibilité accrue
À l'aide de microservices, plusieurs équipes peuvent travailler sur leurs services de manière indépendante et rapide. Chaque partie individuelle de l'application peut être construite indépendamment en raison de l'isolement des composants de microservice. Par exemple, vous pouvez avoir une équipe de 100 personnes travaillant sur l'ensemble de l'application (comme dans une approche monolithique), ou vous pouvez avoir 10 équipes de 10 personnes développant divers services.
Imaginons-le visuellement.
Une flexibilité accrue permet aux développeurs de mettre à jour les composants du système sans arrêter l'application. De plus, la flexibilité offre un processus de déploiement plus sécurisé et une disponibilité accrue. De nouvelles fonctionnalités peuvent être ajoutées au besoin sans attendre le lancement complet de l'application.
La possibilité d'évoluer horizontalement
La mise à l'échelle verticale (en utilisant le même logiciel, mais sur des machines plus puissantes) peut être limitée par la bande passante de chaque service. Mais la mise à l'échelle horizontale (création de plus de services dans un pool) n'est pas limitée et peut fonctionner avec les microservices de manière dynamique. De plus, la mise à l'échelle horizontale peut être entièrement automatisée.
Inconvénients des microservices
Difficulté
Le plus grand inconvénient des microservices est leur complexité. La séparation de l'application en microservices indépendants implique plus d'artefacts de contrôle. Ce type d'architecture nécessite une planification minutieuse, des efforts considérables, des ressources et des compétences d'équipe. Les raisons de la grande complexité sont les suivantes:
- Demande accrue d'automatisation, car chaque service doit être vérifié et contrôlé
- Les outils disponibles ne fonctionnent pas avec les dépendances de service
- La cohérence des données et la gestion des transactions deviennent de plus en plus difficiles car chaque service dispose d'une base de données
Problèmes de sécurité
Dans une application de microservice, chaque fonctionnalité qui interagit via l'API de l'extérieur augmente la probabilité d'attaques. Ces attaques ne peuvent se produire que si les mesures de sécurité appropriées ne sont pas prises lors de la création de l'application.
Différents langages de programmation
La possibilité de choisir différents langages de programmation est une arme à double tranchant. L'utilisation de différentes langues complique le déploiement. De plus, il est plus difficile de basculer les programmeurs entre les étapes de développement, lorsque chaque service est écrit dans une langue différente.
En fin de compte
Les microservices sont bons, mais pas pour tous les types d'applications. Ce modèle est idéal pour développer des applications et des systèmes complexes. Vous pouvez penser à choisir une architecture de microservice lorsque vous avez plusieurs équipes expérimentées et lorsque l'application est suffisamment complexe pour la décomposer en services. Lorsqu'une application est volumineuse et doit être flexible et évolutive, une architecture de microservices est avantageuse.
Nous pouvons maintenant comparer ces trois architectures logicielles pour identifier visuellement les différences entre elles.
Les applications monolithiques sont constituées de blocs interdépendants et indivisibles et ont une vitesse de développement très faible. SOA se décompose en services plus petits et modérément liés et se développe lentement. Les microservices sont de très petits services indépendants faiblement couplés qui se caractérisent par un développement rapide et une intégration continue.
Architecture sans serveur
L'architecture sans serveur est une approche de cloud computing pour créer et exécuter des applications et des services sans avoir besoin de gérer l'infrastructure. Dans les applications sans serveur, l'exécution de code est pilotée par la plateforme, permettant aux développeurs de déployer du code sans se soucier de la maintenance et de la maintenance du serveur. En fait, l'absence de serveur ne signifie pas «pas de serveur». L'application fonctionne toujours sur les serveurs, mais un service cloud tiers tel qu'AWS est entièrement responsable de ces serveurs. L'architecture sans serveur élimine le besoin de ressources supplémentaires, de mise à l'échelle des applications, de maintenance du serveur et de systèmes de stockage et de base de données.
L'architecture sans serveur comprend deux concepts:
- FaaS (Function as a Service) est un modèle de cloud computing qui permet aux développeurs de télécharger des parties de fonctionnalités dans le cloud et permet à ces parties d'être exécutées indépendamment
- BaaS (Backend as a Service) est un modèle de cloud computing qui permet aux développeurs d'externaliser les aspects backend (gestion de base de données, stockage cloud, hébergement, authentification des utilisateurs, etc.), ainsi que d'écrire et de prendre en charge uniquement une partie interface externe.
Voici à quoi ressemble une structure sans serveurEn utilisant une architecture sans serveur, les développeurs peuvent se concentrer sur le produit lui-même sans se soucier de la gestion du serveur ou des temps d'exécution. Cela permet aux développeurs de se concentrer sur le développement de produits à haute fiabilité et évolutivité.
Il existe de nombreux fournisseurs de solutions cloud sur le marché. Voici quelques-uns des principaux fournisseurs d'informatique sans serveur:
Les principaux fournisseurs d'informatique sans serveurPour savoir si ce type d'architecture est nécessaire pour votre projet, déterminons les avantages et les inconvénients de l'implémentation d'un modèle sans serveur.
Avantages de l'architecture sans serveur
Facile à déployer
Dans les applications sans serveur, les développeurs n'ont pas à se soucier de l'infrastructure. Cela leur permet de se concentrer sur le code lui-même. L'architecture sans serveur vous permet de déployer rapidement une application, car le déploiement ne prend que quelques heures ou jours (par rapport aux jours ou semaines avec l'approche traditionnelle).
Réduction des coûts
Le passage à une architecture sans serveur réduit les coûts. Comme vous n'avez pas besoin de traiter des bases de données, de la logique et des serveurs, vous pouvez non seulement créer un meilleur code, mais également réduire les coûts. Lorsque vous utilisez un modèle sans serveur, vous ne payez que pour les cycles CPU et la mémoire que vous utilisez réellement.
Évolutivité améliorée
De nombreux propriétaires d'entreprise souhaitent que leurs applications soient puissantes et évolutives, comme Google ou Facebook. L'informatique sans serveur rend la mise à l'échelle automatique et fluide. Votre application évoluera automatiquement lorsque la charge ou la base d'utilisateurs augmente, sans affecter les performances. Les applications sans serveur peuvent traiter un grand nombre de demandes, tandis que les applications traditionnelles seront surchargées avec leur augmentation soudaine.
Inconvénients de l'architecture sans serveur
Reliure fournisseur
La liaison fournisseur décrit une situation où vous donnez au fournisseur un contrôle total sur vos opérations. En conséquence, les changements dans la logique métier sont limités et la migration d'un fournisseur à un autre peut être difficile.
Pas pour les tâches à long terme.
Le modèle sans serveur ne convient pas aux opérations longues. Les applications sans serveur conviennent aux processus courts en temps réel, mais si la tâche prend plus de cinq minutes, l'application sans serveur nécessitera des fonctionnalités FaaS supplémentaires.
En fin de compte
L'architecture logicielle sans serveur est utile pour résoudre des tâches ponctuelles et prendre en charge les processus. Il fonctionne très bien pour les applications riches en clients et les applications qui se développent rapidement et nécessitent une échelle illimitée.
Enfin, regardons l'image suivante pour savoir quand choisir chacun de ces quatre types d'architecture:
Choisir la bonne architecture pour votre MVP est difficile, mais RubyGarage a de nombreuses années d'expérience pour vous aider dans votre choix. L'auteur de l'article se fera un plaisir de répondre à toutes vos questions sur ce sujet.