Constituer une équipe de référents : pourquoi faire ?

27 July 2020

Après des semaines de débats, d'analyses et d'évaluations, la décision est prise : vous allez migrer vos infrastructures vers le cloud. Mais comment s'y prendre ? Par où commencer ? Qui doit s'en occuper ? Pour répondre à ces questions et aux nombreuses autres qui se posent et créer les conditions du succès, je vous propose une petite série d'articles sur la constitution d'une équipe d'éclaireurs qui aura pour mission de reconnaître le terrain, identifier les problèmes (et apporter des solutions !) et préparer, en plus de la technique, les éléments de processus et les bonnes pratiques. Commençons sans plus attendre....

Une équipe de référents, pourquoi faire ?

L'équipe de référents est une unité spécialisée constituée de quelques un de vos ingénieurs IT, une avant-garde qui va identifier et lever les premiers obstacles sur votre chemin vers le cloud. Ses tâches sont essentiellement techniques avec :

1. le développement de nouvelles architectures de référence

Bien-sûr, on pourrait migrer vers le cloud et reproduire à l'identique les infrastructures qui existent dans vos data centers. Si c'est la solution la plus simple (quoique...), il est quand-même dommage de se donner le mal de tout changer pour retrouver la même chose, n'est-ce pas ? Les référents cloud ont donc la tâche de définir les architectures techniques qui seront mises en place, de façon à concrétiser les bénéfices du cloud pour l'entreprise, et tirer parti notamment :

de la capacité d'adaptation des infrastructures aux besoins : adapter automatiquement le nombre de serveurs à la charge de travail, et ne plus sur-dimensionner les serveurs "pour le futur",
de la haute disponibilité : utiliser les mécanismes de redondance du cloud pour assurer la disponibilité de vos applications les plus critiques,
les services packagés comme les bases de données et les services d'analyse big data, simples à mettre en place dans un monde cloud.

Les référents vont ainsi définir, tester et valider des architectures incluant les serveurs, les bases de données, la sécurité, la redondance, etc, et constituer une bibliothèque d'architectures de référence applicables à l'ensemble du patrimoine applicatif.

Cet investissement de ressources dans la création d'une bibliothèque d'architectures est essentiel pour le succès de la migration. En plus de favoriser la prise de compétence par les référents et de les familiariser avec les possibilités offertes par le cloud, cela permet de tester et d'éprouver ces designs pour garantir qu'ils pourront soutenir votre infrastructure de production. Faire l'économie de cette étape de préparation c'est, dans le meilleur des cas, se priver des avantages du cloud, et dans le pire des cas, prendre le risque de mettre en place des architectures et des infrastructures qui ne seraient pas suffisamment mûres pour la production.

Bien-sûr, le transfert des applications et des données ne va pas se faire du jour au lendemain ; c'est un processus qui prendra du temps et qui va donc exiger que votre data center soit connecté à son équivalent cloud, dans un mode hybride. Il appartient encore aux référents de trouver la meilleure façon d'interconnecter les data centers, avec le débit et la redondance nécessaires.

2. la mise en place d'outils et procédures de développement Infrastructure as Code

Au-delà des aspects purement techniques de l'architecture, la clef pour bénéficier de tous les avantages que le cloud peut offrir est la capacité d'adresser les services du fournisseur par une interface programmatique (API). L'API est une sorte de connecteur logiciel qui permet de connecter des applications tierces à une autre application qui "expose" cette API. Dans notre cas, le connecteur permet à des programmes de manipuler les infrastructures dans le cloud : créer des réseaux, des serveurs, des bases de données, etc... et d'organiser tout cela de la façon dont on le souhaite. Il existe des programmes qui permettent de décrire l'infrastructure que l'on souhaite créer et qui vont transcrire cette description en commandes pour le cloud, transmises via l'API. Ainsi, on peut créer des infrastructures simplement avec des lignes de commandes (relativement) simples, telles que :

exemple (simplifié) de code Terraform qui crée un serveur dans le cloud d'Amazon.

Cette technique, que l'on appelle "Infrastructure as Code" présente de nombreux avantages. Elle permet notamment de :

décrire toute son infrastructure sous forme de scripts qui peuvent être versionnés et archivés, comme du code traditionnel,
déployer très vite des infrastructures archivées, de les répliquer ou de les re-déployer en cas de besoin,
changer de nombreux aspects de l'infrastructure avec un minimum d'efforts,
développer et de tester les infrastructures avant des les passer en production.

Cette capacité à gérer des infrastructures de la même façon que du code informatique impose de nouvelles façons de travailler et la mise en place de nouveaux outils pour les équipes d'infrastructure, similaires aux outils utilisés par les développeurs : un environnement de développement, des infrastructures de tests, un pipeline de développement et d'intégration continue. Ce sera donc le rôle de l'équipe de référents de choisir ces outils, de les mettre en place et de créer les procédures d'utilisation et d'exploitation associées.

