Mettre en place une Cloud Digital Factory

Bien que de nombreuses entreprises parlent de « Digital Factory », cette terminologie reste vague et ce concept peut prendre des formes bien différentes.

Revenons d’abord sur la définition de Digital Factory : ce terme englobe beaucoup d’aspects et la mise en place peut se décliner sous différentes formes. Néanmoins, l’idée commune est de mettre en place un cadre permettant de délivrer des projets digitaux (ou une « usine numérique », pour une traduction littéraire).

Cette Digital Factory doit répondre à un ou plusieurs besoins bien identifiés et sur la base desquels la Digital Factory va pouvoir être pensée ou repensée :

• Besoin d’accompagnement des équipes dans la structuration des projets ;
• Besoin d’accélérateurs techniques pour porter l’innovation ;
• Besoin de définir une base sécurisée sur laquelle devront s’appuyer les projets.

Ces besoins peuvent être variés, et une fois clairement identifiés, nous pouvons définir une cible en prenant en compte tous les aspects :

• Organisation, rôles et compétences ;
• Process et planning ;
• Socle technique.

Dans la suite, nous mettrons l’accent sur le socle technique, pour répondre à la question qui nous est souvent posée : comment décline-t-on techniquement une Digital Factory ?

L’un des besoins qui poussent à mettre en place une Digital Factory est de soutenir et de motiver les initiatives en interne pour promouvoir les projets innovants.

Cette innovation technique repose bien souvent sur des plateformes Cloud pour tirer profit de services de pointe : grande capacité de calcul, scalabilité, haute-disponibilité, services spécialisés dans le Machine Learning, l’IoT, etc. C’est donc naturellement que la mise en place d’une Digital Factory peut s’appuyer sur des plateformes Cloud pour faire émerger de nouveaux projets.

Utiliser les services Cloud pour ses projets techniques, c’est un premier pas. Construire un framework pour y implanter une Digital Factory est un sujet plus vaste. Au-delà des projets en eux-mêmes, il est important de repartir des besoins qui ont motivé la mise en place d’une Digital Factory pour préciser la définition qu’on souhaite lui donner dans notre contexte.

Préparer sa Cloud Digital Factory d’un point de vue technique

Avec ces besoins en tête, nous allons définir l’ensemble des activités qui gravitent autour d’une solution hébergée dans le Cloud.

Activités

Reprenons les activités techniques à aborder lors de la mise en œuvre d’un projet dans le Cloud.

Nous retrouvons classiquement un ensemble de sujets que nous vous conseillons d’adresser :

• Solution Cloud : Le cœur du sujet. Une Cloud Digital Factory a vocation à fournir des solutions Cloud. Il n’y a pas de Digital Factory sans solution hébergée dans le Cloud !
• Environnements : Pour toute solution mise en place dans le Cloud, une bonne organisation et isolation des environnements est essentielle. Au-delà des environnements, si plusieurs solutions Cloud sont amenées à cohabiter sur votre plateforme Cloud d’entreprise, l’isolation des solutions ou projets les uns par rapport aux autres est à définir. Les autres aspects s’appuieront sur cette organisation et ce sera donc plus ou moins facilité !
• FinOps : Une démarche FinOps comporte plusieurs étapes. Une première phase consiste à avoir de la visibilité et de la compréhension sur ce qui est facturé. Une optimisation peut ensuite être envisagée, d’un point de vue contractuel mais aussi d’un point de vue architecture et configuration.
• CI/CD : Le déploiement automatisé des applications est un aspect prépondérant d’une démarche DevOps. Y intégrer le déploiement automatisé de son infrastructure devient également incontournable.
• Gestion de la sécurité : Ce premier sujet est déjà vaste. Il comporte, a minima, les notions d’interconnexion réseau, d’authentification pour les services et les développeurs, ainsi que la gestion des secrets et des certificats.
• Protection : Au-delà de la sécurisation de sa plateforme et de son projet, comment réagir en cas d’indisponibilité ? La plateforme mise en place doit permettre d’atteindre l’objectif de disponibilité fixé et d’avoir un process clairement défini pour rétablir le service.
• Monitoring : Afin d’anticiper un quelconque problème, mais aussi de se projeter à plus long terme, l’observabilité de votre plateforme et de vos solutions est essentielle. L’observabilité passe par une approche de monitoring applicatif, de supervision de l’infrastructure tout en faisant un focus particulier sur la sécurité. Enfin, des solutions de monitoring plus proches du métier peuvent être envisagées.

