Conception de Landing Zone : la tête dans les nuages mais les pieds sur terre

Le Cloud Public me fascine. Il dégage une image où tout est simple, où les problèmes liés à l'infrastructure disparaissent, laissant place à la magie. Le plus impressionnant, c'est que cette promesse est aussi une réalité : il est possible et facile de construire un nouvel environnement opérationnel en cinq minutes.

Est-ce une bonne chose ? Oui, bien sûr, c'est un formidable vecteur d'accélération pour l'innovation dans de nombreux cas.

Est-ce toujours aussi simple ? Malheureusement non, dans le contexte d'une entreprise, il est nécessaire de garder le contrôle, de construire une infrastructure qui sera capable de soutenir au mieux son activité, ses processus et son organisation. La magie peut nous aider, mais pas faire le travail à notre place.

La vision magique que nous avons du Cloud et la vision très technique que nous avons de l'infrastructure nous font souvent oublier la notion de service, qui devrait être au cœur des préoccupations de toutes les équipes travaillant pour l'entreprise.

Il y a un travail à faire pour s'assurer que l'infrastructure cloud qui va être construite répondra aux besoins de l'entreprise et restera alignée avec ses objectifs stratégiques. C'est une tâche de gouvernance qui doit être menée en amont et dans le cadre d'un processus d'amélioration continue. Cette responsabilité doit être identifiée et assumée par une structure au sein de l'entreprise. Parmi nos clients, ce type de structure est souvent appelé Centre d'Excellence du Cloud (CCOE).

L'ensemble des ressources et des processus qui mettent en œuvre la stratégie cloud et la gouvernance au niveau de l'entreprise constitue ce que l'on appelle la Zone d'Atterrissage (LZ). Elle contient tout ce qui est offert aux équipes pour travailler dans le cloud, en termes d'outils, de contraintes et d'organisation.

Rapide et Pragmatique

C'est vraiment très facile de commencer avec le cloud. De plus, lorsqu'un client se questionne ou commence à s'y intéresser, nous commençons par proposer une Preuve de Concept (PoC) sur un périmètre restreint et à faible risque afin que la notion de cloud devienne plus concrète pour lui.

Après cette démonstration, souvent réalisée avec beaucoup de magie, certains pourraient être tentés de se projeter et d'imaginer à quel point il serait rapide et facile de reproduire cela à grande échelle et d'abandonner tout ou partie de leur datacenter physique en faveur du cloud, lançant ce que nous appelons un projet de Transition vers le Cloud.

C'est à ce moment précis que nous observons une erreur commune à éviter : considérer que la PoC a été réalisée dans les conditions cibles ! Et en déduire sur cette base un budget ou un délai pour la création de l'infrastructure de l'ensemble de l'entreprise.

En fait, pour être rapide et réduire les coûts, la PoC a au contraire été réalisée complètement en dehors du contexte de l'entreprise. Le champ de l'étude a été précisément choisi pour ne pas être soumis à trop de contraintes et ne pas nécessiter un audit long et précis de l'organisation de l'entreprise au préalable. Nous avons délibérément ignoré un grand nombre de problèmes qui devront nécessairement être abordés afin de construire une zone d'atterrissage robuste et à l'échelle de l'entreprise. La zone d'atterrissage est la fondation de l'infrastructure cloud, la qualité de sa conception détermine le retour sur investissement en termes de qualité, de fiabilité, d'agilité et d'économies financières potentielles.

À ce stade du projet, les enjeux sont bien trop élevés pour envisager une approche rapide et sommaire, il est crucial d'adopter à la place une approche pragmatique et itérative pour réaliser un travail de conception approfondi. Contrairement à ce que l'on pourrait penser, la conception est tout aussi importante lors de l'utilisation de services PaaS, SaaS ou serverless.
C'est toujours la magie versus le contrôle !

Taille unique ?

Ok, il est important de commencer avec une zone d'atterrissage bien organisée, mais existe-t-il des modèles de zone d'atterrissage qui peuvent garantir le succès ?

