Les bases du cloud : Dix commandements pour des migrations vers le cloud plus rapides et plus rentables
La mise en place d’une base solide pour le cloud n’est pas un « coût de fonctionnement ». Il s’agit d’un investissement essentiel qui permettra de récolter des bénéfices importants en termes de vitesse et de valeur. Les dix actions suivantes sont les plus importantes pour construire cette base.
1. Optimiser la technologie pour accélérer le processus « de l’idée à la vie ».
Que leurs charges de travail soient dans le cloud ou dans des centres de données traditionnels, de nombreuses entreprises ont des méthodes de travail dépassées et bureaucratiques qui entraînent des retards et des frustrations. Votre base de cloud computing doit être construite de manière à permettre la progression rapide d’une idée, de sa conception à sa mise en service dans un environnement de production, sans sacrifier la sûreté et la sécurité.
Dans la pratique, cela signifie qu’il faut automatiser autant d’étapes que possible du parcours de production, notamment les demandes de sandbox, les modifications de pare-feu, la création à la demande d’un grand nombre de réseaux isolés, la gestion des identités et des accès (IAM), l’enregistrement des applications, la génération de certificats, la conformité, etc. L’automatisation de ces étapes est aussi précieuse dans les centres de données traditionnels que dans le cloud. Mais comme le cloud offre des outils uniques qui facilitent l’automatisation, et que le passage au cloud amène les organisations à repenser l’ensemble de leur stratégie, le début du processus de migration est souvent le bon moment pour changer le mode de fonctionnement de l’informatique.
2. Concevoir l’architecture du cloud pour qu’elle puisse évoluer
Si les entreprises s’y prennent bien, elles peuvent construire une architecture de cloud computing basée sur cinq personnes qui peut évoluer jusqu’à en prendre en charge 500 ou plus sans changements significatifs. Au fur et à mesure que l’empreinte du cloud se développe, une architecture bien conçue doit pouvoir accueillir davantage de composants, y compris davantage de modèles d’application, de zones d’isolement et de capacités. La prise en charge de cette évolutivité nécessite des interfaces simples et bien conçues entre les composants. Comme il est difficile d’y parvenir du premier coup, les ingénieurs spécialisés dans l’architecture en nuage qui l’ont déjà fait à grande échelle constituent un avantage considérable.
3. Construisez une organisation qui reflète l’architecture
Selon la loi de Conway, la façon dont les équipes sont organisées détermine la forme de la technologie qu’elles développent. Les organisations informatiques ont une structure fixe pour les équipes, ce qui peut les amener à construire des choses qui ne correspondent pas à la forme de l’architecture du cloud.
Par exemple, certaines entreprises ont une équipe « cloud » distincte pour chacune de leurs unités commerciales. Cela peut conduire chaque équipe à construire des capacités de cloud différentes pour son unité commerciale respective et à ne pas les architecturer pour qu’elles soient réutilisées par d’autres unités commerciales. Cela peut entraîner des ralentissements, voire des retards, lorsque les modifications apportées par une équipe affectent l’utilisation d’une autre.
L’informatique doit d’abord concevoir son architecture de cloud computing, puis mettre en place une organisation basée sur cette structure. Cela signifie qu’il faut mettre en place une organisation composée d’une équipe de base, d’équipes chargées des zones d’isolement et d’équipes chargées des modèles d’application afin de réduire les dépendances et les redondances entre les groupes et, au final, de fournir des composants bien architecturés à moindre coût.
4. Utilisez le cloud qui existe déjà
De nombreuses entreprises craignent de s’enfermer dans un fournisseur de services en nuage (FSC) spécifique et cherchent donc des moyens d’atténuer ce risque. Un modèle commun est une dépendance excessive aux conteneurs, qui peuvent être coûteux et longs et empêcher les entreprises de profiter des véritables avantages offerts par les CSP. Par exemple, une entreprise a créé une plateforme de conteneurs dans le cloud au lieu d’utiliser les outils de résilience propres au cloud. En cas de panne, l’impact a été si important qu’il a fallu plusieurs jours pour remettre les systèmes en ligne, car la défaillance était intégrée au cœur de l’outil non cloud.
Il existe d’autres moyens d’atténuer le risque d’enfermement des FSC, notamment en définissant un délai d’enfermement limité et en mettant en place des pratiques et des systèmes permettant un changement rapide, si nécessaire. En essayant de mettre en place des capacités de résilience non natives, les entreprises sont essentiellement en concurrence avec les FSC sans disposer de leur expérience, de leur expertise ou de leurs ressources. L’origine de ce problème est que les entreprises ont encore tendance à traiter les FSC comme s’ils étaient des vendeurs de matériel plutôt que des partenaires logiciels.
5. Proposer des produits en nuage, et non des services en nuage
Il est courant pour les entreprises de créer des équipes internes de services en nuage pour aider l’informatique et l’entreprise à utiliser le nuage. Généralement, ces équipes de services fonctionnent comme des centres d’exécution, répondant aux demandes d’accès à des services en nuage approuvés. L’entreprise finit par utiliser des dizaines de services en nuage de manière indépendante et sans architecture cohérente, ce qui se traduit par une complexité, des défauts et une faible transparence de l’utilisation.
Au lieu de cela, les entreprises ont besoin d’équipes de produits dédiées, composées d’architectes et d’ingénieurs en nuage expérimentés, pour créer et gérer des produits en nuage simples, évolutifs et réutilisables pour les équipes d’application. Les contraintes imposées par l’alignement sur les produits du cloud peuvent contribuer à garantir que l’entreprise utilise les bonnes capacités de la bonne manière.
Une fois que l’équipe produit dispose d’un inventaire des produits de cloud computing, elle peut encourager les équipes d’application à les utiliser pour accélérer leur migration vers le cloud computing. Toutefois, l’aptitude et l’intérêt de chaque équipe d’application influenceront la rapidité et la facilité avec lesquelles elle adoptera les nouveaux produits de cloud computing. Les équipes ayant peu d’expérience, de compétences ou d’intérêt pour le cloud auront besoin d’une assistance étape par étape, tandis que d’autres seront capables d’avancer rapidement avec peu de conseils. L’équipe produit doit donc disposer d’un modèle opérationnel capable de prendre en charge différents niveaux d’implication des équipes d’application dans le parcours de migration vers le cloud.
Un parcours efficace propose trois niveaux d’engagement (voir l’illustration) :
- Niveau concierge : L’équipe d’engagement construit tout ce dont a besoin une équipe d’application.
- Niveau intégré : Les architectes de l’équipe centrale du cloud sont intégrés dans les équipes d’application pour les aider à créer les bons modèles d’application.
- Niveau partenaire : Une équipe partenaire construit et exécute sa propre zone d’isolement en utilisant les capacités de base de la fondation de base, telles que la mise en réseau, la journalisation et l’identité.
Illustration
Nous nous efforçons de fournir aux personnes handicapées un accès égal à notre site Web. Si vous souhaitez obtenir des informations sur ce contenu, nous serons heureux de travailler avec vous. Veuillez nous envoyer un courriel à l’adresse suivante : info@techgenic.co
En définissant les produits en nuage, les équipes chargées de les prendre en charge et le modèle par lequel les équipes chargées des applications peuvent s’engager avec les équipes chargées des produits, l’entreprise dispose des mécanismes nécessaires pour faire évoluer sa stratégie en nuage de manière réfléchie.
6. Les équipes chargées des applications ne doivent pas réinventer la manière de concevoir et de déployer des applications dans le nuage
Lorsque les entreprises donnent carte blanche aux équipes chargées des applications pour migrer les applications vers le fournisseur de cloud computing, il en résulte une ménagerie de capacités et de configurations de cloud disparates qui rend difficile la maintenance permanente de l’ensemble de l’inventaire.
Au lieu de cela, les entreprises doivent traiter les capacités de déploiement d’une application comme un produit autonome, en résolvant les problèmes communs une seule fois à l’aide de patrons d’application. Les patrons d’application peuvent être chargés de configurer les ressources partagées, de normaliser les pipelines de déploiement et de garantir la conformité en matière de qualité et de sécurité. Le nombre de patterns nécessaires pour prendre en charge l’inventaire des applications peut être faible, ce qui permet de maximiser le retour sur investissement. Par exemple, une grande banque a utilisé avec succès seulement dix patrons d’application pour satisfaire 95 % de ses cas d’utilisation nécessaires.
7. Assurez une gestion ciblée des changements en utilisant des zones d’isolement
Les zones d’isolement sont des environnements en nuage où vivent les applications. Dans le but d’accélérer la migration vers le cloud, les FSC et les intégrateurs de systèmes commencent généralement par une seule zone d’isolation pour héberger toutes les applications. Il s’agit d’une approche à haut risque, car les changements de configuration pour prendre en charge une application peuvent affecter involontairement les autres. À l’autre extrême, une zone d’isolement pour chaque application empêche le déploiement efficace des changements de configuration, car le même travail doit être effectué dans plusieurs zones d’isolement.
En règle générale, une entreprise devrait disposer de cinq à cent zones d’isolement, en fonction de la taille de l’entreprise et de la façon dont elle répond aux questions suivantes :
- L’application est-elle tournée vers l’Internet ?
- Quel est le niveau de résilience requis ?
- Quel est le niveau d’assurance des risques ou la posture de sécurité requise pour les applications fonctionnant dans la zone ?
- Quelle unité opérationnelle a le droit de décider de la manière dont la zone est modifiée à des fins juridiques ?
8. Construire les capacités de base une seule fois pour les utiliser sur tous les FSC
La plupart des entreprises seront présentes sur plusieurs clouds. Le mélange se décompose souvent en environ 60 % de charges de travail dans l’un, 30 % dans un autre et le reste dans un troisième. Plutôt que de construire les mêmes capacités de base (par exemple, connectivité et routage réseau, services d’identité, journalisation et surveillance) dans tous les CSP, les entreprises devraient les construire une fois et réutiliser les capacités dans toutes les zones d’isolation, même celles qui résident dans un CSP différent de la base.
9. Accélérer l’intégration des acquisitions en mettant en place une autre instance du socle de base
Lors d’une acquisition, la fusion des actifs informatiques est difficile et prend du temps. Le cloud peut accélérer le processus de fusion et le rendre moins complexe si l’entreprise acquéreuse crée une « base d’intégration » capable de gérer les actifs de l’entreprise acquise. Ainsi, les politiques d’IAM, de sécurité, de réseau et de conformité déjà en place dans l’entreprise acquise peuvent être maintenues, ce qui permet aux charges de travail existantes de continuer à fonctionner comme prévu. Au fil du temps, ces charges de travail peuvent être migrées de la base d’intégration vers la base principale à un rythme mesuré et prévisible.
Grâce à cette approche, les entreprises peuvent exploiter efficacement leur parc de clouds principal ainsi que celui de l’acquisition en utilisant le même logiciel avec une configuration différente. Cela permet généralement de réduire le temps d’intégration de deux à trois ans à trois à neuf mois.
10. Faire de la sécurité et de la conformité préventives et automatisées du cloud la pierre angulaire
Tous les composants et systèmes logiciels doivent passer par une couche de sécurité. Les mécanismes traditionnels de cybersécurité dépendent de la surveillance et de l’examen humains, qui ne peuvent pas s’adapter au rythme nécessaire pour tirer pleinement parti de l’agilité et de la rapidité du cloud. C’est pourquoi les entreprises doivent adopter de nouvelles architectures et de nouveaux processus de sécurité pour protéger leurs charges de travail en nuage.
La sécurité en tant que code (SaC) a été l’approche la plus efficace pour sécuriser les charges de travail en nuage avec rapidité et agilité. L’approche SaC définit les politiques et les normes de cybersécurité de manière programmatique afin qu’elles puissent être référencées automatiquement dans les scripts de configuration utilisés pour approvisionner les systèmes en nuage. Les systèmes fonctionnant dans le cloud peuvent être évalués par rapport aux politiques de sécurité afin d’éviter les modifications qui mettraient le système hors conformité.
Rédigé par Aaron Bawcom, Sebastian Becerra, Beau Bennett et Bill Gregg, Mckinsey Digital.