En cette période de crise, tout discours basé sur des éléments de réassurance permet de passer facilement au-dessus des barrières de sécurité de notre naïveté largement mise à mal par le contexte ambiant.
Il n’est donc pas surprenant de constater une recrudescence importante, ces derniers temps, des actes cybercriminels : phishing, man in the middle, brute force.
Dans le même esprit, quoique moins dangereux à court terme, les sirènes du multi-cloud chantent de plus en plus fort ces dernières semaines. Il faut dire qu’elles ont des arguments à faire valoir :
- Une indépendance vis-à-vis d’un fournisseur (et donc un levier de négociation)
- Une résilience en cas d’incident chez un CSP (Cloud Service Provider, ici AWS, Azure et GCP)
- Une approche « best of breed” tirant parti du meilleur des différents mondes
- Un choix plus large de solutions pour ses développeurs et autres acteurs de la DSI
Mais en se bouchant les oreilles et en ouvrant les yeux 😉 que constate-t-on ?
Un avantage financier très relatif
En reprenant point par point les éléments évoqués ci-dessus :
La capacité de négociation est concrètement aujourd’hui très limitée, certains acteurs n’en offrant pas ou très peu, et jamais sans contrepartie (prestations de conseil « incluses » facturées à des montants déraisonnables, packages incluant des licences…).
De même, on sait maintenant toute la complexité de penser une architecture réalisée pour un CSP, l’indépendance est donc toute relative, avec des coûts de réversibilité et de transition élevés.
Enfin, et par expérience, il faut apporter au crédit des CSPs qu’ils ont plutôt tendance à réduire dans le temps le coût unitaire d’utilisation de leurs ressources rendant ainsi peu probable notre envie d’ailleurs sur ce simple critère.
La résilience oui, mais à quelles conditions ?
La capacité à résister à un incident touchant un cloud ou une région en particulier est réelle en théorie.
En pratique, elle se heurte toutefois à trois limites principales :
- Pour qu’une application s’appuie de façon identique et complètement redondante sur deux CSP différents, elle devra se limiter aux services communs entre les CSP, souvent ceux avec le moins de valeur ajoutée
- Il faudra mettre en place une solution de GSLB (Global Server Load Balancing) afin de recevoir et rediriger les flux qui deviendra un SPOF de fait (même si redondé…) et qui devra être hébergé dans un 3e cloud ou via une offre SaaS dont on aura la garantie qu’elle ne s’appuie pas sur les infrastructures qu’on cherche à protéger (Good luck with that …)
- Certains services n’ont pas vraiment d’équivalent !
Multicloud ou multi-hébergeurs ?
Nous nous retrouvons donc souvent à déployer finalement beaucoup de IaaS et utiliser ses clouds en mode « hébergement » dans un cercle vicieux : si on est multi-cloud et que l’on veut pouvoir déplacer ses applications, il faut se limiter à utiliser des services « simplement équivalent » entre le CSP, souvent du IaaS.
De même, ce cercle vicieux touche aussi la production : il est complexe d’avoir de l’expertise sur toutes les solutions, il est donc préférable d’aller moins profond sur chaque CSP, et donc de se limiter souvent aux services « de base »
L’approche « Best of breed » est séduisante dans un environnement cloud : pourquoi ne pas bénéficier des services là où ils sont les meilleurs ? par exemple l’identité Azure AD, K8S chez GKE et son stockage sur AWS S3 ?
Une explosion de la complexité !
En dehors des problématiques de résilience vues au-dessus, de la complexité inhérente générée sur l’architecture, c’est surtout en termes de compétences que le bât blesse : chaque CSP utilise ses propres termes, concepts et pratiques (comparez les VPC GCP, VPC AWS et VNET Azure par exemple !), qu’il faut impérativement maitriser pour offrir un support de qualité.
Il y a déjà beaucoup de tension sur le marché des experts et des architectes pour chacun des CSP, imaginez l’ampleur du problème si vous avez besoin de personnes qui en maitrisent deux ou trois !
Un relâchement de la sécurité
Ceci vaut aussi dans le cas où le multi-cloud vient pour « ouvrir l’horizon » et permettre à tous les acteurs de choisir la solution qui leur convient.
Sauf à penser « vraiment » DevOps et transmettre l’intégralité de la responsabilité du run aux équipes en charge des projets, les contraintes d’opérations vont très rapidement se faire sentir et se multiplier.
Les coûts associés à la maintenance de ces N piles technologiques s’envoleront de concert.
De plus, un fort enjeu de sécurité apparaît souvent : la complexité inhérente à chaque CSP empêche de concentrer ses efforts sur une politique de sécurité commune et cohérente.
Nous avons des exemples très concrets de clients ayant une politique… par CSP, la politique générale ne pouvant s’appliquer dans chaque cas, et les investissements étant généralement limités à la maîtrise du cloud majoritairement déployé.
Quelques recommandations
Dans cet article, nous avons identifié plusieurs limites à l’approche multi-cloud :
- Le besoin de compétences et de moutons à 5 pattes
- Une capacité très faible à utiliser les différentes solutions de résilience
- Une capacité limitée à tirer parti de l’essence des CSP, c’est-à-dire leurs services PaaS
Des solutions existent pour pallier ces limites : Anthos dans un cadre K8S uniquement, Clougnitive en traitant les différents CSP comme des hébergeurs secs, mais il s’agit de réponses avec des périmètres relativement restreints et donc forcément décevants.
Mais alors, quelle position adopter ?
Journeys to cloud
Les anglo-saxons parlent souvent de “Journey to the Cloud”. Et c’est vrai qu’aller dans le cloud peut être un véritable voyage technique, organisationnel, culturel et même philosophique !
Il est donc important, avant d’envisager plusieurs “Journeys to the Clouds”, d’arriver au bout du premier !
Alors, concrètement, c’est quoi arriver au bout de son voyage “Public Cloud” ?
Tout d’abord, il y a un mot très important et qu’il ne faut jamais oublier c’est “Public”.
Concrètement, cela veut dire que par défaut et par construction, toute ressource créée chez un CSP est automatiquement accessible “publiquement”. En conséquence, toute interconnexion avec un réseau privé sera superfétatoire tant d’un niveau de l’accessibilité que du niveau sécurité.
En effet, l’accès public ne sera jamais “supprimé” mais tout au plus “restreint”. Certains diront que seuls des “private connections” sont fiables d’un point de vue QoS. Sur le papier, c’est vrai.
Mais combien d’entre nous ont poursuivi leurs activités dans cette période de crise sanitaire grâce à Teams, Meet ou Zoom applications extrêmement exigeantes en termes de latence mais fonctionnant complètement sur le réseau public ?
Dans la vraie vie, une connexion Internet fibre adossée à une GTR faible fonctionne au moins aussi bien qu’une liaison dédiée.
Journey to security !
L’élément à prendre en compte ensuite est évidemment la sécurité et l’une de ses briques fondamentales est la gestion des identités et des accès.
Rappelons-le une nouvelle fois : toute ressource créée chez un CSP est par défaut et par construction “publique”.
La presse relate régulièrement la diffusion large d’informations confidentielles due, non pas à l’architecture technique du CSP mais à l’incompétence de ses utilisateurs.
En conséquence, il est indispensable de maîtriser la gestion des accès aux différents services proposés par un CSP avant d’envisager de voyager au milieu de ceux-ci.
Mais alors comment pourrais-je accéder aux applications que je souhaite porter dans le Cloud ?
Simplement en utilisant pour celles-ci les mêmes technologies que les CSP, eux-mêmes, utilisent mais également la plupart des fournisseurs SaaS, à savoir oAuth ou autres OpenID.
L’effort pour porter les systèmes IAM internes vers ces technologies peut paraître important mais il est indispensable pour réussir son voyage, surtout si l’on envisage des voyages ultérieurs vers d’autres CSP 😉
Journey to maturity
Ensuite, il faut découpler au maximum les interactions entre les applications de son Système d’Information (les “micro-services” dans ce domaine sont un Graal mais non indispensables à un voyage réussi) afin de minimiser le “blast radius” en cas d’incidents et faciliter les portabilités incrémentales.
Mais tout cela ne peut être réalisé sans une organisation en réelle capacité d’exploiter un “Public Cloud”. Une montée en compétence des forces en place peut s’avérer nécessaire sur les domaines tels qu’Agile, DevOps, Sécurité Cloud, …
De plus, la concurrence féroce que se livrent les principaux acteurs du marché les incite à innover en permanence tant sur les fonctionnalités de leurs services que sur leur mode de facturation.
Il est donc indispensable de mettre en place une organisation capable d’évangéliser dans les équipes les apports de ces innovations dans des domaines aussi différents que FinOps, Serverless, Monitoring, Multi-AZ, new regions, Edge Computing, …
Une fois atteint un bon niveau de maturité de son organisation lors d’un “Journey to the Cloud”, d’autres voyages vers d’autres CSP peuvent alors être envisagés en envoyant en éclaireurs des composants métiers ayant une faible adhérence avec le reste du Système d’Information.
Certes mais alors, que faire ?
Nous avons constaté que le multicloud est souvent organique et imposé, notamment par des départements « data » ou « digital ». En tant qu’acteur de la DSI, nous espérons que cet article vous aidera à spontanément identifier les limites et savoir les expliciter auprès de vos partenaires.
Notre recommandation est en conclusion d’investir tout d’abord dans UN cloud, de le maitriser réellement, dans sa profondeur et sa richesse.
C’est cette stratégie qui nous parait apporter les meilleurs bénéfices à terme :
- Résilience à travers les multiples régions / zones de disponibilité
- Utilisation des services à forte valeur ajoutée PaaS (Lambda, Kendra, GKE…)
- Sécurité renforcée en concentrant ses efforts
- Maitrise des coûts en limitant les besoins de support et les compétences rares
- Meilleure qualité de service à travers une meilleure maitrise d’un socle technologique unique
La première “Journey to the cloud”, menée avec succès, produira une architecture, une sécurité, une infrastructure et une production aux bons niveaux de maturité. L’organisation pourra alors ( et seulement alors) envisager sereinement et probablement avec beaucoup de réussites ses autres voyages vers d’autres CSP.
