Chemin de modernisation pour les applications .NET sur Google Cloud

Ce document examine les limites courantes des applications monolithiques et décrit un processus progressif et structuré permettant de les moderniser.

Ce document est destiné aux architectes de cloud, aux administrateurs système et aux responsables techniques qui connaissent bien Windows et l'écosystème .NET, et souhaitent en savoir plus sur ce que la modernisation implique. Bien que ce document se concentre sur les applications de serveur personnalisées (telles que les applications ASP.NET ou Windows Services), vous pouvez appliquer les leçons à d'autres cas d'utilisation.

Applications anciennes et modernes : Pourquoi moderniser ?

La modernisation des anciennes applications est une transition. Le début et la fin de cette transition, ainsi que les avantages dont vous bénéficiez, dépendent en grande partie de l'état de vos applications, ainsi que du temps et des efforts que vous pouvez consacrer à la modernisation.

Dans le contexte des applications .NET, que signifient ancien et moderne ? Il n'est pas facile de répondre à cette question de manière exhaustive ou définitive. Chaque application a des besoins différents en matière d'héritage et de modernisation. Toutefois, les anciennes applications partagent certaines limites courantes.

Le schéma suivant récapitule les caractéristiques des applications anciennes et modernes dans le cloud.

Différences entre les applications cloud monolithiques et modernes dans le cloud

Une ancienne application .NET est généralement un monolithe basé sur .NET Framework, hébergé sur un serveur Microsoft Windows sur site et connecté à un serveur sur site exécutant Microsoft SQL Server. Les détails de votre architecture peuvent différer de ces caractéristiques générales, mais la plupart des applications monolithiques présentent les limitations suivantes :

  • La nécessité de gérer des serveurs sur site exécutant Windows et SQL Server
  • Les environnements de déploiement limités et les coûts de licence associés à Windows
  • La difficulté de mettre à jour d'anciennes applications basées sur une architecture monolithique
  • Peu de flexibilité pour la planification, le budget et le scaling avec les ressources sur site

Les applications conçues pour une architecture cloud présentent plusieurs avantages :

  • Une intégration minimale à l'aide de l'intégration avec les services gérés
  • Une mobilité totale avec .NET Core et les conteneurs, sans dépendances Windows ni frais de licence
  • Un chemin de mise à niveau à grande vitesse basé sur des microservices déployables indépendamment
  • Une agilité totale par rapport au scaling et au budget à l'aide d'une architecture sans serveur

Par rapport à l'approche traditionnelle sur site, une architecture cloud offre un mode d'exécution plus économique, efficace et résilient de vos applications. Avec une approche basée sur le cloud, vous disposez de davantage de flexibilité pour choisir où et quand déployer vos applications.

Chemin de modernisation

Bien que les avantages d'une architecture cloud soient clairs, le chemin portant vers le cloud ne l'est peut-être pas. La modernisation d'une ancienne architecture .NET à une architecture dans le cloud ne suit pas un modèle unique. Comme le montre le schéma suivant, la modernisation implique une série d'étapes, où chaque étape supprime une limitation, améliore les fonctionnalités de l'application et offre de nouvelles possibilités pour les phases ultérieures de la modernisation.

Processus, technologies et services impliqués dans le processus de modernisation.

Les étapes de la modernisation sont regroupées en trois phases :

  1. Réhébergement dans le cloud (également appelé migration Lift and Shift)
  2. Changement de plate-forme
  3. Restructuration et recompilation

Évaluation et apprentissage prémodernisation