Et évidemment selon le contexte, il y aura potentiellement des éléments supplémentaires à prendre en compte.

Rôles et responsabilités

Pour chacune de ces activités, en ayant toujours en tête les besoins qui ont motivé votre mise en place de Digital Factory, définissez les rôles et responsabilités des équipes en charge de développer les solutions Cloud.

Comme indiqué au préalable, la gestion des environnements et l’isolation des projets posent un premier cadre. Celui-ci est souvent défini par une équipe qui a de la visibilité sur l’ensemble des projets. Donc le choix d’allouer telle ou telle « zone » à un projet ne peut a priori pas se faire par le projet lui-même.

Cependant, pour l’ensemble des autres thématiques, on peut se poser la question d’une responsabilité totale du projet, d’une responsabilité partagée avec une équipe dédiée ou d’une responsabilité complètement déléguée à une équipe dédiée et centrale.

Prenons l’exemple sensible de la sécurité. Une équipe projet qui met en place sa solution est-elle totalement responsable du niveau de sécurité ? Ou bien souhaite-t-on imposer un niveau de sécurité minimal aux projets embarqués dans la Digital Factory ?

En ayant répondu à ces questions, on pourra commencer à mettre en place concrètement sa Cloud Digital Factory. Et soyons agiles, tout cela pourra être enrichi et évoluer !

Priorisation et agilité

Les Cloud Providers mettent à disposition un certain nombre d’outils permettant de vous aider à structurer cette Cloud Digital Factory. Vous avez ainsi tout ce qu’il faut pour mettre à disposition une Cloud Digital Factory totalement industrialisée.

Selon la répartition des responsabilités définie et l’ensemble des activités à prendre en compte, cela peut être plus ou moins costaud à mettre en place !

Essayons là encore d’être agiles et de prioriser les actions. Quelques questions à se poser pour prioriser les actions :

• Qu’est-ce qui est critique ?
• Qu’est-ce qui ferait gagner un temps précieux en étant automatisé ?
• Quel est l’impact de cette configuration sur les projets ? Cela met-il en péril le time-to-market des projets ?

Prenons deux exemples :

1. Une entreprise avec des forts enjeux de sécurité. Cette entreprise n’autorisera aucun déploiement de solution dans le Cloud sans avoir l’assurance d’un niveau élevé de sécurité. Le responsable sécurité de l’entreprise en porte l’entière responsabilité. La mise en place d’une Digital Factory est motivée par l’assurance de fournir un cadre sécurisé duquel les projets ne pourront pas s’affranchir.
2. Une entreprise qui utilise le Cloud pour ses solutions depuis déjà quelques temps mais qui souhaite monter une Cloud Digital Factory pour inciter plus d’équipes à tirer profit des services Cloud. Ce sera également l’occasion de maîtriser la plateforme avec une bonne gestion des coûts, de la sécurité, de la performance, etc.

Dans le premier exemple, les actions visant à sécuriser les projets auront tendance à être mises en priorité forte par rapport à des actions visant à optimiser les coûts. Les projets ne pourront déployer leurs solutions dans le Cloud qu’une fois que le cadre fourni sera suffisamment sécurisé.

