Dans un article précédent, nous avons expliqué comment les services cloud sont devenus une norme non écrite pour la fourniture de services informatiques. Il est facile de deviner que les entreprises qui souhaitent continuer à gagner de l'argent sur les applications utilisateur doivent s'adapter et créer de nouveaux produits en tenant compte de l'approche Cloud-Native. Cependant, pour les développeurs, c'est définitivement une bonne nouvelle, car l'utilisation des technologies cloud leur ouvre de nouvelles opportunités. L'essentiel est de pouvoir les éliminer correctement.
Lorsqu'une application commande un environnement
Si vous avez déjà lu le
guide de la technologie cloud, vous vous souviendrez probablement que la technologie de virtualisation est l'une des «sources magiques» des nuages. Grâce à cela, le développeur n'a pratiquement pas besoin de penser aux paramètres des serveurs sur lesquels son application fonctionnera. Pourquoi y consacrer du temps si un hyperviseur ou un conteneur correctement configuré peut configurer une machine avec presque toutes les caractéristiques dont une application a besoin pour fonctionner?
Le développement de cette idée est l'approche Infrastructure as code (IAC). Son essence est de permettre aux développeurs ou aux services d'exploitation d'utiliser les mêmes approches que celles utilisées pendant la phase de développement pour maintenir l'infrastructure. Il vous permet de préparer à l'avance des unités de contrôle logiciel communes et d'intégrer facilement ces composants dans de nouveaux projets.
Les capacités des datacenters modernes nous permettent déjà de passer au langage déclaratif de la gestion des infrastructures. Idéalement, l'application doit administrer le pool de ressources qu'elle occupe dans le centre de données. Cela permettra au développeur de ne pas être bloqué dans les limitations associées au processus de travail avec l'infrastructure, lorsqu'il est nécessaire de commander et de concevoir à l'avance ou si les mêmes composants d'infrastructure sont répétés dans différents projets.
En fait, le développeur ou l'ingénieur fait une requête Pull, qui contient la configuration de la machine virtuelle (noyau, mémoire, réseau, modèle, etc.), puis le gestionnaire d'environnement virtuel crée indépendamment la machine ou crée une nouvelle instance de base de données ou démarre le service préinstallé, selon les paramètres de fichier. Cette approche est un véritable salut lorsque l'on travaille avec des mégadonnées et des réseaux de neurones. Les applications associées à ces technologies, dans certains cas, nécessitent des quantités de mémoire et de puissance de processeur dynamiques.
Par exemple, pour former un réseau, il est nécessaire de «conduire» des centaines de gigaoctets d'informations à travers celui-ci, et les nuages vous permettent d'obtenir la capacité requise pour cela sur demande. Une fois la formation terminée, les ressources sont renvoyées au pool de fournisseurs et le développeur n'a pas besoin de réfléchir à la façon de les utiliser ou de configurer l'application d'une manière différente afin qu'elle continue de fonctionner avec une capacité inférieure.
Monolith vs. chaos ordonné
Étant donné que les nuages peuvent s'adapter de manière flexible aux besoins du développeur, cela simplifie théoriquement une autre tâche - le problème de la mise à l'échelle des applications. Pourquoi théoriquement?
Malheureusement, la tâche de mise à l'échelle des applications n'est pas linéaire. Pour que l'application puisse faire face à des charges énormes pendant les périodes de fréquentation (ou de calcul) de pointe, il ne suffit pas de lui donner davantage de mémoire et de puissance processeur. Absolument chaque application traditionnelle a un seuil, après quoi elle n'est plus en mesure de «digérer» de nouvelles ressources et de démontrer une augmentation des performances. Le problème dans ce cas n'est pas les ressources, mais l'architecture de la plupart des programmes.
Ce problème est particulièrement aigu pour les applications avec une architecture monolithique, qui sont en fait des fichiers binaires uniques. Les avantages de cette approche sont évidents: les applications monolithiques sont assez simples et linéaires. Tous les scénarios de comportement des utilisateurs peuvent être prédits, suivis et, si nécessaire, débogués.
Cependant, une telle simplicité a un prix. Tout d'abord, ce sont les problèmes de mise à l'échelle mentionnés ci-dessus. À un moment donné, même l'application monolithique la plus réfléchie cesse de fonctionner plus efficacement depuis une mise à niveau vers la configuration du serveur sur laquelle elle s'exécute.
Deuxièmement, une application monolithique n'est pas si facile à transférer vers de nouveaux serveurs et cela peut nécessiter une recompilation complète du programme.
Troisièmement, une telle application est difficile à maintenir et à développer. Tout tour de mise à jour nécessite l'assemblage complet de l'ensemble du programme, et une erreur dans l'un des blocs de code peut entraîner la chute de l'ensemble du système.
À la recherche d'idées sur la façon de résoudre ces problèmes, un autre concept a été développé - l'architecture orientée services (SOA). Cela implique que l'application est divisée en plusieurs modules, chacun fournissant aux autres une sorte de fonctionnalité. Les modules interagissent les uns avec les autres via un ensemble de services Web et, indépendamment les uns des autres, ils peuvent accéder à une seule ou à leurs propres bases de données.
Cette approche simplifie vraiment le support du programme et ne transforme pas sa mise à jour «en travail de sapeur», dans lequel il n'y a pas de place pour l'erreur; mais il a aussi ses défauts. Le principal est les problèmes de mise à l'échelle du développement de ces applications. Au fur et à mesure que le programme se développe, il devient de plus en plus difficile de «pousser» de nouvelles fonctionnalités dans les packages 5-10 initialement approuvés par l'architecte. Leur nombre augmente, ce qui se transforme en problèmes de support.
Le microservice comme élément de l'évolution des applications
Le résultat de l'évolution de SOA est l'idée d'une architecture de microservices, qui est utilisée dans la conception d'applications cloud. Sur le plan conceptuel, les idées des deux approches sont extrêmement similaires et certains architectes ne distinguent même pas l'architecture de microservices comme un paradigme distinct, la considérant comme un cas particulier de SOA.
L'architecture de microservice implique que l'application ne se compose pas d'un petit nombre de grands modules, mais de nombreuses parties indépendantes. Contrairement à un monolithe, dans une application de microservice, vous pouvez utiliser différentes méthodes pour l'interaction des composants entre eux. Le système n'a pas un seul état prédéterminé. Au lieu de cela, chaque composant fonctionne «selon la situation»: dès qu'il reçoit un événement, il commence à fonctionner. Cela permet une architecture très flexible et indépendante.
Dans le même temps, le nombre de services dans l'application de microservice change constamment - certains sont ajoutés, certains sont supprimés. Dans la nouvelle approche, tout microservice peut être remplacé et une chaîne de microservices intégrée à la place. D'autres services continuent de fonctionner de manière stable, car ils ne sont pas directement liés. C'est l'évolution naturelle du programme. Grâce à cela, les développeurs et les architectes ont la possibilité de changer rapidement quelque chose afin de répondre aux changements des exigences commerciales et de surpasser les concurrents.
En plus d'augmenter la vitesse de mise à jour des mises à jour, l'utilisation de l'architecture de microservice permet une gestion décentralisée. L'équipe chargée du développement d'un service a le droit de déterminer son architecture interne et ses fonctionnalités. Soit dit en passant, une telle approche est actuellement mise en œuvre par le Sberbank Architectural Council dans le bloc technologique.
Dans le même temps, assis pour développer votre application cloud, vous ne devriez pas vous précipiter avec la rapidité de l'écraser dans ses éléments constitutifs. Le principal adversaire d'une telle approche irréfléchie est Martin Fowler; il est l'un des auteurs de l'idée d'architecture de microservices. Il est plus facile d'utiliser initialement une approche monolithique, puis de stimuler l'évolution de l'application de manière "naturelle", en se concentrant sur la rupture des goulots d'étranglement et l'ajout de fonctions supplémentaires.
En conséquence, nous pouvons formuler la règle suivante: la tâche du programmeur lorsqu'il travaille avec une architecture de microservices n'est pas seulement de diviser l'application en un nombre maximal de composants, mais de faire délibérément la distinction entre leur responsabilité de recevoir et de traiter les données.
Quatre détails
En plus des nombreux avantages évidents, l'architecture de microservice a ses propres caractéristiques, qui doivent être prises en compte lors du développement de votre application cloud. En particulier, pour soutenir le fonctionnement d'une telle application, il est nécessaire de maintenir en permanence des exigences accrues pour la qualité de gestion des API internes.
Lorsqu'un des composants change d'interface, il doit prendre en charge la compatibilité descendante afin de prendre en charge la version précédente de sa propre API. Si cette règle est respectée, vous pouvez passer dynamiquement de l'ancienne version à la nouvelle sans échecs. Si la prise en charge de la version précédente de l'API n'est pas établie, cela menace dans le meilleur des cas, la perte d'une partie des fonctionnalités de l'application et, dans le pire des cas, des plantages permanents de son fonctionnement.
La deuxième caractéristique importante des applications de microservices est la difficulté d'y trouver des bogues. Si une application écrite en logique monolithique ou SOA plante, il ne sera pas difficile de trouver la source du problème. Dans une application composée de nombreux services, la recherche de la cause du bogue peut prendre beaucoup de temps car les données de l'utilisateur passent souvent par plusieurs microservices et il est difficile de déterminer lequel d'entre eux se bloque. Dans le même temps, le processus de recherche de bogues doit être effectué très soigneusement: toute refactorisation infructueuse peut entraîner une panne du module de travail, et en plus du problème initial, le développeur en recevra un deuxième.
Le troisième détail important à prendre en compte lors du développement d'une application cloud est la manière dont ses composants interagissent entre eux. Comme dans SOA, les services utilisent des services Web pour échanger des données, mais des modèles d'interaction, tels que le streaming, CQRS, Event sourcing, sont apparus dans l'architecture de microservice. En règle générale, les développeurs s'attendent à ce que le temps de réponse entre la demande et la réponse dans l'application soit assez petit. Dans un système distribué, on ne peut même pas compter sur le fait que la réponse viendra du tout.
De plus, dans l'architecture des applications cloud, les microservices utilisent diverses bases de données les mieux adaptées pour résoudre leurs problèmes spécifiques. Par exemple, les grilles peuvent lire rapidement, mais peuvent difficilement faire face à un grand nombre d'opérations de changement de données. Une telle base est bien adaptée pour maintenir des comptes de dépôt - ils changent rarement. Un autre type d'opération est le traitement; il peut y avoir des dizaines de changements sur chaque carte chaque jour, et au contraire, il y a peu de lectures de données.
Enfin, le quatrième fait dont vous devez vous souvenir lors du développement d'une application cloud est que l'architecture de microservice est principalement axée sur l'utilisation de services sans état. Dans ce cas, n'allez pas à l'extrême. Si nécessaire, certains services peuvent toujours fournir un support de l'État si la logique métier l'exige, et ils doivent être conçus avec un soin particulier.
Par exemple: si l'utilisateur fait une demande de prêt, le système qui a reçu la demande doit sauvegarder cet état afin de le transférer vers d'autres services. Mais le service chargé de trouver des informations dans le fichier interne des antécédents de crédit peut ne pas enregistrer son état et oublier les données sur le nom de l'utilisateur qu'il a recherché il y a quelques minutes - de toute façon, après un moment, une nouvelle demande lui sera adressée (bien que dans ce processus, il puisse être un comportement de service différent).
Tous les exemples et pratiques décrits ci-dessus sont déjà activement utilisés par les leaders de l'industrie informatique mondiale. Par exemple, Netflix est un pionnier dans le développement d'une architecture de microservices. La société a publié de nombreuses applications open source, des bibliothèques et un cadre de surveillance, d'équilibrage et de journalisation des applications de microservices.