Avant de moderniser, vous devez vous préparer. La première étape consiste à évaluer les applications et leurs dépendances pour déterminer quelles applications sont adaptées à la modernisation, et quelles applications ne peuvent pas être modifiées ni déplacées (généralement pour des raisons liées à l'ancienneté ou à des règles). Pour en savoir plus, consultez la page Migration vers Google Cloud : évaluer et découvrir vos charges de travail.

Parallèlement à cette évaluation, votre équipe doit être formée aux capacités du cloud. Google Cloud propose des certifications, des guides techniques, et des ateliers de programmation spécifiques à Windows et .NET. pour accélérer le processus d'apprentissage.

Une fois que vous avez identifié les applications à moderniser, vous pouvez commencer à migrer vos applications classiques dans le cloud telles qu'elles sont, ou en apportant des modifications minimes au code ou à la configuration de l'application.

Phase 1 : Réhébergement dans le cloud

L'objectif principal de cette première phase consiste à transférer la charge de la gestion des serveurs de vos ressources sur site vers l'infrastructure cloud. Au cours de cette phase, vous vous assurez que votre infrastructure est adaptée au cloud afin de pouvoir l'optimiser au cours des phases ultérieures.

Migration manuelle et migration avec des outils

Une migration Lift and Shift des applications .NET basées sur Windows commence généralement par le déplacement des instances Windows Server et SQL Server sur site vers des instances de machine virtuelle (VM) Compute Engine. Vous pouvez réaliser ce processus manuellement ou l'automatiser à l'aide d'un outil de migration.

Lors d'une migration manuelle, vous pouvez utiliser des images Windows Server Compute Engine pour démarrer des instances. Google Cloud Marketplace propose également des solutions prêtes à être déployées sur Compute Engine, telles que la solution ASP.NET Framework pour obtenir une VM Windows Server incluant IIS, SQL Express et ASP.NET.

De même, vous pouvez démarrer des instances SQL Server à partir d'images SQL Server, ou accéder directement à une solution plus gérée : Cloud SQL pour SQL Server.

Google Cloud propose également des outils de migration tels que Migrate to VMs ou VMware Engine pour vous aider à déplacer des VM VMware sur site vers un environnement VMware dans Google Cloud.

Après avoir configuré les VM, vous créez généralement des images de VM personnalisées afin de pouvoir recréer des instances à la demande. Cette étape est également importante pour les modèles d'instance, qui seront abordés plus loin dans ce document.

Si vous avez besoin de services de domaine dans le cloud, vous pouvez déployer un environnement Microsoft Active Directory tolérant aux pannes sur Compute Engine avec un cloud privé virtuel (VPC) ou accéder directement au Service géré pour Microsoft Active Directory.

Connectivité sur site et dans le cloud

Lorsque vous migrez des VM vers le cloud, il n'est pas rare de conserver certaines charges de travail sur site, par exemple lorsque vous avez des applications nécessitant d'anciens matériels ou logiciels, ou lorsque vous devez respecter des exigences de conformité et de réglementation locale. Vous avez besoin d'un VPN ou d'une solution d'interconnexion pour vous connecter en toute sécurité aux ressources sur site et dans le cloud. Pour découvrir comment créer et gérer cette connexion, ainsi que d'autres implications de l'exécution de charges de travail cloud hybrides et sur site, consultez la page Migrer vers Google Cloud : établir les fondations.

Avantages initiaux

À la fin de la phase 1, votre infrastructure de base s'exécute dans le cloud, ce qui offre les avantages suivants :

  • Optimisation des coûts : vous pouvez créer un type de machine personnalisé (processeur, mémoire et stockage) et payer ce que vous utilisez, démarrer et arrêter les VM et les environnements de reprise après sinistre à volonté. Vous ne payerez que lorsqu'ils sont en cours d'exécution, et vous obtiendrez des recommandations de dimensionnement avant la migration.
  • Amélioration de l'efficacité opérationnelle : vous pouvez associer des disques persistants à des VM et créer des instantanés pour des sauvegardes et des restaurations simplifiées.
  • Fiabilité accrue : vous n'avez plus besoin de planifier des intervalles de maintenance en raison de la fonctionnalité de migration à chaud.

Ces avantages initiaux sont utiles, mais d'autres avantages se dégagent lorsque vous commencez à optimiser votre application pour le cloud.

Phase 2 : Changement de plate-forme

Lorsque vous changez de plate-forme, vous optimisez votre application en mettant à niveau certaines parties des composants de l'application, tels que sa base de données, sa couche de mise en cache ou son système de stockage, sans modifier l'architecture de l'application et en apportant des modifications minimes au codebase. L'objectif de la phase 2 est de commencer à utiliser les fonctionnalités cloud pour améliorer la gestion, la résilience, l'évolutivité et l'élasticité de votre application, sans la restructurer de manière significative ni quitter l'environnement de VM.

Profiter de Compute Engine

Compute Engine fournit certaines fonctionnalités standards utiles pour l'exploration. Par exemple, vous pouvez utiliser des modèles d'instance dans Compute Engine pour créer des modèles à partir de configurations de VM existantes. Les groupes d'instances sont un parc de VM identiques qui vous permet d'adapter efficacement les performances et la redondance de votre application. Au-delà de l'équilibrage de charge simple et de la redondance, les groupes d'instances gérés disposent de fonctionnalités d'évolutivité telles que l'autoscaling, de fonctionnalités de haute disponibilité telles que l'autoréparation et les déploiements régionaux, et de fonctionnalités de sécurité telles que la mise à jour automatique.

Grâce à ces fonctionnalités, vous pouvez rester dans le monde des VM tout en augmentant la résilience, la redondance et la disponibilité de vos applications sans avoir à complètement les restructurer.

Rechercher des remplacements existants

Lorsque vous migrez votre application vers le cloud, vous devez rechercher des opportunités pour remplacer votre infrastructure hébergée par des options cloud gérées de Google et de partenaires tiers sur Cloud Marketplace, y compris :

  • Cloud SQL au lieu des solutions auto-hébergées de SQL Server, MySQL ou Postgres. Cloud SQL vous permet de vous concentrer sur la gestion de la base de données plutôt que sur l'infrastructure (par exemple, l'application de correctifs aux VM de base de données pour la sécurité ou la gestion des sauvegardes), avec l'avantage ultérieur de ne pas nécessiter une licence Windows.
  • Service géré pour Microsoft Active Directory au lieu d'Active Directory auto-hébergé
  • Memorystore au lieu d'instances Redis auto-hébergées

