[Retours Tech&Wine] 📝 ✅ La checklist ultime pour rendre vos applications cloud native !” - 2/5

Kévin Delbegue était à la "Tech & Wine" qui se tenait au château de Montchat le 18 juin dernier. Découvrez ici son retour sur la conférence de Katia Himeur.

Pour commercer, nous adressons nos remerciements envers Katia HIMEUR qui a consacré du temps sur cette journée de Tech and Wine à nous partager son retour d'experience lors de la conférence qu'elle a tenu.

Avec l’émergence du “cloud” il y a des dizaines d’années maintenant, on entend et voit très régulièrement les termes “Application Cloud Native”, “Architecture Cloud Native” ou encore “Infrastructure Cloud Native”.

Mais du coup “Cloud Native” kesako ?

Voici la définition officielle de la Cloud Native Computing Foundation (CNCF) :

Les pratiques "Cloud Native" permettent aux organisations de développer, construire et déployer des workloads dans des environnements cloud (public, privé, hybride) pour répondre à leurs besoins organisationnels à l'échelle d'une manière programmatique et reproductible.

Elles se caractérisent par des systèmes faiblement couplés qui interagissent de manière sécurisée, résiliente, gérable, durable et observable.f

Les technologies et architectures “Cloud Native” consistent généralement en une combinaison de conteneurs, de service mesh, de microservices, d'infrastructures immuables, de serverless et d'API déclaratives — cette liste n'est pas exhaustive.

Source : https://github.com/cncf/toc/blob/main/DEFINITION.md#definition

Histoire de rendre ce terme “Cloud Native” encore plus parlant, voici ci-dessous un aperçu de l’ensemble des projets et produits référencé par la CNCF, dans le fameux impressionnant “CNCF Landscape”.

Source : https://landscape.cncf.io/docs/landscape.png

Au cours de sa présentation, Katia HIMEUR, est revenue également sur les bases de ce terme “Cloud Native”, la définition, les concepts, les outils, les enjeux, etc…

À partir de ses constatations sur de nombreux projets de migration vers le cloud, elle soulève des questions intéressantes :

• “Toutes les applications sont-elles faites pour être déployées sur le Cloud ?”
• “Pourquoi tant de projets de migrations sont en échecs ?”

Grâce à ses retours d’expériences sur ces différents projets, voici les règles de base à suivre avant de vouloir rendre son application “Cloud Native”.

