Cloud Adoption Framework : le premier étage de la fusée Landing zone

Dans un précédent article, nous avions abordé les grands piliers pour concevoir une Cloud Digital Factory. Pour rappel, voici quelques-uns de ses composants techniques, auxquels il faut ajouter l’organisation.

Nous avons là les briques techniques. Par nature, le Cloud est un environnement en évolution perpétuelle : de nouvelles fonctionnalités sont mises en production tous les jours. Il est donc difficile de se tenir informé de tout et de s’assurer de ne rien oublier avec un tel périmètre.

Pour délivrer et opérer cette infrastructure, nous avons besoin de beaucoup de méthodologie (et de technique). Chez Microsoft, cette méthodologie se nomme Cloud Adoption Framework. Son objectif est de mettre à disposition :

• Une méthodologie intégrant les aspects métiers, organisationnels, le choix d’implémentation, les recommandations ;
• Des exemples d’implémentations à utiliser comme base de travail.

L’aspect méthodologique est plus que complet puis qu’il intègre les domaines suivants :

• La définition de la stratégie ;
• L’élaboration du plan pour accompagner cette stratégie ;
• La mise en œuvre technique de cette stratégie (la mise en œuvre de Landing zones) ;
• Une méthodologie pour migrer nos applications dans Azure ;
• Favoriser l’innovation ;
• Proposer un cadre pour garantir la gouvernance sur le long terme ;
• S’assurer que l’on soit capable d’opérer cette infrastructure depuis le premier jour ;
• Aligner organisation et technologie.

Il faut voir le Cloud Adoption Framework comme un accélérateur pour notre adoption du Cloud. On peut construire sans mais pourquoi faire compliqué quand on peut faire simple ?

Dans le cadre de cet article, nous allons nous intéresser plus particulièrement à l’implémentation. Nous connaissons les différentes briques technologiques : ce que nous devons faire, c’est les assembler pour produire ce que l’on nomme une Landing Zone.

Qu’est-ce qu’une Landing Zone ?

Dans une traduction littéraire, une Landing Zone est une zone d’atterrissage et s’inspire de la terminologie propre à la conquête spatiale. Lorsqu’on construit une fusée pour aller sur la lune, c’est pour y envoyer une charge utile (satellite, alunisseur…). Dans Azure, le but de la Landing Zone n’est pas de mettre sur orbite notre Digital Product / application mais de lui fournir les services nécessaires pour faciliter sa mission. Problème : chaque Digital Product / application a des besoins bien distincts. On peut donc difficilement envisager de faire de la Haute Couture, cela va à l’encontre de l’approche industrielle prônée par le Cloud. On doit donc penser cette Landing Zone comme un produit industrialisé délivré par une chaine de production, devant répondre au plus grand nombre. Ainsi, l’usine peut tout à fait avoir plusieurs lignes de production pour proposer plusieurs Landing Zones aux consommateurs.

Généralement, on considère que l’on délivre une Landing Zone au sein d’une souscription Azure dédiée car :

• Isoler les digital products / applications en souscriptions distinctes permet une meilleure séparation des rôles et responsabilités ;
• Une souscription est une unité de facturation, cela simplifie la refacturation des services mis à disposition ;
• Une souscription est une limite de sécurité facile à isoler en cas de risque sécurité avéré.

Le Cloud Adoption Framework : une usine avec plusieurs lignes de production

A noter : l’approche industrielle de la Landing Zone permet de délivrer rapidement mais aussi de s’assurer du maintien à niveau des Landing Zones déjà délivrées. Il n’est pas envisageable de ne pas maintenir à niveau les Landing Zones déjà mises à disposition. En tant qu’équipe en charge des Landing Zones, nous en restons responsables.

Tout comme pour la conquête spatiale, aller sur la lune est un travail d’équipe. L’approche de l’homme-orchestre appliquée à Azure ne fonctionnera pas. Nous allons avoir besoin d’une équipe pluridisciplinaire pour couvrir des sujets aussi variés que :

• L’identité
• La sécurité
• Les coûts (maîtriser les budgets est inévitable)
• La culture DevOps
• Le réseau (aussi dénommé « Plomberie du Cloud »)
• La gouvernance

Comment construire une Landing Zone ?

On peut partir de zéro ou s’inspirer de ce que propose le Cloud Adoption Framework (CAF). Parce qu’il n’est pas possible de répondre à tous les Business cases avec une solution unique, le CAF propose :

• Deux types de Landing Zones selon la taille de l’entreprise (Small, Enterprise Scale)
• Deux modes de déploiements (BluePrints / Terraform module)

D’un point de vue Azure, une Landing Zone doit proposer un certain nombre de services, qu’ils soient mis à disposition dans la souscription (cas des small Landing Zones) ou qu’ils soient considérés comme des services mutualisés mis à disposition de toutes les Landing Zones (cas des Enterprise Landing zones).