Ces remplacements ne nécessitent aucune modification de code et que des modifications de configuration minimes. Elles présentent en outre les avantages suivants : une gestion minimale, une sécurité améliorée et l'évolutivité.

Premiers pas avec les conteneurs Windows

Après avoir optimisé les fonctions de base pour le cloud, vous pouvez commencer à migrer vos VM vers des conteneurs.

Un conteneur est un package léger contenant une application et toutes ses dépendances. Par rapport à l'exécution directe de votre application sur une VM, les conteneurs vous permettent d'exécuter vos applications dans différents environnements et de manière plus cohérente, prévisible et efficace (en particulier lorsque vous exécutez plusieurs conteneurs sur le même hôte). L'écosystème autour des conteneurs (tels que Kubernetes, Istio et Knative) fournit également un certain nombre de fonctionnalités de gestion, de résilience et de surveillance permettant d'accélérer la transformation de votre application d'un simple monolithe à un ensemble de microservices ciblés.

Pendant un certain temps, la conteneurisation n'était qu'une fonctionnalité Linux. Les applications Windows ne pouvaient pas bénéficier des conteneurs. Ceci a changé avec les conteneurs Windows et leur compatibilité avec Kubernetes et Google Kubernetes Engine (GKE).

Les conteneurs Windows sont une option si vous ne souhaitez pas migrer des applications .NET Framework vers .NET Core mais vous souhaitez conserver les avantages des conteneurs (tels que l'agilité, la portabilité et le contrôle). Vous devez choisir le bon OS à cibler en fonction de la version de .NET Framework et n'oubliez pas que toutes les piles Windows ne sont pas compatibles avec les conteneurs Windows. Pour connaître les limites de cette approche et les alternatives, consultez la section Conteneurs .NET Core et Linux plus loin dans ce document.

Après avoir conteneurisé votre application .NET Framework dans un conteneur Windows, nous vous recommandons de l'exécuter dans un cluster Kubernetes. Kubernetes fournit des fonctionnalités standards, telles que la détection de l'arrêt d'un pod de conteneur et sa recréation, l'autoscaling des pods, des déploiements ou des rollbacks automatisés, ou des vérifications d'état. GKE ajoute des fonctionnalités telles que l'autoscaling de clusters, les clusters régionaux, des plans de contrôle à disponibilité élevée, et une compatibilité hybride et multicloud avec Anthos. Si vous décidez d'utiliser GKE ou Anthos, vous pouvez utiliser Migrate to Containers pour simplifier et accélérer la migration des VM Windows vers des conteneurs. Migrate to Containers automatise l'extraction d'applications depuis des VM vers des conteneurs sans que vous ayez besoin de réécrire ni de repenser l'architecture des applications.

Bien que vous puissiez tirer de nombreux avantages en utilisant les bonnes fonctionnalités de Compute Engine et en passant à des conteneurs, GKE vous aide à tirer pleinement parti de vos VM en compressant plusieurs pods sur les mêmes VM. Cette stratégie peut potentiellement se traduire par un nombre de VM moins important et réduire les coûts de licence Windows.

La gestion des conteneurs Windows et Linux de manière déclarative à l'aide de Kubernetes et de GKE permet également d'optimiser la gestion de votre infrastructure. Une fois la conteneurisation en place, votre équipe est prête pour la prochaine phase de modernisation.

Phase 3 : Repenser l'architecture et recompilation

Le changement de plateforme n'est que la première étape pour tirer pleinement profit du cloud. La transformation de votre architecture en plate-forme cloud offre plusieurs avantages, tels que les suivants :

Passer à des services gérés

Lorsque vous réécrivez certaines parties de votre application, nous vous recommandons de passer des services hébergés aux services gérés. Par exemple :

Bien que vous ayez besoin de code supplémentaire pour intégrer votre application à ces services, il s'agit d'un investissement intéressant, car vous transférez la charge de gestion des plates-formes vers Google Cloud. Bibliothèques clientes .NET de Google Cloud, Outils pour Visual Studio et Cloud Code pour Visual Studio Code peuvent vous aider à rester dans l'écosystème et les outils .NET lorsque vous intégrez ces services.

Les services gérés sont également compatibles avec les opérations de votre application. Vous pouvez stocker vos journaux d'application dans Cloud Logging et envoyer ces métriques à Cloud Monitoring, où vous pouvez créer des tableaux de bord avec des métriques de serveur et d'application. Google Cloud propose des bibliothèques clientes .NET pour Cloud Logging, Cloud Monitoring et Cloud Trace).