3. la création d'une bibliothèque de modules de base

A partir des architectures définies et à l'aide des outils d'Infrastructure as Code, les référents vont pouvoir créer des modules de base réutilisables qui serviront à la construction d'infrastructures plus complexes à la manière de Légos : leurs modules de base sont les briques Légos dont ils vont définir la forme et la taille, puis à partir de ces briques ils vont créer des infrastructures prêtes à l'emploi, réplicables et ré-utilisables à l'envie. La combinaison des modules permettra de créer une grande variété d'infrastructures sans avoir à reproduire tout l'effort de conception. Les modules de base et les architectures seront conservés dans une bibliothèque accessible le moment venu par tous leurs collègues. Cela garantit l'utilisation de code éprouvé, porteur des bonnes pratiques d'architecture et de sécurité définies par le service IT. Ainsi, l'Infrastructure as Code :

accélère le déploiement d'infrastructures,
réduit le risque d'erreurs
et garanti l'application des bonnes pratiques !

Cependant, ne sous-estimez pas l'effort que demande sa mise en place : décrire des infrastructures qui soient aptes à être déployées en production exige une bonne maîtrise des architectures cloud, du langage de développement choisi et un effort de développement conséquent pour créer des infrastructures aux normes de production, c'est à dire non seulement sécurisées et résilientes, mais aussi conçues de telle façon que l'ajout d'infrastructures ne perturbe pas les éléments déjà en place. Cela demandera beaucoup de temps et d'efforts à vos référents, mais la récompense est une infrastructure solide à même d'accueillir la production informatique de votre entreprise.

4. la création d'un Minimum Viable Cloud puis d'une Landing Zone

Afin de démontrer la viabilité du cloud à l'ensemble des parties prenantes, les référents construiront un Minimum Viable Cloud destiné à :

réaliser un premier "quick-win" pour montrer et mettre en application les progrès de l'équipe,
mettre à l'épreuve certains choix d'architecture et d'implémentation,
éprouver les outils choisis pour la mise en place de Infrastructure as Code.

Le Minimum Viable Cloud sera prolongé par la réalisation d'une Landing Zone complète. Cette "Landing Zone" est la zone d'atterrissage de votre cloud, à partir de laquelle toutes les infrastructures à venir seront construites. Pour ma part, j'y mets toutes les infrastructures relatives à la surveillance (monitoring,logging et alerting) et à la gestion de la sécurité (droits d'accès et gestion des mots de passe et clefs d'encryption). Comme la landing zone constitue le point de départ de vos infrastructures, il faut prendre beaucoup de soin lors de sa construction. Ainsi, les référents auront à :