Illustration Small Landing Zone – Source Documentation Microsoft

Ce qui est intéressant avec les Landing Zones proposées par le Cloud Adoption Framework, c’est que leur déploiement est modulaire. Dans l’illustration ci-dessous, un découpage en modules permet de déployer progressivement :

• Les services communs (que l’on place dans une / plusieurs souscriptions Hub) ;
• Les différentes Landing Zones.

La modularité permet de répondre au besoin de mise à l’échelle pour héberger plus de Digital Products / applications sur une infrastructure existante (Scale-up) ou de les héberger au plus proche de nos nouveaux marchés (Scale-out).

Cliquer sur l’image pour lancer l’animation

Illustration : Déploiement modulaire en fonction de la taille de l’entreprise (Source : GitHub public du Cloud Adoption Framework)

Les détails d’implémentation de ces Landing zones sont disponibles ici. Allons voir dans le détail à quoi cela ressemble.

Deep dive Landing Zone Blueprint

Comme indiqué précédemment, il existe plusieurs moyens pour déployer une Landing Zone. En premier lieu, nous avons les Blueprints. On peut comparer les Blueprints à du papier calque. En l’appliquant à une souscription, on assure la mise en place des différents composants de notre Landing Zone. Le premier avantage de cette méthode de déploiement est qu’elle est déjà disponible dans vos souscriptions. Il ne reste plus qu’à demander la création d’un Blueprint à partir d’un des modèles existants.

Illustration : Créer un Blueprint Cloud Adoption Framework

C’est un modèle que l’on peut librement personnaliser selon nos besoins en ajoutant :

• L’Assignation d’un rôle (RBAC) ;
• L’assignation d’une Azure Policy ;
• La création de groupes de ressources ;
• Le déploiement d’un template ARM.

Illustration : Contenu du BluePrint Cloud Adoption Framework

A chaque fois que nous ajoutons un élément, nous créons une nouvelle version du Blueprint. C’est grâce à cette mécanique de version que nous pouvons maintenir à jour les Landing Zones déjà mises à disposition. Pour son déploiement, on utilisera un pipeline Azure DevOps qui se chargera de publier le Blueprint (et créera une nouvelle version si nécessaire) ainsi que de l’assigner sur la souscription Azure choisie.  L’approche Blueprint s’adresse en premier lieu aux petites structures. Dès lors qu’on est dans le contexte d’une grande organisation, le modèle « Terraform » sera le plus adapté.

Deep Dive Landing Zone Terraform

La seconde méthode de déploiement repose sur Terraform, plus particulièrement sur des modules Terraform mis à disposition sur la Terraform Registry. Pour simplifier l’expérience, l’ensemble est mis à disposition sous la forme d’un conteneur Docker nommé « Rover » que l’on pourra instancier localement puis via Azure DevOps ultérieurement. Cette approche présente plusieurs avantages :

• On travaille toujours avec les mêmes versions de Terraform et des modules associés, cela nous garantit la reproductibilité de nos déploiements localement ou dans notre chaîne CI/CD ;
• Nous sommes indépendants de notre environnement d’exécution. Il n’y a pas de risque d’avoir un résultat différent lorsque l’on va déployer la même configuration depuis notre chaine CI/CD ;
• On dispose d’un cadre déjà opérationnel immédiatement ;
• Le modèle est évolutif pour prendre en charge les spécificités des Landing Zones de notre organisation.

L’utilisation des modules Terraform présente de nombreux avantages :

• Garantie dans l’uniformité dans la charte de nommage ;
• Garantie dans l’uniformité dans la propagation de nos tags ;
• Proposer un cadre pour nous permettre de simplifier son évolution.

La mise en œuvre est un peu plus complexe mais dès lorsqu’on dispose de VS Code, son extension Remote Development et Docker, on peut rapidement mettre en œuvre son environnement local. Si le sujet vous intéresse, je ne peux que recommander la lecture de cet article d’Arnaud Lheureux : Cloud Adoption Framework landing zones with Terraform, vous y découvrirez le Rover.

Cloud Adoption Framework Rover – Source de l’image

La liste des modules Terraform utilisés par le Rover grandit de jour en jour. Vous y découvrirez que cela couvre bien plus que les fondations nécessaires à notre Landing Zone. Avec cette approche, nous sommes à même de standardiser le déploiement de la majorité des ressources Azure. C’est amplement suffisant. Si vous souhaitez approfondir le sujet, je vous invite à regarder les vidéos suivantes :

• Cloud Adoption Framework for Azure landing zones on Terraform – épisode 1 – Introduction
• [Vidéo] Cloud Adoption Framework for Azure landing zones on Terraform – épisode 2 – installation en démo

Azure Landing Zone Accelerator

Le Cloud Adoption Framework évolue très vite. Pour preuve, on est maintenant capable de déployer des Landing Zone complexes directement depuis le portail Azure comme on peut le voir dans l’illustration ci-dessous :

