Ce document vise à décrire le processus, les bonnes pratiques et les outils permettant de moderniser les anciennes applications Java monolithiques à l'aide d'Anthos.
Il est destiné aux directeurs de la technologie, aux responsables des technologies de l'information, aux architectes d'entreprise, aux administrateurs de sécurité informatique, aux développeurs d'applications, aux équipes DevOps et aux équipes d'ingénieurs chargés de la fiabilité des sites (ingénierie SRE). Dans ce guide, nous partons du principe que vous possédez des connaissances de base sur la conteneurisation, ainsi que sur ses avantages opérationnels et en termes de développement.
Ce document propose une approche de modernisation en deux étapes :
- Conteneuriser. Au cours de cette étape, vous allez intégrer et déployer des applications Canary appropriées sur la plate-forme Anthos (sur site ou dans Google Cloud). Vous utiliserez divers services et technologies tels que Migrate to Containers, des pratiques d'intégration continue/livraison continue (CI/CD) modernes et des outils d'intégration système.
- Refactoriser et changer de plate-forme. Au fil du temps, vous allez refactoriser et redéfinir les anciennes applications monolithiques vers des frameworks Java modernes (tels que Spring Boot) et des microservices.
Ce document fournit des conseils et des ressources pour chacune de ces phases. Il propose également une alternative si vous prévoyez de laisser votre entreprise sur des machines virtuelles (VM).
Les avantages de la modernisation
De nombreuses organisations ont du mal à faire fonctionner leurs applications professionnelles tout en essayant d'innover. Les équipes de développement et d'exploitation doivent répondre aux nouvelles demandes de services d'applications, et, dans le même temps, gérer, exploiter et améliorer les portefeuilles d'applications existants.
Ces nouvelles exigences résultent des initiatives commerciales numériques et de l'objectif de la transformation numérique visant à améliorer les fonctions existantes. Selon un rapport Gartner (Building a Multiplatform Application Modernization Business Case, novembre 2019), 90 % des applications actuelles seront toujours utilisées d'ici 2025, et les contraintes techniques liées à la gestion de ces applications continueront à s'accumuler, consommant plus de 40 % des budgets informatiques actuels.
Bien que les entreprises misent sur le développement et l'adoption de nouvelles applications, elles continuent à s'appuyer majoritairement sur des applications monolithiques classiques. La plupart de ces anciennes applications s'exécutent sur des serveurs d'applications propriétaires et commerciaux, tels qu'IBM WebSphere ou Oracle® WebLogic. Elles sont souvent bien optimisées, maintenues et gérées, si bien que les entreprises rechignent à innover dans ce domaine. Revers de la médaille, les serveurs d'applications propriétaires peuvent augmenter les coûts opérationnels et nécessiter (dans de nombreux cas) des contrats de licence exorbitants.
Plusieurs études montrent que les entreprises peuvent gagner du temps et de l'argent en modernisant les applications classiques au lieu de réécrire le code existant. C'est pourquoi toute stratégie visant à moderniser d'anciennes applications doit se concentrer sur la réduction des délais et des coûts de l'opération.
Applications modernes
Des applications modernes peuvent vous aider à améliorer l'expérience de vos clients, ce qui permet de les fidéliser en répondant mieux à leurs attentes, et ainsi d'augmenter votre rentabilité. Les principes du développement d'applications et de plates-formes modernes mettent en évidence les avantages de la transformation numérique. Ces principes clés sont expliqués dans les sections suivantes.
Augmenter la productivité des développeurs et des opérateurs
Les anciennes applications sont souvent des applications monolithiques. Elles possèdent un codebase volumineux qui effectue plusieurs fonctions. À mesure que les applications se développent, de même que les équipes qui en ont la charge, il devient difficile de gérer et de lancer rapidement de nouvelles fonctionnalités. De nombreuses dépendances existant entre les équipes doivent être rapprochées et approuvées avant qu'une modification puisse être appliquée en production et au client. Cette dynamique peut entraîner une baisse de la productivité des développeurs et des opérateurs, ainsi qu'une insatisfaction des clients.
Les applications modernes sont conçues à l'aide de microservices. Les différents domaines d'une application monolithique sont répartis entre plusieurs services distincts, chacun ayant la charge d'une fonction spécifique (d'où le terme de microservices). Cette architecture offre plusieurs avantages :
- Pour les développeurs. Le découplage des services permet aux développeurs de travailler sur des fonctionnalités spécifiques indépendamment des autres services. Cette approche augmente la productivité des développeurs, car ils peuvent ajouter des fonctionnalités à leur service sans dépendances strictes avec d'autres services et équipes.
- Pour les opérateurs. Chaque version de microservice apporte des modifications mineures, ce qui est beaucoup plus facile à gérer pour votre équipe opérationnelle. Le déploiement de modifications plus petites de cette manière contrôlée présente moins de risques en cas d'échec d'une version, ce qui augmente la productivité pour les opérations.
- Pour les clients. L'efficacité de développement et d'exploitation d'une architecture moderne peut aider vos équipes à proposer plus rapidement de nouvelles fonctionnalités qu'une architecture monolithique.
Se concentrer sur les services et les API
Les anciennes applications sont souvent considérées en termes d'infrastructure. Les serveurs, les machines virtuelles (VM), la mise en réseau et le stockage sont des éléments essentiels de la conception d'une application monolithique. Les applications modernes sont considérées en termes de services et d'API. L'accent mis sur les services et les API offre plusieurs avantages :
- Redondance et résilience des services. Vous pouvez exécuter des services n'importe où, souvent dans plusieurs endroits, tels que des VM, des conteneurs ou des clusters.
- Disponibilité des services. L'utilisation de services peut vous aider à augmenter la disponibilité globale de votre application. Tant que le service est disponible, les défaillances d'infrastructure sont sans incidence. La conception et la réflexion en termes de services et d'API plutôt que d'infrastructure mettent l'accent sur la disponibilité, qui vous permet d'atteindre votre objectif de niveau de service (SLO).
Exécuter en tant que microservices dans des conteneurs
Les anciennes applications s'exécutent généralement en tant que VM ou sur serveurs physiques. Ces plates-formes sont coûteuses et inefficaces (sous-utilisation des processeurs et de la mémoire) et sont plus difficiles à gérer que les plates-formes modernes basées sur le cloud (en particulier pour les serveurs physiques). Les applications modernes s'exécutent en tant que microservices dans des conteneurs, ce qui offre plusieurs avantages, y compris les suivants :
- Des applications plus petites et plus efficaces. Les conteneurs peuvent empaqueter un microservice dont l'empreinte est deux à trois fois inférieure à celle d'une application monolithique.
- Isolation de l'espace utilisateur Linux. Vous pouvez exécuter plusieurs conteneurs sur un même hôte, en utilisant l'hôte efficacement.
- Portabilité entre différents environnements et infrastructures. Les conteneurs encapsulent l'application avec toutes les dépendances et bibliothèques requises. Vous pouvez donc exécuter des conteneurs dans n'importe quel environnement, qu'il s'agisse d'un centre de données sur site ou d'un environnement de cloud public.
S'appuyer sur des normes ouvertes
Les anciennes applications utilisent souvent des produits commerciaux ou sous licence pour fonctionner. Non seulement cette approche est coûteuse en raison des frais de licence, mais elle rend également les applications très dépendantes des plates-formes commerciales.
Dans certains cas, le logiciel commercial est limité par l'infrastructure ou le matériel sur lesquels il peut s'exécuter. Par exemple, si le logiciel ne peut s'exécuter que sur site, votre entreprise doit gérer une infrastructure (comprenant la mise en réseau, le stockage, les serveurs, l'alimentation et le CVC) et des centres de données coûteux.
Les applications et services modernes sont souvent créés à l'aide de logiciels Open Source, ce qui offre plusieurs avantages :
- Extensibilité et portabilité. Vous pouvez exécuter des services n'importe où.
- Assistance. Les technologies Open Source bien connues telles que Kubernetes et Docker possèdent souvent des communautés fortes (composées de nombreuses entreprises) qui ne sont pas dépendantes ou liées aux intérêts d'une seule entreprise. Cette approche Open Source permet d'améliorer globalement les fonctionnalités du produit. Plus vous adoptez une technologie Open Source (par exemple, Kubernetes), plus votre ensemble de fonctionnalités est performant par rapport à la plupart des équivalents commerciaux.
- Flexibilité. Dans ce modèle, votre entreprise n'est plus limitée à un seul fournisseur pour la plate-forme ou l'infrastructure de votre application. L'adoption de normes ouvertes vous permet de prendre des décisions concernant les applications et l'infrastructure en fonction des exigences du client et de l'entreprise.
Plate-forme moderne
Les applications modernes doivent disposer d'une plate-forme moderne. Une plate-forme moderne doit répondre à plusieurs besoins.
Déploiement rapide, fiable et sécurisé des fonctionnalités
Les plates-formes modernes doivent permettre des déploiements rapides, fiables et sécurisés de nouvelles fonctionnalités.
- Rapidité. Cette condition dépend d'une automatisation suffisante pour déployer des services et de nouvelles fonctionnalités. L'automatisation élimine le travail humain et les erreurs, et accélère la livraison.
- Fiabilité. La plate-forme doit permettre aux équipes de mettre progressivement en service les fonctionnalités ou de rétablir leur état d'origine si elles ne fonctionnent pas.
- Sécurité. La plate-forme doit permettre des contrôles d'accès précis. Seuls les opérateurs autorisés doivent pouvoir accéder aux services, ou déployer des fonctionnalités et des services sur la plate-forme.
Priorité aux services
Les applications modernes sont conçues, développées et exécutées en fonction des services et non de l'infrastructure. Cette priorité donnée aux services dépend de la résilience des plates-formes aux défaillances de l'infrastructure. Les plates-formes modernes disposent d'une fonctionnalité intégrée qui permet la reprise des services (et de la plate-forme elle-même) après des défaillances matérielles et logicielles.
Approche hybride et multicloud avec plan de contrôle cohérent
Dans le cadre de leur transformation numérique, de nombreuses entreprises adoptent une stratégie multicloud ou cloud hybride pour leur portefeuille de services. Peut-être ne pouvez-vous pas transférer certaines applications des centres de données sur site vers le cloud public (pour des raisons réglementaires, de conformité ou de sécurité), tout en souhaitant quand même utiliser le cloud pour d'autres services. Les plates-formes modernes peuvent s'exécuter (ce qui est souvent le cas) sur plusieurs environnements tels que des centres de données sur site, des clouds privés, ou un ou plusieurs clouds publics. Bien qu'elles s'exécutent sur différentes infrastructures, les plates-formes modernes doivent fournir aux développeurs et aux opérateurs une expérience unifiée du plan de contrôle afin d'augmenter l'efficacité opérationnelle.
Tout sous forme de code déclaratif
Les anciennes plates-formes (telles que les VM) sont par nature impératives. Les opérateurs créent souvent des ressources, et fournissent des scripts et des configurations qui s'exécutent au moment de l'exécution de l'application. Lorsque les opérateurs modifient une application, ils effectuent la modification directement sur la VM sur laquelle l'application s'exécute. Ce processus peut entraîner un écart de configuration, ce qui signifie qu'à tout moment, rien ne garantit que l'application et la plate-forme se trouvent dans l'état souhaité. Dans un tel environnement, il peut être difficile de résoudre les problèmes et de récupérer de pannes.
Les plates-formes modernes sont des systèmes déclaratifs où toutes les ressources sont définies sous forme de code, également appelé Infrastructure as Code (IAC). L'infrastructure, les services, les déploiements, la sécurité et les règles sont regroupés dans des documents de ressources qui définissent l'état souhaité de la plate-forme. Cette approche déclarative permet aux opérateurs de définir leurs services, leur sécurité et leurs règles via un langage unifié. Étant donné que ces ressources sont constituées de code, elles peuvent être stockées dans un dépôt de code et soumises aux mêmes contrôles de code que les applications. Lorsque l'état de la plate-forme réside dans un dépôt Git (ainsi que l'historique de tous les commits pour chaque changement d'état), il est plus facile de revenir à un état précédent en cas de défaillance du système ou de sinistre.
Plate-forme Anthos
Anthos est la plate-forme d'applications moderne de Google Cloud. Avec la plate-forme ouverte, hybride et multicloud d'Anthos, vous pouvez moderniser vos applications existantes, en créer de nouvelles et les exécuter n'importe où de manière plus sécurisée. En s'appuyant sur des technologies Open Source développées par Google, telles que Kubernetes, Istio et Knative, Anthos vous aide à assurer la cohérence entre les environnements cloud et sur site, et à accélérer le développement d'applications.
Le diagramme suivant décrit les composants Anthos et leurs interactions dans un environnement d'entreprise classique.
Les sections suivantes décrivent brièvement les principaux composants d'Anthos.
Clusters Anthos : Orchestration de conteneurs
L'environnement informatique principal d'Anthos repose sur les clusters Anthos pour gérer les installations Kubernetes dans les environnements dans lesquels vous souhaitez déployer vos applications. Ces offres regroupent les versions en amont de Kubernetes et fournissent des fonctionnalités de gestion pour la création, le scaling et la mise à niveau de clusters Kubernetes conformes.
Kubernetes est composé de deux éléments principaux : le plan de contrôle et les composants de nœud. Lorsque vous utilisez GKE, Google Cloud héberge le plan de contrôle, et le serveur d'API Kubernetes est le seul composant du plan de contrôle auquel les clients peuvent accéder. GKE gère les composants de nœud dans le projet du client à l'aide d'instances dans Compute Engine. Lorsque vous utilisez les clusters Anthos, tous les composants sont hébergés dans l'environnement de virtualisation sur site du client.
Une fois Kubernetes installé et en cours d'exécution, vous pouvez accéder à une couche d'orchestration commune qui gère le déploiement, la configuration, la mise à niveau et le scaling des applications.
Anthos Config Management : gestion des règles
Anthos Config Management vous permet de gérer des clusters uniques, des clusters mutualisés et des déploiements multiclusters Kubernetes à l'aide de fichiers appelés "configurations". Vous stockez les configurations dans un dépôt Git.
Certaines configurations sont des fichiers manifestes d'objets Kubernetes. D'autres ne correspondent pas à des fichiers manifestes d'objets, mais fournissent des informations dont Anthos Config Management a besoin. Vous pouvez écrire des configurations au format YAML ou JSON. Anthos Config Management recherche les mises à jour de ces fichiers et applique automatiquement les modifications à tous les clusters concernés.
Une approche de type configuration en tant que code vous permet de gérer la configuration de vos clusters Anthos en appliquant les principes que vous utilisez déjà pour gérer vos applications déployées dans Kubernetes.
Anthos Service Mesh : gestion des services
Anthos Service Mesh est un framework compatible avec Istio qui vous permet de connecter, de surveiller et de sécuriser des services exécutés sur des clusters Anthos. Grâce à Anthos Service Mesh, vous pouvez créer un réseau de services déployés tels que l'équilibrage de charge, l'authentification de service à service et la surveillance, sans avoir à modifier le code des services.
Anthos Service Mesh injecte automatiquement un proxy side-car pour chacun des pods de votre application. Un pod est l'unité d'exécution de base d'une application Kubernetes. Un pod encapsule le conteneur d'une application (ou, dans certains cas, plusieurs conteneurs). Dans Anthos Service Mesh, chaque pod contient deux conteneurs : le conteneur d'applications et un conteneur de proxy Envoy (également appelé proxy side-car). Le proxy side-car intercepte tout le trafic réseau en provenance et à destination des pods. Anthos Service Mesh configure une passerelle d'entrée pour gérer le trafic entrant vers le maillage. Vous pouvez utiliser des API Istio Open Source pour configurer des règles appliquées à l'aide de side-cars et de passerelles.
Plan de modernisation
Google Cloud fournit un processus normatif pour convertir vos applications Java monolithiques en microservices. Vous pouvez adopter la procédure ci-après et effectuer la transition au rythme le mieux adapté aux besoins et aux exigences de votre entreprise :
- Migrez et modernisez les applications appropriées, d'une exécution sur des VM à une exécution dans des conteneurs, sans réécrire le code.
- Déployez des applications en conteneurs sur la plate-forme Anthos à l'aide de pratiques CI/CD modernes. Certaines applications peuvent ne pas être de bons candidats pour la conteneurisation et continuer à être exécutées via des VM.
- Refactorisez des applications vers des piles d'applications OSS, des frameworks modernes et des microservices au fil du temps.
Le diagramme suivant illustre le déroulement des opérations.
Chacune de ces étapes importantes est détaillée dans la section suivante.
Étapes de la modernisation
Les sections ci-dessous décrivent chaque étape du processus de modernisation, et la façon dont Anthos et Migrate to Containers interviennent à chaque étape.
Étape 1 : Conteneuriser des applications Java
Dans cette étape de modernisation, vous conteneurisez les applications Java appropriées qui s'exécutent en tant que VM.
La conteneurisation est un processus qui empaquette le code de l'application avec toutes les dépendances et bibliothèques de son environnement d'exploitation. Vous pouvez exécuter plusieurs conteneurs sur un seul hôte, chacun avec ses propres environnements d'application autonomes. Les conteneurs sont des alternatives légères, portables et efficaces aux VM.
Généralement, vous créez et empaquetez des applications Java sous forme de fichiers JAR à l'aide d'outils tels que Maven ou Gradle. Vous exécutez ensuite les binaires dans des VM ou sur des serveurs physiques.
Vous pouvez intégrer une application Java à un conteneur de deux manières :
- Migrer et moderniser l'application à l'aide de Migrate to Containers
- Créer des conteneurs à l'aide d'outils d'intégration système
Migrer et moderniser à l'aide de Migrate to Containers
Migrate to Containers vous permet de migrer des applications directement depuis des VM vers des artefacts conteneurisés (tels qu'un fichier Dockerfile ou des fichiers manifestes de ressources Kubernetes). Vous déployez ensuite les conteneurs sur Anthos (sur GKE et sur les clusters Anthos sur VMware).
Migrer avec Migrate to Containers
Le processus d'utilisation de Migrate to Containers pour migrer des applications est le suivant :
- Identifiez les candidats pour la migration. Au cours de cette étape, vous allez déterminer quelles applications sont adaptées à la migration. Deux types d'applications sont de bons candidats pour la migration :
- Applications dont le code source est inaccessible. Il est possible que les développeurs ne soient plus associés à une entreprise et que le codebase ne soit plus compatible. Au lieu de gérer ces applications en tant que VM, vous pouvez utiliser le processus simplifié de conteneurisation dans Migrate to Containers pour transférer ces applications vers Anthos.
- Applications qui sont conservées, mais non développées. Certaines applications peuvent ne pas être activement développées, mais les entreprises en ont toujours besoin en raison de dépendances sur d'autres services. Migrate to Containers simplifie le processus de modernisation de la plate-forme compatible avec ces applications.
- Migrez vers Anthos. Une fois que vous avez identifié les candidats appropriés pour la migration, vous utilisez Migrate to Containers pour convertir les VM en artefacts conteneurisés pouvant être déployés sur Anthos à l'aide de pratiques CI/CD modernes (voir la section suivante). Migrate to Containers permet également de déplacer les données et l'état des applications.
Migrate to Containers et migrations complexes
Le nombre d'applications que les entreprises gèrent peut parfois se compter en milliers. Le nombre d'applications à migrer ou les complexités de la conteneurisation peuvent empêcher les entreprises de mettre en œuvre des projets cloud d'envergure. De ce fait, les entreprises peuvent passer à côté d'opportunités commerciales et des avantages de services cloud publics de pointe. Ces services peuvent être des services de données et d'analyse tels que BigQuery, des applications d'intelligence artificielle telles que AutoML, ou des applications de machine learning (ML) telles que les API pré-entraînées de Google Cloud.
Migrate to Containers peut vous aider à faire face aux défis et à la complexité de votre portefeuille d'applications de différentes manières :
- Gérer les migrations d'applications à grande échelle. Grâce à Migrate to Containers, vous pouvez moderniser et, en parallèle, déplacer de nombreuses applications vers Anthos sans faire subir à vos développeurs et opérateurs des contraintes techniques accrues.
- Simplifier la conteneurisation. Associée à un grand nombre d'applications, la conteneurisation peut être complexe, et les entreprises peuvent manquer des compétences ou des ressources nécessaires pour soutenir de grands efforts de modernisation en temps opportun. Dans de tels cas, Migrate to Containers vous permet de migrer vers Anthos de manière simplifiée et efficace.
Pour en savoir plus, consultez la documentation de Migrate to Containers.
Autres outils de conteneurisation
Docker est une plate-forme largement utilisée pour la création d'images de conteneurs. Un Dockerfile est un document texte qui contient toutes les commandes que vous pouvez appeler sur la ligne de commande pour assembler une image. Pour créer un conteneur Docker, créez vos binaires (fichiers JAR), puis empaquetez-les dans un fichier Dockerfile. Une fois le fichier Dockerfile créé, vous pouvez l'utiliser dans un pipeline CI/CD. Le schéma suivant illustre le workflow qui utilise un fichier Dockerfile.
Étape 2 : Déployer des applications sur Anthos à l'aide de CI/CD modernes
Dans cette étape de modernisation, vous déployez des applications Java conteneurisées sur Anthos en utilisant les pratiques modernes de livraison de logiciels.
Pour créer, tester et livrer des applications aux clients, vous devez disposer d'un moyen bien conçu, automatisé, reproductible et fiable. Comme plusieurs équipes de développement ajoutent continuellement des fonctionnalités, un système de CI/CD est souvent utilisé pour créer les applications, les tester et les déployer en conteneurs.
Avantages des pratiques modernes de livraison de logiciels
Le système de CI/CD (ou plate-forme de livraison de logiciels) moderne d'Anthos vous permet d'effectuer les opérations suivantes :
- Créer et actualiser les bonnes pratiques de provisionnement des applications
- Intégrer de nouvelles applications via des projets de démarrage (ou standards)
- Développer et itérer des applications sans interférer avec le développement d'autres applications
- Mettre en œuvre et diffuser des règles de manière transparente sur la plate-forme
- Utiliser GitOps pour le déploiement comme pour améliorer la gestion des versions et le suivi des modifications
Plate-forme de livraison de logiciels avec Anthos
Les composants illustrés dans le schéma suivant constituent une plate-forme complète de livraison de logiciels, disponible avec la plate-forme Anthos.
Chaque composant fournit des fonctionnalités au système et aux applications exécutées sur la plate-forme. Plusieurs équipes (développement, opérations et sécurité, entre autres) sont généralement chargées d'assurer la disponibilité, la configuration, la stabilité et l'évolutivité de la plate-forme.
Le système CI/CD est un composant essentiel de la plate-forme de livraison de logiciels. Lorsque vous commencez à définir le processus CI/CD, vous devez vous assurer que chaque composant produit ou consomme des artefacts conformes à une interface standardisée. Lorsque vous utilisez une interface standard, il est plus facile d'échanger chaque composant lorsqu'une mise en œuvre plus adaptée est disponible sur le marché. Lorsque vous créez une plate-forme pour des applications en conteneurs, vous avez le choix entre trois interfaces standardisées :
- Dépôts Git
- Images Docker
- Fichiers manifestes Kubernetes
Une fois ces interfaces en place, vous pouvez créer un pipeline CI/CD réutilisable et flexible avec les flux présentés dans le schéma suivant.
Le processus est le suivant :
- Les développeurs valident le code de l'application dans le dépôt Git de l'application.
- Le système CI teste le code, crée un artefact d'image Docker et stocke l'image dans un registre.
- Une fois que l'artefact est prêt pour le déploiement, une référence à cet artefact est ajoutée au fichier de configuration de l'application.
- Cette configuration d'application est affichée dans un format lisible par Kubernetes et stockée dans un dépôt de code qui la déploie dans un environnement de préproduction.
- Une fois les modifications validées dans le dépôt de code, les opérateurs les examinent, puis les fusionnent dans la branche principale.
- L'application est déployée en production.
- Lorsque les opérateurs souhaitent apporter des modifications à l'ensemble de l'organisation, ils valident ces modifications dans leurs dépôts, ce qui déclenche une configuration d'application. Lorsque les développeurs déploient la modification suivante, ils récupèrent les mises à jour des opérateurs.
- En parallèle, les ingénieurs en sécurité peuvent mettre en œuvre et modifier les règles qui définissent ce qui peut être déployé en effectuant des commits dans leur propre dépôt de règles.
Étape 3 : Optimiser les VM sur site pour les anciennes applications Java
Dans cette étape de modernisation, les applications Java s'exécutent en tant que VM dans des centres de données sur site ou dans Google Cloud, comme le montre le schéma suivant.
Certaines applications Java peuvent ne pas être adaptées à la conteneurisation pour les raisons suivantes :
- Certaines de vos applications sont critiques pour l'entreprise. Si la migration de vos applications critiques vers des conteneurs est trop risquée, vous pouvez toujours bénéficier des avantages en termes de coûts liés à l'élasticité de l'infrastructure en déplaçant des VM vers Google Cloud. Dans Google Cloud, vous pouvez personnaliser la taille de la VM pour optimiser ses coûts d'utilisation.
- Les équipes opérationnelles connaissent peu la gestion d'une plate-forme moderne. Certaines équipes opérationnelles peuvent ne pas être au fait de la gestion des environnements de VM ou ne possèdent pas les compétences nécessaires pour fonctionner sur des plates-formes modernes en conteneurs. Par exemple, votre équipe connaît peut-être déjà la chaîne d'outils actuelle pour gérer la connectivité et les dépendances entre les anciennes applications, mais elle a besoin de temps pour s'adapter à une plate-forme conteneurisée en production.
- Vous devez adopter le cloud par étapes. Par exemple, vous pouvez commencer à adopter le cloud, mais sans apporter trop de changements à la fois. Ou, en raison des risques, vous ne souhaiterez peut-être pas modifier simultanément votre environnement (depuis un centre de données vers le cloud) et vos plates-formes (en passant de vos VM à des conteneurs).
- Vous avez des contraintes budgétaires et opérationnelles. Il peut s'agir d'exigences matérielles/d'infrastructure, liées aux licences ou à l'architecture des applications.
Options d'exécution des charges de travail de VM
Vous pouvez choisir l'une ou plusieurs des options suivantes pour exécuter vos charges de travail de VM plus efficacement :
- Sur Google Cloud. Vous pouvez exécuter des VM sur Google Cloud de deux manières :
- En tant qu'instances Compute Engine. Compute Engine offre des VM configurables s'exécutant dans les centres de données Google, qui ont accès à une infrastructure réseau et à un stockage de blocs hautes performances. Cette option libère les entreprises de la gestion des centres de données et des serveurs sur site, ainsi que du paiement des licences commerciales de virtualisation (le cas échéant).
- Comme VMware en tant que service. Le partenariat entre VMware et Google Cloud offre une plate-forme ouverte qui assure un déploiement, des opérations et un niveau de sécurité cohérents pour les applications cloud natives dans les environnements multicloud et cloud hybrides. Cette option s'adresse aux entreprises qui exécutent actuellement VMware et qui s'appuient sur des fonctionnalités spécifiques à VMware. Les entreprises se trouvent dans un environnement cloud hybride pour lequel elles souhaitent un plan de contrôle cohérent pour gérer leurs VM (dans plusieurs environnements), ou ne souhaitent plus gérer leurs propres centres de données et infrastructure de serveur.
- Centres de données sur site. Vous souhaitez peut-être exécuter certaines applications en tant que VM sur site pour plusieurs raisons :
- Considérations réglementaires ou de conformité
- Vos application doivent rester proches de vos utilisateurs ou d'autres applications pour des raisons de performances.
- Investissements actuels en matériel sur site
Outils et solutions pour la migration de VM
Google Cloud fournit divers outils et solutions que vous pouvez utiliser pour migrer vos VM vers Google Cloud. Migrate to Virtual Machines vous permet de valider, d'exécuter et de migrer des applications dans Google Cloud en quelques minutes pendant que les données sont transférées de manière transparente en arrière-plan. Pour obtenir des ressources sur la migration vers Compute Engine, consultez la page Migration vers Google Cloud : premiers pas.
Pour les migrations vers VMWare en tant que service, Google collabore avec des partenaires agréés pour fournir des services professionnels facilitant vos migrations VMware sur Google Cloud.
Étape 4 : Refactoriser des applications en microservices
Une fois la plate-forme modernisée, vous pouvez vous concentrer sur la modernisation des applications exécutées sur la plate-forme. À ce stade, vous sélectionnez des applications qui s'exécutent sur la plate-forme Anthos et les refactorisez en microservices.
Certaines applications peuvent toujours s'exécuter de façon monolithique dans des conteneurs, sans poser problème. La migration de vos applications vers une plate-forme moderne (Anthos, par exemple) est l'une des conditions préalables à la modernisation des applications. Après la migration, le processus de modernisation de vos applications en microservices peut se dérouler au fil du temps.
La migration vers Anthos permet aux développeurs et aux opérateurs de se familiariser avec les nouvelles méthodes de gestion des applications et des plates-formes. Les développeurs apprennent rapidement à fusionner le code et à effectuer des tests fréquemment, tandis que les opérateurs se familiarisent avec les méthodes modernes de création, de test et de livraison de logiciels aux clients.
Pour les applications exécutées sur la plate-forme Anthos, vos domaines d'activité peuvent déterminer celles que vous devez moderniser en priorité sous forme de microservices. Google et ses partenaires d'intégration système (SI) fournissent plusieurs outils destinés aux développeurs et aux opérateurs pour aider les entreprises à réaliser cette étape de modernisation. Ces ressources sont présentées dans les sections suivantes.
Spring Google Cloud
Dans le cadre de la refactorisation, vous pouvez transférer des applications Java vers des frameworks Java modernes tels que Spring Boot. Spring Boot et Spring Framework fournissent un modèle de programmation et de configuration complet pour les applications d'entreprise modernes basées sur Java. Spring Cloud fournit aux développeurs des outils permettant de créer rapidement certains des modèles couramment utilisés dans les systèmes distribués : gestion de la configuration, détection de services, disjoncteurs, routage intelligent, micro-proxy, control bus, jetons ponctuels, verrouillage global, choix du leadership, sessions distribuées et état du cluster.
Pour simplifier l'utilisation de Google Cloud à partir des applications Spring Boot, le projet Spring Google Cloud fournit plusieurs bibliothèques et fonctionnalités compatibles avec les produits Google Cloud suivants :
- Pub/Sub : intégration de Spring et Spring Stream
- Cloud Spanner, Datastore et Cloud SQL : Spring Data
- Cloud Logging et Cloud Trace
- Firestore : dépôts réactifs Spring Data
- Cloud Storage : Spring Resource et intégration de Spring
- API Cloud Vision : modèle
CloudVisionTemplate - Identity-Aware Proxy (IAP) : extraction des identités Spring Security à partir d'en-têtes IAP
- BigQuery : intégration de Spring
Outils de développement
Google Cloud fournit des outils qui vous aident à créer des applications Java modernes en conteneurs. Voici quelques-uns de ces outils :
- Cloud Code. Cloud Code fournit une assistance IDE pour le cycle de développement complet des applications Kubernetes, de la création d'un cluster pour le développement et les tests à l'exécution d'une application finalisée en production. Cloud Code fournit des exemples et des extraits de configuration prêts à l'emploi, ainsi qu'une expérience de débogage sur mesure pour simplifier le développement avec Kubernetes. Cloud Code offre une expérience optimisée de Google Kubernetes Engine (GKE). La création de clusters hébergés sur Google Cloud est plus facile et GKE s'intègre mieux aux outils Google Cloud tels que Cloud Source Repositories, Cloud Storage et une variété de bibliothèques Cloud. Cloud Code peut être utilisé avec VS Code ou IntelliJ.
- Artifact Registry. Artifact Registry fournit un emplacement central pour stocker des artefacts et créer des dépendances dans le cadre d'une expérience Google Cloud intégrée. Artifact Registry fournit un seul emplacement pour la gestion des packages, des bibliothèques et des images de conteneurs Docker. Vous pouvez utiliser ces artefacts (packages et images de conteneurs) dans un pipeline CI/CD moderne, tel que décrit plus haut dans ce document.
Outils de compilation tels que Jib et Buildpacks. Jib et Buildpacks vous permettent de créer des conteneurs à l'aide des outils Java que vous connaissez déjà (tels que Maven ou Gradle). Sans ces outils de compilation, vous devez créer et tester manuellement le fichier Dockerfile. Cette approche manuelle nécessite un hôte avec le daemon Docker en cours d'exécution pour créer et exécuter les conteneurs. Ce processus comprend quelques étapes supplémentaires et peut être répétitif pour les développeurs qui souhaitent transférer leur code en production le plus rapidement et facilement possible. Dans une seule étape de compilation, Jib orchestre la compilation du binaire, crée l'image du conteneur, puis transfère l'image à un registre de conteneurs. Jib utilise des outils de construction connus des développeurs, ce qui améliore leur productivité. Après avoir transféré le conteneur Java dans le registre, vous pouvez le déployer via un pipeline CI/CD. Le schéma suivant illustre ce flux global pour Buildpack ou Jib.
Changer de plate-forme pour des serveurs d'applications Open Source
Pour certaines applications, la refactorisation des applications Java nécessite également de passer à des serveurs d'applications Java. Dans une optique de réduction des coûts de licence, les applications Java qui s'exécutent sur des plates-formes de serveurs d'applications commerciales (par exemple, WebSphere ou WebLogic) sont remplacées par des composants Open Source (tels que JBoss ou Tomcat).
Ancienne architecture d'application Java
Les anciennes applications Java utilisent généralement une architecture JEE à trois ou quatre niveaux. L'architecture JEE permet de développer des applications d'entreprise à plusieurs niveaux. Le schéma suivant montre les niveaux généralement disponibles dans un système d'application JEE.
Les niveaux sont les suivants :
- Niveau de présentation. Au niveau de la présentation, les composants Web, tels que des servlets, des pages JavaServer (JSP ou JST) ou des applications Java autonomes fournissent une interface dynamique au niveau intermédiaire.
- Niveau d'application ou intermédiaire. Au niveau de l'application ou niveau intermédiaire, Enterprise Java Beans et les services Web encapsulent la logique métier réutilisable et distribuable pour l'application. Ces composants au niveau du serveur sont contenus sur un serveur d'applications JEE, qui fournit la plate-forme dont ils ont besoin pour effectuer des actions et stocker des données.
- Niveau des données d'entreprise. Dans ce niveau, les données de l'entreprise sont stockées et conservées, généralement dans une base de données relationnelle.
Ces différents niveaux sont généralement déployés dans des environnements virtualisés et reposent sur des serveurs d'applications, ce qui peut entraîner des coûts de licence élevés.
Avantages du passage à des normes ouvertes
Le passage aux normes ouvertes réduit les coûts de licence et offre les avantages des méthodologies de déploiement et d'une plate-forme basées sur le cloud.
Outils et solutions
Google Cloud s'associe à plusieurs intégrateurs système (SI) ayant opté pour des approches et des outils qui ont fait leurs preuves pour le changement de plate-forme pour les applications JEE et l'adoption des technologies OSS.
Le processus de changement de plate-forme commence par l'évaluation de vos anciennes applications Java. L'évaluation prend en compte de nombreux facteurs, tels que la complexité d'une application, les fonctionnalités, les métriques d'utilisation et la criticité métier. Cette évaluation produit une liste hiérarchisée des applications candidates au changement de plate-forme. Les SI fournissent des outils de développement et DevOps qui aident les entreprises à supprimer du code source toutes les dépendances du serveur d'applications commerciales. Les tests et les critères de sortie sont pris en compte pour chaque application avant le passage à l'étape suivante (déploiement). Cette étape concerne les applications où le code source est accessible et où la variante Open Source de la plate-forme existe.
Bonnes pratiques de refactorisation
Les deux articles Google Cloud suivants expliquent les avantages du passage d'applications monolithiques à des microservices, ainsi que la procédure à suivre :
- Migrer une application monolithique vers des microservices
- Faciliter votre migration avec le déploiement du maillage de services Istio
Connecter des microservices à des VM avec Anthos Service Mesh
Les entreprises disposent de nombreuses applications. Pratiquement toutes les entreprises finissent par exécuter des applications sur l'une des plates-formes suivantes :
- Plate-forme Anthos pour l'exécution de microservices dans des conteneurs
- Plate-forme de virtualisation pour l'exécution des VM
Les services exécutés sur ces deux plates-formes sont souvent dépendants les uns des autres et doivent pouvoir communiquer entre eux de manière sécurisée. Pour les microservices exécutés sur la plate-forme Anthos, Anthos Service Mesh fournit une connexion sécurisée aux VM s'exécutant en dehors d'Anthos dans un environnement virtualisé.
Avantages de l'utilisation d'Anthos Service Mesh avec des VM
- Les VM peuvent exploiter le même framework déclaratif de type Kubernetes pour la gestion de la sécurité et des règles que les conteneurs et les microservices exécutés sur Anthos. Cette approche permet aux opérateurs de disposer d'une connexion authentifiée (mTLS) sécurisée entre les conteneurs s'exécutant sur Anthos et des VM situées dans un autre environnement.
- Aucun codage n'est requis sur les VM existantes pour qu'elles apparaissent en tant que services sur la plate-forme Anthos. Une fois que la VM apparaît en tant que service, Anthos la considère comme un service s'exécutant dans GKE.
- Les opérateurs bénéficient d'une meilleure observabilité (métriques) pour les VM sans aucune instrumentation. Les métriques s'affichent de la même façon que pour un service exécuté sur Anthos.
VM vers conteneurisation
Au fil du temps, vous pouvez déplacer vos VM refactorisées existantes vers des conteneurs. Cette approche vous permet d'effectuer la transition à votre rythme, en privilégiant les applications à moderniser en priorité.
Étape suivante
- Consultez la checklist d'intégration de Google Cloud Enterprise.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.