Au contraire, dans le second cas, l’entreprise ne souhaite pas trop impacter le time-to-market des projets et pourra construire un cadre de façon progressive. La priorité pourra, par exemple, être mise sur les actions visant à fournir des environnements de façon automatisée pour attirer les équipes projets, puis travailler sur l’optimisation des coûts, avant d’améliorer le niveau de sécurité.

A noter : Un contexte alternatif pourrait être constitué d’une zone sécurisée et d’un espace de « Lab » isolé permettant aux équipes projets de tester de nouveaux services Cloud sans contrainte de sécurité, ni risque évidemment.

Toujours dans une démarche Agile et DevOps, avoir un projet complice pour tester ce nouveau framework sera un atout pour détecter au plus tôt d’éventuels soucis.

Construire sa Cloud Digital Factory dans Azure

Pour illustrer la mise en place d’une Cloud Digital Factory, nous allons voir qu’Azure met à disposition plusieurs leviers pour vous aider.

Environnements

Sur le premier thème évoqué, la gestion des environnements ou encore l’organisation des ressources, je vous conseille de vous appuyer les différents niveaux d’organisations :

• Les Management Groups ;
• Les Subscriptions ;
• Les Resource Groups.

Pour plus d’informations, je vous invite à consulter la documentation Microsoft sur « Comment organiser vos ressources Azure efficacement. »

Plusieurs patterns proposés peuvent donner des idées, mais c’est surtout le fonctionnement de l’entreprise et des équipes IT qui guidera votre organisation de ressources. Vous pourrez ainsi définir ce qu’est un « projet » dans votre contexte.

Exemple 1 – Un projet peut être un Management Group constitué de 3 subscriptions, une par environnement (Dev, Test, Prod).

Exemple 2 – Un projet peut être un ensemble de 3 Resource Groups, un par environnement. Les Resource Groups étant dispatchés dans des subscriptions liées à un environnement.

A noter : Vous pouvez ajouter plusieurs niveaux de Management Groups, contrairement aux Subscriptions ou Resource Groups.

Guidelines et Compliance

Sur l’ensemble des autres thèmes : Sécurité, Monitoring, FinOps, CI/CD… La cible souhaitée et les niveaux de responsabilités sont définis. Au-delà de la documentation nécessaire qui en est sortie, mettre en place concrètement ces bonnes pratiques c’est mieux.

Encore une fois, selon le niveau de responsabilités des équipes, il est possible d’avoir une approche plutôt restrictive ou permissive. Néanmoins, même avec une approche permissive, vous pouvez avoir de la visibilité sur ce qu’il se passe et évaluer le taux de conformité de ces bonnes pratiques. Vous pourrez ensuite accompagner les équipes projets pour améliorer ce taux de conformité ou « compliance ».

Pour restreindre l’usage des services Azure et/ou évaluer le taux de conformité par rapport à vos guidelines, les policies Azure vous seront indispensables.

Sur ce sujet, je vous propose de consulter notre précédent article de blog.

Ces policies sont également intéressantes pour customiser les audits de sécurité mis à disposition par Azure Security Center. En activant Security Center, on se retrouve bien souvent avec des faux positifs car les éléments évalués ne correspondent pas au contexte.

Pour gérer ces policies à grande échelle, vous pouvez les appliquer aussi bien au niveau des Resource Groups, des Subscriptions ou des Management Groups… D’où l’importance d’avoir une bonne organisation de ses ressources.

Accélérateurs

Une Cloud Digital Factory n’a pas pour unique vocation de sécuriser les projets : l’objectif plus intéressant est de faciliter l’adoption du Cloud par les projets. Et on souhaite pouvoir fournir des accélérateurs via la Digital Factory.

Les policies peuvent avoir une vocation restrictive mais peuvent aussi être un facilitateur ! Par exemple, nous pouvons automatiquement préconfigurer un service dès son déploiement :

• Activer la collecte des logs d’une base Azure SQL dès sa création pourra aider le projet à cibler l’origine d’un problème ;
• Configurer automatiquement l’intégration au réseau et la configuration DNS d’un App Service pour que celui-ci puisse résoudre des noms privés.