.NET Core et conteneurs Linux

Si votre application est une ancienne application .NET Framework qui s'exécute uniquement sous Windows, vous pouvez être tenté de l'exécuter sur un serveur Windows sur Compute Engine ou dans un conteneur Windows Server sur GKE. Bien que cette approche puisse fonctionner à court terme, elle peut vous limiter considérablement à long terme. Windows est soumis à des frais de licence et exige des ressources plus importantes que Linux. Ces facteurs peuvent entraîner un coût de possession plus important à long terme.

.NET Core est la version moderne et modulaire de .NET Framework. Les conseils de Microsoft indiquent que .NET Core représente l'avenir de .NET. Bien que Microsoft prévoie de prendre en charge .NET Framework, toutes les nouvelles fonctionnalités seront ajoutées uniquement à .NET Core (et éventuellement .NET 5). Même si vous souhaitez toujours exécuter sur Windows, tout nouveau développement devrait se produire sur .NET Core.

L'un des aspects les plus importants de .NET Core est qu'il s'agit d'une multiplate-forme. Vous pouvez intégrer une application .NET Core à un conteneur dans un conteneur Linux. Les conteneurs Linux sont plus légers que les conteneurs Windows et s'exécutent plus rapidement sur plusieurs plates-formes. Ce facteur crée des options de déploiement pour les applications .NET et vous permet de vous libérer de la dépendance de Windows et des coûts de licence associés.

Portage d'applications .NET Framework vers .NET Core

Pour commencer le portage vers .NET Core, vous pouvez consulter la présentation du portage de .NET Framework vers .NET Core. Des outils tels que .NET Portability Analyzer et .NET API Analyzer peuvent vous aider à déterminer si les assemblages et les API sont portables. D'autres outils de portage tels que dotnet try-convert peuvent aussi être utiles.

Les outils externes peuvent vous aider à identifier les problèmes de compatibilité et à déterminer quels composants migrer en premier. À terme, vous devez créer des projets .NET Core, déplacer progressivement votre code .NET Framework vers le nouveau projet et corriger toute incompatibilité tout au long du processus. Avant de transférer votre code, il est essentiel de mettre en place des tests, puis de tester votre fonctionnalité après le transfert. Nous vous recommandons d'utiliser les tests A/B pour tester l'ancien et le nouveau code. Les tests A/B vous permettent de maintenir l'exécution de votre ancienne application tout en dirigeant certains de vos utilisateurs vers la nouvelle application. Cette approche vous permet de tester les résultats, l'évolutivité et la résilience de la nouvelle application. Pour vous aider à effectuer les tests A/B, Google Cloud propose des solutions d'équilibrage de charge telles que Traffic Director.

Transformation culturelle