identifier les besoins de monitoring et d'alerting, et les traduire en infrastructures Cloud puis en code,
choisir et mettre en place les solutions de sécurité pour la gestion des identités et des secrets (connexion Active Directory, gestion des clefs d'encryption, etc),
identifier les besoins de conformité et mettre en place les solutions appropriées.

5. la réflexion sur la stratégie de gestion des utilisateurs et des environnements

Au-delà de l'apprentissage des référents et de la création d'une Landing Zone, il faut penser à la mise en production et aux besoins des ingénieurs qui vont développer et maintenir les infrastructures. En développement classique, on utilise au moins 3 environnements :

un environnement de développement,
un environnement de test et d'intégration,
un environnement de production pour développer, tester et exploiter le logiciel.

Dans notre contexte d'Infrastructure as Code, les besoins sont similaires et les mêmes questions se posent :

de quels types d'environnement avons-nous besoin ?
faut-il un compte cloud unique qui regroupera toutes les environnements, ou un compte dédié pour chaque ?
faut-il un compte de développement pour chaque ingénieur ou un pour tous ?
comment gérer la production ? Comment séparer les infrastructures pour limiter les risques de sécurité et augmenter la disponibilité ?

Des réponses à ces questions dépendront les possibilités d'apprentissage de vos ingénieurs, leur capacité à innover et la stabilité de vos infrastructures de production. Nous aurons l'occasion d'aborder les réponses possibles et leur impact dans un prochain billet de blog.

6. la mise en place de la gestion des identités et des assets dans le cloud

A l'intersection de la stratégie des comptes utilisateurs, des environnements et de la gestion de la sécurité, la gestion des identités et des assets nécessite une réflexion particulière.

J'ai connu une société avec des infrastructures critiques et des données hautement confidentielles qui avait, comme on peut s'y attendre, un data center hautement sécurisé. Mais 540 personnes avaient accès à ce data center. Beaucoup ne savaient même pas qu'elles avaient ce privilège, mais comment garantir la sécurité si le data center est plus peuplé qu'un hall d'aéroport ?

oc_referents_legos_minifigure_measurements_01

De mon point de vue, la sécurité et la stabilité imposent des accès extrêmement limités, attribués pour des durées courtes, pour des actions connues et ciblées. Pour votre cloud, c'est la même chose. Qui doit y accéder ? Pour y faire quoi ? Avec quels droits ? Il appartient aux référents de poser les bases de la réflexion en consultation avec les intervenants de la sécurité, de la conformité (compliance) le cas échéant, et en prenant en compte les contraintes opérationnelles (mise en service et maintenance) et liées au développement des infrastructures. Les tables RASCI (tables de responsabilités) et des ébauches de politiques de sécurité seront les résultats tangibles de cette activité.

7. établir la gouvernance des coûts

Dans le cloud, à la différence de ce qui se passe dans un data center classique, tous les intervenants peuvent être à l'origine de coûts, qui vont se cumuler et peuvent vite devenir importants. Si chaque ingénieur peut développer ses infrastructures, et que lorsque vient le vendredi soir tout le monde se sauve en laissant tourner inutilement des infrastructures de test dans le cloud, les coûts vont se cumuler très rapidement. Et si certaines infrastructures sont très bon marché, d'autres en revanche peuvent être extrêmement coûteuses. Il s'agit s'agit donc d'établir une gouvernance des coûts qui viendra en complément de la gestion des utilisateurs :

quelles sont les infrastructures que les ingénieurs peuvent construire, en fonction de leurs postes et projets ?
comment les coûts individuels sont-ils gérés ? Faut-il un budget d'équipe ou un budget personnel ? Ou les deux ?
faut-il un budget par projet ? Par îlot d'infrastructure / par service ?
comment mesurer les coûts ? Avec quels outils, sur quelle période ?
qui est en charge de définir et d'attribuer les budgets ? De mesurer les coûts ? De faire respecter les budgets ?
que se passe-t'il en cas de dépassement ?

Le cloud peut conduire à des belles économies, et permettre d'exploiter de nouvelles opportunités d'affaire pour l'entreprise. Mais mal gérés, les coûts peuvent devenir un véritable problème. On entend parfois parler de sociétés qui ont "été dans le cloud", puis qui en sont revenues, jugeant que l'investissement était trop cher. Leur point commun ? Aucune n'avait mis en place de gouvernance des coûts.

8. répondre aux questions et évangéliser

En dehors des tâches techniques, les référents ont aussi la tâche de répondre aux questions de leur camarades ingénieurs IT et à celles des gens du métier, et notamment aux questions « comment fait-on pour ».

Ils ne sont pas sensés répondre à brûle-pourpoint, mais ils doivent s'engager à trouver une réponse, dans un mode exploratoire ; c'est la condition pour que eux et le cloud gagnent en crédibilité. Ils doivent montrer l'utilité du cloud, sa capacité à simplifier le travail IT et à favoriser l'innovation. Ils doivent ensuite faire la promotion de leurs découvertes tant auprès de la technique que du business. En un mot, ils doivent évangéliser pour susciter l'adhésion de tous et la demande qui va soutenir le projet dans les phases difficiles.

9. mettre en place les formations

Profitant de leur avance sur leurs collègues de l'IT, les référents vont participer à la sélection des formations des fournisseurs, et proposer leurs propres formations, en fonction des objectifs de la société et des compétences techniques au sein des équipes IT. Les formations peuvent concerner les aspects généraux du cloud, des spécialisations réseaux, sécurité, etc... ou encore l'automatisation. Des formations internes sur les possibilités du cloud et les avantages qu'elles procurent peuvent être conduites à destination du management et du business pour les sensibiliser aux nouvelles possibilités qui s'offrent à eux.

10. préparer l'après "legacy"

Lorsque les tâches de maintenance des équipements auront disparues, que fera l'équipe IT ? Comment sera t'elle organisée, quelles seront ses tâches ? Quelles sont les compétences qui seront nécessaires, et celles qui ne le seront plus ? Ces questions doivent être anticipées de façon à ce que les équipes soient capables d'opérer et d'entretenir vos infrastructures cloud aussi efficacement qu'elles opèrent et maintiennent aujourd'hui vos infrastructures sur site. Il en va de la capacité de votre informatique à soutenir votre business.

Ces 10 points couvrent tous les aspects techniques, opérationnels et promotionnels de l'introduction du cloud dans votre société. Les référents cloud vont véritablement partir en éclaireurs pour découvrir un nouveau monde. Ils vont en ramener de nouvelles façons de travailler pour l'IT, de nouvelles opportunités pour le business, et faire rayonner dans l'entreprise une nouvelle culture, une culture qui dit "oui, c'est possible" et qui va favoriser la mise en place rapide d'infrastructures pour l'expérimentation et la production. Voyons, dans le prochain chapitre, comment choisir ces éclaireurs.