Pour aller plus loin, vous pouvez également utiliser les blueprints.

Un blueprint peut être vu comme un calque qui va être appliqué à une subscription (pas au niveau du Resource Group, ni du Management Group). Un blueprint suit le même principe qu’une policy : on a une définition du blueprint avec une notion de version supplémentaire, puis l’affectation d’une version d’un blueprint sur une subscription.

Ce calque peut contenir plusieurs types d’objets (nommés artifacts) :

• Des Resource Groups: lorsque le blueprint va être affecté à une subscription, les Resource Groups définis au sein du blueprint seront créés dans la subscription.
• Des policies assignment: lorsque le blueprint va être affecté à une subscription, les policies définies dans le blueprint seront affectées à la subscription ou à un des Resource Groups définis dans le blueprint.
• Des roles assignment : lorsque le blueprint va être affecté à une subscription, une affectation de rôle va être faite à une ou plusieurs identités configurées sur le périmètre de la subscription ou sur un Resource Group défini dans le blueprint.
• Des templates ARM: ce dernier type d’artifact vous permet de déployer des services dans la subscription sur laquelle vous appliquez le blueprint. Par exemple, vous pouvez choisir de déployer un service Log Analytics dans chaque subscription pour y collecter tous les logs issus des services de la subscription.

Enfin les accélérateurs peuvent être des outils variés, non spécifiques au Cloud Provider, mis à disposition des projets, pour faciliter leur configuration

Automatisation

L’hébergement de projets dans le Cloud apporte de la souplesse et favorise donc naturellement le déploiement automatisé d’environnements et de projets, ce n’est plus une nouveauté ! Une Cloud Digital Factory capable de mettre à disposition des environnements pour les projets de façon totalement automatisée sera pleinement efficace.

Nous n’allons pas détailler ici les technologies vous permettant d’automatiser les déploiements. Vous trouverez tout ce qu’il faut pour déployer les environnements et services Azure :

• Infrastructure as code : Terraform, ARM Templates…
• Scripts : az cli, powershell
• API / SDK : .Net, Java…

Pour ce qui est des services non spécifiques Azure, ce sera évidemment au cas par cas.

Le sujet principal est de bien définir le process de déploiement en accord avec le framework défini et les responsabilités identifiées. Cela permettra de découper le déploiement en plusieurs étapes voire modules qui font sens. Cette modularité sera bénéfique pour faciliter les évolutions de la Cloud Digital Factory, qu’elles soient techniques ou organisationnelles.

Remarque : Nous ne sommes pas rentrés dans le détail technique de la mise en place d’une Cloud Digital Factory, tout simplement car cela peut prendre des formes très variées et sera fonction des besoins et objectifs. Néanmoins, quelques services incontournables dans un chantier de mise en place de Cloud Digital Factory dans Azure ont été évoqués.

L’agilité pour une mise en place efficace

Une Cloud Digital Factory va donc définir un framework, plus ou moins rigide selon les objectifs définis. Toutefois, pour être efficace et adoptée, la mise en place de ce framework doit se faire de façon agile. Un des écueils de ce type de chantier est de se retrouver dans un tunnel sans fin ou en gestion cycle en V. Alors selon le contexte, travaillez avec des projets pilotes pour avoir des feedbacks réguliers et si possible construisez ce framework brique par brique.

En savoir plus sur les Digital Factories

Vous souhaites approfondir le sujet ? Les experts Cellenza ont rédigé une série d’articles autour des Digital Factories :

• Créer une Digital Factory : pourquoi et comment ?
• Digital Factory : quelle stratégie et quelle vision ?
• Digital Factory : retour d’expérience de Saint Gobain – Aari
• Comment organiser les équipes dans une Digital Factory ?
• Digital Factory : quel socle technique mettre en place ?
• Financement et budget d’une Digital Factory