Azure Landing zone accelerator

Dans cette configuration, le déploiement est assuré en utilisant un template ARM. C’est une approche intéressante pour tester rapidement la solution. Le défaut, c’est qu’on ne pourra pas le personnaliser autant que le Rover avec ses modules Terraform. Si l’approche vous tente, rendez-vous à cette URL : https://aka.ms/caf/ready/accelerator

Quel second étage à notre fusée ?

Après avoir déployé notre Landing Zone et industrialisé son déploiement via un Pipeline Azure DevOps, il est tentant de rapidement développer de nouveaux services pouvant apporter de la valeur à nos consommateurs. A terme, je suis d’accord, mais avant cela il nous faut déjà embarquer nos premiers consommateurs. La phase d’embarquement est souvent sous-estimée, c’est même une cause majeure d’échec des projets de Landing Zone. Embarquer, cela veut dire que notre produit (la Landing Zone) intéresse des consommateurs pour qu’ils y souscrivent. On a donc besoin :

• De consommateurs, voire mieux : d’early adopters prêts à tester notre Landing Zone et nous faire des retours. C’est grâce à eux et leurs feedbacks que l’on pourra décider quels services on pourra leur proposer ultérieurement ;
• De documentation à destination de nos consommateurs pour expliquer à quoi sert leur Landing Zone et comment en tirer avantage. Si vous ne montrez pas comment vous avez simplifié la vie de vos consommateurs, il y a de grandes chances qu’ils perdent du temps à traiter les mêmes sujets.
• D’accompagner nos consommateurs par de la formation et du support. Ne partez pas du principe que vos consommateurs sont aussi experts que vous sur Azure. Il faut souvent les aider à faire les premiers pas pour qu’ils deviennent autonomes rapidement. Il faut considérer la formation comme un investissement. Par manque d’autonomie, c’est vers les sachants que les consommateurs vont se tourner, donc vous ! La conséquence est que vous allez passer plus de temps à assurer le support de vos consommateurs que développer votre offre de Landing Zone.

Si vous avez réussi à embarquer des consommateurs et que ceux-ci sont en mesure de déployer leurs Digital Product / application jusqu’en production, on peut alors commencer à regarder de nouveaux services. C’est le second étage de notre fusée. Cet aspect n’est pas vraiment abordé dans le Cloud Adoption Framework. Notre Landing Zone est un produit et doit convaincre le consommateur. Avant de se lancer dans cette aventure, il ne faudra pas perdre de vue quelques points :

• Nous sommes responsables / coupables des produits que nous allons développer pour nos consommateurs. Cette exigence de qualité / fiabilité ne s’acquiert pas en un jour. On ne devient pas SRE (Site Reliability Engineering) du jour en lendemain juste en renommant une équipe. C’est une culture à développer et on apprend malheureusement beaucoup de ses échecs.
• Notre service devra répondre à un besoin exprimé par nos consommateurs. Mettez-vous à la place d’un consommateur de votre Landing Zone en vous demandant :
  • Moi, en tant que consommateur de Landing Zone, quel est mon premier besoin pour mon Digital Product ?
  • Moi, en tant que consommateur de Landing Zone, quel est le premier sujet le plus complexe que je dois adresser pour arriver jusqu’en production ?
  • Moi, en tant que consommateur de Landing Zone, quel est le sujet bloquant du produit ?
  • Moi, en tant que consommateur de Landing Zone, quel prix suis-je prêt à payer pour le service ?

Avant de vous lancer dans cette aventure, essayez de regarder ce que Le Cloud Adoption Framework peut vous proposer comme base de travail. A ce jour, on a déjà les fondations pour des scénarios autour des usages suivants :

• Des applications Cloud-Native avec une implémentation de référence de Azure Kubernetes Services;
• L’analyse de la donnée et l’intelligence artificielle : Introduction to enterprise-scale for analytics and AI in Azure

Dans la construction de notre produit Landing Zone, le Cloud Adoption Framework nous donne les bonnes pratiques à suivre (Patterns) ainsi que les écueils à éviter (Anti-Patterns). Gardez toujours un œil sur ces anti-patterns, cela vous évitera de nombreux pièges.

De la théorie à la pratique

Pour résumer, le Cloud Adoption Framework est un cadre et une base de travail pour accélérer la transition vers le Cloud Azure.  C’est un accélérateur pour mettre en place la « plomberie technique » mais il ne faut pas oublier que c’est un outil au service d’une stratégie et que ce sera un travail d’équipe.

La première étape est bien d’avoir une stratégie. Cellenza est à même de vous accompagner dans la définition de celle-ci tout comme dans sa mise en œuvre technique.

Si le sujet du Cloud Adoption Framework vous intéresse, je vous recommande de consulter Learning Path de Microsoft.