Une plateforme cloud avec la sécurité conçue dès le départ

Plateforme cloud et migration, c'est construire une fondation cloud que votre équipe peut exploiter et y déplacer un ensemble connu d'applications. SEYA Group conduit un programme de l'inventaire à la bascule en passant par la landing zone, de sorte que chaque application migre selon un plan documenté, sur une fondation commune. L'identité, les frontières réseau et la journalisation font partie de cette fondation.

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 CTO et responsables infrastructure qui ont décidé de migrer et ont maintenant besoin que la migration se fasse sans facture surprise ni panne imprévue. Aux chefs de projet informatique qui ont hérité d'une migration avec une date et un inventaire incomplet. Aux architectes solutions qui doivent régler la structure des comptes, le réseau et la conception de l'identité avant l'arrivée de la première charge de travail.

Si la question ouverte est encore de savoir s'il faut quitter le centre de données, commencez par l'adoption du cloud. Cette mission démarre une fois la migration posée comme hypothèse de travail.

Les problèmes que nous résolvons

• Un parc partiellement inventorié, avec des dépendances que personne n'a consignées.
• Un dossier de coûts bâti sur des prix catalogue, jamais confronté à la façon dont les charges de travail tournent réellement.
• Une migration sur le point de démarrer avant que les comptes, le réseau, l'identité et les contrôles de base n'existent.
• Un passage d'un cloud à un autre, ou depuis un hébergeur, alors que l'environnement actuel n'a jamais été capturé sous forme de code.
• Des applications qui dépendent de bases de données ou de services devant rester sur site pour l'instant.

Ce que vous obtenez

• Recommandation de plateforme. Un choix écrit de plateforme, de structure de comptes et d'outillage pour les charges de travail du périmètre, avec les options envisagées. Votre équipe garde la décision.
• Estimation du coût de migration. Une estimation de ce que coûteront les charges de travail du périmètre sur la plateforme cible, pour que le dossier d'investissement soit revu avant le début de la construction.
• Landing zone. Les comptes ou projets, le réseau, l'identité, la journalisation et les contrôles de base dans lesquels atterrissent les charges de travail migrées, construits en infrastructure as code et remis avec leur documentation.
• Découverte et plan par vagues. Chaque application et son infrastructure listées, placées sur une trajectoire (rehost, replatform, repurchase, refactor, retain ou retire) et regroupées en vagues avec les prérequis de chacune.
• La migration elle-même. La trajectoire convenue exécutée pour les applications du périmètre, y compris la migration des données, la connectivité vers tout ce qui reste en arrière, et les tests avant et après la bascule.

Déroulement d'une mission

• Appel d'évaluation. Vous décrivez le parc, l'échéance et les contraintes. Nous convenons de ce que la découverte doit couvrir et de qui doit y participer.
• Découverte et conception. Nous inventorions les applications et l'infrastructure avec vos équipes, rédigeons la conception cible et produisons l'estimation de coûts et le plan par vagues pour revue.
• Construction de la landing zone. La fondation est mise en place sous forme de code, revue par vos responsables sécurité et réseau, et documentée pour vos opérateurs.
• Vagues de migration. Les applications migrent dans l'ordre convenu, chacune avec un plan de test, une fenêtre de bascule validée par votre métier et un chemin de retour arrière.
• Passation. Les runbooks, le code et les accès sont transférés, et les points ouverts pour d'éventuels travaux de refonte sont consignés pour la phase suivante.

Périmètre technique

SEYA a réalisé des migrations vers AWS, Microsoft Azure et Google Cloud, y compris des migrations de cloud à cloud. Les fondations sont construites avec HashiCorp Terraform, avec Packer pour les images machine et Ansible pour la configuration lorsque le parc le demande. Les travaux de rehost ont utilisé AWS Migration Hub et CloudEndure ; les trajectoires conteneurs ont utilisé Docker et Kubernetes. La connectivité hybride vers des bases de données sur site, les groupes d'autoscaling et la configuration des répartiteurs de charge font partie de la migration lorsque les applications en ont besoin.

Ce dont vous avez besoin au départ

Un décideur nommé pour la migration, l'accès à l'environnement actuel et à sa documentation, et des responsables sécurité et réseau capables de revoir la conception de la landing zone. Les comptes cloud sont ouverts à votre nom et facturés à vous. Lorsqu'une application doit être repensée avant de pouvoir migrer, la découverte le dit, et ce travail est cadré séparément.

Hors périmètre ici : décider s'il faut migrer, ce qui relève de l'adoption du cloud ; reconstruire une application sur une conception cloud-native, ce qui se poursuit dans le développement cloud-native ; et les vérifications de sécurité dans votre pipeline de livraison, ce qui relève de sécurité et DevSecOps. Un contrat d'exploitation managée ou une certification de conformité ne fait pas partie de cette mission.

Réalisations associées

• Boeing : migration de la pile applicative GoldCare vers Azure avec connexions aux bases de données sur site
• Broadcom : migration de cloud à cloud d'une infrastructure de gestion d'API, d'AWS vers Google Cloud
• Clearly : passage de Rackspace et de l'hébergement sur site à AWS, avec Terraform et autoscaling

Questions fréquentes

Combien de temps prendra la migration ?

Cela dépend du nombre d'applications dans le périmètre, de la qualité de leur documentation et de l'ampleur des changements que chacune nécessite. La découverte produit le plan par vagues, et c'est ce plan qui porte les dates. Nous ne chiffrerons pas une durée avant d'avoir vu le parc.

À qui appartiennent les comptes cloud et le code ?

À vous, dès le premier jour. Les comptes sont créés dans votre organisation, le code d'infrastructure vit dans vos dépôts, et SEYA travaille avec des accès que vous accordez et pouvez révoquer.

Comment travaillez-vous avec notre équipe d'exploitation ?

À ses côtés. Vos opérateurs revoient la conception de la landing zone, assistent aux bascules et reçoivent des runbooks rédigés pour l'environnement qu'ils exploiteront. L'objectif est que rien ne dépende de nous après la passation.

Qu'en est-il des interruptions pendant la bascule ?

Chaque application reçoit une fenêtre de bascule et un chemin de retour arrière convenus avec son responsable métier avant la migration. L'interruption acceptable et les limites de perte de données sont fixées par application dans ce plan.

Si vous avez un ensemble d'applications à migrer et une échéance à tenir, réservez un appel d'évaluation de migration. Nous vous dirons ce que la découverte devrait couvrir.