Points à Retenir
- L'architecture des microservices reste le style architectural le plus populaire pour les systèmes distribués. Mais Kubernetes et le mouvement cloud natif ont redéfini certains aspects de la conception et du développement d'applications à grande échelle.
- Sur une plateforme native en cloud, l'observabilité des services ne suffit pas. Une condition préalable et fondamentale est de rendre les microservices automatisables, en mettant en œuvre des health checks, en réagissant aux signaux, en déclarant la consommation de ressources, etc.
- Dans l'ère post-Kubernetes, l'utilisation de bibliothèques pour implémenter les soucis de mise en réseau opérationnels (tels que Hystrix comme « circuit breaking ») a été complètement dépassée par la technologie service mesh.
- Les microservices doivent maintenant être conçus pour la « récupération », en implémentant l’idempotence sur plusieurs dimensions.
- Les développeurs modernes doivent maîtriser un langage de programmation pour mettre en œuvre les fonctionnalités métier et maîtriser également les technologies cloud natives pour répondre aux exigences au niveau d'infrastructure non fonctionnel.
Le battage médiatique des microservices a débuté avec un tas d'idées extrêmes sur la structure organisationnelle, la taille de l'équipe, la taille du service, la réécriture et la diffusion des services plutôt que les fixer, l'évitement des tests unitaires, etc. D'après mon expérience, la plupart de ces idées se sont avérées fausses, peu pratiques ou généralement peu applicables. De nos jours, la plupart des principes et des pratiques restants sont tellement génériques et peu définis qu'ils resteraient vrais pendant de nombreuses années sans pour autant avoir beaucoup de sens dans la pratique.
Adopté quelques années avant la naissance de Kubernetes, le microservice reste le style architectural le plus populaire pour les systèmes distribués. Mais Kubernetes et le mouvement cloud natif ont redéfini certains aspects de la conception et du développement d'applications à grande échelle. Dans cet article, je voudrais remettre en question certaines de ses idées originales sur les microservices et reconnaître le fait qu’elles ne sont pas aussi fortes dans l’ère post-Kubernetes qu’avant.
Non seulement observable, mais aussi des services automatisables
L'observabilité a été un principe fondamental des microservices dès le début. Bien que cela soit vrai pour les systèmes distribués généralement, aujourd'hui (sur Kubernetes en particulier), une grande partie de ces systèmes est prête à l'emploi au niveau de la plateforme (contrôles de processus, consommation de processeur et de mémoire). L'exigence minimale est qu'une application se connecte à la console au format JSON. À partir de là, la plateforme peut suivre la consommation de ressources, effectuer un suivi des demandes, rassembler toutes sortes de mesures, taux d'erreurs, etc. sans trop d'efforts de développement au niveau de service.
Sur les platesformes cloud natives, l'observabilité n'est pas suffisante. Une condition préalable et fondamentale est de rendre les microservices automatisables, en mettant en œuvre des health checks, en réagissant aux signaux, en déclarant la consommation de ressources, etc. Il est possible de placer presque toutes les applications dans un conteneur et de les exécuter. Mais pour créer une application conteneurisée pouvant être automatisée et orchestrée efficacement sur une plateforme en cloud native, il est nécessaire de respecter certaines règles. En suivant ces principes et patterns, vous vous assurerez que les conteneurs résultants se comportent comme un bon citoyen du cloud natif dans la plupart des moteurs d’orchestration de conteneurs, leur permettant d’être programmés, mis à l’échelle et contrôlés de manière automatisée.
Plutôt que d'observer ce qui se passe dans un service, nous souhaitons que la plateforme détecte les anomalies et les réconcilie comme déclarées. Que ce soit en arrêtant la direction du trafic vers une instance de service, en redémarrant, en augmentant ou en diminuant ou en déplaçant un service vers un autre hôte fonctionnel, en réessayant une demande défaillante ou autre, cela n'a pas d'importance. Si le service est automatisable, toutes les actions correctives se produisent automatiquement et il suffit de décrire l'état souhaité, plutôt que d'observer et de réagir. Un service devrait être observable, mais également rectifiable par la plateforme sans intervention humaine.
Plateforme intelligente et services intelligents mais avec les bonnes responsabilités
Lors de la transition de l’architecture SOA vers le monde des microservices, la notion de « smart endpoints and dumb pipes » était un autre changement fondamental dans les interactions de service. Dans le monde des microservices, les services ne reposent pas sur la présence d'une couche de routage intelligente centralisée, mais s'appuient plutôt sur les endpoints intelligents dotés de certaines fonctionnalités au niveau de la plateforme. Cela a été réalisé en intégrant certaines des fonctionnalités des ESB traditionnels dans chaque microservice et en effectuant une transition vers des protocoles légers ne comportant pas d’éléments de logique métier.
Bien que ce soit toujours un moyen populaire pour mettre en œuvre une interaction de service sur une couche réseau non fiable (avec des bibliothèques telles que Hystrix), la technologie des services mesh l'a complètement dépassée. Il est intéressant que les services mesh sont encore plus intelligents que ce que les ESB traditionnels avaient l'habitude d'être. Le mesh peut effectuer un routage dynamique, une découverte de service, un équilibrage de charge basé sur la latence, le type de réponse, les métriques et le suivi distribué, les nouvelles tentatives, les délais d'attente, etc.
La différence avec l'ESB est que, plutôt qu'une couche de routage centralisée, avec un mesh de service, chaque microservice a généralement son propre routeur - un conteneur sidecar qui exécute la logique de proxy avec une couche de gestion centrale supplémentaire. Surtout, les canaux (la plateforme et le service mesh) ne contiennent aucune logique métier ; ils visent uniquement les problèmes d'infrastructure, laissant le service se concentrer sur la logique métier. Comme le montre le diagramme, cela représente l’évolution depuis les ESB et des microservices pour s'adapter à la nature dynamique et non fiable des environnements en cloud.
[Cliquer sur l'image pour l'agrandir]
SOA vs MSA vs CNA
En examinant les autres aspects des services, nous remarquons que le cloud natif n'affecte pas seulement les endpoints et les interactions de service. La plateforme Kubernetes (avec toutes les technologies supplémentaires) prend également en charge la gestion des ressources, la planification, le déploiement, la gestion de la configuration, la mise à l’échelle, l’interaction avec les services, etc. Plutôt que de l'appeler « smart proxy and dumb endpoints », je pense qu'il est préférable de le décrire comme une plateforme intelligente et des services intelligents avec les bonnes responsabilités. Il ne s'agit pas uniquement d’endpoints ; c'est plutôt une plateforme complète qui automatise tous les aspects d'infrastructure des services axés principalement sur les fonctionnalités de l'entreprise.
Ne pas concevoir pour l'échec, concevoir pour la récupération
Les microservices s'exécutant dans des environnements cloud natifs où l'infrastructure et le réseau ne sont pas fiables par nature, doivent être conçus pour faire face aux pannes. Il n'y a pas de doute sur ce sujet. Cependant, de plus en plus de défaillances sont détectées et traitées par la plateforme, et il reste moins de possibilités pour détecter les défaillances dans un microservice. Au lieu de cela, pensez à concevoir votre service pour la récupération en implémentant l’idempotence à partir de plusieurs dimensions.
La technologie des conteneurs, les orchestrateurs de conteneur et le service mesh peuvent détecter et récupérer de nombreuses pannes : boucles infinies - partages de CPU, fuites de mémoire et OOM - health checks, panne de disque - quotas, limites de mémoire, cloisonnement et isolation de processus, découverte de service basée sur la latence et la réponse, réessais, délais d'attente, mise à l'échelle automatique, etc. Sans parler du passage à un modèle serverless pendant quelques millisecondes pour traiter une requête unique, les pools de threads, les fuites de ressources sont de moins en moins pertinentes...
Tout cela étant traité par la plateforme, pensez à votre service en tant que boîte noire hermétique qui sera démarrée et arrêtée plusieurs fois, rendant le service idempotent pour les redémarrages. Votre service sera multiplié par plusieurs fois, ce qui le rend plus robuste en le rendant sans état. Supposons que de nombreuses demandes entrantes finiront par expirer - faites en sorte que les endpoints soient idempotents. Supposez que de nombreuses requêtes sortantes échouent temporairement et que la plateforme les réessayera pour vous - assurez-vous de consommer des services idempotents.
Pour être adapté à l'automatisation dans les environnements cloud natifs, un service doit être :
- Idempotent pour les redémarrages (un service peut être tué et démarré plusieurs fois).
- Idempotent pour la mise à l'échelle vers le haut/bas (un service peut être mis à l'échelle automatiquement sur plusieurs instances).
- Producteur de service idempotent (les autres services peuvent réessayer les appels).
- Consommateur de service idempotent (le service ou le mesh peut réessayer les appels sortants).
Si votre service se comporte toujours de la même manière lorsque les actions ci-dessus sont effectuées une ou plusieurs fois, la plateforme pourra récupérer vos services en cas d'échec sans intervention humaine.
Enfin, gardez à l'esprit que toutes les récupérations fournies par la plateforme ne sont que des optimisations locales. Comme le souligne très bien Christian Posta, la sécurité des applications et leur exactitude dans un système distribué restent la responsabilité de l'application. Un état d'esprit global des processus métier (pouvant couvrir plusieurs services) est nécessaire pour concevoir un système stable.
Responsabilités de développement hybrides
De plus en plus de principes de microservices sont mis en œuvre et fournis en tant que fonctionalités par Kubernetes et ses projets complémentaires. En conséquence, un développeur doit maîtriser un langage de programmation pour mettre en œuvre les fonctionnalités métier et également des technologies natives en cloud pour répondre aux exigences au niveau d’infrastructure non fonctionnel tout en implémentant pleinement une fonctionnalité.
La ligne entre les exigences métier et l'infrastructure (exigences opérationnelles ou inter-fonctionnelles, ou attributs de qualité du système) est toujours floue et il n'est pas possible de prendre un aspect et d'attendre que quelqu'un fasse l'autre. Par exemple, si vous implémentez la logique de nouvelle tentative dans la couche de service mesh, vous devez définir le service consommé idempotent au niveau de la logique métier ou de la couche de base de données du service. Si vous utilisez un délai d'attente au niveau du service mesh, vous devez synchroniser les délais d'expiration du consommateur de service au sein du service. Si vous devez implémenter une exécution récurrente d'un service, vous devez configurer un job Kubernetes pour effectuer l'exécution temporelle.
À l'avenir, certaines fonctionnalités du service seront implémentées dans les services sous forme de logique métier, et d'autres seront fournies sous forme de capacités de plateforme. Bien que l’utilisation d’un bon outil pour la bonne tâche constitue une bonne séparation des responsabilités, la prolifération des technologies augmente énormément la complexité globale. La mise en œuvre d'un simple service en termes de logique métier nécessite une bonne compréhension des piles de technologie distribuée, car les responsabilités sont réparties sur chaque couche.
Il est prouvé que Kubernetes peut prendre en charge des milliers de nœuds, des dizaines de milliers de modules et des millions de transactions par seconde. Mais peut-il les réduire ? Le seuil de taille, de complexité ou de criticité de votre application qui justifie l'introduction de la complexité « native cloud » n'est pas encore clair pour moi.
Conclusion
Il est intéressant de voir comment le mouvement des microservices a donné un tel élan à l’adoption de technologies de conteneurs telles que Docker et Kubernetes. Au début, ce sont les pratiques des microservices qui ont fait progresser ces technologies, mais maintenant Kubernetes définit les principes et les pratiques de l'architecture des microservices.
Comme exemple récent, nous ne sommes pas loin d’accepter le modèle de fonction comme une primitive de microservices valide, plutôt que de le considérer comme un anti-pattern pour les nano services. Nous ne remettons pas suffisamment en question les technologies cloud natives pour leur caractère pratique et leur applicabilité aux cas de petite et moyenne taille, mais nous passons plutôt inutilement à l’excitation.
Kubernetes a tiré de nombreux leçons des ESB et des microservices, et en tant que tel, il s'agit de la plateforme de système distribué ultime. C'est la technologie qui définit les styles architecturaux plutôt que l'inverse. Que ce soit bon ou mauvais, seul le temps le montrera.
A propos de l'Auteur
Bilgin Ibryam (@bibryam) est un architecte principal chez Red Hat, committer et membre d'ASF. Il est un évangéliste open source, blogueur et auteur de livres Camel Design Patterns et Kubernetes Patterns. Dans son travail quotidien, Bilgin aime le mentorat, le codage et les principaux développeurs pour réussir dans la création de solutions en cloud. Ses travaux actuels portent sur l'intégration d'applications, les systèmes distribués, le messaging, les microservices, les devops et les défis liés au cloud en général. Vous pouvez le trouver sur Twitter, Linkedin ou son Blog.