Ce qu'il faut garder à l'esprit, c'est que l'infrastructure cloud, tout comme celle sur site, doit répondre à vos besoins et être parfaitement alignée avec l'organisation de votre entreprise : les acteurs, les processus, les périmètres de responsabilité, la stratégie. C'est la loi de Conway.
Utiliser un modèle générique impliquerait également de nombreux compromis.

Les fournisseurs de cloud commencent à offrir des outils pour aider à créer des zones d'atterrissage basées sur les meilleures pratiques et les retours de leurs clients, comme par exemple AWS Control Tower. Ce type d'outil propose de nous assister dans la mise en œuvre, mais ils ne feront pas le travail de conception nécessaire pour nous. De plus, ils sont généralement orientés console et peuvent donc ne pas bien s'intégrer avec une approche d'infrastructure en tant que code. Néanmoins, les choses évoluent rapidement, il faut donc rester attentif.

Et qu'en est-il de la réutilisation d'une zone d'atterrissage mise en place par une autre entreprise ? Lorsque vous copiez une zone d'atterrissage, vous devez être prêt à adapter votre organisation en conséquence pour qu'elle corresponde. Pour une entreprise en cours de constitution, cela peut être possible, mais pour une entreprise déjà établie, devoir adapter l'organisation au produit est très compliqué et va la plupart du temps à l'encontre des enjeux commerciaux.

La construction d'une zone d'atterrissage doit être un processus itératif où l'on ne construit pas directement le produit final, mais où on le peaufine petit à petit avec un processus d'amélioration continue. Le chemin emprunté par les équipes pour parvenir au résultat est au moins aussi important que le résultat lui-même. L'expérience, la maturité et la maîtrise de ce qui a été produit par les équipes sont la meilleure garantie qu'elles seront capables de le maintenir et que la zone d'atterrissage continuera de répondre à vos besoins dans le temps.

Donc, sans surprise, il n'existe pas de modèle unique universel. Il est possible de réutiliser certaines choses, mais le meilleur chemin est de construire votre propre zone d'atterrissage sur mesure pour garantir une productivité maximale et un retour sur investissement optimal.

Comment construire une zone d'atterrissage

Nous avons parlé de l'importance de réaliser une pré-étude sérieuse, mais quels sont les sujets importants ?

Expression des besoins

La zone d'atterrissage doit refléter l'organisation cible, donc la première chose à faire est de décrire précisément l'organisation cible et la gouvernance que vous souhaitez mettre en place. La qualité de l'expression des besoins et la mise en place d'une structure de gouvernance dès le départ seront décisives pour le projet.

La zone d'atterrissage est une couche d'infrastructure au niveau de l'entreprise, c'est-à-dire qu'elle est l'interface entre les fonctions transversales (gouvernance, sécurité, gestion des accès, réseau, etc.) et les équipes de projet.

Les choix de mise en œuvre consistent souvent à positionner un curseur entre le niveau de mutualisation que nous souhaitons obtenir (gouvernance, cohérence, contrôle, rationalisation) et l'autonomie que nous voulons donner aux équipes (autonomisation, agilité, encouragement à l'innovation). Sur ce point, il n'y a pas de bonnes ou de mauvaises décisions, juste un curseur à placer et à déplacer ensuite si nécessaire.

