Adoption du cloud avec le socle de sécurité intégré

L'adoption du cloud consiste à décider quels systèmes doivent quitter votre centre de données, ce qui doit changer en matière de responsabilités, de revue des coûts et de compétences avant qu'ils ne partent, et dans quel ordre la migration doit se faire. SEYA Group mène cette décision sous la forme d'une courte mission de conseil, de sorte que le dossier présenté à votre conseil d'administration repose sur votre propre parc et vos propres factures. Le socle de sécurité, dont l'identité, la journalisation et les frontières réseau, fait partie de ce dossier.

Pour les programmes de migration où la sécurité n'est pas le moteur, notre société sœur Cloud Architects Expert pilote l'architecture et la migration.

À qui s'adresse ce service

Aux CIO et CTO à qui l'on a demandé « pourquoi exploitons-nous encore notre propre matériel ? » et qui veulent une réponse qu'ils peuvent défendre. Aux responsables informatiques dont le bail du centre de données, le renouvellement du matériel ou le contrat de support arrive à échéance et qui doivent savoir quoi renouveler. Aux architectes d'entreprise qui ont une cible en tête et doivent régler les questions de responsabilités et de coûts avant que quiconque n'ouvre un compte.

Si votre équipe sait déjà quelles applications migrent et a besoin qu'elles soient migrées, commencez plutôt par plateforme cloud et migration. Cette page concerne l'étape qui précède.

Les problèmes que nous résolvons

• Le centre de données fixe la limite de l'endroit où le logiciel peut tourner et de sa vitesse d'exécution.
• Les dépenses d'infrastructure sont difficiles à rattacher aux équipes et aux produits qui les consomment.
• Personne n'a convenu de qui sera responsable d'un compte cloud, de ses factures et de ses accès après la migration.
• Différents groupes démarrent discrètement leurs propres empreintes cloud sans règles communes.
• La direction veut une recommandation indépendante et n'a jusqu'ici entendu que des fournisseurs.

Ce que vous obtenez

• Dossier d'adoption. Une recommandation écrite de ce qui doit migrer, de ce qui doit rester et de ce qui doit être vrai au préalable, avec les options envisagées et les raisons pour lesquelles elles ont été écartées.
• Profil de coûts. Une comparaison entre votre capacité actuelle, allumée en permanence, et une dépense à la consommation pour les charges de travail que vous décrivez, montrant où la capacité reste inutilisée aujourd'hui. C'est un intrant pour votre dossier d'investissement, au format de votre équipe finance.
• Modèle de responsabilités. Qui est responsable des comptes, de l'identité, du réseau et de la revue des coûts une fois les charges de travail dans le cloud, rédigé pour les personnes qui feront le travail.
• Base de préparation. Les compétences, les routines d'exploitation et la responsabilité de la sécurité qui doivent exister avant la migration de la première charge de travail, avec les écarts listés par équipe.
• Étape suivante séquencée. Un brief pour le travail de migration ou de développement qui suit, afin que la mission suivante parte de faits convenus.

Déroulement d'une mission

• Appel de cadrage. Vous décrivez le parc, la pression derrière la question et qui doit signer. Nous convenons de ce à quoi le dossier doit répondre.
• Découverte. Sessions de travail avec les responsables infrastructure, applications, sécurité et finance. Nous partons de l'inventaire, des factures et des contrats que vous détenez déjà.
• Options et dossier préliminaire. Nous présentons les plateformes et trajectoires candidates, avec les compromis consignés par écrit, et intégrons les corrections de votre équipe.
• Dossier final et restitution. Le dossier d'adoption, le profil de coûts, le modèle de responsabilités et la base de préparation, présentés aux personnes qui décident. Votre équipe garde la décision.

Périmètre technique

AWS, Microsoft Azure et Google Cloud sont tous dans le périmètre comme plateformes candidates, et la recommandation est faite par parc. Le travail de préparation couvre la structure des comptes et de l'organisation, l'identité et les accès, la conception du réseau et la pratique d'infrastructure as code (Terraform, par exemple) dont votre équipe aurait besoin pour exploiter le résultat. Lorsqu'une première fondation fait partie du brief, comme ce fut le cas pour le premier environnement Google Cloud de LiveRamp, cette conception est transmise à la phase de construction avec les questions de responsabilités déjà réglées.

Ce dont vous avez besoin au départ

Il vous faudra un sponsor exécutif capable de réunir les responsables infrastructure, applications, sécurité et finance dans les mêmes sessions, et un accès en lecture à l'inventaire, aux factures et aux contrats que vous détenez déjà. Lorsque la documentation est mince, la découverte prend plus de temps, et nous le disons dès le départ.

Hors périmètre ici : construire la landing zone et migrer les charges de travail, ce qui relève de plateforme cloud et migration ; reconstruire une application sur des conteneurs ou des services managés, ce qui relève du développement cloud-native ; et changer l'organisation de vos équipes de livraison, ce qui relève de la transformation d'entreprise. Le dossier d'adoption indique lequel de ces chantiers doit suivre.

Réalisations associées

• LiveRamp : une première fondation Google Cloud avec réseau partagé, GKE et IAM granulaire
• Clearly : la décision de quitter Rackspace et l'hébergement sur site pour AWS, puis la migration elle-même

Questions fréquentes

Recommanderez-vous un cloud en particulier ?

Oui, lorsque les éléments le justifient. Le dossier nomme une plateforme, les raisons et les alternatives que nous avons envisagées. Si deux options sont proches, nous le disons aussi et précisons ce qui ferait pencher la balance.

Combien de temps dure la découverte ?

Cela dépend de la part de votre parc déjà documentée et de la rapidité avec laquelle les responsables peuvent être réunis. Nous convenons du nombre de sessions lors de l'appel de cadrage et vous prévenons tôt si l'inventaire est plus mince que prévu.

À qui appartiennent les livrables ?

À vous. Le dossier, le modèle de coûts et la base de préparation sont rédigés pour vos équipes, dans vos formats de documents, et vous êtes libres de les réutiliser avec un autre prestataire ou en interne.

Le dossier nous engage-t-il à confier la migration à SEYA ?

Non. Le dossier est rédigé de façon à ce que toute équipe compétente puisse l'exécuter. Vous pouvez continuer avec nous, puisque les personnes qui ont rédigé le dossier connaissent déjà le parc, mais c'est votre décision.

Si votre organisation envisage une migration et a besoin d'un dossier qu'elle peut défendre, réservez un appel de cadrage sur l'adoption du cloud. Venez avec la question qu'on vous a posée.