La transformation des serveurs .NET Framework et Windows en conteneurs .NET Core et Linux n'est pas seulement un processus technique. Cette transition nécessite une transformation culturelle au sein de votre organisation. Les membres de l'équipe qui peuvent avoir l'habitude d'utiliser des environnements Windows uniquement doivent s'adapter aux environnements multiplates-formes. Cette transformation culturelle nécessite du temps et un budget pour s'entraîner à utiliser .NET Core, Linux et des outils de conteneur tels que Docker et Kubernetes. Toutefois, le passage d'une organisation utilisant Windows uniquement à une organisation multiplate-forme vous permet d'accéder à un plus grand nombre d'outils et de compétences.

Décomposition monolithe

Le passage de .NET Framework à .NET Core peut soulever plusieurs questions, dont les suivantes :

  • Devez-vous réécrire l'intégralité de votre application dans .NET Core ?
  • Devez-vous diviser votre application en services plus petits et les écrire dans .NET Core ?
  • Devez-vous écrire uniquement les nouveaux services dans .NET Core ?

Pour répondre à ces questions, vous devez tenir compte des avantages, du temps et des coûts associés à chaque approche. Il est préférable d'avoir une approche équilibrée sans réécrire tout en une seule fois. À la place, vous pouvez écrire les nouveaux services dans NET Core et divisez votre monolithe existant en services plus petits dans .NET Core lorsque l'occasion se présente. Les livres blancs suivants peuvent vous aider lors de la planification :

Options de déploiement pour les conteneurs .NET Core

Comme décrit dans Déployer des applications .NET sur Google Cloud, vous disposez de différentes options pour déployer des conteneurs .NET Core sur Google Cloud. Lorsque vous décomposez votre application monolithique en microservices, vous pouvez décider d'utiliser plusieurs solutions d'hébergement, en fonction de l'architecture et de la conception de vos microservices.

Les réponses aux questions suivantes peuvent vous aider à choisir la meilleure stratégie d'hébergement :

  • Qu'est-ce qui déclenche votre application ? Toutes les solutions d'hébergement sont adaptées au protocole HTTP(S) standard, mais si vous utilisez un protocole TCP/UDP ou un protocole propriétaire, GKE peut être la seule option.
  • Votre application nécessite-t-elle un matériel spécifique ? Cloud Run offre une quantité raisonnable de mémoire et de processeur pour chaque requête. Cloud Run pour Anthos offre des options de personnalisation supplémentaires, telles que des GPU, plus de mémoire et de l'espace disque.
  • Quelles sont vos attentes en matière de scaling ? Si votre application est associée à des périodes d'inactivité, les solutions sans serveur telles que Cloud Run proposent le scaling à zéro instance.
  • Quelle importance accordez-vous à la latence et quelle est la tolérance de votre application au démarrage à froid ? Si la tolérance aux démarrages à froid est faible, vous devez envisager d'utiliser un nombre minimal d'instances sur Cloud Run ou GKE avec autoscaling.

Nous vous recommandons de lire la documentation de chaque environnement d'hébergement pour vous familiariser avec ses fonctionnalités, ses points forts, ses points faibles et son modèle de tarification.

En règle générale, si vous souhaitez créer des microservices qui diffusent des requêtes HTTP, vous devez procéder à un déploiement dans Cloud Run lorsque cela est possible, puis basculer sur GKE pour demeurer dans l'écosystème Kubernetes ou exiger davantage d'options de personnalisation. GKE constitue également le choix par défaut si vous suivez un processus à long terme, tel qu'un processus à l'écoute d'une file d'attente ou une application utilisant des protocoles autres que HTTP(S).

Cloud Functions est également une bonne option de déploiement sans serveur, mais elle n'est pas décrite ici, car Cloud Run fournit la plupart des fonctionnalités fournies par Cloud Functions et Cloud Functions n'est pas compatible avec dernières versions de .NET Core

Kubernetes et GKE

Si vous souhaitez exécuter vos applications dans un environnement optimisé pour les conteneurs, cette approche est susceptible d'impliquer Kubernetes et sa version gérée, GKE. Kubernetes et GKE sont particulièrement adaptés si vous envisagez de déployer un grand nombre de conteneurs avec des exigences différentes, et si vous souhaitez contrôler avec précision la manière dont chaque conteneur est déployé et géré.