Concernant le périmètre de responsabilité de chaque équipe, notamment pour décrire les interactions entre les équipes transverses et les équipes de projets métiers, la production de RACIs (Responsable, Accountable, Consulté et Informé) ou de RAM (Matrice d'Affectation des Responsabilités) est un réel atout pour faire des choix pertinents concernant la zone d'atterrissage, ainsi que pour partager la même vision à travers l'entreprise.

Implémentation

L'expression des besoins décrit ce qui doit être mis en place. D'autre part, le fournisseur de cloud propose un ensemble générique de ressources qui devraient être vues comme une boîte à outils. La mise en œuvre consiste à donner notre propre sens à ces ressources afin de construire une zone d'atterrissage particulière, tenant compte des spécificités de l'entreprise.

Prenons un exemple concret d'AWS. Une zone d'atterrissage reposera généralement sur plusieurs comptes AWS appartenant à une unique Organisation AWS. Ces comptes peuvent ensuite être divisés en différentes UO (Unités Organisationnelles) et chacun des comptes peut contenir un ou plusieurs VPC (Virtual Private Cloud). C'est notre boîte à outils, avec ces éléments nous avons une liberté totale pour mettre en œuvre ce que nous voulons. Alors, que voulons-nous ?

• La gestion des accès AWS IAM est principalement basée sur des rôles, chacun contenant un ensemble d'autorisations, attribuées à l'utilisateur dans un compte donné. La gestion des coûts permet également de suivre séparément la consommation des différents comptes. La notion de compte peut donc être utilisée pour isoler des « choses » qui devraient être accessibles à différentes populations ou suivies différemment. Il est important de pouvoir donner une règle définissant le périmètre d'un compte dans le contexte de l'entreprise. D'un point de vue opérationnel et pour chaque nouveau besoin métier, il devrait être facile de savoir s'il est nécessaire de créer un nouveau compte ou si nous pouvons réutiliser un compte existant.

• Les OUs (Organizational Units) permettent de regrouper des comptes ayant des points communs, mais elles peuvent aussi porter certaines Politiques de Service qui s'appliqueront à tous leurs comptes enfants. Ces politiques sont directement liées à la stratégie de gouvernance que nous souhaitons mettre en place. Nous devons donc nous demander quelle stratégie de regroupement aurait du sens dans le contexte de l'entreprise, mais aussi si nous voulons réguler l'utilisation du cloud pour certains de ces groupes. Comme pour la notion de compte, une règle globale doit définir ce que signifie la notion d'UO dans notre contexte et ainsi savoir précisément dans quelle UO un nouveau compte doit aller.

Bien sûr, il y a de nombreux autres sujets sur lesquels travailler pour mettre en œuvre la stratégie de l'entreprise :

• Conventions de nommage et d'étiquetage
• Gestion de l'identité, de l'accès, du DNS ou de la conformité
• Granularité des VPC
• Accès au réseau et interconnexion
• Sécurité des flux provenant de ou allant vers Internet
• Plans d'adressage
• Etc.

Dans une approche Infrastructure as Code (IaC), il sera également nécessaire de réfléchir à la granularité des projets d'infrastructure. Avec des outils comme Terraform, il est possible de factoriser le code pour obtenir quelque chose de puissant qui agit en une seule fois sur l'ensemble de la zone d'atterrissage.

D'un autre côté, la factorisation du code implique également un couplage fort entre les ressources, ce qui n'est pas toujours une bonne idée pour les opérations de jour-2. Tout ce qui est développé doit être conçu pour rester agile tout en facilitant la maintenance. Il est nécessaire d'éviter qu'un changement technique mineur puisse avoir un impact sur trop de ressources en même temps, car il serait pratiquement impossible de planifier un tel changement, compte tenu des contraintes de chaque projet impliqué. Cela conduirait à l'immobilisme et à une dette technique grandissante et non maîtrisée.

Conclusion

À travers cet article, je voulais partager un peu de l'expérience que j'ai acquise lors de missions réalisées pour des clients.

Nous avons vu que :

• Le côté magique du cloud peut être pratique mais nous préférons garder le contrôle dans un contexte d'entreprise
• Une zone d'atterrissage efficace est une zone d'atterrissage pleinement alignée avec les spécificités de l'entreprise
• Pour ce faire, la définition des besoins et la mise en place d'une structure de gouvernance sont essentielles
• Un soin particulier doit être pris dans la mise en œuvre pour rester agile tout en facilitant la maintenance, en particulier pour les composants transversaux
• Je suis conscient qu'il reste encore beaucoup à dire sur ce sujet et je serai heureux d'échanger avec vous sur le sujet.

N'hésitez également pas à m'envoyer vos suggestions éventuelles pour améliorer cet article. Merci.