Comment optimiser un développement cloud natif
7 nouvelles règles sont venues s'ajouter aux 12 première règles d'or du développement cloud natif. Objectif : prendre en compte les applications containérisées.
On ne peut pas aborder la question du développement cloud natif sans évoquer ce que l'on appelle les twelve-factor qui représentent la bible du domaine. L'ensemble des experts interrogés dans le cadre de cet article ont bien insisté sur ce point. Ces twelve-factor (voir le tableau ci-dessous) recouvrent les douze règles d'or à suivre dans le cadre de la programmation en mode cloud. Reste qu'il faut bien avoir en tête que ces règles ont été édifiées en 2011 dans le cadre de la mise sur le marché d'une des premières plateformes cloud de l'époque. Baptisée Heroku, elle a depuis été acquise par Salesforce. "Ces règles, certes fondamentales, n'intègrent donc pas les bonnes pratiques liées à la mise en œuvre d'applications containérisées et / ou basées sur Kubernetes", précise Pierre-Yves Aillet, développeur et consultant DevOps chez Zenika.
I. Base de code | Suivre la base de code via un système de contrôle de versions |
---|---|
II. Dépendances | Déclarer explicitement et isoler les dépendances |
III. Configuration | Stocker la configuration dans l'environnement |
IV. Services externes | Traiter les services externes comme des ressources attachées |
V. Assemblez, publiez, exécutez | Séparer strictement les étapes d'assemblage et d'exécution |
VI. Processus | Exécuter l'app comme un ou plusieurs processus sans état |
VII. Associations de ports | Exporter les services via des associations de ports |
VIII. Concurrence | Grossir à l'aide du modèle de processus |
IX. Jetable | Favoriser les démarrages rapides et des arrêts "gracieux" |
X. Parité dev/prod | Garder développement, validation et production au plus proche |
XI. Logs | Traiter les logs comme des flux d'évènements |
XII. Processus d'administration | Lancer les processus d'administration et de maintenance comme des one-off-processes |
Parmi ces twelve-factor, quels sont les plus importants ? "Il y en a un qui, une fois qu'on l'a intégré, va mener assez naturellement à s'intéresser aux autres. C'est le fait d'opter pour une approche stateless", souligne Olivier Beautier, directeur technique de l'agence du cabinet français Zenika basée à Brest. "Une fois qu'on a compris qu'une application web est capable de mourir et de ressusciter sans perte de données, et qu'elle peut travailler avec des clones d'elle-même en parallèle, on est capable d'appréhender des développements orientés cloud avec la notion de réplications que cela implique, notamment pour gérer les montées en charge de trafic." Le protocole dit sans état externalise les données en dehors de l'application. Les sessions étant là pour faire le lien entre les requêtes et transactions de l'utilisateur.
"La gestion des dépendances avec des composants ou des bibliothèques externes est une autre bonne pratique des twelve-factor", indique Pierre-Yves Aillet. Jamel Ben Amar, CTO de Smile, ajoute : "La gestion des dépendances va aussi concerner les appels d'API. Comme toute dépendance, il est important de les invoquer en passant par des connexions standard pour faire en sorte qu'elles soient appelées par n'importe quel composant en couplage lâche." Et Jérôme Tama, architecte chez Onepoint, d'insister : "Il faut être absolument certain d'isoler les appels vers les API de la logique applicative métier pour éviter qu'elles ne contaminent le cœur de l'application. Les briques externes auxquelles ils font appel doivent pouvoir évoluer dans le temps indépendamment."
La prise en compte de la containérisation
Suite à l'avènement des microservices dans les années 2010, 7 facteurs ont été ajoutés au 12 premiers (voir tableau ci-dessous). Dans ce nouveau paradigme, l'objectif est d'embarquer dans des containers des composants métier qui pourront être gérés, mis à jour et scalés indépendamment. Des services qui pourront s'exécuter à la chaîne. "Sur un site d'e-commerce par exemple, une fonction de paiement pourra en appeler deux autres, par exemple celle qui gère le versement par SMS ou celle qui l'orchestre par Stripe ou Paypal", illustre Jamel Ben Amar. Autre avantage : "En lien avec le versioning de code, les containers permettent de distribuer automatiquement le code avec toutes ses dépendances et tout son environnement. Ce qui garantit que l'exécution est rigoureusement la même que ce soit sur l'environnement de test ou tout autre environnement de production", indique Jérôme Tama.
"Le service mesh mène à s'intéresser aux notions de release management et d'AB Testing entre plusieurs éditions en production"
En toile de fond, l'orchestrateur de Kubernetes (Keda) va permettre de générer autant de containers que nécessaire en fonction de la montée en charge du trafic sur un service donné, un panier sur un site d'e-commerce en période de solde par exemple. Pour Jamel Ben Amar, la sélection d'un PaaS implique nécessairement la présence de technologies open source, à l'image de Kubernetes ou Terraform. Objectif : ne pas se retrouver pieds et poings liés au provider de cloud. "Mais, cela passe également des types de PaaS qui existent aussi chez d'autres fournisseurs. Par exemple des offres de fonctions as a service qui pourront intégrer le même code quel que soit le cloud", ajoute le CTO.
XIII: Observabilité | Des applications avec une visibilité sur leur état de santé et leurs métriques |
---|---|
XIV: Programmable | Des applications qui doivent fournir des indications sur les contraintes de ressources attendues |
XV : évolutive | Des applications qui doivent mettre à niveau les formats de données des générations précédentes |
XVI : Moindre privilège | Des conteneurs qui doivent fonctionner avec le moins de privilèges possibles |
XVII : Vérifiable | Avoir une visibilité sur les opérations critiques de bout en bout |
XVIII : Sécurisé | Protéger l'application et les ressources des sollicitations étrangères (Maîtriser identité, réseau, couverture et certificats) |
XIX : Mesurable | Une application dont l'utilisation est mesurable en termes de quotas et de refacturation |
Le service mesh est un autre point clé issu des 7 nouvelles règles d'or. "Il consiste à définir des conventions définissant l'accès à telle ou telle version. Il mène à s'intéresser aux notions de release management et d'AB Testing entre plusieurs éditions en production", évoque Pierre-Yves Aillet. Et Jérôme Tama de compléter : "La gestion de la concurrence est également importante. Il faut pouvoir développer une application qui sache gérer la concurrence des appels sans générer d'anomalies. Typiquement, je dois être en capacité de ne pas confondre le traitement mis en œuvre pour un utilisateur avec celui activé pour un autre."
Pour faire fonctionner les solutions d'observabilité des systèmes Kubernetes, les développeurs devront par ailleurs prendre l'habitude de taguer les applications embarquées dans les containers pour faire le lien avec les missions métier attribuées à ces dernières. "In fine, l'objectif est de mettre les indicateurs de monitoring à la portée des responsables de système et des DevOps", explique Olivier Beautier. Et Pierre-Yves Aillet d'ajouter : "Via les plateformes d'observabilité, on dispose d'une masse importante d'informations. C'est aussi une opportunité de rapprocher les développeurs de la production et de les sensibiliser sur la manière dont se comporte leur application en vue de les inscrire dans un cycle d'amélioration continue."
"Quand on s'oriente vers un développement cloud natif, il faudra se poser la question de savoir si l'application est réplicable d'un cloud à un autre, voire sur un environnement cloud local. Ce qui implique de se détourner des solutions propriétaires", insiste Jérôme Tama. Une application cloud native se doit aussi d'être résiliente. Si un service n'est pas disponible, l'application doit être en capacité d'avertir les utilisateurs et de leur conseiller de revenir ultérieurement. "A partir du moment où j'ai une forte montée en charge, je ne peux pas répliquer l'erreur sur plusieurs centaines voire plusieurs milliers d'utilisateurs. Il est donc important que je communique sur cette erreur pour éviter d'aller dans le mur", conseille Jérôme Tama. Le développement cloud natif a donc lui-aussi son erreur 404.