Kubernetes est conçu pour exécuter des conteneurs à grande échelle et fournit des composants fondamentaux tels que des pods, des services, des déploiements et des ensembles d'instances dupliquées. Bien comprendre et utiliser ces conceptions peut s'avérer difficile, mais elles vous permettent de transférer la majeure partie de la charge de gestion des conteneurs vers Kubernetes. Elles sont également adaptées à l'architecture de microservices où un microservice est un déploiement avec un ensemble de pods à équilibrage de charge derrière un service.

En plus de Kubernetes, GKE propose des fonctionnalités telles que l'autoscaling de cluster, la réparation automatique et la mise à niveau automatique pour simplifier la gestion de Kubernetes, ainsi que des fonctionnalités de sécurité telles que l'isolation de conteneurs et des registres privés. Bien que vous soyez facturé pour chaque nœud du cluster dans GKE, GKE est compatible avec les VM préemptives pour réduire les coûts.

GKE peut gérer à la fois les conteneurs Windows et Linux. Cette fonctionnalité est utile si vous souhaitez maintenir un seul environnement hybride pour les applications Windows et les applications Linux modernes.

Knative et Cloud Run

Concernant les conteneurs .NET Core sans état, Knative et sa version gérée, Cloud Run, fournissent un environnement de conteneurs sans serveur. Les conteneurs sans serveur offrent des avantages tels que le provisionnement, l'autoscaling et l'équilibrage de charge, sans surcharge liée à la gestion de l'infrastructure.

Pour déployer des conteneurs dans un cluster Kubernetes, Knative fournit une surface d'API de niveau supérieur et plus réduite que Kubernetes. Knative peut ainsi vous aider à éviter les complexités de Kubernetes, ce qui simplifie le déploiement de vos conteneurs.

Cloud Run suit le fonctionnement de l'API Knative, mais s'exécute sur l'infrastructure Google, éliminant ainsi le besoin de clusters Kubernetes. Cloud Run fournit une option sans serveur pour les conteneurs. Par défaut, les conteneurs dans Cloud Run font l'objet d'un autoscaling et sont facturés en fonction de la durée de la requête. Le délai de déploiement est exprimé en secondes. Cloud Run fournit également des fonctionnalités utiles, telles que les révisions et la répartition du trafic.

Cloud Run for Anthos est la version plus flexible de Cloud Run qui offre la simplicité de Knative et Cloud Run avec la flexibilité opérationnelle de Kubernetes. Par exemple, Cloud Run sur Anthos vous permet d'ajouter des GPU aux instances sous-jacentes qui exécutent vos conteneurs ou de faire évoluer votre application pour qu'elle accepte plusieurs conteneurs.

Cloud Run s'intègre à d'autres services tels que Pub/Sub, Cloud Scheduler, Cloud Tasks, ainsi qu'à des backends tels que Cloud SQL. Il peut s'utiliser avec les interfaces Web à autoscaling ou pour les microservices internes déclenchés par des événements.

Moderniser les opérations

La modernisation ne concerne pas uniquement le code de votre application. Elle s'applique à l'ensemble du cycle de vie de votre application : méthode de compilation, de test, de déploiement et de surveillance. Par conséquent, lorsque vous pensez à moderniser, vous devez prendre en compte les opérations.

Cloud Build peut vous aider à moderniser et à automatiser le cycle de compilation-test-déploiement de votre application. Cloud Build fournit non seulement des compilateurs pour .NET Core, mais il s'intègre également à Vulnerability Scanner de Container Registry et à l'autorisation binaire pour empêcher l'exécution d'images créées à partir de code source inconnu ou de dépôts non sécurisés dans votre environnement de déploiement.

La suite Google Cloud Operations (anciennement Stackdriver) propose plusieurs services qui vous permettent de moderniser l'observabilité de votre application :

Vous pouvez utiliser la bibliothèque Google.Cloud.Diagnostics.AspNetCore pour une intégration simple de la suite Google Cloud Operations dans vos applications ASP.NET Core. Pour exporter des métriques OpenTelementry vers la suite Operations, vous pouvez utiliser la bibliothèque OpenTelemetry.Exporter.Google Cloud's Suite.

Pour en savoir plus sur la façon dont la modernisation s'applique aux processus et à la culture de l'équipe, consultez la page Solutions Google Cloud pour DevOps.

Étapes suivantes