Google réunit la planification et la préparation de la modernisation
Google regroupe les outils existants de migration et de modernisation, de nouveaux agents d’intelligence artificielle (IA) et un Modernization Hub au sein de Google Cloud Modernize. Google indique que l’objectif est d’accélérer les évolutions de l’infrastructure et des applications d’entreprise. L’entreprise a un intérêt commercial à faciliter ces changements, car les migrations vers Google Cloud déplacent les charges de travail sur sa plateforme.
Pour les directeurs des systèmes d’information (DSI) et les responsables de l’ingénierie, cette refonte traite deux tâches liées : coordonner un programme de modernisation et préparer des charges de travail individuelles à être déplacées. Des évaluations combinées peuvent aider les équipes à décider ce qu’il faut modifier, tandis que des agents peuvent les assister dans l’exploration des coûts et l’ingénierie de migration. Les équipes d’entreprise restent toutefois seules décisionnaires pour déterminer si les systèmes obtenus sont prêts pour la production.
Une planification consolidée relie évaluations, choix de migration et coûts
La coordination devient plus difficile lorsqu’une entreprise exécute plusieurs types d’applications sur différents clouds. Pareekh Jain, analyste principal chez Pareekh Consulting, illustre le problème avec un environnement hypothétique dont les catégories de charges de travail nécessitent des évaluations et des équipes distinctes. Son cabinet de conseil accompagne les entreprises dans leurs décisions technologiques et a donc lui aussi un intérêt commercial dans les activités de modernisation.
« Une entreprise peut avoir des charges de travail VMware, des applications Java, des mainframes, des bases de données Oracle et des applications Kubernetes exécutés sur différents clouds. Auparavant, cela pouvait nécessiter des outils, des évaluations et des équipes de migration distincts. Avec cette offre élargie, les DSI ont besoin de moins de relais, de décisions plus rapides et d’une meilleure visibilité sur un vaste programme de modernisation », a déclaré Jain. Dans cet exemple, la difficulté consiste à rassembler les conclusions d’équipes distinctes avant de décider de la suite à donner au programme.
Des conclusions séparées peuvent laisser aux dirigeants une vision partielle d’un même environnement, obligeant les équipes à expliquer les dépendances et à aligner leurs recommandations à chaque relais. Jain décrit cette consolidation comme le fait de réunir le travail dans « un processus de bout en bout ». Maintenir le lien entre évaluation et planification peut simplifier les décisions, tandis que les équipes d’entreprise restent responsables de leur mise en œuvre.
Google Cloud Modernize fournit la structure de cette consolidation : Migration Center y est intégré et continuera de prendre en charge l’évaluation et la planification des migrations. À ses côtés, Modernization Hub se concentre sur la modernisation des applications. Les équipes qui échangent avec Google sur ce portefeuille doivent donc distinguer l’orientation applicative du Hub des fonctions de migration plus larges.
Dans ce périmètre applicatif, Google combine l’App Modernization CLI, une interface en ligne de commande par laquelle les utilisateurs saisissent des commandes textuelles, avec des capacités de modernisation Java et .NET. Les outils mainframe comprennent Mainframe Assessment Tool, Dual Run et Mainframe Connector. Google indique que les équipes accéderont au Hub via la Google Cloud Console, ce qui leur donnera une interface commune pour les outils de modernisation des applications qui y sont regroupés.
Une interface commune peut aussi relier l’évaluation à la planification qui suit. Viet-Anh Nguyen, responsable machine learning chez Scopic Software, décrit cet avantage de gestion ; Scopic Software a un intérêt commercial dans les investissements des entreprises dans la modernisation logicielle. « Au lieu d’outils fragmentés, le nouveau Hub fournit un workflow d’évaluation consolidé. Il offre aux DSI un point central pour évaluer, planifier et gérer la modernisation des applications », a-t-il déclaré.
Planifier à partir d’une évaluation combinée aide les équipes à choisir le travail d’ingénierie dont une application a besoin. « Auparavant, les capacités étaient réparties entre différents outils Google. Les équipes peuvent désormais comprendre les applications et les dépendances, obtenir des recommandations de modernisation et décider quoi migrer, rehoster ou refactorer depuis une interface plus unifiée », a déclaré Jain. Les dépendances sont les services et systèmes dont une application dépend ; les comprendre aide les équipes à décider s’il faut déplacer une application, la rehoster avec des changements limités ou refactorer sa structure.
Ces choix façonnent aussi l’évaluation financière, que Google étend via le Quick Estimator Agent de Migration Center. Google indique que les utilisateurs en entreprise peuvent fournir des données d’infrastructure, y compris des exports d’inventaire VMware, afin de générer des estimations du coût total de possession, c’est-à-dire les coûts globaux d’un scénario de migration. Les utilisateurs peuvent ensuite explorer des scénarios et interroger les hypothèses de coûts en langage naturel, reliant ainsi les informations d’infrastructure à la planification financière.
Ces hypothèses comptent, car une estimation dépend des choix de migration qui la sous-tendent. Une équipe de planification peut utiliser l’estimateur pour voir comment différents scénarios modifient les coûts projetés, plutôt que de considérer la première estimation comme figée. Cela donne aux équipes un autre moyen d’évaluer un déplacement envisagé, même si les coûts d’exploitation finaux dépendront toujours de la manière dont elles le mettront en œuvre.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.
L’automatisation de la migration prépare les changements pour la revue d’ingénierie
Une fois qu’une équipe choisit une trajectoire de migration, le travail d’ingénierie devient plus précis. L’EKS-to-GKE Migration Agent de Google prend en charge une trajectoire définie : déplacer des charges de travail Kubernetes, ou des applications gérées par Kubernetes, depuis Amazon EKS, le service Kubernetes managé d’Amazon Web Services (AWS), vers Google Kubernetes Engine (GKE). Les équipes doivent évaluer ses capacités au regard de cette trajectoire, car son périmètre annoncé n’implique pas une prise en charge équivalente pour chaque migration d’un cloud à un autre.
Pour un passage d’EKS à GKE, la préparation commence par la compréhension de l’environnement existant et des changements exigés par la destination. Google indique que l’agent peut analyser des environnements EKS, traduire des manifests Kubernetes, c’est-à-dire les fichiers qui décrivent comment les charges de travail doivent s’exécuter, et cartographier les besoins en stockage et en réseau. Il peut ensuite aider à préparer les charges de travail pour leur déploiement sur GKE, avec des points de validation humaine tout au long du processus.
Le stockage et le réseau nécessitent une attention particulière, car une charge de travail dépend d’une infrastructure qui va au-delà de son manifest. Cartographier ces besoins aide les équipes à prendre en compte ce dont l’application aura besoin à destination. La description de Google réunit donc des tâches de préparation connexes dans un workflow assisté unique, tandis que les ingénieurs examinent les changements proposés.
Nguyen explique comment cette revue peut s’intégrer dans la pratique de l’ingénierie. « Puisque l’Agent peut découvrir et traduire automatiquement l’infrastructure spécifique à AWS et les configurations Kubernetes, valider les résultats et créer des pull requests pour une revue humaine, il réduit le travail d’ingénierie répétitif », a-t-il déclaré. Les pull requests sont des modifications proposées soumises à revue, permettant aux ingénieurs d’examiner le travail de l’agent avant de l’accepter.
Les pull requests donnent une forme concrète à la revue humaine que Google inclut dans ses points de validation. L’agent peut découvrir des configurations, préparer des changements et vérifier les résultats, tandis que les ingénieurs décident de les accepter ou non. Les développeurs et les ingénieurs plateforme pourraient donc passer moins de temps à répéter le travail de découverte, de traduction et de préparation, avec des résultats qu’ils peuvent examiner et évaluer.
Réduire ce travail manuel pourrait aussi modifier l’effort nécessaire pour changer de cloud. Jain y voit un potentiel de migrations plus rapides, moins coûteuses et moins risquées. Pour une migration EKS-vers-GKE donnée, les équipes doivent juger dans quelle mesure l’agent peut aider à la préparation et comment ses changements proposés s’intègrent à leur processus de revue existant.
La responsabilité de l’entreprise se poursuit jusqu’au basculement en production
L’examen des changements proposés fait partie de la responsabilité plus large qui reste à la charge de l’entreprise. Selon Jain, les équipes restent responsables des tests, des décisions d’architecture, de la migration des données et du basculement en production, c’est-à-dire la transition qui met le système migré en exploitation réelle. Des configurations préparées peuvent soutenir ce travail, mais l’équipe doit toujours décider si l’application et les systèmes qui la soutiennent sont prêts à fonctionner.
Prendre cette décision exige des DSI et des responsables plateforme qu’ils attribuent clairement la responsabilité au-delà des points de validation de l’agent. Les personnes qui acceptent les changements de configuration doivent aussi savoir qui est responsable des tests du système, des décisions d’architecture, du déplacement de ses données et de l’autorisation de la transition vers la production. Accepter un changement proposé par un agent constitue donc une validation parmi d’autres dans le processus de migration ; l’autorité pour mettre le système en exploitation réelle doit rester explicitement définie.
Points clés à retenir pour les décideurs
- Relier les évaluations aux décisions de migration : Google Cloud Modernize intègre l’évaluation, la modernisation des applications et l’exploration des coûts dans un workflow plus large. Les DSI et les responsables plateforme peuvent utiliser ces conclusions combinées pour comparer des trajectoires de migration, examiner les dépendances et tester les hypothèses de coûts avant d’engager des ressources d’ingénierie.
- Évaluer l’automatisation au regard de la trajectoire de migration : l’EKS-to-GKE Migration Agent de Google aide à traduire les configurations et à cartographier les besoins en stockage et en réseau pour ce déplacement spécifique. Les ingénieurs plateforme doivent examiner les changements qu’il propose et évaluer dans quelle mesure il réduit le travail de préparation dans leur workflow existant.
- Attribuer la responsabilité jusqu’au basculement en production : les entreprises conservent la responsabilité de l’architecture, des tests, de la migration des données et de la transition vers l’exploitation réelle. Les DSI et les responsables de l’ingénierie doivent désigner explicitement un responsable pour chaque décision, y compris pour l’acceptation des changements générés par l’agent et pour l’autorisation du déploiement en production.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.