1. “Ne pas se concentrer uniquement sur la technique” : La technique est importante et occupe une part conséquente dans une migration, mais ce n’est pas pour autant qu’elle soit le seul facteur à prendre en compte. Il est assez “simple” de rapidement tomber dans un piège comme “AWS c’est cool, nous aussi, on doit migrer sur AWS !”… Il est important de bien prendre en compte l’application, les enjeux, les contraintes, bien au-delà de la technique et de certaines technos.
2. “Définir ses objectifs” : Il est important de se poser les bonnes questions, pourquoi choisir le cloud ? Quels sont les avantages du cloud par rapport à notre solution existante ? Comment le cloud peut-il nous aider à atteindre nos objectifs business ? Aller sur le cloud n’est pas un objectif, mais un moyen d’atteindre ses objectifs business.
3. “Communiquer avant, pendant et après le projet” : Comme partout, la communication est essentielle, toutes les parties prenantes doivent avoir le même niveau d’informations ! Il est important de communiquer au sein de l’équipe réalisant la migration et le projet, mais aussi avec toutes les autres personnes intervenant de près ou de loin dans le cadre de l’application et de son infrastructure.
4. “Analyser votre culture et vos pratiques” : Avant de commencer une migration, il est important de faire un “état des lieux” du workflow projet. Vérifier si la culture et les bonnes pratiques DevOps sont bien mises en place, évaluer le degré d’automatisation (tests, déploiements, CI/CD, …), vérifier les procédures internes, etc…
5. “Identifier les personnes clefs” : Suivant les projets et les profils, chacun maîtrise plus ou moins l’ensemble de l’application, il est normal également que des personnes maîtrisent plus l’architecture de l’application, son fonctionnement dans le code, son infrastructure, ou tout simplement son utilisation en tant qu’utilisateur. L’essentiel est de bien identifier qui maîtrise quoi, ainsi que qui est en charge de quoi.
6. “Collaborer” : La création de “silos” entre les différentes équipes est une problématique récurrente, Wanadev n’échappe pas à cette règle. Il est totalement utopique de penser que chaque collaborateur peut maîtriser l’ensemble des sujets, technos, … et ce pour l’ensemble des projets. Il est donc primordial d’essayer de casser ces “silos” et d’apporter une cohésion et une collaboration inter-équipes.
7. “Analyser votre existant” : Avant de faire de notre application monolithique un “monolithe distribué”, il faut se poser les bonnes questions sur l’état actuel de l’application. Est-elle “statefull” ou bien “stateless” ? Si je crée deux instances de mon application, que va-t-il se passer ? Est-ce qu’il y a des développements préalables à réaliser avant ma migration ?
8. “Faire un point sécurité” : Même si la sécurité peut être perçue comme une contrainte par certains, elle est tout aussi importante au sein des différents projets. C’est malheureusement le point qui est souvent sacrifié, à tort, car les enjeux et impacts peuvent être désastreux par la suite. Le terme “Secure by Design” traduit bien l’importance de concevoir les aspects de sécurité au cœur de l’application.
9. “Cadrer votre projet” : Définir l’architecture, de l’infrastructure, mais aussi de l’application en cas de modifications nécessaires. Choisir quel(s) fournisseur(s) cloud, quel(s) service(s), quelle taille, quelle(s) localisation(s), etc… Il est également important d’identifier les besoins de formations pour les équipes en amont de chaque migration. Il est de plus important de choisir la stratégie de migration : Refactor, Replatform, Repurchase, Rehost, Retain ou encore Retire.
10. “Définir vos KPIs” : Les KPIs sont très importantes pour mesurer l’avant/après de la migration. Savoir si la migration et les évolutions tiennent leurs promesses initiales, ou encore éviter les remarques “c’était mieux avant” ou “ça marchait mieux avant”.
11. “Préparer votre application” : Il paraît presque inconcevable de faire évoluer l’infrastructure avant d’adapter l’application. Le découpage en microservices s’il est nécessaire est à réaliser en amont. Si l’application ne supporte pas les mécanismes d’autoscalling par exemple. La gestion du cache ou des sessions de manière centralisée.
12. “Préparer le jour J” : Ne pas oublier le DNS ! Et bien évidement établir des procédures et tester ces procédures avant le jour J.
13. “Se préparer aux surprises” : Ne pas oublier que le souci vient souvent du DNS !
14. “Documenter” : L’importance de réaliser une documentation tout au long du projet n’est plus à démontrer. Plus la documentation sera complète, plus l’onboarding de nouveaux collaborateurs sera simple. Mais aussi en cas de maintenance ou d’évolution, par une personne expérimenté ou non sur l’application.
15. “Itérer” : L’amélioration continue est importante, les pratiques Agiles peuvent également s’appliquer à ce genre de projets. Les choix et décisions initiaux ne doivent pas rester figés, au contraire, il est important d’ajuster au fur et à mesure l’application et son infrastructure.
16. “Apprendre de votre projet” : Organiser des rétrospectives est un bon moyen d’analyser ce qui a marché et moins bien marché dans ce genre de projets.

Cette checklist ne protège pas de l’échec, mais elle permet d’avoir de nombreuses clés en main pour orienter la migration d’une application “Cloud Native”.

Avec la variété des projets chez WanadevDigital, les différentes migrations à venir, mais aussi pour les projets futurs, ce retour d’expérience apporte une bonne base de travail pour mener à bien ces sujets.

A nouveau, nous remercions Katia HIMEUR pour ses riches enseignements lors de cette journée du Tech and Wine.

Suite à la journée "Tech & Wine", plusieurs articles sont disponibles. N'hésitez pas à aller les consulter :

• DevOps is Dead, les -Plateformes- sont le futur - 1/5
• REX: transformer de l'Ansible+docker-compose en Helm+k8s - 3/5
• Défier l'entropie : réécrire ses applications ou reprendre le contrôle ? - 4/5
• Vers un Nouveau Paradigme : Platform Engineering, Docker, DevOps et la Gestion de l'Entropie - 5/5