Développeurs et professionnels

Choisir le bon outil de développement Google IA selon votre projet

Fri, 19 Dec 2025 07:00:00 +0000

Vous souvenez-vous de ce que signifiait préparer un long voyage il y a vingt ans ? Il fallait prévoir l’appareil photo, l’agenda, la pile de livres, la console portable, le guide touristique rempli de cartes, un téléphone, un lecteur CD… et parfois même des chèques de voyage. Aujourd’hui ? Un smartphone suffit !

Appelez-ça « l’effet consolidation »… mais l’évolution passe aussi parfois par la diversification. Prenons l’ordinateur, par exemple : il n’y a pas si longtemps, il se résumait au PC de bureau, unique appareil pour tous les usages. Désormais, nous avons des ordinateurs portables pour travailler en situation de mobilité, des tablettes pour consulter des contenus, des smartphones pour rester connecté en permanence à Internet, des téléviseurs intelligents pour regarder tout type de média… sans oublier une multitude de consoles de jeux.

Tantôt regroupement, tantôt éclatement, ces évolutions me rappellent l’état actuel des outils pour développeurs. Jusqu’à récemment, le paysage était relativement stable : des outils de conception UX pour réaliser des maquettes, des IDE pour écrire du code, des systèmes de build pour assembler les artefacts, et des scripts système ou shell pour déployer infrastructures et applications.
Avec l’essor de l’IA générative, tout a basculé : l’univers des outils est devenu foisonnant et en constante évolution. Nos pratiques, comme nos outils, ne seront plus jamais les mêmes.

Dans ce contexte, comment choisir le bon outil en fonction du projet ? Rien que chez Google, l’éventail est déjà large : des interfaces LLM comme l’application Gemini et Google AI Studio, des extensions d’IDE comme Gemini Code Assist, des environnements de développement dans le navigateur tels que Firebase Studio, ou encore des services « agentiques » comme Jules et Gemini CLI. Face à une telle profusion d’outils, on est vite submergé ! Pas de panique : on va vous aider ici à faire le tri !

La diversification des outils s’explique notamment par la façon dont l’IA intervient aujourd’hui dans le développement logiciel.

La première approche, dite déléguée, repose sur des options agentiques : vous confiez la tâche à l’IA comme si vous l’externalisiez à un prestataire, en lui donnant des instructions détaillées, puis vous n’avez que très peu d’interactions jusqu’à la fin de l’exécution du processus. L’objectif est avant tout d’obtenir un résultat rapidement, sans chercher à développer vos propres compétences.
La deuxième approche, dite supervisée, consiste à considérer l’IA comme un collaborateur placé sous votre supervision. Vous interagissez davantage avec elle que dans l’approche déléguée : vous la guidez, l’orientez, et tirez parti de votre expérience pour cadrer son action.
Enfin, l’approche collaborative repose sur un dialogue continu avec l’assistant IA, dans un va-et-vient permanent où l’on « progresse » ensemble, comme dans un processus d’apprentissage partagé.

Forces et usages de chaque outil IA de développement

Jules excelle dès qu’il s’agit d’appliquer des instructions explicites, des consignes précises, pour automatiser des tâches en série (des batchs) sans supervision : ajouter de la documentation, améliorer la couverture des tests, moderniser chirurgicalement du code. Tout ceci directement sur du code source hébergé sur GitHub.com. Ses atouts ?

Pas d’infrastructure ou de processus à gérer et maintenir : Jules fonctionne directement, sans avoir à déployer ou entretenir des serveurs ou pipelines.
Possibilité de définir le déroulé avant exécution : vous pouvez discuter avec Jules pour établir un plan des actions (quelles tâches lancer, dans quel ordre) avant de lui confier l’exécution automatique.
Résultats restitués sous forme de modifications prêtes à l’emploi : Jules propose un lot de changements concrets dans le code, accompagné d’une pull request que vous pouvez examiner puis valider dans GitHub.
Un modèle de tarification souple : Jules est disponible avec un palier gratuit, complété par des formules payantes (Pro et Ultra) pour les usages plus avancés.

Gemini CLI propose une interface en ligne de commande ouverte et flexible, conçue pour travailler efficacement avec du code et du contenu, en mode interactif ou « délégué » :

Mise en place simple : une simple installation locale de Node suffit.
Extensible : outils intégrés et compatibilité avec MCP.
Intégration avec d’autres services, dont Gemini Code Assist et Firebase Studio.
Gemini CLI GitHub Actions en open source : permet de déléguer des tâches en arrière-plan sur vos dépôts de code — comme le tri des tickets ou la revue de pull requests — via des déclencheurs automatiques ou manuels.
Souplesse d’utilisation et de tarification : des quotas (volumes d’utilisation) gratuits conséquents sont proposés pour les modèles Gemini, le support des accès sécurisés ‘entreprise’ via Vertex AI et la compatibilité avec une licence Gemini Code Assist

Gemini Code Assist propose une extension pour IDE complète qui permet des interactions conversationnelles ou de type agentiques avec une base de code :

Disponible en mode plug-in pour Visual Studio Code (VSCode) et JetBrains.
Gère la complétion de code, la génération de tests, l’explication de code, la création de nouvelles portions de code.
Extensible : support des commandes personnalisées, outils complémentaires et personnalisation sur vos bases de code privées. Le mode agent, basé sur Gemini CLI, permet en plus des interactions plus complexes
Tarification souple : quotas (volumes d’utilisation) gratuits et formule par utilisateur et par mois pour les équipes

Firebase Studio est le choix idéal si vous voulez concevoir des applications de qualité professionnelle, sans avoir besoin d’être développeur de métier, dans un environnement de développement managé par Google et accessible depuis le navigateur :

Templates inclus pour les frameworks et langages populaires afin de démarrer rapidement vos projets
Vous pouvez laisser Gemini Vibe générer votre application, ou bien prendre la main et exploiter toute la puissance d’une machine virtuelle personnalisable pour coder vous-même l’application
Configuration de l’environnement de travail avec Nix
Gratuit pendant la phase de preview. Davantage d’environnements sont proposés aux personnes inscrites au Google Developer Program.

Google AI Studio propose la façon la plus simple d’explorer les derniers modèles de Google, d’expérimenter avec des prompts et de prototyper des applications web légères.

Générez des contenus multimédia, utilisez l’API Live pour des sessions interactives et rédigez des prompts pour les modèles Gemini et Gemma
Rédigez des prompts avancés, combinez-les à des outils, appuyez-vous sur Google Search pour l’ancrage et comparez les résultats
Obtenez des clés API pour appeler les modèles Gemini de manière programmatique
Tarification souple : un quota gratuit conséquent (volumes d’utilisation) et une formule payante avec des limites de requêtes plus élevées, davantage de fonctionnalités et une gestion des données différenciée

En résumé :

Choisissez Gemini app pour prototyper rapidement une application.
Choisissez Google AI Studio pour expérimenter des prompts ciblant des modèles et fonctionnalités spécifiques.
Choisissez Gemini Code Assist pour un développement assisté par l’IA dans votre environnement, avec votre suite d’outils habituelle.
Choisissez Firebase Studio si vous souhaitez travailler dans un environnement entièrement managé par Google, accessible via le navigateur, pour prototyper ou laisser Gemini Vibe coder des applications complètes, sans avoir besoin d’être développeur.
Choisissez Gemini CLI si vous travaillez sur de nombreux de projets en IA générative et que vous recherchez la rapidité et la portabilité d’une interface en ligne de commande agentique.
Et utilisez les GitHub Actions Gemini CLI si vous voulez bénéficier de la sécurité Google Cloud et des modèles Gemini, tout en déclenchant des tâches interactives ou en arrière-plan pour vos projets basés sur GitHub.
Choisissez Jules si vous avez des projets hébergés sur GitHub nécessitant des modifications pouvant être exprimées clairement sous forme d’instructions.

De toute ma carrière, je n’ai jamais vu les outils de développement logiciel évoluer aussi vite — ni une telle volonté chez les développeurs d’expérimenter toutes les nouveautés. C’est à la fois enthousiasmant… et déroutant. Ces différents outils sont complémentaires : vous aurez sans doute besoin d’en combiner plusieurs pour mener vos projets à bien.

Chez Google, nous allons continuer à nous concentrer sur un objectif simple : vous donner les meilleurs outils IA pour créer les meilleures applications IA. Et nous comptons aussi beaucoup sur vos retours d’expérience pour y parvenir.

Boostez vos projets IA avec l’architecture de référence GKE pour passer plus facilement de l’expérimentation à la production

Fri, 31 Oct 2025 08:00:00 +0000

Nous sommes définitivement entrés dans l’ère de l’IA. Partout dans le monde, les organisations s’empressent de déployer des modèles toujours plus puissants pour stimuler l’innovation, enrichir leur offre et inventer de nouvelles expériences utilisateurs.
Néanmoins, transformer un modèle entraîné en laboratoire en un service d’inférence scalable, rentable et prêt pour la mise en production reste un défi d’ingénierie majeur. Cela demande une expertise pointue en infrastructure, réseau, sécurité, ainsi qu’une maîtrise de tous les domaines « Ops » : MLOps, LLMOps, DevOps, etc.

Aujourd’hui, nous simplifions radicalement cette étape ! Nous lançons « l’architecture de référence GKE pour l’inférence » (GKE inference reference architecture) : une solution complète, prête pour le passage en production et conçue pour le déploiement de vos workloads d’inférence sur Google Kubernetes Engine (GKE).

Bien plus qu’un simple guide, cette architecture de référence propose un framework prêt à l’emploi, opérationnel, automatisé et prescriptif, conçu pour offrir le meilleur de GKE pour l’inférence.

Démarrez avec des fondations solides : GKE base platform

Toute architecture solide commence par des fondations fiables : notre architecture de référence pour l’inférence de modèles IA s’appuie sur GKE base platform, une couche fondamentale fournissant une configuration sécurisée et optimisée pour exécuter tout type de workload nécessitant un accélérateur matériel (GPU, TPU).

Reposant sur les principes de l’infrastructure-as-code (IaC) et sur Terraform, cette plateforme de base pose les fondations solides d’un environnement optimal pour l’inférence, avec à la clé les atouts suivants:

Des déploiements automatisés et reproductibles : garantissez la cohérence de vos environnements et facilitez le versioning grâce au provisioning automatisé de vos ressources avec des scripts IaC.
Scalabilité et haute disponibilité intégrées : profitez d’une configuration qui prend nativement en charge l’autoscaling et la tolérance aux pannes.
Bonnes pratiques de sécurité : protégez vos environnements critiques en appliquant dès le début du projet les meilleures pratiques : clusters privés, nœuds GKE protégés (Shielded GKE Nodes) et gestion sécurisée des artefacts.
Observabilité intégrée : bénéficiez d’une visibilité complète sur vos applications et votre infrastructure, grâce à l’intégration native avec Google Cloud Observability.

En vous appuyant sur cette base GKE standardisée, vous bénéficiez dès le départ d’un socle sécurisé, évolutif et simple à administrer, ce qui permet d’accélérer la mise en production de vos projets.

Pourquoi une plateforme optimisée pour l’inférence ?

La GKE Base Platform fournit le socle. Notre nouvelle « architecture de référence GKE » l’enrichit d’une couche spécialisée, conçue pour la haute performance. Elle a été pensée pour relever les défis spécifiques de la mise en production des modèles de machine learning.

Voici trois bonnes raisons d’adopter notre plateforme pour accélérer le déploiement de vos workloads d’inférence IA :

1 - Trouver l’équilibre optimal entre performance et coûts

Déployer une inférence, c’est jongler entre latence, débit et coûts. Notre solution est conçue pour trouver l’équilibre idéal et maximiser l’utilisation de vos ressources.

Utilisation intelligente des accélérateurs : l’usage des GPU et TPU est optimisé grâce à des classes de calcul personnalisées, pour que vos pods s’exécutent sur le matériel dont ils ont réellement besoin. Avec le Node Auto-Provisioning (NAP), le cluster provisionne automatiquement les ressources adéquates, au moment opportun.
Un scaling plus intelligent : au-delà du simple dimensionnement basé sur le CPU et la mémoire, un adaptateur de métriques personnalisé permet au Horizontal Pod Autoscaler (HPA) d’ajuster vos modèles en fonction de vraies métriques d’inférence — comme les requêtes par seconde (QPS) ou la latence — afin que vous ne payiez que ce que vous utilisez réellement.

Chargement plus rapide des modèles : les modèles volumineux impliquent des images de conteneur lourdes. Nous exploitons l’API Container File System et le streaming d’images dans GKE, associés à Cloud Storage FUSE, pour réduire de façon significative le délai de démarrage des pods. Vos conteneurs peuvent ainsi se lancer immédiatement, tandis que les données du modèle sont chargées en arrière-plan, ce qui minimise la latence liée aux démarrages à froid (cold start).

2 - S’adapter à tous les scénarios d’inférence

Que vous fassiez de la détection de fraude en temps réel, de l’analytique en mode batch ou que vous travailliez avec un modèle « frontière », notre architecture est conçue pour s’adapter à tous vos besoins. Son framework prend en charge les cas suivants :

Inférence en temps réel (online) : privilégie des réponses à faible latence pour les applications interactives.
Inférence par lots (batch/offline) : traite efficacement de grands volumes de données pour les tâches non sensibles au temps.
Inférence en flux (streaming) : gère en continu les données entrantes, par exemple depuis Pub/Sub.

L’architecture s’appuie sur des fonctionnalités GKE comme le cluster autoscaler et l’API Gateway, pour un routage du trafic avancé, flexible et robuste, capable d’absorber des volumes massifs de requêtes sans perte de performance.

3 - Simplifier l’exploitation des modèles complexes

Nous avons intégré des fonctionnalités qui masquent la complexité de la mise en production des modèles IA modernes, et tout particulièrement des LLM. Notre architecture inclut également des bonnes pratiques ainsi que des exemples et des configurations prêtes à l’emploi pour mettre en œuvre des techniques avancées d’optimisation de modèles, telles que la quantification (INT8/INT4), le parallélisme de tenseurs et de pipelines, ou encore les optimisations de cache KV comme Paged et Flash Attention.

De plus, avec GKE en mode Autopilot, vous déléguez entièrement la gestion des nœuds à Google : vous pouvez ainsi vous concentrer sur vos modèles plutôt que sur la gestion de l’infrastructure.

Prêts à passer à l’action ?

Construisez dès maintenant votre plateforme d’inférence sur GKE. L’architecture de référence GKE pour l’inférence est disponible dans le dépôt GitHub Google Cloud Accelerated Platforms. Vous y trouverez tout le nécessaire pour vous lancer : code Terraform, documentation et exemples de cas d’usage.

Nous avons inclus des exemples pour déployer rapidement des workloads courants comme ComfyUI, ainsi qu’un scénario d’inférence en temps réel générique exploitant GPU et TPU.

En combinant les fondations robustes de GKE base platform avec les performances et les optimisations opérationnelles de l’architecture de référence pour l’inférence, vous pouvez déployer vos workloads IA avec confiance, rapidité et efficacité. Inutile de réinventer la roue : commencez à bâtir l’avenir sur GKE.

Construire l’avenir de l’IA avec GKE

L’architecture de référence GKE pour l’inférence est bien plus qu’un simple ensemble d’outils : elle reflète l’engagement de Google à faire de GKE la meilleure plateforme pour exécuter vos workloads d’inférence. En proposant une architecture claire, prescriptive et extensible, nous vous donnons les moyens d’accélérer votre adoption de l’IA et de concrétiser vos idées les plus innovantes.

Nous avons hâte de découvrir ce que vous allez construire avec l’architecture de référence GKE pour l’inférence. Vos retours sont les bienvenus : n’hésitez pas à partager vos remarques directement dans le dépôt GitHub.

Créer plus vite et coder mieux : comment l’IA refaçonne l’expérience développeur sur Google Cloud

Tue, 30 Sep 2025 07:00:00 +0000

La mission de l'équipe Expérience Développeur de Google Cloud est simple : aider les développeurs à passer de l'apprentissage au déploiement aussi rapidement et efficacement que possible. Pour y parvenir, notre stratégie repose sur deux outils principaux : une documentation pratique et robuste associée à des exemples de code prêts à l'emploi intégrés directement dans celle-ci, sur lesquels les développeurs s'appuient quotidiennement. Alors que les services de Google Cloud s'étendent et évoluent à un rythme rapide, maintenir la qualité, la précision et la couverture de ces ressources étroitement intégrées représente un défi d’envergure. Or les développeurs d’aujourd’hui attendent des réponses immédiates et des conseils précis et idiomatiques. Toute lacune risque de freiner l'adoption et de compromettre leur productivité.

Pour relever ce défi, nous exploitons de manière stratégique l’IA générative, propulsée par Gemini, au cœur de nos workflows de création de contenus. Il ne s’agit pas de remplacer l’expertise humaine, mais d’utiliser la technologie pour renforcer notre capacité à apporter de la valeur aux développeurs, plus rapidement et à plus grande échelle. Voici comment nous mettons l’IA au service d’une documentation de qualité et d’exemples de code plus riches et mieux intégrés.

Une documentation dopée à l’IA : accélérer la cadence et garantir l’exactitude

Pour nos équipes de rédaction technique, la cadence du développement de Google Cloud soulève deux questions majeures : comment suivre le rythme pour documenter les nouvelles fonctionnalités sans cesse ajoutées et comment garantir que la documentation existante reste exacte ?

Pour accélérer le processus de création, nous avons intégré Gemini au cœur des environnements d'écriture de nos rédacteurs. L’assistant IA agit comme un multiplicateur de productivité, en fluidifiant des tâches courantes telles que la génération de tableaux formatés à partir de contenus non structurés, la traduction entre langages de balisage ou l’application en un clic de guides stylistiques complexes. Surtout, l’IA libère du temps pour l’essentiel : concevoir une documentation plus stratégique et livrer un contenu de haute qualité.

La validation du contenu représente un enjeu aussi crucial que sa création. Depuis des années, les tests de non-régression automatisés traquent les bugs dans le code. Nous appliquons désormais la même discipline à la documentation, un objectif longtemps considéré comme utopique, en raison de l’ambiguïté du langage naturel.
Pour nos « quickstarts » (guides de démarrage rapide), nous utilisons Gemini pour lire les étapes pas-à-pas et automatiquement générer des scripts d’orchestration web (en utilisant des frameworks comme Playwright). Ces scripts exécutent ensuite les différentes étapes dans un environnement Google Cloud réel, vérifiant automatiquement que notre documentation reflète fidèlement le comportement du produit. Nous faisons tourner plus d’une centaine de tels tests chaque jour, ce qui garantit une validation continue de nos guides « quickstart » et vous assure de la fiabilité des étapes présentées.

Démultiplier les exemples de code au sein des documentations via des Agents IA

Les extraits de code intégrés à nos documentations soulèvent des défis similaires, voire plus complexes : assurer une large couverture des langages, gérer leur mise à jour au fur et à mesure des évolutions des API et des bonnes pratiques, et optimiser l’utilisation de nos ressources d’ingénierie.
Créer et maintenir manuellement des dizaines de milliers d’exemples idiomatiques pour l’ensemble de notre documentation — y compris pour la « longue traîne » d’API spécialisées — n’est simplement pas imaginable.

Notre solution repose sur un système agentique qui automatise l’intégralité du cycle de vie d’un exemple de code destiné à notre documentation. Ce workflow automatisé est ancré sur l’ultime source de vérité des API Google à savoir les essentielles définitions Protobuf (proto) hébergées dans les dépôts publics « googleapis ». Ainsi, nos exemples restent toujours fidèles à l’implémentation réelle et actualisée de l’API, sans risque d’erreurs ou d’écarts.

Le système fonctionne en trois étapes principales :

1 - Assemblage du prompt : Un agent prépare un prompt très détaillé en analysant la méthode API ciblée et en combinant un modèle de code « one-shot » avec les noms de méthodes, paramètres et documentations issus de sa définition officielle Protobuf. Cette approche structurée et fondée sur les données est essentielle : elle contraint le modèle, évite les hallucinations et garantit que le prompt repose dès le départ sur les détails factuels de l’API.

2 - Génération et affinage : Le prompt est ensuite transmis à Gemini pour générer un premier brouillon. Un autre agent « évaluateur » note ensuite l’exemple généré selon un barème rigoureux. Si le résultat est insuffisant, un retour précis est renvoyé au générateur afin d’obtenir une version améliorée. Ce « dialogue » automatisé entre agents imite un processus de relecture par les pairs, qui s’exécute à une vitesse et une échelle impossibles à atteindre manuellement.

3 - Tests automatisés : Une fois approuvé, l’exemple est déployé dans un environnement conteneurisé où il subit une batterie finale de tests : build/compilation, linting et exécution pour confirmer son bon fonctionnement. De quoi offrir un niveau de confiance permettant sa publication en toute sérénité et à grande échelle dans notre documentation.

Au cœur de notre approche se trouve un agent d’audit dopé à l’IA. Véritable contrôleur qualité, il passe chaque appel d’API au crible en le comparant à la documentation officielle, grâce à l’association de Gemini et Google Search. Résultat : chaque détail est vérifié en appui sur nos documentations publiques, assurant un standard de qualité uniforme pour tous les exemples, qu’ils soient écrits par des humains ou générés par l’IA.

L’avenir est augmenté : qualité et expertise à l’échelle

À mesure que nous montons en charge, ce niveau d’automatisation permet à nos experts humains de faire évoluer leur rôle. Ils se concentrent désormais sur l’amélioration des systèmes d’IA eux-mêmes, enquêtant sur les anomalies statistiques, effectuant des échantillonnages d'audit pour valider les évaluateurs IA, et affinant les modèles génératifs. Cette nouvelle approche valorise leur travail et garantit une qualité uniforme à une échelle que des humains seuls ne pourraient atteindre.

En automatisant la création de la documentation de base et du code qu’elle contient, nous libérons nos équipes pour qu’elles se consacrent à ce dont les développeurs ont le plus besoin : un contenu détaillé, orienté solutions, qui résout des problèmes complexes et concrets. Ce partenariat stratégique entre experts humains et agents IA est au cœur de notre approche. Il nous permet d’offrir une expérience développeur plus complète, précise et réactive, garantissant que, quel que soit votre projet sur Google Cloud, vous disposiez de la documentation et du code intégré nécessaires à votre réussite.

Comment créer et déployer un serveur MCP distant sur Google Cloud Run en 10 minutes chrono !

Sun, 24 Aug 2025 11:00:00 +0000

Plus un modèle IA a connaissance des contextes, plus ses réponses sont pertinentes et moins il a tendance à halluciner. Mais cette intégration du contexte – issu des outils métier et des sources de données – dans les LLMs s’avère souvent laborieuse et freine la création et la démocratisation des agents IA. Pour relever ce défi, Anthropic a introduit le Model Context Protocol (MCP), qui standardise la manière dont les applications fournissent du contexte aux LLM.

Imaginez que vous souhaitiez créer un serveur MCP pour votre API afin de le rendre vos données accessibles à d’autres développeurs, pour qu’ils puissent l’utiliser comme contexte dans leurs propres applications d’IA. Se posera alors forcément la question « où le déployer ? ». Notre réponse à cette question sonne comme une évidence : « sur Google Cloud Run bien sûr ! »

Le guide ci-dessous, directement inspiré de la documentation officielle de Cloud Run, vous montre étape par étape comment créer et héberger facilement votre propre serveur MCP à distance. De quoi révolutionner la manière dont vous injectez du contexte dans vos applications IA !

Transports MCP

Le protocole MCP repose sur une architecture client-serveur. À l’origine limité à une exécution locale via stdio, le protocole MCP a, depuis, considérablement évolué et prend désormais en charge des transports d’accès distant : streamable-http et sse. Certes, les « Server-Sent Events » (SSE) sont aujourd’hui obsolètes et remplacés par Streamable HTTP dans la dernière spécification MCP, mais ils restent pris en charge pour assurer la compatibilité avec les versions précédentes.

https://modelcontextprotocol.io/introduction

Avec Streamable HTTP, le serveur MCP fonctionne comme un processus indépendant capable de gérer plusieurs connexions client. Ce transport utilise les requêtes HTTP POST et GET.

Le serveur DOIT exposer un unique chemin d’endpoint HTTP (appelé endpoint MCP) supportant les méthodes POST et GET. Par exemple, au travers d’une URL telle que : https://example.com/mcp.

Pour explorer les différents types de transport, consultez la documentation officielle de MCP.

Pourquoi passer au serveur MCP distant ?

Exécuter un serveur MCP à distance sur Google Cloud Run offre plusieurs avantages :

Scalabilité : Cloud Run est conçu pour s’adapter rapidement au volume des requêtes entrantes. Le service absorbe sans sourciller les montées en charge, dimensionnant votre serveur MCP à la volée, que ce soit pour quelques requêtes ou de massifs pics soudains de trafic.

Serveur centralisé : Vous pouvez partager l’accès à un serveur MCP centralisé avec d’autres membres de votre équipe via les privilèges IAM. Chacun peut s’y connecter depuis sa propre machine, en toute sécurité, sans avoir à gérer son propre serveur. Toute modification apportée au serveur MCP profite instantanément à tous les utilisateurs.

Sécurité renforcée : Cloud Run facilite la mise en place d’un accès authentifié, garantissant que seules les connexions autorisées peuvent accéder à votre serveur MCP et évitant ainsi tout accès non autorisé.

IMPORTANT : sans authentification, votre serveur MCP devient accessible à n’importe qui sur le web. Une faille critique à éviter absolument.

Prérequis

* Python 3.10 ou supérieur

* Uv, l’outil nouvelle génération pour gérer vos dépendances Python et piloter votre projet. Consultez la doc officielle pour une installation rapide.

* Google Cloud SDK (gcloud)

Installation

Adaptation dynamique et incisive :

Commencez par créer un dossier de travail « mcp-on-cloudrun ». C’est dans ce répertoire que vous centraliserez l’ensemble du code source de votre serveur MCP ainsi que les fichiers nécessaires au déploiement sur Cloud Run.

code_block: <ListValue: [StructValue([('code', 'mkdir mcp-on-cloudrun\r\ncd mcp-on-cloudrun'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7dd60>)])]>

Passons à l’action ! Utilisez uv pour initialiser votre projet. Ce puissant gestionnaire de projets va simplifier à la fois la création et la gestion des dépendances de votre serveur MCP.

code_block: <ListValue: [StructValue([('code', 'uv init --name "mcp-on-cloudrun" --description "Example of deploying a MCP server on Cloud Run" --bare --python 3.10'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7da00>)])]>

Après avoir exécuté la commande ci-dessus, vous devriez voir apparaître le fichier pyproject.toml suivant :

code_block: <ListValue: [StructValue([('code', '[project]\r\nname = "mcp-on-cloudrun"\r\nversion = "0.1.0"\r\ndescription = "Example of deploying a MCP server on Cloud Run"\r\nrequires-python = ">=3.10"\r\ndependencies = []'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7dd30>)])]>

Poursuivons la mise en place ! Ajoutez maintenant les fichiers essentiels à la racine de votre projet :
- server.py : le cœur du code de votre serveur MCP.
- test_server.py : pour valider facilement le fonctionnement du serveur à distance.
- Dockerfile : indispensable pour packager et déployer votre application sur Cloud Run.

code_block: <ListValue: [StructValue([('code', 'touch server.py test_server.py Dockerfile'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7ddc0>)])]>

La structure de nos fichiers devrait maintenant être complète et ressembler à ça :

code_block: <ListValue: [StructValue([('code', '├── mcp-on-cloudrun\r\n│ ├── pyproject.toml\r\n│ ├── server.py\r\n│ ├── test_server.py\r\n│ └── Dockerfile'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7d340>)])]>

Maintenant que notre structure de fichiers est en place, configurons nos identifiants Google Cloud et sélectionnons notre projet :

code_block: <ListValue: [StructValue([('code', 'gcloud auth login\r\nexport PROJECT_ID=<your-project-id>\r\ngcloud config set project $PROJECT_ID'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7de20>)])]>

Math MCP Server

Les LLM excellent dans les tâches non déterministes : comprendre l’intention, générer du texte créatif, résumer des idées complexes ou raisonner sur des concepts abstraits. En revanche, ils sont notoirement peu fiables pour les tâches déterministes : celles qui n’admettent qu’une seule réponse correcte.

Doter les LLM de fonctions déterministes (comme des opérations de calcul mathématique) est un bon exemple de la façon dont des outils externes peuvent apporter un contexte précieux via MCP pour améliorer leur utilisation et/ou leurs capacités.

Nous allons utiliser FastMCP pour créer un simple serveur MCP dédié aux opérations mathématiques, doté de deux « outils » : addition et soustraction. FastMCP propose une méthode rapide et pythonique pour construire des serveurs et clients MCP.

Ajoutez FastMCP comme dépendance dans votre fichier pyproject.toml :

code_block: <ListValue: [StructValue([('code', 'uv add fastmcp==2.6.1 --no-sync'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7d220>)])]>

Copiez et collez le code suivant dans le fichier server.py afin de mettre en place notre serveur MCP dédié aux opérations mathématiques :

code_block: <ListValue: [StructValue([('code', 'import asyncio\r\nimport logging\r\nimport os\r\n\r\nfrom fastmcp import FastMCP \r\n\r\nlogger = logging.getLogger(__name__)\r\nlogging.basicConfig(format="[%(levelname)s]: %(message)s", level=logging.INFO)\r\n\r\nmcp = FastMCP("MCP Server on Cloud Run")\r\n\r\n@mcp.tool()\r\ndef add(a: int, b: int) -> int:\r\n """Use this to add two numbers together.\r\n \r\n Args:\r\n a: The first number.\r\n b: The second number.\r\n \r\n Returns:\r\n The sum of the two numbers.\r\n """\r\n logger.info(f">>> Tool: \'add\' called with numbers \'{a}\' and \'{b}\'")\r\n return a + b\r\n\r\n@mcp.tool()\r\ndef subtract(a: int, b: int) -> int:\r\n """Use this to subtract two numbers.\r\n \r\n Args:\r\n a: The first number.\r\n b: The second number.\r\n \r\n Returns:\r\n The difference of the two numbers.\r\n """\r\n logger.info(f">>> Tool: \'subtract\' called with numbers \'{a}\' and \'{b}\'")\r\n return a - b\r\n\r\nif __name__ == "__main__":\r\n logger.info(f" MCP server started on port {os.getenv(\'PORT\', 8080)}")\r\n # Could also use \'sse\' transport, host="0.0.0.0" required for Cloud Run.\r\n asyncio.run(\r\n mcp.run_async(\r\n transport="streamable-http", \r\n host="0.0.0.0", \r\n port=os.getenv("PORT", 8080),\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7d2b0>)])]>

Transport

Dans cet exemple, nous utilisons le transport streamable-http, recommandé pour les serveurs distants. Cependant, il est également possible d’utiliser sse (Server-Sent Events), qui reste pris en charge pour des raisons de compatibilité.

Si vous souhaitez utiliser sse, il suffit de modifier la dernière ligne du fichier server.py en définissant transport="sse".

Déploiement sur Cloud Run

Il est temps de passer au déploiement sur Cloud Run. Copiez et collez le code ci-dessous dans le fichier Dockerfile (actuellement vide) : ce fichier utilise uv pour exécuter notre server.py.

code_block: <ListValue: [StructValue([('code', '# Use the official Python lightweight image\r\nFROM python:3.13-slim\r\n\r\n# Install uv\r\nCOPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/\r\n\r\n# Install the project into /app\r\nCOPY . /app\r\nWORKDIR /app\r\n\r\n# Allow statements and log messages to immediately appear in the logs\r\nENV PYTHONUNBUFFERED=1\r\n\r\n# Install dependencies\r\nRUN uv sync\r\n\r\nEXPOSE $PORT\r\n\r\n# Run the FastMCP server\r\nCMD ["uv", "run", "server.py"]'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7d9a0>)])]>

Deux options s’offrent à vous : déployer directement votre code source ou passer par une image conteneurisée.

Quel que soit votre choix, il est crucial d’ajouter le flag --no-allow-unauthenticated lors du déploiement : c’est votre rempart contre tout accès non autorisé. Sans cette précaution, votre serveur MCP serait exposé à la première sollicitation venue… avec tous les risques que cela implique.

Option 1 – Déployer le code source

code_block: <ListValue: [StructValue([('code', 'gcloud run deploy mcp-server --no-allow-unauthenticated --region=us-central1 --source .'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7d5e0>)])]>

Option 2 – Déployer une image conteneurisée

Commencez par créer un dépôt Artifact Registry pour stocker l’image du conteneur.

code_block: <ListValue: [StructValue([('code', 'gcloud artifacts repositories create remote-mcp-servers \\\r\n --repository-format=docker \\\r\n --location=us-central1 \\\r\n --description="Repository for remote MCP servers" \\\r\n --project=$PROJECT_ID'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7dca0>)])]>

Enchaînons avec la création de votre image Docker et son transfert sécurisé dans Artifact Registry grâce à Cloud Build.
Cet outil Google Cloud automatise chaque étape : compilation de l’image, gestion des dépendances et push dans votre repository Artifact Registry, le tout dans un environnement conteneurisé, fiable et reproductible.

code_block: <ListValue: [StructValue([('code', 'gcloud builds submit --region=us-central1 --tag us-central1-docker.pkg.dev/$PROJECT_ID/remote-mcp-servers/mcp-server:latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d7db20>)])]>

Il ne reste plus qu’à déployer votre image conteneurisée du serveur MCP sur Cloud Run.

code_block: <ListValue: [StructValue([('code', 'gcloud run deploy mcp-server \\\r\n --image us-central1-docker.pkg.dev/$PROJECT_ID/remote-mcp-servers/mcp-server:latest \\\r\n --region=us-central1 \\\r\n --no-allow-unauthenticated'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095844190>)])]>

Une fois l’une ou l’autre des options terminée, si votre service a été déployé avec succès, vous verrez s’afficher un message similaire à celui-ci :

code_block: <ListValue: [StructValue([('code', 'Service [mcp-server] revision [mcp-server-12345-abc] has been deployed and is serving 100 percent of traffic.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095844040>)])]>

Authentification des clients MCP

On ne badine pas avec la sécurité, même sur des tests. Puisque nous avons spécifié un peu plus haut l’option « --no-allow-unauthenticated » pour exiger une authentification, tout client MCP se connectant à notre serveur MCP distant devra s’authentifier.

La documentation officielle « Héberger des serveurs MCP sur Cloud Run » fournit des informations détaillées sur ce sujet, selon l’environnement dans lequel vous exécutez votre client MCP.

Dans cet exemple, nous utiliserons le proxy Cloud Run pour établir un tunnel authentifié vers notre serveur MCP distant, directement depuis notre machine locale.

Par défaut, l’URL des services Cloud Run exige que toutes les requêtes soient autorisées avec le rôle IAM « Cloud Run Invoker » (roles/run.invoker). Ce binding de politique IAM garantit l’utilisation d’un mécanisme d’authentification robuste pour votre client MCP local.

Assurez-vous que vous, ainsi que tous les membres de l’équipe qui souhaitent accéder au serveur MCP distant, disposez bien du rôle IAM « roles/run.invoker » associé à votre compte Google Cloud principal (ou à leurs comptes Google Cloud).

Remarque : La commande suivante peut vous inviter à télécharger le proxy Cloud Run s’il n’est pas déjà installé. Suivez les instructions pour l’installer si besoin.

code_block: <ListValue: [StructValue([('code', 'gcloud run services proxy mcp-server --region=us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb0958444c0>)])]>

Si tout se passe bien, vous devriez voir apparaître le message suivant :

code_block: <ListValue: [StructValue([('code', 'Proxying to Cloud Run service [mcp-server] in project [<YOUR_PROJECT_ID>] region [us-central1]\r\nhttp://127.0.0.1:8080 proxies to https://mcp-server-abcdefgh-uc.a.run.app'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb0958440a0>)])]>

Tout le trafic envoyé vers http://127.0.0.1:8080 sera désormais authentifié et redirigé vers notre serveur MCP distant.

Tester le serveur MCP distant

Dernière ligne droite : la validation ! Connectez-vous à votre serveur MCP fraîchement déployé avec le client FastMCP, via l’URL locale sécurisée http://127.0.0.1:8080/mcp (attention, le suffixe /mcp est indispensable avec le transport Streamable HTTP).

Il ne vous reste plus qu’à ajouter ce script dans test_server.py pour tester en conditions réelles les fonctions d’addition et de soustraction de votre serveur MCP distant.

code_block: <ListValue: [StructValue([('code', 'import asyncio\r\n\r\nfrom fastmcp import Client\r\n\r\nasync def test_server():\r\n # Test the MCP server using streamable-http transport.\r\n # Use "/sse" endpoint if using sse transport.\r\n async with Client("http://localhost:8080/mcp") as client:\r\n # List available tools\r\n tools = await client.list_tools()\r\n for tool in tools:\r\n print(f">>> Tool found: {tool.name}")\r\n # Call add tool\r\n print(">>> Calling add tool for 1 + 2")\r\n result = await client.call_tool("add", {"a": 1, "b": 2})\r\n print(f"<<< Result: {result[0].text}")\r\n # Call subtract tool\r\n print(">>> Calling subtract tool for 10 - 3")\r\n result = await client.call_tool("subtract", {"a": 10, "b": 3})\r\n print(f"<<< Result: {result[0].text}")\r\n\r\nif __name__ == "__main__":\r\n asyncio.run(test_server())'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fb095dac970>)])]>

Remarque : Assurez-vous que le proxy Cloud Run est bien lancé avant d’exécuter le serveur de test.

Dans une nouvelle fenêtre Terminal, exécuter la commande :

code_block: <ListValue: [StructValue([('code', 'uv run test_server.py'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095daca90>)])]>

Vous devriez voir s’afficher :

code_block: <ListValue: [StructValue([('code', '>>> Tool found: add\r\n>>> Tool found: subtract\r\n>>> Calling add tool for 1 + 2\r\n<<< Result: 3\r\n>>> Calling subtract tool for 10 - 3\r\n<<< Result: 7'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095daca00>)])]>

Félicitations ! Vous avez déployé avec succès un serveur MCP distant sur Cloud Run et l’avez testé à l’aide du client FastMCP.

Envie d’aller plus loin dans le déploiement d’applications IA sur Cloud Run ? Le blog « Easily Deploying AI Apps to Cloud Run » extrait du dernier Google I/O vous propose de maîtriser toutes les astuces et dernières avancées du déploiement d’IA sur Cloud Run. À explorer sans hésiter pour monter en puissance !

Cinq trucs et astuces pour optimiser vos workloads IA

Wed, 25 Jun 2025 07:00:00 +0000

L’information ne vous a probablement pas échappé. Mais, au cas où, Google a récemment annoncé l’arrivée d’une version sans frais à usage individuel de Gemini Code Assist, notre assistant IA d’aide au codage. Cette technologie jusqu’ici réservée aux plus grandes entreprises devient ainsi accessible au plus grand nombre et notamment aux start-ups et aux développeurs indépendants.
De même, les infrastructures techniques nécessaires aux projets IA/ML — GPU ultra performants, TPU spécialisés et systèmes de stockage ultra-rapides — ne sont désormais plus réservées aux grands groupes : elles sont aujourd’hui accessibles à tous.

Malgré cette tendance vers une plus grande accessibilité, les entreprises doivent continuer d’optimiser leurs gros workloads IA, les ressources nécessaires pouvant encore se révéler assez coûteuses. Dès lors, l’optimisation des workloads est non seulement une tâche pertinente mais aussi essentielle pour maîtriser les dépenses.

Dans cet article, nous vous proposons cinq conseils concrets pour optimiser vos workflows IA sur Google Cloud Platform.

À noter : toutes les suggestions présentées dans cet article ne s’appliquent pas forcément à tous les cas d’usage. Il ne s’agit pas de recommandations officielles.

1. Comparez les différentes plateformes pour entraîner et déployer vos modèles

Il y a encore quelques années, entraîner, affiner ou déployer un modèle IA impliquait de configurer manuellement un cluster de machines équipées de GPU ou de TPU, d’orchestrer l’ensemble du pipeline d’apprentissage et de gérer avec précision toutes les ressources mobilisées par le processus. Avec Kubernetes, vous pouviez alléger un peu la charge de travail mais, globalement, les services permettant de simplifier cette mise en œuvre étaient rares et peu accessibles. Conséquence : les coûts additionnels étaient importants, en raison du matériel monopolisé qu’il fallait financer mais aussi du temps consacré à la gestion de toute cette infrastructure.

Mais ce temps est révolu ! Google Cloud propose aujourd’hui un large éventail de solutions, allant d’environnements entièrement managés à des plateformes entièrement personnalisables. À vous de choisir l’approche la plus adaptée à vos besoins.
Voici un aperçu rapide des possibilités mises à votre disposition :

Vertex AI est une plateforme unifiée et entièrement managée pour le développement de solutions IA. Entraînement, personnalisation, inférence : vous pouvez tout faire depuis une interface web simple et intuitive. Vous gagnez un temps précieux en déléguant à Google la gestion de l’infrastructure nécessaire à vos workloads IA. Et surtout, vous ne payez que ce que vous consommez — fini les GPU monopolisés à vide en attendant la prochaine tâche.
Avec Cloud Run, vous pouvez désormais exécuter vos conteneurs sur des machines équipées de GPU. C’est la solution idéale pour déployer un service d’inférence scalable et entièrement managé, sans avoir à se familiariser avec de nouvelles plateformes.
Cloud Batch permet également d’accéder à des GPU — une option particulièrement bien adaptée aux tâches longues, comme l’entraînement ou l’optimisation de modèles. Cloud Batch se charge automatiquement de provisionner l’infrastructure nécessaire, de relancer les jobs en cas d’erreur et de libérer les ressources une fois la tâche terminée. Combinée aux Spot Instances, la fonction de relance automatique des jobs peut entraîner une réduction significative des coûts.
Google Kubernetes Engine (GKE) vous permet de conserver le contrôle sur l’infrastructure, tout en bénéficiant des avantages de l’automatisation sur le provisioning, la configuration et la gestion des ressources. C’est une solution particulièrement adaptée aux organisations qui utilisent déjà Kubernetes pour développer et exécuter leurs workloads IA et qui disposent de l’expertise nécessaire pour tirer pleinement parti du niveau de contrôle offert.
Google Compute Engine (GCE) se situe à l’opposé de Vertex AI en matière de gestion automatisée. En accédant directement à des machines virtuelles équipées de GPU ou de TPU, vous gardez le contrôle total sur tous les aspects de vos workflows, de l’infrastructure aux paramètres d’exécution.

2. Optimisez le temps de démarrage de vos conteneurs d’inférence

Lorsque vous utilisez GKE ou Cloud Run, évitez d’intégrer directement vos modèles dans vos conteneurs. Minimiser la taille de vos conteneurs en externalisant le stockage des modèles sur des solutions telles Cloud Storage (with FUSE), Filestore ou des disques persistants en lecture seule.

Pourquoi ? Parce que des conteneurs trop volumineux, embarquant les modèles, ralentissent considérablement la montée en charge. Avant de pouvoir exécuter quoi que ce soit, les nœuds doivent télécharger ces images de conteneurs souvent très lourdes. Ce qui surcharge également le stockage local des nœuds, qui n’est pas conçu pour un très haut débit. En externalisant les modèles, vous les découplez du conteneur, ce qui accélère les temps de démarrage, facilite le scaling automatique et évite les points de contention sur les ressources locales.

Gardez à l’esprit que les conteneurs sont faits pour être temporaires et légers, et ne doivent contenir que l’essentiel. À l’inverse, les modèles sont volumineux et doivent être stockés sur le long terme. En les séparant et en optant pour un stockage externe, vous mettez en place un déploiement plus rapide, plus fluide, plus scalable et plus efficace.

Si vous ne pouvez pas modifier les conteneurs avec lesquels vous travaillez, GKE propose une option de disque de démarrage secondaire pour accélérer le lancement des nouveaux nœuds. Ces derniers démarrent alors avec un disque supplémentaire contenant déjà certaines images de conteneur préchargées. Et puisque l’on parle d’optimisation des temps de démarrage, jetez un œil à la fonctionnalité Image streaming de GKE, qui permet d’accélérer le lancement de n’importe quel workload — et pas uniquement ceux liés à l’IA.

3. Stocker n’est pas aussi simple qu’il y paraît

Les projets de machine learning nécessitent généralement d’énormes volumes de données — allant de plusieurs centaines de téraoctets à plusieurs pétaoctets — pour produire des résultats pertinents, en particulier lorsqu’ils impliquent des données non textuelles ou des modèles multimodaux. Maximiser l’utilisation des GPU/TPU lors de l’entraînement, du checkpointing (sauvegarde périodique de l’état des modèles en cours d’entraînement) ou de l’inférence est essentiel, mais la tâche est rarement triviale.

Pour des workloads IA plus modestes, avec quelques nœuds et quelques téraoctets de données, notre service Filestore offre une solution NFS simple et efficace.

Pour les entreprises dont les workloads IA ont été développés pour consommer directement du stockage objet, Cloud Storage est un service entièrement managé, capable de gérer des workloads IA/ML à très grande échelle. Toutefois, de nombreux cas d’usage IA requièrent une interface de type système de fichiers. Cloud Storage FUSE permet de monter des buckets Cloud Storage comme un système de fichiers local. Attention : Cloud Storage FUSE n’est pas entièrement conforme à la norme POSIX (Portable Operating System Interface), ce qui implique des limitations par rapport à un système de fichiers classique qu’il convient de bien comprendre. Cloud Storage FUSE permet néanmoins d’accéder aux données d’entraînement, aux modèles et aux checkpoints avec la scalabilité, les performances et les coûts optimisés de Cloud Storage.

Pour les workloads nécessitant une latence très faible et utilisant des fichiers de petite taille, Parallelstore est un système de fichiers parallèle temporaire, entièrement managé sur Google Cloud. C’est la solution idéale pour les charges IA/ML ayant besoin d’un accès en dessous de la milliseconde, avec un débit élevé et un grand nombre d’opérations d’E/S par seconde (IOPS). Vous pouvez consulter l’architecture de référence pour faciliter sa mise en œuvre en suivant ce lien.

Enfin, selon vos besoins en matière de mise en production, Hyperdisk ML est une solution de stockage haute performance, particulièrement adaptée aux tâches nécessitant un très haut débit agrégé (~1 To/s), avec un support jusqu’à 2 500 machines virtuelles en parallèle.

4- Exploitez DWS et/ou Future Reservations pour garantir l’accès aux ressources dont vous avez besoin

Ne pas disposer des ressources nécessaires pour exécuter des workloads intensifs peut rapidement entraîner des surcoûts. Vous avez tout préparé : les données sont prêtes, le pipeline est en place… mais il n’y a pas assez de GPU disponibles. Ce type d’imprévu ne génère pas toujours un coût direct immédiat, mais le temps perdu à réorganiser votre planning et à chercher les ressources manquantes ralentit votre projet — et le temps, c’est de l’argent. Pour éviter ce genre de problèmes, Google Cloud propose deux solutions : Dynamic Workload Scheduler et Future Reservations.

Future Reservations (réservations anticipées) fonctionne comme son nom l’indique : cette solution permet de réserver à l’avance des ressources cloud (GPU, TPU, etc.) que vous prévoyez d’utiliser ultérieurement. Une fois la réservation confirmée par le système, vous avez la garantie que les ressources seront disponibles au moment prévu. Elles vous sont allouées exclusivement, et vous pouvez les utiliser comme bon vous semble, tant que la réservation est active. Attention : ces ressources vous seront facturées, qu’elles soient utilisées ou non !

Dynamic Workload Scheduler (DWS) est une plateforme backend utilisée par plusieurs produits Google Cloud, conçue pour faciliter l’accès à du matériel très demandé. Grâce à ses modes Flex et Calendar, DWS vous évite de perdre du temps à attendre que des GPU se libèrent au compte-gouttes, au fur et à mesure qu’ils ne sont plus utilisés par d’autres clients. C’est un moyen efficace d’optimiser votre temps et vos coûts. Pour en savoir plus sur le fonctionnement de DWS et son intégration dans l’écosystème Google Cloud, vous pouvez consulter cette vidéo.

5- Utilisez des images disque personnalisées pour accélérer vos déploiements

Exécuter des workloads IA sur des machines virtuelles nécessite souvent une phase de configuration lourde. Il faut un système d’exploitation à jour, les bons pilotes GPU, ainsi que les frameworks IA comme JAX, PyTorch ou TensorFlow, installés et configurés correctement. Si vous partez d’une image système « propre », la mise en place complète de cette configuration peut facilement prendre jusqu’à une heure, — selon la version du système d’exploitation utilisé et les outils que vous choisissez d’installer. Autant dire qu’il serait bien plus logique de ne faire cette configuration qu’une seule fois, non ?

C’est précisément l’intérêt des images disque personnalisées. Une fois votre VM correctement configurée avec tous les logiciels nécessaires, vous pouvez l’arrêter, créer une image disque à partir de ce système, et ainsi lancer en quelques secondes de nouvelles instances prêtes à l’emploi à partir de cette image disque personnalisée.

Pour simplifier encore plus votre quotidien, vous pouvez utiliser nos services image families et managed instance groups. Google Cloud gérera alors automatiquement les mises à jour progressives de votre environnement de travail.

Pour aller plus loin

Pour rester informé des dernières actualités et évolutions de Google Cloud, voici quelques ressources utiles :

Abonnez-vous à notre chaîne YouTube (ou à notre chaîne destinée à un public moins technique)
Suivez notre blog ( ou via flux RSS)
Inscrivez-vous à notre newsletter
Rejoignez le programme Google Cloud Innovators

Créez et éditez votre podcast audio avec Gemini 1.5 Pro

Mon, 31 Mar 2025 06:00:00 +0000

L'IA générative révolutionne notre façon de consommer les contenus audio, des podcasts aux résumés vocaux. Prenons l'exemple de la dernière fonctionnalité Audio Overview de NotebookLM, plébiscitée par les utilisateurs. Celle-ci transforme les documents textuels en fichiers audio. En un seul clic, deux présentateurs virtuels peuvent entreprendre une discussion approfondie et dynamique basée sur des informations sources que vous leur fournissez. Ils résument votre contenu, établissent des liens entre les différents sujets et échangent leurs points de vue.

Toutefois, bien que NotebookLM excelle dans l’analyse et le traitement d’informations complexes, certains utilisateurs souhaitent pouvoir contrôler davantage leurs productions audio, notamment pour concevoir leurs propres podcasts. Or, les podcasts connaissent un succès grandissant auprès des créateurs, des dirigeants d'entreprise et des utilisateurs en quête de contenus sur leurs centres d’intérêt. Dans cet article, nous vous proposons de découvrir comment Gemini 1.5 Pro et l'API Text-to-Speech de Google Cloud vous permettent de créer des échanges audio en utilisant des voix variées et de générer des scripts de podcast à l’aide de prompts personnalisés.

Objectif : développer son impact et son audience en capitalisant sur un large éventail de formats audio

Un podcast réussi commence par un contenu audio accessible. Les fonctionnalités multimodales de Gemini, combinées à notre API Text-to-Speech haute-fidélité, vous donnent accès à plus de 380 voix dans plus de 50 langues, ainsi qu'à la création de voix personnalisées. En vous permettant de réinventer l’expérience utilisateur et d'accroître votre impact à travers une multitude de formats audio, ce large éventail de possibilités vous ouvre de nouveaux horizons.

Cette approche dopée à l’IA peut aider les créateurs de contenu à élargir leur public tout en optimisant le processus de création, notamment à travers :

Une audience étendue : connectez-vous avec les segments d'audience qui privilégient les contenus audios.
Un engagement renforcé : créez des liens privilégiés avec votre audience grâce à des contenus audio personnalisés.
Une revalorisation des contenus : maximisez la valeur de vos contenus écrits existants en les convertissant dans un nouveau format – vocal – afin de toucher une audience plus large sans avoir à repartir de zéro.

Nous vous proposons de découvrir dans la suite de cet article la méthode détaillée pour atteindre ces objectifs.

L'architecture : Gemini 1.5 Pro et Text-to-Speech

Comme nous l’avons évoqué plus haut, notre architecture de création de contenus audio s'appuie sur deux puissants services de Google Cloud :

Gemini 1.5 Pro : ce modèle d'IA générative avancé excelle dans la compréhension et la génération de textes naturels. Nous utiliserons Gemini 1.5 Pro pour :
- Générer des scripts engageants : indiquez la trame de votre podcast à Gemini 1.5 Pro afin qu’il génère ensuite des scripts convaincants, incluant introductions, transitions et « appels à l'action ».
- Adapter un contenu au format audio : L’expression écrite et l’expression vocale sont différentes. Gemini 1.5 Pro peut optimiser les contenus écrits pour le format audio afin de garantir un flux naturel et une expérience d'écoute engageante. Il peut également ajuster le ton et le style pour l'adapter à différents formats, tel un podcast.
API Text-to-Speech : cette API transpose vos textes en audio avec des voix réalistes. Vous pouvez choisir parmi une large palette de voix et langues afin d’aligner l’identité sonore sur votre marque et votre audience.

Comment créer un podcast captivant étape par étape

Préparation du contenu : préparez la structure de votre podcast. Veillez à disposer d’une organisation logique et cohérente et assurez-vous que le contenu est clair et compréhensible. Pour une durée d'écoute optimale, fractionnez les contenus longs en plusieurs épisodes.
Intégration de Gemini 1.5 Pro : Utilisez Gemini 1.5 Pro pour générer un script à partir de de la structure de votre podcast. Expérimentez différents prompts pour affiner le résultat et obtenir le style et le ton souhaités. Exemple de prompt : « Génère un script audio engageant à partir de cette structure de podcast, incluant une introduction, des transitions et un appel à l'action. Le public cible comprend des développeurs, ingénieurs et architectes cloud ».
Découpage en sections : pour les podcasts complexes ou longs, vous pouvez utiliser Gemini 1.5 Pro pour extraire les sections et sous-sections clés au format JSON, permettant une approche plus structurée dans la génération du script.

Le processus de création de podcast repose sur une fonction Python des plus simples :

code_block: <ListValue: [StructValue([('code', 'def extract_sections_and_subsections(document1: Part, project="<your-project-id>", location = "us-central1") -> str:\r\n """\r\n Extracts hierarchical sections and subsections from a Google Cloud blog post\r\n provided as a PDF document.\r\n\r\n\r\n This function uses the Gemini 1.5 Pro language model to analyze the structure\r\n of a blog post and identify its key sections and subsections. The extracted\r\n information is returned in JSON format for easy parsing and use in\r\n various applications.\r\n\r\n\r\n This is particularly useful for:\r\n\r\n\r\n * **Large documents:** Breaking down content into manageable chunks for\r\n efficient processing and analysis.\r\n * **Podcast creation:** Generating multi-episode series where each episode\r\n focuses on a specific section of the blog post.\r\n\r\n\r\n Args:\r\n document1 (Part): A Part object representing the PDF document,\r\n typically obtained using `Part.from_uri()`.\r\n For example:\r\n ```python\r\n document1 = Part.from_uri(\r\n mime_type="application/pdf",\r\n uri="gs://your-bucket/your-pdf.pdf"\r\n )\r\n ```\r\n location: The region of your Google Cloud project. Defaults to "us-central1".\r\n project: The ID of your Google Cloud project. Defaults to "<your-project-id>".\r\n\r\n\r\n\r\n\r\n Returns:\r\n str: A JSON string representing the extracted sections and subsections.\r\n Returns an empty string if there are issues with processing or\r\n the model output.\r\n """\r\n\r\n\r\n vertexai.init(project=project, location=location) # Initialize Vertex AI\r\n model = GenerativeModel("gemini-1.5-pro-002")\r\n\r\n\r\n prompt = """Analyze the following blog post and extract its sections and subsections. Represent this information in JSON format using the following structure:\r\n [\r\n {\r\n "section": "Section Title",\r\n "subsections": [\r\n "Subsection 1",\r\n "Subsection 2",\r\n // ...\r\n ]\r\n },\r\n // ... more sections\r\n ]"""\r\n\r\n\r\n try:\r\n responses = model.generate_content(\r\n ["""The pdf file contains a Google Cloud blog post required for podcast-style analysis:""", document1, prompt],\r\n generation_config=generation_config,\r\n safety_settings=safety_settings,\r\n stream=True, # Stream results for better performance with large documents\r\n )\r\n\r\n\r\n response_text = ""\r\n for response in responses:\r\n response_text += response.text\r\n\r\n\r\n return response_text\r\n\r\n\r\n except Exception as e:\r\n print(f"Error during section extraction: {e}")\r\n return ""'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb0960a0610>)])]>

Utilisez ensuite Gemini 1.5 Pro pour générer le script de chaque section. Dans vos prompts, précisez le public visé, le ton désiré et la durée approximative souhaitée pour chaque l'épisode.

Pour chaque section et sous-section, vous pouvez utiliser une fonction similaire à celle-ci pour générer le script :

code_block: <ListValue: [StructValue([('code', 'def generate_podcast_content(section, subsection, document1:Part, targetaudience, guestname, hostname, project="<your-project-id>", location="us-central1") -> str:\r\n """Generates a podcast dialogue in JSON format from a blog post subsection.\r\n\r\n\r\n This function uses the Gemini model in Vertex AI to create a conversation\r\n between a host and a guest, covering the specified subsection content. It uses\r\n a provided PDF as source material and outputs the dialogue in JSON.\r\n\r\n\r\n Args:\r\n section: The blog post\'s main section (e.g., "Introduction").\r\n subsection: The specific subsection (e.g., "Benefits of Gemini 1.5").\r\n document1: A `Part` object representing the source PDF (created using\r\n `Part.from_uri(mime_type="application/pdf", uri="gs://your-bucket/your-pdf.pdf")`).\r\n targetaudience: The intended audience for the podcast.\r\n guestname: The name of the podcast guest.\r\n project: Your Google Cloud project ID.\r\n location: Your Google Cloud project location.\r\n\r\n\r\n Returns:\r\n A JSON string representing the generated podcast dialogue.\r\n """\r\n print(f"Processing section: {section} and subsection: {subsection}")\r\n\r\n\r\n prompt = f"""Create a podcast dialogue in JSON format based on a provided subsection of a Google Cloud blog post (found in the attached PDF).\r\n The dialogue should be a lively back-and-forth between a host (R) and a guest (S), presented as a series of turns.\r\n The host should guide the conversation by asking questions, while the guest provides informative and accessible answers.\r\n The script must fully cover all points within the given subsection.\r\n Use clear explanations and relatable analogies.\r\n Maintain a consistently positive and enthusiastic tone (e.g., "Movies, I love them. They\'re like time machines...").\r\n Include only one introductory host greeting (e.g., "Welcome to our next episode..."). No music, sound effects, or production directions.\r\n\r\n\r\n JSON structure:\r\n {{\r\n "multiSpeakerMarkup": {{\r\n "turns": [\r\n {{"text": "Podcast script content here...", "speaker": "R"}}, // R for host, S for guest\r\n // ... more turns\r\n ]\r\n }}\r\n }}\r\n\r\n\r\n Input Data:\r\n Section: "{section}"\r\n Subsections to cover in the podcast: "{subsection}"\r\n Target Audience: "{targetaudience}"\r\n Guest name: "{guestname}"\r\n Host name: "{hostname}"\r\n """\r\n\r\n\r\n vertexai.init(project=project, location=location)\r\n model = GenerativeModel("gemini-1.5-pro-002")\r\n\r\n\r\n responses = model.generate_content(\r\n ["""The pdf file contains a Google Cloud blog post required for podcast-style analysis:""", document1, prompt],\r\n generation_config=generation_config, # Assuming these are defined already\r\n safety_settings=safety_settings, # Assuming these are defined already\r\n stream=True,\r\n )\r\n\r\n\r\n response_text = ""\r\n for response in responses:\r\n response_text += response.text\r\n\r\n\r\n return response_text'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb0960a0820>)])]>

Envoyez ensuite le script Gemini vers l'API Text-to-Speech en sélectionnant une voix et une langue qui correspondent à votre cible et votre contenu. Pour générer un contenu audio de qualité professionnelle à partir du texte, utilisez cette fonction basée sur l'API Text-to-Speech avancée de Google Cloud :

code_block: <ListValue: [StructValue([('code', 'def generate_audio_from_text(input_json):\r\n """Generates audio using Google Text-to-Speech API.\r\n\r\n\r\n Args:\r\n input_json: A dictionary containing the \'multiSpeakerMarkup\' for the TTS API. This is generated by the Gemini 1.5 Pro model in the buildPodCastContent() function. \r\n\r\n\r\n Returns:\r\n The audio data in bytes (MP3 format) if successful, None otherwise.\r\n """\r\n\r\n\r\n try:\r\n # Build the Text-to-Speech service\r\n service = build(\'texttospeech\', \'v1beta1\')\r\n\r\n\r\n # Prepare synthesis input\r\n synthesis_input = {\r\n \'multiSpeakerMarkup\': input_json[\'multiSpeakerMarkup\']\r\n }\r\n\r\n\r\n # Configure voice and audio settings\r\n voice = {\r\n \'languageCode\': \'en-US\',\r\n \'name\': \'en-US-Studio-MultiSpeaker\'\r\n }\r\n\r\n\r\n audio_config = {\r\n \'audioEncoding\': \'MP3\',\r\n \'pitch\': 0,\r\n \'speakingRate\': 0,\r\n \'effectsProfileId\': [\'small-bluetooth-speaker-class-device\']\r\n }\r\n\r\n\r\n # Make the API request\r\n response = service.text().synthesize(\r\n body={\r\n \'input\': synthesis_input,\r\n \'voice\': voice,\r\n \'audioConfig\': audio_config\r\n }\r\n ).execute()\r\n\r\n\r\n # Extract and return audio content\r\n audio_content = response[\'audioContent\']\r\n return audio_content\r\n\r\n\r\n except Exception as e:\r\n print(f"Error: {e}") # More informative error message\r\n return None'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb0960a0190>)])]>

Pour finaliser le processus, vous pouvez stocker votre contenu audio encodé en MP3 base64 dans Google Cloud Storage en utilisant la bibliothèque Python google-cloud-storage. Elle permet de décoder la chaîne base64 et de télécharger directement les octets résultants vers un bucket désigné, en spécifiant le type de contenu comme 'audio/mp3'.

La preuve par l'écoute

API Text-to-Speech produit un audio de haute qualité. Mais vous pouvez encore enrichir vos podcasts avec une musique de fond, des effets sonores ou encore à l’aide d’outils d’édition professionnels. Découvrez ce que l’on peut obtenir en téléchargeant le résultat audio de l’exemple donné dans cet article, réalisé à l’aide de Gemini 1.5 Pro et l'API Text-to-Speech.

Si vous souhaitez commencer à créer vos propres contenus, prenez le temps d’examiner la gamme complète de fonctionnalités de génération audio proposée par Google Cloud, notamment l'API Text-to-Speech et les modèles Gemini disponibles en version gratuite. Testez différentes options de prompts, textuels comme visuels, pour explorer toutes les capacités créatives de Gemini.

Comment développer et déployer des applications IA à l’Edge

Tue, 09 Jan 2024 08:00:00 +0000

Que ce soit pour s'assurer que les ouvriers portent bien leur équipement de protection individuelle (EPI), pour gérer les stocks des magasins et des entrepôts, ou pour assurer une maintenance prédictive sur les chaînes de montage, les modèles ML de vision exécutés à l’Edge peuvent répondre à une grande variété de cas d’usage et profondément améliorer l'expérience des clients ou des collaborateurs. Cependant, l'exploitation de l'IA, la sécurité des données critiques et la complexité de gestion de multiples déploiements en périphérie (à l’Edge) peuvent constituer des obstacles difficiles à surmonter.

La maintenance prédictive, la sécurité en usine, la reconnaissance vocale, et bien d'autres encore sont autant de cas d’usages très populaires des technologies ML et IA. Ces cas d'utilisation nécessitent des modèles d'IA déployés sur des sites périphériques, à l’Edge, tels que des installations de fabrication, des centres de soins de santé, des magasins de détail, des véhicules, etc. Pour simplifier le déploiement et la gestion des workloads IA à l'échelle du cloud public et du Edge, Google Cloud propose un ensemble de technologies et de plateformes permettant d'exécuter et de gérer des applications d'IA à grande échelle sur le cloud public, les sites périphériques Edge et les appareils.

Déployer données et IA à l’Edge avec Google Cloud

Ainsi, avec sa plateforme Vertex AI, Google Cloud a considérablement simplifié et fluidifié le développement, le déploiement et l'exploitation d'applications IA industrielles.
Vertex AI fournit des modèles pré-entraînés de haute qualité, tels que des modèles de reconnaissance de produits et de tags, ainsi que d'autres modèles d'IA pour la vision et l’analyse vidéo par exemple.
Parce que les applications Edge AI peuvent nécessiter le développement de modèles personnalisés tels que la reconnaissance d'objets, la plateforme Vertex AI permet aux développeurs de personnaliser ou former des modèles dans le cloud puis de les déployer aisément sur les sites Edge.

Parallèlement, l’offre Google Distributed Cloud (GDC) permet aux développeurs et aux entreprises de combiner le meilleur de l’IA, de la sécurité et des outils open source de Google tout en conservant leur indépendance et leur contrôle total des données critiques partout où se trouvent leurs clients, et y compris à l’Edge que ce soit au travers de Google Distributed Cloud Edge (GDC Edge et son portfolio de services managés et de hardware conçus pour les workloads d’entreprises dans les domaines du retail, du manufacturing, des transports…) ou de Google Distributed Cloud Hosted (GDC Hosted, une solution cloud privé isolée pour aider les gouvernements et les entreprises soumises à régulation à respecter des normes rigoureuses de localisation et de sécurité des données).

Autre composante différenciante, Edge TPU est un ASIC (un circuit intégré spécialisé) spécialement conçu par Google Cloud pour l’exécution des inférences IA à l’Edge. Il offre des performances élevées dans un faible encombrement physique et énergétique idéalement adapté aux déploiements d’IA de haute précision à la périphérie. Il complète Cloud TPU et les services de Google Cloud pour fournir une infrastructure matérielle et logicielle de bout en bout, du Cloud à l’Edge. Il ne s'agit pas seulement d'une solution matérielle, mais d'une combinaison de processeurs, de logiciels ouverts et d'algorithmes d'IA de pointe pour fournir des solutions d'IA de haute qualité et faciles à déployer dans l’Edge. Notamment, Edge TPU vous permet de déployer une inférence ML en périphérie à l’aide de différentes solutions matérielles de prototypage et de production signées Coral.
Edge TPU complète ainsi les CPU, GPU, FPGA et autres solutions ASIC pour l'exécution de l'IA dans l’Edge.

Avec ce portfolio de solution Google Cloud en tête, voyons un peu plus en détail comment construire, former et déployer dans l’Edge un modèle ML basé sur la vision Google Vertex AI, Google Distributed Cloud et Edge TPUs pour prendre en charge des cas industriels tels que la détection des stocks, la détection des EPI et la maintenance prédictive.

De l’apprentissage dans l’Edge

Lors du déploiement de workloads IA sur des emplacements Edge, chaque cas d'usage doit s'assurer que les modèles formés sont déployés sur la topologie adéquate en prolongement du cloud public. D'un côté du spectre, nous avons de grandes fermes de serveurs utilisant des hyperviseurs. De l'autre, on exploite une multitude de capteurs et autres dispositifs tels que des caméras.
Avec Google Cloud, les développeurs bénéficient d'une expérience homogène lors du développement et de l'exécution des applications IA sur les sites en périphérie. Et les opérateurs de la plateforme IA déployée gèrent et surveillent les applications aisément, quel que soit leur lieu d'exécution.

En utilisant les plateformes GDC, nos clients ont la possibilité de déployer indifféremment leurs modèles AI/ML sur les Edge TPUs ou sur des GPUs. Les GPU et TPU, en plus de simplifier les tâches IA, offrent aussi de multiples avantages tels que l’accélération des exécutions, des performances graphiques améliorées, de l'apprentissage profond, une efficacité énergétique certaine et une indéniable scalabilité. Les modèles ML peuvent être formés avec les Cloud TPUs ou les GPUs Cloud puis être ensuite déployés sur GDC dans l’Edge comme dans les datacenters. Rappelons au passage que les plateformes GDC supportent les GPU NVidia T4 et A100.

Un processus de déploiement et de gestion d'un modèle ML à l’Edge se déroule typiquement en plusieurs étapes :

Préparation des données
Développement des modèles
Entraînement des modèles
Mise en place des modèles
Surveillance des prédictions
Gestion des versions

Combinés, Vertex AI et GDC permettent de rationaliser et fluidifier l’ensemble de ce processus, de la préparation jusqu’à l’exécution à grande échelle des workloads IA sur l’Edge. Autre brique essentielle, Google Kubernetes Engine (GKE) vous permet d'exécuter des charges de travail d'IA conteneurisées qui nécessitent une TPU ou un GPU pour accélérer l'inférence ML, l'entraînement et le traitement des données dans Google Cloud. Vous pouvez exécuter les Workloads IA sur GKE dans l’Edge grâce à GDC.

Pour démontrer le potentiel de ces technologies et des usages de l’IA dans les points de vente, T-Mobile et Google Cloud ont, par exemple, développé le projet « magic mirror (miroir magique) », un écran interactif s’appuyant sur GDG Edge : l’utilisateur montre simplement un objet en magasin et l’écran lui donne vie comme par magie fournissant détails et vidéos explicatives.

Du ML de bout en bout

Comme nous l’avons vu, Google Cloud propose une suite complète de services et d’outils couvrant, de bout en bout, la création, le déploiement à grande échelle et la gestion de solutions IA à l’Edge. Nos clients peuvent ainsi concevoir des solutions Edge robustes adaptées à leurs différents cas d’usage de l’IA en périphérie. L’illustration ci-dessous présente une vue d’ensemble de la manière dont les différents composants et services évoqués ci-dessus s’imbriquent harmonieusement.

Entraînement du modèle à l'aide de données étiquetées ou annotées sur Vertex AI
Exportation du modèle Vertex AI
Stockage du modèle exporté dans un Bucket GCS (Google Cloud Storage) ou dans le repository privé AI Hub
Chaque cluster Edge télécharge ce nouveau modèle en utilisant KRM (configuration YAML K8s) sur un déploiement TF Serving ou Inference Server à travers Anthos Config Manager (ACM).
Le feedback peut optionnellement être exporté sous forme de résultats en pourcentage (6) ou vers une application personnalisée de vérification des résultats IA par l’humain (6a). Exportation vers les buckets GCS.
Utilisation de BigQuery pour analyser l'efficacité du modèle ML, identifier les modifications apportées aux étiquettes, à l'attribution, aux classificateurs, à la qualité, etc., afin d’enrichir les données de test (7).

Ce schéma fonctionnel en tête, entrons un peu plus au cœur des technologies et voyons comment configurer les Edge TPUs et GPUs qui animent les IA sur GDC.

Configurer les Edge TPUs

Lorsque vous développez pour une plateforme fonctionnant sous Linux, Windows ou macOS, vous pouvez choisir d'utiliser TensorFlow Lite (bibliothèque spécialement optimisée pour le déploiement de modèles à l’Edge) et une programmation Python ou C/C++.

Quel que soit le langage choisi, vous devez installer le moteur d'exécution Edge TPU (libedgetpu.so) pour tirer profit des accélérations matérielles intégrées dans les cartes de prototypages et les cartes IOT « IA » de notre partenaire Coral. Ce dernier propose des guides d’installation pour chacun de ses dispositifs IA qui détaillent notamment comment installer la bibliothèque TensorFlow Lite appropriée et la bibliothèque optionnelle Coral correspondante.

Les modèles ML sont packagés sous forme de containers et nécessitent un développement personnalisé.

Configuration des GPU

Voyons maintenant comment configurer les GPU NVIDIA T4 pour les Workers K8s sur des plateformes GDC ou Edge Anthos GKE.

Prérequis :

Configuration des rôles et des autorisations.
Désactiver selinux
Désactiver apparmor
Si selinux est activé, exécuter le plugin daemonset avec un contexte de sécurité privilégié.
Dépendances :
Installer les dépendances Cuda sur le système d'exploitation
Installer le pilote NVIDIA-Linux à l'aide d'un script ou manuellement.

3 . Installer le runtime docker Nvidia

Configurer le runtime conteneurs de kubernetes pour qu'il pointe vers Nvidia (*dans la plupart des cas, il s'agit de containerd).
Installer le daemon Nvidia sur chaque nœud.
Vérifier les systèmes d'exploitation pris en charge
Tests
Utiliser l'outil CLI nvidia-smi
Exécuter un workload de test gpu dans le cluster
Exécuter cmd check gpu : kubectl describe nodes

Installation :

Configurer la sécurité (selinux, apparmor)

code_block: <ListValue: [StructValue([('code', 'sudo systemctl stop apparmor.service'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d5bcd0>)])]>

Pour désactiver SELinux, ouvrez le fichier de configuration /,etc/selinux/config et changez la propriété en : SELINUX=disabled

Configurez Anthos Bare Metal en lançant des commandes bmctl sur la VM (vous devez être propriétaire/éditeur du projet utilisé).
Docker

Ajoutez votre utilisateur au groupe docker

code_block: <ListValue: [StructValue([('code', 'sudo usermod -aG docker $USER'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d5b730>)])]>

Redémarrez la machine virtuelle pour que les modifications apportées au groupe d'utilisateurs de Docker soient prises en compte.

code_block: <ListValue: [StructValue([('code', 'sudo reboot'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d5b100>)])]>

Installer les pilotes Nvidia et cuda

Connectez-vous en mode ssh à la VM et exécutez les commandes suivantes :

code_block: <ListValue: [StructValue([('code', 'curl https://raw.githubusercontent.com/GoogleCloudPlatform/compute-gpu-installation/main/linux/install_gpu_driver.py --output install_gpu_driver.py\r\n\r\nsudo python3 install_gpu_driver.py'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d4c760>)])]>

Reportez-vous à cette page en cas d'erreur ou si vous souhaitez en savoir plus.

Installez Nvidia Docker et préparez le conteneur par défaut de kubernetes pour nvidia :

code_block: <ListValue: [StructValue([('code', '# Install nvidia-docker \r\ndistribution=$(. /etc/os-release;echo $ID$VERSION_ID) \\\r\n && curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - \\\r\n && curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list\r\nsudo apt-get update\r\nsudo apt-get install -y nvidia-docker2\r\nsudo systemctl restart docker\r\n\r\n# Edit /etc/docker/daemon.json to include the following (use sudo) follow instructions https://github.com/NVIDIA/k8s-device-plugin#quick-start\r\n{\r\n "default-runtime": "nvidia",\r\n "runtimes": {\r\n "nvidia": {\r\n "path": "/usr/bin/nvidia-container-runtime",\r\n "runtimeArgs": []\r\n }\r\n }\r\n}\r\n\r\n#When running kubernetes with containerd, edit the config file which is usually present at /etc/containerd/config.toml to set up nvidia-container-runtime as the default low-level runtime:\r\n\r\nversion = 2\r\n[plugins]\r\n [plugins."io.containerd.grpc.v1.cri"]\r\n [plugins."io.containerd.grpc.v1.cri".containerd]\r\n default_runtime_name = "nvidia"\r\n\r\n [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]\r\n [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia]\r\n privileged_without_host_devices = false\r\n runtime_engine = ""\r\n runtime_root = ""\r\n runtime_type = "io.containerd.runc.v2"\r\n [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options]\r\n BinaryName = "/usr/bin/nvidia-container-runtime"\r\n\r\n\r\n# And then restart containerd and run some tests:\r\n\r\n$ sudo systemctl restart containerd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d4c820>)])]>

Installer le daemonset (peut avoir besoin d'être exécuté en tant que administrateur) :

code_block: <ListValue: [StructValue([('code', 'kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.9.0/nvidia-device-plugin.yml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d4c310>)])]>

7. Vérifiez la bonne installation en utilisant le client nvidia-smi et vérifiez kubectl describe node. Il devrait lister "nvidia/gpu" avec une valeur de 1 ou plus sous les ressources allouables.

code_block: <ListValue: [StructValue([('code', '$ sudo docker run --runtime=nvidia --rm nvcr.io/nvidia/cuda:9.0-devel-ubuntu16.04 nvidia-smi\r\n$ nvidia-smi\r\n$ kubectl get nodes\r\nNAME STATUS ROLES AGE VERSION\r\nbaremetalvm1 Ready control-plane,master 43d v1.24.7-gke.300\r\n$ kubectl describe node\r\nCapacity:\r\n cpu: 16\r\n ephemeral-storage: 253869360Ki\r\n hugepages-1Gi: 0\r\n hugepages-2Mi: 0\r\n memory: 14726616Ki\r\n nvidia.com/gpu: 1\r\n pods: 110\r\nAllocatable:\r\n cpu: 15890m\r\n ephemeral-storage: 233966001789\r\n hugepages-1Gi: 0\r\n hugepages-2Mi: 0\r\n memory: 12176856Ki\r\n nvidia.com/gpu: 1\r\n pods: 110'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fb095d4c220>)])]>

Prochaines étapes ?

L'Edge computing accélère la transformation numérique des entreprises de manière inédite. Avec un portefeuille complet de solutions matérielles et logicielles entièrement managées, Google Distributed Cloud rapproche les solutions d'IA et d'analyse de Google Cloud de l'endroit où vos données sont générées et consommées, afin que vous puissiez exploiter des informations en temps réel. Grâce à l’universalité de GKE, vous bénéficiez d’une expérience et d’une administration cohérente du cloud jusqu’à l’Edge quel que soit le workload IA envisagé.

Pour en savoir plus sur comment exploiter et combiner vos données à l’Edge et les dernières technologies IA de Google Cloud sur des infrastructures Google Distributed Cloud Edge : Google Distributed Cloud by Google Cloud

Pour en savoir plus sur Google Distributed Cloud, une famille de produits qui vous permet de libérer vos données avec les dernières avancées en matière d'IA à partir de déploiements en périphérie, de centres de données privés, de nuages aériens et de nuages hybrides. Disponible pour les entreprises et le secteur public, vous pouvez désormais tirer parti de l'IA, de la sécurité et des logiciels open source de Google, les meilleurs de leur catégorie, avec l'indépendance et le contrôle dont vous avez besoin, partout où se trouvent vos clients.

Pour plonger davantage dans les cas d’usage de l’IA à l’Edge et l’exploitation de Google Distributed Cloud et des hardwares Edge TPU, retrouvez en replay nos sessions Google Cloud Next 2023 dédiées à ces sujets :

Running AI at the edge to deliver modern customer experiences Session ARC 101
Mind the air gap: How cloud is addressing today’s sovereignty needs Session ARC100
What’s next for architects and IT professionals Spotlight SPTL202
Hardware-verse: Experience real-time visual inspection at the edge Interactive Demo HWV-101
Hardware-verse: Address sovereignty needs with air-gapped private cloud—Interactive Demo HWV-102
Hardware-verse: Supercharge your generative AI model development with Cloud TPUs Interactive Demo HWV-103

Retrouvez également nos guides pratiques “pas à pas” sur la configuration des GPU :

Le Zero Trust et BeyondCorp de Google Cloud

Wed, 02 Nov 2022 06:00:00 +0000

Imaginons que vous possédez une machine à remonter le temps et que vous vous apprêtez à organiser un évènement en présentiel en 2021 dans un contexte de pandémie. Vous devez bien entendu vous assurer que les participants ne courent aucun risque de contamination par le COVID. Dans cette perspective, vous mettez en place un dispositif afin de tester chaque personne, ne laissant entrer que ceux et celles qui affichent un résultat négatif. Vous faites bien entendu remplir un formulaire à chaque participant dans lequel il indique que son test est négatif. Mais vous ne pouvez pas faire confiance implicitement à vos invités pour la simple raison qu’ils peuvent avoir contracté la maladie entre le moment où ils ont eu leur résultat et celui où ils se rendent à votre évènement. Vous leur faites donc passer un test rapide sur place avant de les laisser entrer.

Comme dans ce scénario du monde réel, la confiance implicite dans n’importe quel composant d’un système numérique peut engendrer de gros risques de sécurité. Pour réduire les risques, le modèle de sécurité Zero-Trust exige que la confiance soit accordée par de multiples mécanismes et vérifiée en permanence. Cette approche peut être appliquée aussi bien à l’authentification des utilisateurs et à la protection des workloads qu’aux mécanismes et processus au cœur de votre système de production.

BeyondCorp, l’approche innovante Zero-Trust de Google

Dès 2011, Google proposait une nouvelle approche de la gestion des accès d'entreprise : le framework BeyondCorp pour faciliter l’implémentation du modèle de sécurité Zero Trust.
À l’origine, BeyondCorp était une initiative interne à Google visant à permettre à tous ses collaborateurs de travailler depuis des réseaux non sécurisés sans avoir recours à un VPN classique. Son principe est simple : en déplaçant la prise de décision d’accès au niveau de l’utilisateur et de son appareil, et non plus en fonction du réseau à partir duquel il se connecte, BeyondCorp transforme la façon de travailler tout en permettant aux collaborateurs d’exercer leurs missions de manière plus sûre depuis n'importe quel endroit.

Qu’est-ce que BeyondCorp Enterprise ?

BeyondCorp Enterprise est l'implémentation commerciale du modèle de contrôle des accès développé depuis une dizaine d'années par Google. Dit autrement, c’est un service cloud qui implémente le framework BeyondCorp au-dessus de vos ressources Google Cloud.
Dans un tel modèle, personne ne peut accéder aux ressources à moins de satisfaire à toutes les règles et conditions requises, codifiées dans les politiques d'accès définies pour chaque ressource. En pratique, avec BeyondCorp Enterprise, nous aidons vos collaborateurs à accéder aux applications et aux ressources de manière simple et sécurisée.

Son fonctionnement repose sur l’utilisation de Chrome (ou un navigateur basé sur Chromium) avec des protections intégrées contre les menaces et pour la protection des données. Le réseau Google surveille et protège le trafic vers les ressources tout en permettant aux organisations d'appliquer des règles contextuelles (en utilisant des facteurs tels que l'identité, les informations sur l'appareil, la localisation, l'heure de la journée, le réseau utilisé par l'employé, etc.) pour autoriser ou non l’accès aux ressources demandées.

BeyondCorp Enterprise procure deux avantages essentiels :

* Des contrôles d'accès très complets aident à protéger l'accès aux systèmes (applications, machines virtuelles, API, etc.) en tenant compte des contextes de la demande utilisateur pour garantir que chaque demande est authentifiée, autorisée et aussi sûre que possible.

* Les protections sur les données et contre les menaces apportent un niveau de sécurité supplémentaire à vos appareils d'entreprise en défendant les utilisateurs contre les risques d'exfiltration tels que le copier-coller, en étendant la prévention des pertes de données (DLP) au navigateur et en empêchant les logiciels malveillants de pénétrer dans les appareils gérés par l'entreprise.

Comment fonctionne BeyondCorp Enterprise ?

BeyondCorp fonctionne en se concentrant sur les utilisateurs et les appareils plutôt que sur les réseaux et les emplacements. Il analyse séparément puis ensemble les contextes et preuves liées à l’identification de l’utilisateur et à l’identification (et l’état de sécurité) de son appareil.
Des critères de base comme l’adresse IP, la position géographique, l’heure de connexion, la durée de la session sont combinés pour déterminer le contexte de connexion et accorder ou non les autorisations d’accès mais aussi quelles règles DLP seront appliquées.
Différentes règles d’accès peuvent être définies pour chaque ressource. Typiquement, on peut indiquer que telle ressource ne peut pas être accédée depuis une position géographique venant d’un autre pays ou encore que seuls les employés utilisant un appareil chiffré pourront y avoir accès. Couplé aux conditions IAM, vous pouvez augmenter la granularité de ce niveau d'accès en autorisant par exemple l'accès uniquement entre 9h00 et 17h00.

Sécurisation des ressources avec Google Cloud IAP

Google Cloud IAP (Identity Aware Proxy) vous permet d'appliquer les conditions IAM (Identity & Access Management, gestion des identités et des accès) sur les ressources Google Cloud et contribue à établir une couche d'autorisation centrale pour vos ressources Google Cloud accessibles par le trafic HTTPS et SSH/TCP.
Avec IAP, vous pouvez établir un modèle de contrôle d'accès au niveau des ressources au lieu de vous appuyer sur des pare-feux au niveau du réseau. Une fois sécurisées, vos ressources sont accessibles à vos employés, à partir de leurs appareils, sur votre réseau, pour autant que cet employé, ce réseau et cet appareil respectent toutes les règles et conditions d'accès préalablement définies.

Application des conditions IAM

Les conditions IAM (gestion des identités et des accès) vous permettent de définir et d'appliquer, sur les ressources Google Cloud, un contrôle d'accès conditionnel, basé sur de multiples attributs.
Avec les conditions IAM, vous pouvez choisir d'accorder des autorisations aux principaux utilisateurs uniquement si les conditions configurées sont remplies. Les conditions IAM peuvent limiter l'accès à l'aide de divers attributs, notamment les niveaux d'accès.
Les conditions sont spécifiées dans les « rôles IAP » associés aux politiques IAM d'une ressource.

BeyondProd

Les informations d'identification d'un utilisateur pouvant être saisies par des acteurs malveillants, un modèle de sécurité axé sur le périmètre est désormais inadéquat. De même, tout logiciel qui interagit avec le monde extérieur doit être protégé à plusieurs niveaux.
C'est pourquoi il est judicieux d'appliquer une approche Zero Trust au sein même de votre environnement de protection et dans la manière dont vous l’exploitez, en englobant la façon dont les logiciels sont conçus, produits, gérés et interagissent avec d'autres logiciels.
Google a publié un livre blanc sur notre modèle BeyondProd pour expliquer comment nous protégeons notre architecture cloud-native et pour aider les organisations à apprendre à appliquer les principes de sécurité Zero Trust dans ce domaine.

Cet article n’offre qu’un aperçu du modèle de sécurité Zero Trust de Google et de sa mise en œuvre commerciale au travers de notre solution cloud BeyondCorp Enterprise. Pour un examen plus approfondi de BeyondCorp Enterprise, consultez notre documentation.

Comprendre la mise en réseau dans GKE

Fri, 14 Oct 2022 06:00:00 +0000

Principes de base de la mise en réseau

L’orchestrateur Kubernetes s’est imposé comme la plateforme open source de référence pour gérer les workloads et services containerisés. Créé à l’origine par Google, il trouve en GKE (Google Kubernetes Engine) une implémentation optimale afin de vous permettre d’exécuter Kubernetes et vos containers au sein de l’infrastructure Google Cloud dans un environnement entièrement managé.

GKE et Kubernetes reposent sur quelques piliers techniques communs qu’il est important de connaître. Le réseau est bien évidemment l’un d’eux. Nous vous proposons ici d’explorer les composantes réseau de GKE (Google Kubernetes Engine) et les différentes options disponibles.

L’adressage IP

Pour communiquer entre eux, les différents composants réseau de Kubernetes utilisent, comme on peut s’en douter, des adresses IP et des ports pour communiquer. Pour rappel, les adresses IP sont des adresses uniques qui identifient les différents composants du réseau.

Les composants clés :

Les containers - Il s'agit des plus petits composants d'exécution des processus applicatifs. Un ou plusieurs containers sont exécutés au sein d’un « pod ».
Les Pods – Les Pods regroupent « physiquement » une collection de containers. Les pods sont affectés à des nœuds.
Les Nœuds - Les nœuds sont des machines de travail (des serveurs) au sein d’un cluster Kubernetes (un cluster est donc une collection de nœuds). Un nœud exécute zéro ou plusieurs pods.

Les services clés :

ClusterIP - Ces adresses IP internes au cluster permettent d’exposer les services.
Load Balancer – Assure l’équilibrage des charges du trafic interne ou du trafic externe vers les nœuds du cluster.
Ingress – est un type spécial d'équilibreur de charge (load balancer) qui gère le trafic HTTP(S).

Les adresses IP sont attribuées aux composants et aux services à partir de différents sous-réseaux. Des masques de sous-réseau à longueur variable (VLSM) sont utilisés pour créer des blocs CIDR. Le nombre d'hôtes disponibles sur un sous-réseau dépend du masque de sous-réseau utilisé.

Remarque : la formule pour calculer le nombre d’hôtes disponibles dans Google Cloud est 2n- 4, et non 2n- 2 contrairement aux usages classiques des réseaux « on prem » (sur site).

Le flux d'attribution des adresses IP se présente comme suit :

1/ Les nœuds se voient attribuer des adresses IP à partir du réseau VPC du cluster.

2/ Par défaut, les adresses IP des Load Balancers internes sont automatiquement attribuées à partir du bloc IPv4 du nœud. Si nécessaire, vous pouvez créer une plage spécifique pour vos Load Balancers en utilisant l'option loadBalancerIP.

3/ Les pods se voient attribuer des adresses IP à partir de la plage assignée aux pods pour le nœud considéré. Par défaut, le nombre maximal de pods par nœud est de 110. Pour allouer une adresse à ce nombre, ce nombre est multiplié par 2 (110*2=220) et le sous-réseau le plus proche est utilisé, soit une place CIDR /24.
Ce mécanisme permet d'avoir un tampon pour la planification des pods. Il est important de se souvenir que si ce nombre maximal de pods par nœud est personnalisable au moment de la création, il ne peut être modifié une fois le cluster créé.

4/ Les containers partagent l'adresse IP des pods sur lesquels ils fonctionnent.

5/ Les adresses IP des services (Cluster IP) sont attribuées à partir d'un pool d'adresses réservé aux services.

Vous trouverez dans la bible technique « VPC-native clusters », au sein de la section dédiée aux plages d’adresses IP, un exemple de planification et de délimitation des plages d'adresses.

Le DNS (Système de nom de domaine)

Le DNS permet la résolution de noms en adresses IP. Des entrées de nom de domaine sont automatiquement créées dans le DNS pour les différents services. Il existe quelques options dans GKE pour contrôler le DNS.

kube-dns - Service complémentaire natif de Kubernetes, Kube-dns permet par défaut aux différents pods d'un cluster de résoudre les requêtes DNS. Le document "Using kube-dns'' décrit son fonctionnement.
Cloud DNS - Il s'agit du service DNS managé de Google Cloud. Il peut être utilisé pour gérer le DNS de votre cluster. Utiliser Cloud DNS en lieu et place de kube-dns présente quelques avantages. En effet, Cloud DNS :

Élimine (au moins en partie) la gestion d'un serveur DNS hébergé au sein du cluster.
Prend en charge la résolution locale DNS sur les nœuds GKE. Cela se fait par une mise en cache locale des réponses, ce qui offre à la fois vitesse et évolutivité.
S'intègre à la suite de surveillance Google Cloud Operations.

Service Directory est un autre service de Google Cloud qui peut être intégré à GKE et à Cloud DNS pour gérer les services via des espaces de noms (namespaces). Le repo github « gke-networking-recipes » contient quelques exemples de Service Directory que vous pouvez essayer pour les LoadBalancers internes, ClusterIP, Headless et NodePort.

Pour une meilleure compréhension des différentes options DNS dans GKE, veuillez consulter l'article DNS sur GKE : tout ce que vous devez savoir.

Les Load Balancers

Les Load Balancers (ou services d’équilibrage de charge) contrôlent l'accès et distribuent le trafic sur les ressources du cluster. Voici quelques options à connaître dans GKE :

Ingress

Les Ingress sont des objets Kubernetes qui gèrent l’accès externe aux services d’un cluster et le trafic HTTP(S) correspondant. Lorsqu'un tel objet (une telle ressource) est utilisé, il crée un Load Balancer HTTP(S) pour GKE. Lors de la configuration, vous pouvez attribuer une adresse IP statique à l'équilibreur de charge, afin de garantir que l'adresse reste la même.

Dans GKE, vous pouvez provisionner à la fois des Ingress externes et internes. Les liens vers les guides ci-dessous vous montrent comment les configurer :

GKE vous permet de tirer profit du load balancing natif des containers, qui dirige le trafic directement vers l'IP du pod à l'aide des groupes d'extrémité de réseau (NEG – Network Endpoint Group).

Le service de routage

Au niveau routage, trois concepts principaux doivent retenir votre attention :

Frontend - Votre service est exposé aux clients par le biais d'un « frontend » : ce dernier accepte le trafic en fonction de diverses règles. Il peut s'agir d'un nom DNS ou d'une adresse IP statique.
Load Balancing - Une fois que le trafic est autorisé, l'équilibreur de charge distribue les ressources disponibles pour répondre à la demande en fonction des règles.
Backend - Différents points de terminaison qui peuvent être utilisés dans GKE.

Opérations

Dans GKE, vous avez plusieurs façons de concevoir la mise en réseau de vos clusters :

Standard - Ce mode permet à l'administrateur de configurer l'infrastructure sous-jacente des clusters. Ce mode est avantageux si vous avez besoin d'un niveau de contrôle et de responsabilité plus approfondi.
AutoPilot (Pilote automatique) - GKE fournit et gère l'infrastructure sous-jacente du cluster. Pratique et préconfiguré pour s’adapter à tous les usages, ce mode vous offre néanmoins une certaine liberté de gestion.
Private Cluster (Cluster privé) - Ce mode n'autorise que les connexions IP internes. Si vous avez néanmoins besoin qu'un client ait accès à l'Internet (par exemple, pour des mises à jour), vous pouvez utiliser un Cloud NAT.
Private Service Access – Ce mode permet à votre VPC de communiquer avec les services des fournisseurs (de service) via des adresses IP privées. Le service Private Service Connect permet la consommation privée de services à travers les réseaux VPC (Virtual Private Cloud).

En résumé

Regroupés, tous ces éléments permettent de rapidement tracer un paysage de la gestion réseau sous GKE. Une vue de haut niveau qui peut se résumer ainsi :

Des adresses IP sont assignées aux différentes ressources de votre clusters : Nœuds, Pods, Containers et Services.
Ces plages d’adresses IP sont réservées aux différents types de ressources. Vous avez la possibilité d'ajuster la taille de la plage pour répondre à vos besoins en définissant un sous-réseau. Il est recommandé de restreindre les accès externes inutiles à votre cluster.
Par défaut, les pods ont la possibilité de communiquer à travers le cluster.
Pour exposer les applications fonctionnant sur les pods, vous avez besoin d'un service.
Des adresses IP de clusters (Cluster IPs) sont attribuées aux services.
Pour la résolution DNS, vous pouvez vous appuyer sur une option native telle que « kube-dns » ou utiliser Google Cloud DNS au sein de votre cluster GKE.
Les Load Balancers peuvent être utilisés en interne et en externe avec votre cluster pour exposer les applications et distribuer le trafic.
Ingress gère le trafic HTTP(S). Il utilise le service de load balancing HTTP(S) de Google Cloud. Ingress peut être utilisé pour des configurations internes et externes.

Pour en savoir plus sur la mise en réseau GKE, consultez les documents suivants :

Documentation : Stratégies de gestion des adresses IP lors de la migration vers GKE

Documentation : Bonnes pratiques pour la mise en réseau GKE

Blog : DNS sur GKE : tout ce que vous devez savoir

YouTube : Concepts de mise en réseau de GKE

Une question ? Besoin d’approfondir un sujet ? Envie de partager une idée ? N'hésitez pas à me contacter sur Linkedin ou Twitter (@ammettw).

La sécurité des données dans Google Cloud

Thu, 29 Sep 2022 08:00:00 +0000

Quelle que soit l’organisation, publique ou privée, la sécurité des données est une composante essentielle de toute posture de cyber-résilience. Le chiffrement est un pilier essentiel de la sécurité des données. Google Cloud propose de multiples options pour chiffrer les données, qu’elles soient au repos, en transferts ou même en cours d’utilisation. Mettons un coup de projecteur sur chacune d’elles.

CHIFFREMENT

Chiffrement au repos par défaut

Pour protéger vos données, Google les chiffre au repos, en veillant à ce qu'elles ne soient accessibles qu'aux rôles et services autorisés, avec un accès contrôlé aux clés de chiffrement. Les données sont systématiquement chiffrées avant d'être écrites sur le disque. Voici comment :

Les données sont d'abord "fragmentées", c'est-à-dire divisées en blocs, et chaque bloc est chiffré avec sa propre clé de chiffrement des données (DEK – Data Encryption Key).
Chaque clé de chiffrement des données (DEK) est ensuite enveloppée à l'aide d'une clé de chiffrement de clés (KEK, Key Encryption Key). Les blocs chiffrés et les clés de chiffrement enveloppées sont alors distribués au travers de l'infrastructure de stockage de Google.
Si un morceau de données est mis à jour, il est chiffré avec une nouvelle clé, plutôt qu'en réutilisant la clé existante.

Lorsque les données doivent être récupérées (autrement dit lues et exploitées), le processus se répète en sens inverse.

Si un attaquant devait compromettre une clé individuelle ou obtenir un accès physique au stockage, il ne pourrait toujours pas lire les données des clients, car il devrait pour cela identifier tous les blocs de données d'un objet, les récupérer et retrouver également les clés de chiffrement associées.

Chiffrement par défaut des données en transit

Toutes les communications via Internet vers Google Cloud nécessitent des connexions TLS correctement « terminées », autrement dit dont l’intégrité a été pleinement vérifiée.
Un tel chiffrement protège vos données en transit même si les communications sont interceptées pendant que les données se déplacent entre votre site et le fournisseur de cloud computing ou entre deux services.
Cette protection est obtenue en chiffrant les données avant la transmission, en authentifiant les points d'extrémité et en déchiffrant et vérifiant les données à l'arrivée.
Transport Layer Security (TLS) est typiquement utilisé pour chiffrer les données en transit entre les services alors que Secure/Multipurpose Internet Mail Extensions (S/MIME) est plutôt utilisé pour la sécurité des messages électroniques.

Le chiffrement de données en cours d'utilisation : L'informatique confidentielle

L'informatique confidentielle ajoute un "troisième pilier" à la protection des données. Elle protège vos données en mémoire contre toute compromission ou exfiltration en les chiffrant pendant leur traitement.
Vous pouvez protéger vos données lors de leur utilisation en vous appuyant aussi bien sur les VM confidentielles que sur les nœuds GKE confidentiels.
Ces protections reposent notamment sur les défenses offertes par les VM blindées (Shielded VMs) contre les rootkits et les bootkits.

Le chiffrement de la mémoire principale est effectué à l'aide d'un matériel dédié intégré au cœur des contrôleurs de puces mémoires. Chaque contrôleur comprend en effet un moteur AES haute performance. Ce dernier chiffre les données lorsqu'elles sont écrites dans la DRAM ou partagées entre les sockets, et les déchiffre lorsqu'elles sont lues. Il est important de signaler que Google n'a pas accès à la clé de chiffrement.

Options de chiffrement des données au repos

Même si dans la plupart des cas, le chiffrement par défaut suffit à apporter le niveau de sécurité attendu, Google Cloud propose à ses clients d'autres options en fonction de leur niveau de confiance et de leurs besoins professionnels.

Des clés de chiffrement fournies par l’entreprise

Si vous souhaitez ou devez opérer vos infrastructures cloud en n’accordant qu’une confiance minimale à Google Cloud, l’option CSEK (Customer Supplied Encryption Keys, autrement dit Clés de chiffrement fournies par le client) répond à vos besoins. Cette option vous permet de maintenir votre propre racine de confiance (root of trust) et de « pousser » les clés au moment de leur utilisation vers Google Cloud via une API. Ces clés sont stockées dans la RAM pendant le temps nécessaire à l'exécution de l'opération.

Avec CSEK, la charge et la responsabilité de protéger et ne pas perdre les clés vous incombent intégralement. Google n'a aucun moyen de récupérer vos données si vos clés sont supprimées ou perdues par inadvertance. Une erreur est si vite arrivée ! Par conséquent, si vous utilisez CSEK, vous devez être extrêmement prudent et investir dans votre propre système de distribution de clés pour envoyer des clés à Google au rythme de leur utilisation par vos applications.

Cloud KMS, le service de gestion de clés de Google Cloud

Autre option possible, le service de gestion des clés dans Google Cloud (Cloud Key Management Service) vous permet de tirer parti de notre système évolutif de gestion des clés à l'échelle mondiale. Avec Cloud KMS, vous conservez un contrôle intégral de toutes les opérations liées aux clés et pouvez activer l’audit de toutes les opérations sur toutes vos clés.

Cloud KMS vous évite de devoir créer votre propre système de distribution et de protection des clés tout en vous offrant une totale visibilité de chacune de leurs utilisations. Les clés créées et maintenues dans Cloud KMS sont utilisées comme clés de chiffrement en lieu et place des clés de chiffrement par défaut de Google.

L’option HSM (Hardware Security Modules)

Vous pouvez également stocker vos clés dans un module de sécurité matériel (HSM) hébergé dans le cloud.
Ce service vous permet de stocker des clés de chiffrement et d'effectuer des opérations cryptographiques dans un cluster de modules matériels de sécurité certifiés FIPS 140-2 Level 3. Google gère ce cluster HSM pour vous, de sorte que vous n'avez pas à vous soucier de la mise en cluster, de la mise à l'échelle ou des correctifs.
Parce que Cloud HSM utilise Cloud KMS comme frontal, vous pouvez tirer parti de toutes les commodités et fonctionnalités offertes par Cloud KMS.

L’option Cloud EKM (Gestionnaire de clés externes dans le cloud)

Avec Cloud EKM, vous pouvez utiliser les clés de chiffrement que vous gérez via un partenaire de gestion de clés externes. Ce dernier doit être pris en charge par Cloud EKM pour protéger les données dans Google Cloud.

Voici comment cela fonctionne :

Tout d'abord, vous créez ou utilisez une clé existante dans le système de votre partenaire de gestion de clés externe pris en charge par Cloud EKM. Cette clé possède un URI unique.
Ensuite, vous accordez à votre projet Google Cloud l'accès à l'utilisation de la clé hébergée dans le système du partenaire de gestion de clés externe.
Dans votre projet Google Cloud, vous créez une clé Cloud EKM, en utilisant l'URI de la clé gérée en externe.

La clé Cloud EKM et la clé externe du partenaire de gestion de clés fonctionnent ensemble pour protéger vos données. La clé externe n'est ainsi jamais exposée à Google.

Autres services de sécurité des données

Outre le chiffrement des données, d'autres services peuvent s’avérer utiles pour renforcer la sécurité des données dans Google Cloud :

Les VPC Service Controls atténuent les risques d'exfiltration de données en isolant les services multi-tenants.
Data Loss Prevention permet de découvrir, de classer et de protéger les données sensibles. Nous avons dédié un article à ce sujet sur ce Blog.

Pour une découverte plus approfondie du fonctionnement du chiffrement au repos et en transit au sein de nos différents services, consultez les livres blancs dédiés.

Pour plus de #GCPSketchnote, suivez notre repo GitHub. Et n’hésitez pas à suivre mes explorations de Google Cloud sur Twitter @pvergadia tout en gardant un œil sur thecloudgirl.dev.

Choisissez votre parcours AI/ML sur Google Cloud

Fri, 19 Aug 2022 08:00:00 +0000

Au sein d’une organisation, de nombreux collaborateurs jouent des rôles clés dans le cycle de vie du Machine Learning (ML) : des chefs produits qui interrogent en langage naturel BigQuery pour tirer des enseignements des données, les data scientists qui travaillent sur différents aspects de la construction et la validation des modèles, des ingénieurs ML qui veillent au bon fonctionnement des modèles dans les environnements de production, etc.

Chacun de ces rôles découle de besoins différents. Ce billet de blog explore les services AI/ML de Google Cloud qui permettent justement de répondre à ces différents besoins…

De manière générale, les services qui répondent le mieux à vos besoins dépendent de vos cas d’usage spécifiques et du niveau d’expertise de votre équipe.
Parce que construire et maintenir des modèles ML de haute qualité nécessite beaucoup d’efforts et d’expertise ML, une première approche simple et rapide consiste à exploiter des solutions IA prêtes à l’emploi ou des modèles pré-entraînés tant que ces derniers sont applicables à vos cas d’usage.
Pour aller plus loin, si vos données sont structurées et stockées dans BigQuery et que vos collaborateurs sont habitués à SQL, il est naturel d’opter pour BigQuery ML. Enfin, si votre cas d’usage nécessite que vous codiez votre propre modèle, orientez-vous vers les entraînements personnalisés de Vertex AI. Entrons un peu plus dans le détail de ces différentes options…

Les Solutions d'IA prêtes à l'emploi

Les API pré-entraînées et les solutions IA prêtes à l'emploi peuvent être utilisées sans expertise préalable en ML. Pour illustrer cette approche, voici quatre solutions AI directement utilisables et proposées par Google Cloud :

Contact Center AI – Pour créer des expériences conversationnelles riches et naturelles sur différents appareils et plateformes à l'aide d'un agent virtuel animé par l'IA, d’insights déduits des interactions avec les clients et de fonctions d'assistance aux agents.

Document AI – Pour exploiter vos données non structurées (telles que les images et les PDF) et les rendre accessibles afin d'accroître l'efficacité opérationnelle, d'améliorer l'expérience client et de faciliter la prise de décision. Pour cela, le service s’appuie à l'aide sur la vision par ordinateur de Google (y compris l'OCR) et nos capacités de traitement du langage naturel (NLP).

Recommendations AI – Pour s’appuyer sur la puissance du Machine Learning afin de fournir des recommandations personnalisées en fonction des tendances et des préférences de chaque client, sur tous les points de contact.

Dialogflow CX – Pour élaborer des IA conversationnelles réalistes associées à des agents virtuels intelligents afin de proposer des interactions riches et intuitives à vos clients.

Les API pré-entraînées

Si vous ne disposez d'aucune donnée d'entraînement pour former un modèle ou si votre cas d’usage est assez générique et repose sur des données non structurées telles que des vidéos, des images, du texte ou du langage naturel, alors une API vers une IA pré-entraînée peut s’avérer un excellent choix pour votre projet d'IA/ML. Ces IA sont pré-entrainées à partir d'un énorme corpus de données génériques non structurées, construit, adapté et maintenu par Google. Autrement dit, vous n'avez pas à vous soucier de la création et de la gestion des modèles sous-jacents.

Vision AI – Pour tirer des insights de vos images dans le cloud ou à l’Edge avec AutoML Vision ou pour utiliser les modèles pré-entraînés de l'API Vision afin de détecter des émotions, de comprendre le sens d’un texte, d’extraire les textes des images, etc.

Video AI – Pour optimiser la découverte de contenus utiles embarqués au cœur des vidéos et offrir des expériences vidéo plus interactives.

Translation AI – Pour rendre vos contenus et vos applications multilingues grâce à une traduction automatique rapide et dynamique.

Language AI - Pour récolter des enseignements et observations à partir de textes non structurés grâce à la compréhension du langage naturel (NLU). De puissants mécanismes ML d’extraction et d’analyse permettent de réaliser des analyses de texte précises.

API Speech-to-text – Pour convertir avec précision la parole en texte (et vice versa avec l'API Text-to-speech) afin d’offrir une meilleure expérience utilisateur.

BigQuery ML

Si vos données d'apprentissage se trouvent dans BigQuery et que vos collaborateurs sont plus habitués à SQL, vos data-analysts et data-scientists pourront construire des modèles ML directement dans BigQuery à l'aide de BigQuery ML. Vous devrez cependant préalablement vous assurer que le jeu de modèles disponibles dans BigQuery ML peut répondre au problème que vous essayez de résoudre. BigQuery ML propose des instructions SQL simples pour construire, entraîner et faire des prédictions dans l'interface utilisateur BigQuery ou via l'API BigQuery.

Vertex AI

Vertex AI propose une plateforme de bout en bout, entièrement managée, dédiée à la science des données et au Machine Learning. Simple et complète, Vertex AI s’impose comme la solution à employer si vous devez créer vos propres modèles personnalisés avec vos propres données.
Vertex AI offre deux options pour entraîner vos modèles : AutoML et l’entraînement personnalisé.

Voici comment choisir entre ces deux options :

Cas d’usage : Si votre cas d'usage correspond à une offre AutoML prise en charge, commencez avec AutoML. Cela inclut les cas d'utilisation impliquant des types de données tels que les images, les vidéos, les textes et les tableaux. Mais si votre modèle prend en charge un type d'entrée mixte, comme des images et des métadonnées tabulaires, il est alors plus judicieux de s’orienter vers un modèle personnalisé.
Pré-requis : Si vous avez besoin de contrôler l'architecture de votre modèle, les dépendances des modèles exportés ou encore le framework (par exemple, si votre modèle doit être construit avec TensorFlow ou Pytorch), alors optez pour un modèle personnalisé.
Expertise de l'équipe : Quelle est l'expérience de votre équipe en matière de ML/AI ? Si votre équipe a peu d'expérience dans la création de modèles personnalisés, explorez AutoML avant de vous lancer dans le développement de modèles personnalisés.
Taille de l'équipe : Si vous disposez d'une petite équipe de Data Science et de ML, alors il peut s’avérer plus logique et plus productif de travailler en priorité avec AutoML car le codage d’un modèle personnalisé nécessite plus de temps aussi bien en matière de développement que de maintenance.
Prototypage : Bonne pratique reconnue, commencez par utiliser AutoML pour rapidement développer un modèle initial qui servira de base de référence. Vous pourrez alors décider d’utiliser directement ce modèle de base en production ou chercher à l’améliorer en développant votre propre modèle personnalisé.

Pour explorer plus en profondeur les services ML, reportez-vous à cette documentation ou démarrez votre apprentissage avec nos vidéos Vertex AI détaillées. N’hésitez pas également à explorer les différents contenus proposés lors de l’Applied ML Summit, qui s’est tenu en juin, désormais disponibles à la demande. Vous y découvrirez les conseils et bonnes pratiques des meilleurs data scientists et ingénieurs ML du monde entier.

Pour plus de #GCPSketchnote, suivez le repo GitHub. Pour d’autres contenus similaires autour du Cloud, suivez-moi sur Twitter @pvergadia et gardez un œil sur thecloudgirl.dev.

A la découverte de Cloud DLP (Data Loss Prevention)

Fri, 12 Aug 2022 09:00:00 +0000

Les données sensibles sont partout et parfois là où on ne les attend pas. Par exemple, des clients peuvent vous envoyer par inadvertance des données sensibles à l’occasion d’un échange sur le chat du support ou par un envoi de fichier irréfléchi.
Notamment si vous utilisez des données pour des analyses ou du Machine Learning, il est impératif que les données sensibles soient gérées de manière appropriée pour protéger la vie privée des utilisateurs.

C’est pourquoi il est essentiel de disposer non seulement d’une vue globale des endroits où résident les données, mais aussi de la façon dont elles sont utilisées (vous pourriez être tenu responsable de ces données). Il faut ensuite pouvoir élaborer des processus garantissant un traitement approprié. C’est justement là que Cloud DLP entre en jeu !

Qu’est-ce que Cloud DLP ?

Cloud DLP (pour Cloud Data Loss Prevention – Solution Cloud de prévention des pertes de données) est un service Google Cloud entièrement managé conçu pour découvrir, classer et protéger vos données sensibles, où qu’elles se trouvent ! Et ceci qu’il s’agisse de bases de données, de contenus textuels ou même d’images !
Dit autrement, Cloud DLP procure une visibilité et une classification des données sensibles sur l’ensemble de votre organisation.

En outre, le service réduit les risques liés aux données, qu’elles soient structurées ou non, en les inspectant et en les transformant à l’aide de méthodes d’obscurcissement et d’anonymisation telles que le masquage ou la tokenisation.

Enfin, Cloud DLP peut vous aider à effectuer des analyses de réidentification pour améliorer votre compréhension du risque de confidentialité des données. L'analyse du risque de réidentification est un processus d'analyse des données qui permet de trouver les propriétés qui, une fois associées, augmentent le risque d'identification des personnes. Prenons l'exemple d'un ensemble de données marketing qui comprend des propriétés démographiques telles que l'âge, la fonction et le code postal. À première vue, ces données démographiques peuvent ne pas être identifiables, mais certaines combinaisons d'âge, de fonction et de code postal peuvent correspondre uniquement à un petit groupe d'individus ou à une seule personne, ce qui augmente le risque de réidentification de cette personne.

Comment fonctionne Cloud DLP ?

Cloud DLP propose plusieurs interfaces, notamment une API pour l'incorporer aux systèmes existants ou encore une console UI pour une intégration facile et sans code.
Les méthodes des API de contenu (Content API) offrent aux clients la possibilité d'inspecter et de transformer les données n'importe où et permettent des interactions en temps réel, comme la protection du trafic.
Les méthodes de stockage pour BigQuery, Cloud Storage et Datastore disposent à la fois d'une interface utilisateur et d'une interface API pour faciliter l’analyse de grandes quantités de données au repos. Par exemple, Automatic DLP for BigQuery peut automatiser la découverte et la classification de toute une organisation GCP et s'exécuter en continu pour offrir une visibilité sur le risque lié aux données à mesure que de nouveaux projets, ensembles de données et tables sont créés.

L'inspection et la classification sont animées par la technologie de prévention des pertes de données de Google Cloud, qui dispose de détecteurs pour plus de 150 types d'informations, offre un riche ensemble de règles de personnalisation et de détection, et prend en charge divers formats, notamment les tableaux structurés, le texte non structuré et les données contenues dans les images via de l'OCR embarqué.

De multiples techniques d’anonymisation

Cloud DLP procure différentes techniques d’anonymisation à même de masquer les informations sensibles tout en préservant leur utilité.

Le Masquage - Masque une chaîne de caractères, entièrement ou partiellement, en remplaçant un nombre donné de caractères par un caractère fixe spécifié. Cette technique peut, par exemple, masquer tout sauf les quatre derniers chiffres d'un numéro de compte ou d'un numéro de sécurité sociale.

La Rédaction - Rédige une valeur sous une forme textuelle en supprimant sa valeur numérique.

Le Remplacement - Remplace chaque valeur saisie par une valeur donnée.

La Pseudonymisation avec hachage sécurisé - Remplace les valeurs d'entrée par un hachage unidirectionnel sécurisé, généré à l'aide d'une clé de chiffrement des données.

La Pseudonymisation avec jeton préservant le format - Remplace une valeur d'entrée par un "jeton", ou une valeur de substitution, du même jeu de caractères et de la même longueur en utilisant un cryptage préservant le format (FPE). La préservation du format peut contribuer à assurer la compatibilité avec les systèmes existants qui ont des exigences restreintes en matière de schéma ou de format.

La Généralisation - Masque les valeurs d'entrée en les remplaçant par des "catégories" ou des plages dans lesquelles la valeur d'entrée se situe. Par exemple, vous pouvez regrouper des âges spécifiques dans des tranches d'âge ou des valeurs distinctes dans des plages telles que "faible", "moyen" et "élevé".

Le Décalage de date - Décale les dates d'un nombre aléatoire de jours par utilisateur ou par entité. Cela permet de masquer les dates réelles tout en préservant la séquence et la durée d'une série d'événements ou de transactions.

L’Extraction de l'heure - Extrait ou préserve une partie des valeurs de Date, d'horodatage (Timestamp) et d'heure du jour (TimeofDay).

Les méthodes d’anonymisation de Cloud DLP peuvent assurer l'obscurcissement de données aussi bien structurées que non structurées. Vous pourrez ainsi ajouter une couche supplémentaire de protection des données et de confidentialité à pratiquement tous vos workloads.

Ceci n’est qu'un bref aperçu de Cloud DLP. Pour une exploration plus approfondie, consultez la documentation et notre série de vidéos dédiées au sujet.

Pour plus de #GCPSketchnote, suivez le repo GitHub. Pour d’autres contenus similaires autour du Cloud, suivez-moi sur Twitter @pvergadia et gardez un œil sur thecloudgirl.dev.

Déployer un générateur de pages à colorier en quelques minutes avec Cloud Run

Thu, 28 Jul 2022 14:39:00 +0000

? Bonjour

Avez-vous déjà implémenté un script de traitement d'images ? L'avez-vous partagé ou exécuté sur plusieurs ordinateurs ? Combien de fois avez-vous dû mettre à jour son programme ou sa doc d'installation ? Avez-vous fini par en faire un service ou une application en ligne ? Le déploiement de services de traitement est un besoin récurrent, mais sa mise en place peut rebuter plus d'un développeur. Les technologies serverless vous permettent de résoudre ce défi, facilement et efficacement.

Dans cet article, vous verrez comment…

créer un service de traitement d'images générant des pages à colorier
le rendre disponible en ligne en utilisant un minimum de ressources
avec une latence minimale en profitant des centres de données Google Cloud français

…tout cela en moins de 200 lignes de Python et JavaScript.

?️ Outils

Pour implémenter et déployer un générateur de pages à colorier, quelques outils suffisent :

Une bibliothèque de traitement d'images
Un socle de développement web
Un serveur web
Une solution serverless pour rendre l'application disponible 24h/24 et 7j/7

? Architecture

Voici une architecture possible, basée sur Cloud Run :

Et voici le flux d'échanges :

1 - L'utilisateur ouvre l'application web : le navigateur envoie la requête correspondante.
2 - Cloud Run retourne le code HTML de l'application.
3 - Le navigateur demande les ressources supplémentaires nécessaires.
4 - Cloud Run sert les fichiers CSS, JavaScript et les autres ressources.
A - L'utilisateur fournit une image : le client l'envoie au point d'entrée /api/coloring-page.
B - Le serveur traite l'image et renvoie le résultat, que l'utilisateur peut ensuite visualiser, télécharger ou imprimer depuis le navigateur.

? Couches logicielles

Il existe de multiples possibilités pour implémenter une telle architecture.

Voici un exemple de couches logicielles Python :

Schema

Elles comprennent :

Gunicorn : un serveur HTTP WSGI adéquat pour la production
Flask : un socle de développement web très populaire
scikit-image : une riche bibliothèque de traitement d'images

Pour commencer, définissez les dépendances de l'applicatif dans un fichier nommé requirements.txt :

? Traitement d'images

Comment supprimer les couleurs d'une image ? Une possibilité consiste à détecter les contours des objets qui la composent et à supprimer tout le reste. Cela peut être effectué via un filtre de Sobel, un filtre de convolution qui détecte les régions dans lesquelles l'intensité de l'image varie le plus.

Créez un fichier Python nommé main.py, définissez une fonction, puis utilisez un filtre de Sobel et d'autres fonctions de scikit-image :

Remarque : Les bibliothèques NumPy et Pillow sont automatiquement installées en tant que dépendances de scikit-image.

À titre d'exemple, voici comment le logo de Cloud Run est traité à chaque étape :

Transformation d'une entrée colorée en échelle de gris avec détection des bords.

✨ Application Web

Partie serveur

Pour exposer les deux points d'entrée (GET / et POST /api/coloring-page), définissez des routes Flask dans main.py :

Partie cliente

Du côté du navigateur, écrivez une fonction JavaScript qui appelle le point d'entrée /api/coloring-page et récupère l'image traitée :

La base de votre application est là. Il ne reste plus qu'à ajouter un mélange de HTML + CSS + JS pour fournir l'expérience utilisateur souhaitée.

Développement local

Pour développer et tester l'application en local, une fois l'environnement configuré (e.g. venv pour Python), assurez-vous d'avoir les dépendances nécessaires :

Ajoutez le bloc suivant au fichier main.py. Il ne s'exécutera que lors d'un lancement manuel :

Lancez manuellement l'application :

Flask démarre un serveur web local :

Remarque : Dans ce mode, vous utilisez un serveur web local de développement (i.e. non adapté à la production). Vous allez ensuite configurer le déploiement pour servir votre application avec Gunicorn, un serveur de production.

Vous êtes prêt. Ouvrez localhost:8080 dans votre navigateur, testez, affinez et itérez.

? Déploiement

Une fois votre application prête, vous pouvez définir comment elle sera servie avec cette seule ligne dans un fichier nommé Procfile :

À ce stade, voici les fichiers présents dans ce projet type :

Vous pouvez maintenant déployer votre application depuis le dossier source :

⚙️ Sous le capot

En ligne de commande, les différentes étapes sont détaillées :

Cloud Build est indirectement appelé pour conteneuriser votre application. L'un de ses principaux composants est Google Cloud Buildpacks, qui crée automatiquement une image de conteneur prête pour la production à partir de votre code source. Voici les principales étapes :

Cloud Build récupère le code source.
Buildpacks détecte automatiquement le langage de l'application (Python ici) et utilise l'image de base sécurisée correspondante.
Buildpacks installe les dépendances de l'application (définies dans requirements.txt ici).
Buildpacks configure l'exposition du service (définie dans Procfile pour Python).
Cloud Build transfère l'image du conteneur vers Artifact Registry.
Cloud Run crée une nouvelle révision du service basée sur cette image de conteneur.
Cloud Run y achemine le trafic de production.

Remarques :

Buildpacks prend à ce jour en charge les environnements d'exécution suivants : Go, Java, .NET, Node.js et Python.
L'image de base est activement maintenue par Google, analysée pour détecter d'éventuelles vulnérabilités de sécurité et corrigée contre les problèmes connus. Cela signifie que lorsque vous déployez une mise à jour, votre service s'appuie sur une image la plus sécurisée possible.
Si vous avez besoin de créer votre propre image de conteneur, par exemple avec un environnement d'exécution personnalisé, vous pouvez ajouter votre propre Dockerfile que Buildpacks utilisera directement.

? Mises à jour

Après une utilisation de l'application à plus grande échelle, quelques problèmes remontent.

Tout d'abord, l'application ne gère pas les photos prises dans des orientations non natives. Vous pouvez résoudre ce problème en utilisant les données d'orientation EXIF :

Ensuite, le traitement est trop sensible aux détails dans l'image de départ : les textures dans les peintures, ou le bruit dans les images, peuvent générer de nombreux bords dans l'image à l'arrivée. Vous pouvez améliorer l'algorithme de traitement en ajoutant une étape de débruitage en amont :

Cette étape supplémentaire rend l'image à colorier plus propre et réduit la quantité d'encre utilisée en cas d'impression :

Redéployez ; l'application est automatiquement mise à jour :

? C'est en prod

L'application est visible en tant que service dans Cloud Run :

Le tableau de bord du service donne un aperçu de son utilisation :

Et voilà, votre application de traitement d'images est en production !

? C'est serverless

L'utilisation de Cloud Run dans cette architecture présente de nombreux avantages :

Votre application est disponible 24h/24 et 7j/7.
L'environnement est entièrement géré : vous pouvez vous concentrer sur votre code et ne pas vous soucier de l'infrastructure.
Votre application est automatiquement disponible en HTTPS.
Cloud Run adapte automatiquement le nombre d'instances en fonction du trafic et la facturation n'inclut que les ressources utilisées lors de l'exécution de votre code.
Si l'application n'est pas utilisée, Cloud Run réduit le nombre d'instances à zéro. Pas de trafic ? Pas de coût !
En cas de montée du trafic (votre app a du succès !), Cloud Run augmente la capacité avec le nombre d'instances nécessaires.
Vous pouvez contrôler les performances et les coûts en ajustant de nombreux paramètres : processeur, mémoire, concurrence, instances minimales, instances maximales, etc.
Chaque mois, la tranche gratuite de Cloud Run offre les premières 50 heures de vCPU, 100 Gio-heures de mémoire et 2 millions de requêtes.

? Ça tourne en France

Les services Cloud Run peuvent être déployés dans de nombreuses régions à travers le monde, y compris en France :

La région française vient d'être inaugurée et a pour code europe-west9.
Choisir des régions au plus près des utilisateurs finaux offre des temps de latence encore plus faibles.
Cerise sur le gâteau : europe-west9 est une région à faible émission de carbone ?.

L'application web GCPing (https://gcping.com) permet de tester en conditions réelles le temps de réponse entre votre ordinateur et les différentes régions Google Cloud. Voici un aperçu de la latence observée depuis Paris :

? Code source

Le projet comprend seulement 7 fichiers et moins de 200 lignes de code (Python + JavaScript).

Vous pouvez réutiliser cette démo comme base pour créer votre propre application de traitement d'images :

Retrouvez le code source sur GitHub.
Pour déployer vous-même l'application, étape par étape, en quelques minutes, consultez "Deploying from scratch".

? Plus !

Essayez la démo et générez vos propres pages à colorier.
En savoir plus sur Cloud Run.
Pour plus de contenu cloud, vous pouvez me suivre sur Twitter (@PicardParis) ou LinkedIn (in/PicardParis).

Libérez le potentiel de vos données sur mainframe avec une approche innovante : la « data-first digitization »

Tue, 24 May 2022 08:00:00 +0000

Dans de nombreuses entreprises, de vénérables mainframes abritent encore des décennies de données sur les clients, les processus et les opérations. Et bien évidemment, ces entreprises aimeraient bien pouvoir y accéder pour effectuer des analyses et créer des rapports avec les outils du big data ou encore pour les utiliser dans le cadre de nouveaux projets de Machine Learning et d’Intelligence Artificielle.

Nous avons hâte chez Google de vous accompagner dans cette démarche en vous aidant à transformer les ressources mainframe pour l'ère du cloud. Nous pouvons bien entendu vous aider à moderniser vos applications mainframes en les faisant migrer vers le cloud. Mais en parallèle, nous avons aussi développé une autre alternative avec nos partenaires et nos clients. Plus légère, elle permet de commencer à exploiter les ressources des mainframes sur le cloud beaucoup plus rapidement qu’avec une migration complète de l’existant. Nous avons baptisé cette approche data-first digitization ou, en français, « numérisation des données d'abord ».

Dans un monde numérique qui évolue rapidement, il convient tout d’abord de faire la différence entre « modernisation » et « numérisation ».
Dans une approche classique de modernisation, vous partez de l’existant pour vous projeter dans l’avenir en vous appuyant sur des méthodes de migration d’applications des mainframes, qu’il s’agisse de rehosting (émulation), de refactoring (transformation du code), de réingénierie ou simplement de remplacement d'une application sur mesure par une solution « clés en main ».
À l’inverse, dans une approche « numérisation », on part du résultat attendu et on remonte la chaîne existante en modifiant tout ce qui doit l’être pour atteindre son objectif.

Cette approche « numérisation » s’appuie sur un framework d’intégration privilégiant les données. Constitué à partir de nos outils et solutions et ceux de nos partenaires, il permet de migrer des sources de données hétérogènes provenant des mainframes vers Google Cloud Storage. Une fois les données mainframe copiées sur Cloud Storage, elles peuvent ensuite être intégrées et exploitées par les outils Google Cloud, tels que BigQuery, les solutions d'IA et de Machine Learning ou encore les plateformes d’analyse intelligente (Smart analytics) et d’analyse de flux (Stream analytics).
Notre framework d'intégration couvre à la fois le mode batch pour transférer d’un coup des jeux de données volumineux et la réplication en temps réel par capture des modifications apportées aux données (prise en charge du « change data capture »).

L’approche « numérisation d’abord » repose sur le principe selon lequel « les applications sont éphémères, les données sont permanentes ».

Plutôt que d’utiliser les méthodes traditionnelles de modernisation telles que décrites dans les 7 options de modernisation du Gartner par exemple, les entreprises vont ici privilégier le transfert des données vers Google Cloud, ce qui leur permettra d’accélérer les étapes et de commencer à mettre rapidement en place nouveaux modèles métiers, de nouveaux cas d’usage ou encore de nouvelles façons innovantes de satisfaire leurs clients.

Deux exemples concrets :

Prendre de meilleures décisions, plus rapidement, en s’appuyant sur les solutions d’analyse en temps réel et intelligentes mais aussi sur les moteurs de Machines Learning et/ou AI. Google est un pionnier dans l'extraction d'informations et de valeur à partir de données brutes structurées et non structurées. Ces outils ont toutefois besoin d’être alimentés en données pour gagner en efficacité. En rendant les données sur mainframe accessibles par des outils comme BigQuery et des modèles AI/ML, les entreprises maximisent leurs capacités d’analyse.
Créer de nouvelles applications de reporting. L’accessibilité des données sur mainframe par des outils Google Cloud, tels que Looker et Appsheet, permet de créer de nouvelles applications de reporting et ainsi d’accélérer votre transformation globale en décommissionnant plus rapidement les anciennes applications de reporting hébergées sur mainframe.

D'après notre expérience, l'adoption d'une approche « numérisation » axée sur les données offre un certain nombre d'avantages :

Réactivité métier : cette forme de modernisation s’appuyant sur des outils existants, le cycle de mise en œuvre est beaucoup plus court.
Investissements réduits : l’intégration de produits est moins consommatrice de ressources que le développement d’applications.
Risques minimisés : la démarche data-first repose sur des solutions intégrées aux produits Google Cloud existants, éprouvés et fiables.
Transformation plus rapide de l’existant sur mainframe : en déplaçant le centre de gravité de l’application vers les données, vous abordez la question de la modernisation sous l’angle métier, plutôt que de simplement continuer à faire vivre cet existant. Dès lors, seules les applications réellement critiques pour l’entreprise sont modernisées tandis que les applications non essentielles peuvent être mises hors service progressivement, ce qui permet d’accélérer le processus de transformation.

Une telle numérisation centrée sur les données est encore une approche relativement récente, mais les premiers succès de nos clients nous invitent à poursuivre dans cette voie.
N’hésitez pas à consulter régulièrement sur notre site pour obtenir des informations supplémentaires, des architectures de référence et des livres blancs techniques sur l'approche "data-first". Et si vous pensez qu’elle peut vous convenir, contactez mailto:mainframe@google.com.

Améliorer la rapidité et la sécurité de vos déploiements dans le cloud

Tue, 18 Jan 2022 10:00:00 +0000

La rapidité et la sécurité des déploiements figurent parmi les principales priorités des organisations qui bâtissent leur IT dans le cloud.

Ces objectifs peuvent parfois sembler contradictoires, notamment si la gouvernance de la sécurité est distribuée, si les consignes de sécurité sont davantage rédigées comme des obligations plutôt que des préconisations et qu’en plus les outils font défaut pour qu’elles soient réellement appliquées dans votre environnement. Mais ce n'est pas une fatalité. Nous avons spécialement créé le « security foundations blueprint » pour adresser ces questions.
Nous avons récemment commencé à parler de ce guide sur ce blog afin de présenter son contenu, indiquer à qui il s’adresse et passer en revue certaines des meilleures pratiques qu'il recommande pour créer et maintenir une infrastructure centrée sur la sécurité. Nous avons aussi expliqué comment bien démarrer avec le repository (le répertoire) d'automatisation qui transforme ces meilleures pratiques en modules Terraform déployables.

Le « security foundations blueprint » n’est qu’une des nombreuses ressources proposées par notre centre des meilleures pratiques.

Dans ce billet, nous allons revenir plus en détail sur les retours d’expériences des utilisateurs de Google Cloud qui adoptent, adaptent, et déploient le « security foundations blueprint » dans leur environnement cloud. De toutes tailles et de tous secteurs, ces organisations ont constaté un impact positif sur leurs équipes et leurs activités. Au fil du temps, et alors que nous les écoutions et travaillions avec elles, leurs retours nous ont permis d’identifier différents bénéfices du « security foundations blueprint » :

Il permet de mieux former les nouveaux collaborateurs aux fonctionnalités et aux meilleures pratiques de sécurité de Google Cloud.
Il collecte en un seul lieu toutes les décisions fondamentales prises en matière de sécurité et fournit un modèle de référence fondé sur l’expertise de Google.
Il fournit un exemple de déploiement automatisé qui accélère des déploiements et opérations sécurisées.
Il permet aux partenaires d’élaborer des solutions spécifiques à un domaine d’activité en se fondant sur un socle sécurisé.

Nous vous proposons ci-après d’explorer un peu plus chacun de ces avantages.

Sensibiliser les clients à la sécurité dans Google Cloud

Migrer des workloads vers le cloud ouvre de multiples perspectives de modernisation et d’amélioration. Le renforcement de la sécurité de votre infrastructure est l’une d’entre elles. Toutefois, si vous gérez habituellement la sécurité d’un environnement interne « on-prem », vous devrez vous familiariser avec un nouveau jeu de “infrastructure primitives” (les building blocks proposés) et d’abstractions de contrôle (autrement dit la façon dont vous gérez les stratégies de sécurité) ainsi qu’avec le modèle de « Shared Fate » entre Google Cloud et vous.

Le guide « security foundations blueprint » réunit tous ces sujets dans un document très complet afin de former les nouveaux utilisateurs aux fonctionnalités de sécurité de Google Cloud. Il couvre votre réseau, la hiérarchie de vos ressources, la manière dont vous fournissez l'accès, et bien d'autres choses encore (à découvrir dans ce récent article de blog). Document de référence, il peut être utilisé par les clients lorsqu’ils conçoivent leur architecture et mettent en place des règles ainsi que des lignes directrices pour optimiser la sécurité de leur environnement. Pour les clients ayant déjà établi leur stratégie de sécurité, ce guide peut être utilisé pour valider et affiner leur architecture existante afin de l'aligner sur les meilleures pratiques de sécurité dans Google Cloud.

Cliquez sur l’image pour accéder au guide complet « security foundations blueprint »

Des conseils avisés par des experts de la sécurité

Une fois familiarisé avec les solutions et les options disponibles pour sécuriser vos déploiements, vous pouvez traduire ces connaissances acquises en stratégies de sécurité. Il faut toutefois savoir que le processus peut s’avérer difficile en raison non seulement des nombreuses décisions à prendre mais aussi de leurs dépendances les unes des autres. Le « security foundations blueprint » est précisément là pour vous guider dans cet arbre décisionnel en vous proposant un parcours cohérent et parfaitement maîtrisé afin de vous garantir une posture de sécurité forte.

En d'autres termes, il a été conçu pour vous accompagner en vous fournissant les meilleures pratiques dans le déploiement de workloads sur Google Cloud. Et n’oublions pas qu’il est rédigé par le fournisseur de la plateforme, autrement dit par celui qui maîtrise le mieux non seulement la configuration actuelle de la solution mais aussi ses évolutions à venir.

En suivant les meilleures pratiques fournies par le guide, vous poserez les bases d'une solide posture de sécurité. Celui-ci fournit un contexte ainsi que des informations générales sur les compromis et les raisons sous-jacentes à chacune des décisions, afin que vous puissiez évaluer les risques et adapter votre décision à vos propres besoins. En fait, le modèle est conçu pour être flexible, de sorte qu'il peut être utilisé dans son intégralité tel qu'il est rédigé, ou comme point de départ pour concevoir votre propre architecture avec vos propres stratégies de sécurité. Il est également mis à jour régulièrement pour intégrer les commentaires des utilisateurs, les mises à jour des produits et les modèles de menaces, de sorte que votre stratégie de sécurité reste elle aussi à jour.

Accélérer les déploiements

Le Time-to-market reste l’un des objectifs principaux de tout projet. Les déploiements dans le cloud ne font pas exception. La gestion manuelle des paramètres et des scripts de configuration ainsi que la définition des stratégies d'IAM, de pare-feu, de journalisation et de sauvegarde de votre déploiement engendrent de la complexité. Difficilement répétables faute d’automatisation, ces opérations ralentissent le développement. En adoptant le modèle du « security foundations blueprint », vous bénéficiez automatiquement d’un code pré-écrit et testé pour vous, traduisant les meilleures pratiques en modules Terraform. Par ailleurs, les tâches opérationnelles sont automatisées et intégrées dans le processus de déploiement, ce qui accélère encore la vitesse de vos déploiements. Vous pouvez aussi gérer et suivre les évolutions, ce qui favorise une meilleure gouvernance de l’état de votre infrastructure.

Accélérer les déploiements sans compromettre la sécurité est l'avantage numéro un qui revient constamment dans les retours des utilisateurs après leur adoption du « security foundations blueprint » et des modules Terraform qui l’accompagnent.

Chez Deloitte, nous avons exploité avec succès le « Security Foundations Blueprint » chez nos clients pour les aider à accélérer l'adoption sécurisée de Google Cloud, optimisant au passage nos propres solutions et méthodes de livraison logicielles. Arun Perinkolam
Principal and US Google Cloud Security Practice & Alliance Leader, Deloitte & Touche LLP (Directeur

Le « security foundations blueprint » sous forme de pipeline de déploiement automatisé

Une fondation qui permet une approche personnalisée et adaptée à un contexte spécifique

Au-delà des principes fondamentaux de sécurité, il arrive que des clients et des partenaires soient confrontés à des cas d’usage et/ou à des exigences spécifiques à leur secteur d'activité, à leur situation géographique ou à des contraintes réglementaires propres à leur entreprise. Gérer chaque cas particulier en partant de zéro et en tentant de l’industrialiser peut s’avérer difficile. En outre, les clients et les partenaires détiennent des connaissances précieuses, issues de leur propre expérience et expertise, qu'ils appliquent pour élaborer leurs solutions et sont seuls à maîtriser.

Disposer d’un point de départ universel - défini par Google Cloud et posant les principes de sécurité fondamentaux - permet aux clients et aux partenaires de se concentrer sur les principales différences et améliorations nécessaires pour gérer leur cas d’usage spécifique puis de construire à partir de cette base. Le processus est ainsi accéléré, réimplémenter les contrôles et stratégies de base n’étant plus nécessaires. Par ailleurs, le référentiel de Google Cloud permet aux clients et aux partenaires de comprendre et d'aligner plus facilement leurs approches de la sécurité sur les meilleures pratiques de Google Cloud. En fournissant un point de départ cohérent et des bases universelles, le « security foundations blueprint » permet à chaque utilisateur et consommateur de bâtir son architecture sécurisée et personnalisée à partir d’une vision commune.

Prochaines étapes

Que vous débutiez sur Google Cloud en élaborant vos premières architectures et règles de sécurité ou que vous en soyez au stade de la validation et de l’évolution des règles d'architecture existantes en prenant de nouvelles décisions, le « security foundations blueprint » est l’outil qu’il vous faut pour rendre vos déploiements plus sûrs et plus rapides.

Si vous ne l'avez pas encore fait, n'oubliez pas de lire les trois premiers billets de cette série d’articles qui présentent le « security foundations blueprint », expliquent les sujets abordés et donnent des conseils pour commencer à utiliser les modules Terraform.

Si vous souhaitez accéder directement au Blueprint, n'oubliez pas que celui-ci comporte à la fois un guide pas à pas et un repository de modules d’automatisation pour Terraform.

Merci de votre intérêt pour le « security foundations blueprint ». Passez à l’action, déployez et restez sécurisé !

Comment intéresser les Cloud natifs à OpenStack

Tue, 07 Dec 2021 10:00:00 +0000

Dans ce billet, je vous propose d’expliquer comment accélérer la transformation de vos applications en profitant d’Anthos directement installé sur des serveurs physiques (bare-metal) afin d’exécuter OpenStack. Je reviendrai également sur les guides «Deploy Anthos on bare metal on OpenStack » (Déployer Anthos en bare metal installé sur OpenStack) et « Configure the OpenStack Cloud Provider for Kubernetes » (Configurer Openstack Cloud Provider pour Kubernetes) que nous avons récemment publiés.

Introduction à OpenStack

OpenStack est une plateforme open-source conçue pour faciliter la gestion de grands pools de ressources, qu’ils s’agissent de calcul, de stockage ou de réseau. La solution propose un ensemble d’API uniformisées ainsi qu’un tableau de bord interactif pour gérer et contrôler les ressources. Si vous disposez de vos propres serveurs physiques, vous pouvez installer OpenStack dessus et exposer ainsi ces ressources matérielles, aussi bien en interne à d’autres équipes qu’en externe à des tiers, pour leur permettre de créer des VMs, des loadbalancers (équilibreurs de charge) ou toute autre ressource disponible sur les serveurs. Dit autrement, vous pouvez voir OpenStack comme un équivalent à la couche logicielle exécutée sur les serveurs des datacenters de Google qui permet aux utilisateurs de provisionner des ressources de calcul et des services via la console cloud de Google.

Utilisez-vous OpenStack ?

Bon nombre d’entreprises ayant investi dans l’acquisition de leurs propres équipements matériels (serveurs et réseau) ont ressenti le besoin d’avoir une plateforme uniformisée pour gérer leur infrastructure. Elles ont donc cherché un moyen de gérer et exposer facilement les ressources disponibles de sorte à les rendre facilement consommables par les différentes équipes IT. Apparue dès 2010, OpenStack était une des rares solutions proposées aux entreprises pour les aider à gérer ainsi leur infrastructure. OpenStack prenait en charge toute la complexité de la planification, de la gestion du réseau et du stockage dans un environnement « bare-metal ».

Ainsi, nombre de nos clients sont des utilisateurs de longue date d’OpenStack. Si votre organisation fait partie de ces entreprises qui ont investi dans leurs propres équipements matériels (serveurs, réseau et/ou stockage), il y a de fortes que chances que vous utilisiez OpenStack.

Introduction à « Anthos on Bare Metal »

Anthos est la solution de Google conçue pour vous aider à gérer l’exécution de vos clusters Kubernetes partout : sur Google Cloud, en interne et sur les clouds d’autres fournisseurs.

Anthos vous permet de moderniser vos applications plus rapidement tout en apportant de la cohérence entre tous vos environnements. « Anthos on bare metal » est la déclinaison d’Anthos qui vous permet d'exécuter notre plateforme cloud directement sur vos propres serveurs physiques, gérés et maintenus par vos administrateurs.

En adoptant cette solution, vous pouvez continuer à capitaliser sur vos investissements en matériel, en plateformes et en infrastructure réseau pour héberger vos clusters Kubernetes tout en exploitant les avantages d’Anthos : gestion centralisée, flexibilité accrue et agilité des développeurs. Et ce, quel que soit le niveau d’exigence de vos applications.

Par mesure de simplification, nous désignerons ci-après par « clusters Anthos » les clusters Kubernetes exécutés/gérés par Anthos.

Anthos on Bare Metal peut-il transformer l’existant OpenStack en workloads cloud native ?

La réponse courte est… oui !

Nos clients nous ont fait comprendre qu’ils tenaient à leurs investissements dans leurs propres datacenters et dans leurs flottes de serveurs physiques. Et cela pour plusieurs raisons : exigences liées à la localisation des données, meilleur contrôle sur les ressources, attachement aux investissements CAPEX sans oublier la conservation des compétences existantes qui maitrisent parfaitement leurs environnements.

Une ou plusieurs de ces raisons, voire d’autres, peuvent s’appliquer également à votre entreprise.

Toutefois, la tendance est à la containerisation et au développement d’applications cloud natives. C’est pourquoi nous souhaitons vous aider à exploiter ce levier de modernisation de vos applications tout en vous permettant de continuer à les exécuter sur vos environnements OpenStack.

Anthos a été précisément pensé pour ça. Anthos on Bare Metal cherche à insuffler l’essentiel de Google Cloud au cœur de vos déploiements OpenStack. Vous pouvez ainsi continuer à exécuter vos workloads actuels sur votre infrastructure OpenStack optimisée tout en modernisant la couche applicative avec les fonctions clefs de Google Cloud, tels les services mesh, la gestion centralisée des configurations, la surveillance et les alertes, etc.

Tandis qu’OpenStack vous aide à gérer vos ressources sous-jacentes, Anthos on Bare Metal vous permet de gérer l’exécution des clusters Kubernetes sur votre infrastructure OpenStack existante. Afin de vous aider dans la mise en œuvre d’une approche « Anthos on Bare Metal sur OpenStack », nous avons récemment publié deux guides.

Installer Anthos on Bare Metal sur OpenStack

Le guide «Deploy Anthos on bare metal on OpenStack » (Déployer Anthos on Bare Metal sur OpenStack) vous accompagne dans l’installation d’Anthos on Bare Metal sur un environnement OpenStack existant, étape par étape. Il part du principe que vous disposez d’un environnement OpenStack similaire à celui présenté dans le diagramme suivant et vous guide dans l’installation d’un cluster hybride sur deux machines virtuelles OpenStack.

Notez qu'un réseau OpenStack interne de type "tenant" est créé pour accueillir l’univers Anthos, formant un ilot sous-jacent au réseau OpenStack principal (le Provider Network de votre déploiement OpenStack). Ce réseau « tenant » sert de connexion niveau 2 (du modèle ISO) pour les machines virtuelles que nous utilisons pour installer Anthos sur des machines physiques. En effet, cette configuration comporte trois machines virtuelles :

Une station d’administration : VM à partir de laquelle est géré le processus d’installation. Dans le cadre du processus d’installation d’Anthos on Bare Metal, un cluster de démarrage (bootstrap cluster) est d’abord créé sur la station d’administration et sera supprimé une fois l’installation terminée.
Un Control Plane Node : VM à partir de laquelle sont exécutés les composants du Control Plane, autrement dit du poste de pilotage de Kubernetes.
Un Worker Node : VM sur laquelle sont exécutés les workloads applicatifs.

Combinés, le Control Plane Node et le Worker Node forment les fondations du cluster Anthos on Bare metal.

Nous avons également déployé Octavia, le load balancer d’OpenStack, sur le réseau des VMs (le tenant network). Le load balancer est également connecté au Provider Network via un routeur.

Cette configuration du load balancer est importante pour exécuter la partie suivante de ce guide d’installation dans laquelle nous expliquons comment configurer le fournisseur cloud OpenStack pour Kubernetes.

En configurant OpenStack Cloud Provider pour Kubernetes sur notre cluster Anthos, nous pouvons exposer les services Kubernetes au-delà du Tenant Network (autrement dit hors de l’ilot Anthos). En effet, une fois le fournisseur configuré, chaque fois que vous créerez un service Kubernetes de type LoadBalancer, Octavia assignera une adresse IP à ce service, ce dernier devenant alors accessible depuis le réseau externe (le Provider Network).

Afin de vous permettre de suivre ces deux guides plus facilement, nous avons publié toutes les briques requises dans notre repository publique anthos-samples.

Selon votre existant, vous pouvez suivre le processus à partir d’une des quatre étapes suivantes et continuer ensuite jusqu’à la fin :

Vous ne possédez pas d’environnement OpenStack : commencez par suivre le guide « Deploy OpenStack Ussuri on GCE VM » (Déployer OpenStack Ussuri sur GCE VM) pour assembler un environnement OpenStack s’exécutant sur une VM Google Cloud Engine.
Si vous disposez déjà d’un déploiement OpenStack sans que ce dernier soit assemblé comme montré dans le schéma vu plus haut : commencez par suivre le guide “Provision the OpenStack VMs and network setup using Terraform” (Provisionner des VM OpenStack et configurer le réseau à l’aide de Terraform) afin d’obtenir une configuration conforme à celle du diagramme. Ce guide automatise le processus de mise en place en utilisant Terraform. Ainsi, vous pouvez facilement nettoyer votre environnement une fois cette configuration réalisée.
Vous possédez votre propre environnement OpenStack avec une configuration similaire à celle du diagramme : vous pouvez directement passer au guide «Deploy Anthos on bare metal on OpenStack » (Déployer Anthos on Bare Metal sur OpenStack).
Vous possédez votre propre environnement OpenStack avec une configuration similaire à celle du diagramme ainsi qu’Anthos on Bare Metal déjà installé : suivez le guide « Configure the OpenStack Cloud Provider for Kubernetes » (Configurer OpenStack Cloud Provider pour Kubernetes) afin d’exposer les services Kubernetes hors du réseau « tenant » en utilisant OpenStack Octavia Load Balancer.

Si vous devez commencer par le début pour ensuite suivre les quatre étapes, je vous recommande de vous rendre sur le repository GitHub et de suivre le guide “Getting started”. Il ne présuppose pas d’environnement OpenStack existant et fournit tous les éléments nécessaires pour accéder aux services fonctionnant dans un cluster Anthos – sur une VM OpenStack – au cœur d’OpenStack – à au sein d’une VM Google Compute Engine VM – dans Google Cloud. Oui, ça en fait des couches ! :)

Comment la détection de spam a amélioré notre support IT

Thu, 02 Dec 2021 10:04:00 +0000

Les équipes IT, et particulièrement celles du support et du Helpdesk, ont besoin de pouvoir suivre les problèmes rencontrés par les utilisateurs. Dans l’idéal, elles doivent aussi pouvoir observer comment ces problèmes évoluent au fil du temps, notamment lors de changements de technologies ou de stratégies.

Imaginons un instant que vous soyez responsable d’une équipe chargée de distribuer les journaux dans un quartier. Chaque membre de l’équipe se voit attribuer une bicyclette et un itinéraire pour distribuer le journal à la bonne personne. Mais les itinéraires changent. Ils changent tous les jours. C’est le chaos !

Que faire quand les itinéraires changent constamment ? Dit autrement, comment fournir l’information nécessaire lorsque les contextes évoluent en permanence ?

En informatique aussi, nous rencontrons des défis similaires. Les frameworks spécialisés dans la gestion de ces problèmes, tels qu’ITIL 4, tendent à s’appuyer sur des catalogues de services prédéfinis et figés. Dans cette approche formalisée, chaque incident résolu par les IT est pris en compte et analysé. En combinant cette double approche – référentiel des services et comptabilisation documentée des incidents gérés par l’IT – , il est non seulement possible de comprendre la cause des problèmes rencontrés par un ou plusieurs utilisateurs mais également de déterminer comment pannes et incidents peuvent affecter tout un ensemble d’employés.

Chez Google, nous n’avons pas adopté cette démarche. Tout d‘abord, parce que nous plaçons les utilisateurs au centre de tout : notre priorité numéro 1 est de s’assurer qu’ils redeviennent productifs au plus vite en cas d’incident. Ensuite, parce que - tout comme les routes et les itinéraires ne sont jamais identiques même si les objectifs demeurent - les produits services et incidents évoluent sans cesse. Dit autrement, les utilisateurs se tournent vers notre Help Desk IT avec de nouveaux problèmes tous les jours.

Notre équipe du support technique, dénommée TechStop, est le guichet unique pour tous les problèmes informatiques. Elle assure le support des utilisateurs via les chats, l’email et les canaux vidéo. Elle doit sans cesse s’adapter aux nouveaux problèmes rencontrés par les Googlers et aux nouveaux produits que ces derniers utilisent. Afin d’anticiper les problèmes qui pourraient se poser, l'équipe TechStop a besoin d'un moyen pour cataloguer les outils, applications et services utilisés chez Google.

Si l’on reprend l’analogie avec les itinéraires de livraison des journaux, nous utilisions jusqu’ici une carte approximative, plutôt qu’une carte détaillée. Elle nous fournissait une taxonomie de services « suffisamment bonne » pour la plupart des cas d’usage. Et nous en tirions de la donnée utile mais qui manquait de granularité.

En quête d’innovation

La pandémie Covid-19 nous a poussés à porter un nouveau regard sur notre gestion évolutive des problèmes, notamment sur ceux informatiques rencontrés quotidiennement par les utilisateurs. Avec le confinement massif des collaborateurs et le développement à grande échelle du télétravail, nous avions besoin de vraiment mieux comprendre où les utilisateurs rencontraient des difficultés techniques. C’est un peu comme si tout un nouveau quartier était apparu du jour au lendemain mais que l’équipe de livraison des journaux restait la même avec davantage de territoire à couvrir et une carte des routes totalement nouvelle.

Par ailleurs, des outils de productivité utilisés quotidiennement, tels que Google Meet, ont connu une adoption exponentielle, provoquant des incidents et autres problèmes de montée en charge. Les équipes en charge de ces produits se sont tournées vers TechStop, cherchant de l’aide pour établir des priorités dans une liste de demandes de correction de bugs et de nouvelles fonctionnalités qui ne cessait de s’allonger jour après jour.

À cette occasion, nous avons réalisé que notre taxonomie « suffisamment bonne » des problèmes se révélait trop imprécise pour fournir de la donnée utile. Nous pouvions certes déterminer quels produits étaient les plus affectés mais pas réellement quels incidents nos utilisateurs rencontraient sur ces produits. Pire encore, les nouvelles difficultés propres au modèle du télétravail étaient masquées par le fait que notre catalogue ne pouvait être actualisé à temps pour tenir compte des évolutions rapides de l’éventail des problèmes.

S’inspirer de la Tech des Spams

En explorant d’autres initiatives lancées par Google, l’équipe TechStop a trouvé des exemples de solutions à des problèmes similaires, à savoir détecter rapidement de nouveaux modèles dans un environnement où les données évoluent très vite.

Gmail gère le filtrage du spam pour plus d'un milliard de personnes. Et ces ingénieurs ont depuis longtemps réfléchi à la question suivante : "Comment détecter rapidement une nouvelle campagne de spam ?". Les spammeurs envoient des messages en vrac très vite avec de légères variations de contenu (bruit, fautes d'orthographe, etc.). Dans la plupart des cas, les tentatives de classification des spams ressemblent à un jeu du chat et de la souris. Les experts ont besoin de temps pour établir de nouveaux modèles, temps mis à profit par les spammeurs pour faire varier leurs techniques.

L’utilisation d'un moteur d'identification de tendances axé sur du texte non structuré - s’appuyant sur un algorithme d’agrégation basée sur la densité (Density Clustering) non supervisé - a permis à Gmail de détecter plus rapidement les campagnes de spam éphémères.

Cette technique a inspiré TechStop, sa problématique étant similaire. Des produits qui changent rapidement entraînent en effet une très grande évolutivité des pratiques, tant chez les utilisateurs que chez les professionnels de l’IT chargés d’adresser leurs problèmes. Tout comme les campagnes de spam, les tickets saisis affichaient de légères différences d'orthographe et de choix de mots mais restaient similaires dans les problèmes exprimés.

Une question de densité

Contrairement à des approches plus rigides, telles que les algorithmes d’optimisation combinatoire basés sur un partitionnement en k-moyennes (algorithmes K-means), le partitionnement basé sur la densité se révèle mieux adapté aux grands ensembles de données très hétérogènes, susceptibles de contenir des partitions aux tailles radicalement différentes. Cette flexibilité permet d’adresser l’identification des problèmes à l’échelle de l’entreprise. Une telle identification requiert en effet d’être en mesure de détecter et isoler des incidents certes petits mais néanmoins significatifs parmi un ensemble vaste et stable de signaux.

Notre implémentation utilise ClustOn, une technologie interne avec une approche hybride qui intègre un partitionnement basé sur la densité. Mais un algorithme plus éprouvé comme DBSCAN — dont l’implémentation en open source est disponible via le module de clustering du kit scikit-learn — pourrait être exploité de manière très similaire.

Une solution intermédiaire avec le ML

S’appuyant sur les techniques de partitionnement de densité de Gmail, l’équipe TechStop a développé une solution robuste pour suivre les incidents et résoudre sa problématique de taxonomie. Avec un regroupement par densité, les groupes taxonomiques sont réorganisés en groupe de tendances fournissant un index des problèmes qui surgissent en temps réel au sein de l’entreprise. Plus important encore, ces groupes émergent naturellement et dynamiquement plutôt que d’être prédéfinis de façon empirique par les équipes du support technique.

En utilisant la technologie conçue pour adresser des milliards de comptes de messagerie, nous savions que nous pourrions gérer l'ampleur des demandes d'assistance de Google. Et les solutions seraient plus flexibles qu'une taxonomie bien définie, sans compromettre pour autant la pertinence ou la granularité.

L’équipe est allée encore plus loin en modélisant le comportement des partitionnements à l’aide d’une régression de Poisson (un célèbre modèle de prédiction utilisé sur les tableaux de contingence) afin d’implémenter des mesures de détection d’anomalies et alerter les équipes opérationnelles en temps réel des pannes et autres modifications mal exécutées. Avec une équipe réduite et cette nouvelle technologie, TechStop a pu automatiquement obtenir des informations granulaires qui auraient requis toute une équipe dédiée pour analyser manuellement chaque incident et les regrouper par similitude.

Combiner Machine Learning et Opérations a transformé les données de TechStop en une base de référence précieuse pour les gestionnaires de produits et les équipes d'ingénierie en charge de comprendre les problèmes auxquels les utilisateurs font face avec leurs produits, et ce à l’échelle de l’entreprise.

Comment fonctionne la solution

Pour assembler la solution, nous avons construit un pipeline ML dénommé Support Insights. Objectif : distiller automatiquement les données sommaires des nombreuses interactions et tickets reçus. Le pipeline Support Insights combine apprentissage machine (ML), validation humaine et analyse probabiliste en une approche unique de dynamique des systèmes.

Au fur et à mesure que les données traversent ce pipeline, elles sont :

Extraites – en utilisant l’API BigQuery pour stocker, extraire, entraîner, charger et ingérer plus d’un million de données de support IT.
Traitées avec un étiquetage morpho-syntaxique, une suppression des informations personnelles et une transformation des textes en chiffres (par une méthode TF-IDF) afin de modéliser les données de support pour nos algorithmes de regroupement.
Regroupées à l’aide d’algorithmes de type K-Means exécutés par lots chronométrés avec une persistance des résultats des exécutions précédentes pour maintenir les identificateurs des regroupements et suivre le comportement de ces regroupements au fil du temps.
Notées à l’aide d’une régression de Poisson pour modéliser à la fois le comportement à long terme et à court terme des tendances, mais aussi mesurer les écarts entre les deux. Ce score d'écart est utilisé pour détecter un comportement anormal dans une tendance.
Exploitées – Les tendances avec un score anormal, autrement dit un score au-dessus d’un certain seuil, déclenchent une alerte via l’API IssueTracker. L’alerte est alors prise en charge par les équipes opérationnelles pour une analyse approfondie et un suivi de l’incident.
Rééchantillonnées par des méthodes statistiques pour estimer les impacts d’expérience utilisateur (CUJs) au sein des tendances.
Catégorisées/Cartographiées - Nous travaillons avec les équipes d'exploitation pour cartographier les impacts sur l’expérience utilisateur.

Dans un prochain billet, nous détaillerons les technologies et les méthodes que nous avons utilisées pour concrétiser ces sept étapes. Et nous expliquerons comment vous pouvez utiliser un pipeline similaire pour vos propres problématiques.

Mais avant cela, une étape préliminaire s’impose : chargez dès à présent vos données dans BigQuery et utilisez BigQuery ML pour regrouper vos données d'assistance.

Comment créer et gérer les jeux de données sous Vertex AI

Mon, 13 Sep 2021 08:00:00 +0000

Cette année, à l’occasion de Google I/O, Google Cloud a introduit Vertex AI. Cette nouvelle plateforme unifie tous nos services ML (Machine Learning) en un environnement unique, permettant de construire et gérer de façon fluide et efficace le cycle de vie des projets ML. À l’occasion d’un précédent billet, nous vous avons proposé une découverte rapide de Vertex AI et montré comment le service supporte l’intégralité de votre workflow ML – de la gestion des données jusqu’aux prédictions. Avec ce nouveau billet, nous vous proposons de découvrir comment gérer vos ensembles de données avec Vertex AI.

De plus en plus d’entreprises cherchent à faire parler leurs données et à obtenir des prédictions pour soutenir leur activité et les aider à s’aventurer sur de nouveaux marchés. Pour mener à bien ce type de démarche, elles ont souvent besoin de modèles ML personnalisés. Modèles que toutes les entreprises n’étaient jusqu’ici pas en mesure de créer ou même d’utiliser. C’est là que Vertex AI intervient en changeant la donne. Cette nouvelle plateforme Google Cloud fournit des outils optimisés pour chaque étape du flux ML, de la gestion des jeux de données aux différentes façons de construire un modèle, de l’évaluer, de le déployer et d’en tirer des prédictions. Elle s’adapte aux différents niveaux d’expertise en ML, de sorte qu’il n’est nullement nécessaire d’être un expert en Machine Learning pour tirer avantage de Vertex AI.

Types de données utilisables dans Vertex AI

Les jeux de données constituent la première étape de tout workflow ML. Elles sont nécessaires pour démarrer un apprentissage… et il en faut beaucoup !

Actuellement, Vertex AI peut gérer quatre types de jeux de données : images, tables, textes, et vidéos.

Image

Avec les jeux de données de type Image vous pouvez faire :

De la classification : en identifiant des éléments au sein de l’image.

De la détection : en identifiant la position d’un élément donné dans l’image.

De la segmentation : en assignant des étiquettes à des régions de pixels dans l’image.

Afin d’être certain que votre modèle fonctionne comme attendu en production, assurez-vous pendant la phase d’apprentissage d’utiliser des similaires à celles qu’enverront vos utilisateurs. Par exemple, si les utilisateurs sont susceptibles d’envoyer des photos de mauvaise qualité, assurez-vous de bien disposer d’images floues ou en basse résolution dans votre jeu de données d’apprentissage. N’oubliez pas d’inclure différents angles, contextes et résolutions. Nous vous recommandons d’utiliser au moins un millier d’images par étiquette, autrement dit par élément que vous voulez identifier. Il est bien entendu possible de commencer avec un minimum de 10 images par étiquette. Cependant, plus vous fournirez d’exemples, plus votre modèle sera pertinent.

Table

Les jeux de données tabulaires, les tableaux, vous permettent de réaliser :

Des régressions : pour prédire une valeur numérique.

Des classifications : pour prédire une catégorie associée à un exemple donné.

Des prévisions : pour prédire la probabilité d’évènements ou de demandes.

Les jeux de données tabulaires sous Vertex AI supportent des centaines de colonnes et des milliers de lignes.

Texte

Sous Vertex AI, les jeux de données textuels sont utilisables pour réaliser :

De la classification : attribuer une ou plusieurs étiquettes à un document entier.

De l’extraction d’entités : identifier des entités textuelles au sein d’un document telles que « trop cher » ou « bon rapport qualité/prix ».

De l’analyse de sentiments : identifier le sentiment général exprimé dans un bloc de texte afin, par exemple, de déterminer si un client est satisfait, contrarié ou frustré.

Vidéo

Les jeux de données de type vidéo sont exploitables à des fins de :

Classification : pour étiqueter des vidéos entières, des séquences ou des images.

Reconnaissance d’actions : pour identifier des actions spécifiques dans des séquences vidéo

Suivi d’objets : pour traquer des objets spécifiques dans une vidéo.

Créer et gérer des jeux de données dans Vertex AI

Après avoir étudié les différents types de données utilisables, voyons comment créer et gérer ces ensembles de données. Dans la Console Cloud, allez sur la page du tableau de bord de Vertex AI et cliquez sur Datasets, puis sur « Créer projet / Create Project ».

Imaginons que vous vouliez classer des éléments au sein d’un jeu de photos. Créez un Dataset Image et sélectionnez « Image Classification ». Importez directement les fichiers présents sur votre ordinateur. Ils seront transférés et stockés dans Cloud Storage. Ajoutez ensuite les étiquettes correspondantes, autrement dit les éléments que vous souhaitez identifier au sein de vos images. Si vous avez déjà une liste d’étiquettes, vous pouvez l’importer à partir d’un fichier CSV contenant vos URLs d’images et leurs étiquettes attachées. Si vos images ne sont pas étiquetées et que vous souhaitez réaliser un apprentissage assisté (supervisé par un humain), Vertex AI propose un service d’étiquetage des données qui simplifie le processus. Une fois les fichiers images téléchargés, vous pouvez aisément créer des étiquettes et les assigner aux images correspondantes. Vous pouvez également analyser automatiquement les images dans le jeu de données, obtenir le nombre d'images par étiquette et contrôler quelques autres propriétés.

Selon les catégories de données utilisées, les options peuvent légèrement varier. Par exemple, si vous utilisez des données tabulaires, vous pouvez envoyer un fichier CSV depuis votre ordinateur, en choisir un sur Cloud Storage ou sélectionner directement une table à partir de BigQuery. Une fois le tableau sélectionné, les données sont immédiatement disponibles pour l'analyse.

À venir prochainement

Ceci conclut notre bref aperçu de la création et de la gestion des jeux de données dans Vertex AI. Dans un prochain épisode, nous explorerons une nouvelle étape du flux ML : la construction et la formation de modèles ML.

Si cet exposé vous a intéressé, d’autres épisodes autour de « l’IA simplifiée » sont d’ores et déjà disponibles sur YouTube. Vous pouvez aussi en apprendre davantage sur Vertex AI en suivant ce lien.

Qu’est-ce que Vertex AI ?

Sun, 29 Aug 2021 11:00:00 +0000

Avec autant de données à leur disposition, de plus en plus d’organisations tirent profit du Machine Learning pour générer des prédictions éclairées et améliorer leurs applications. Néanmoins, toutes les équipes n’ont pas le même niveau de connaissance en la matière, certaines étant encore novices alors que d’autres sont plus aguerries, voire expertes. Pour accélérer l’innovation IA, les organisations ont besoin d’une plateforme à même de les aider à développer l’expertise des utilisateurs novices tout en fournissant un environnement flexible aux plus experts. C’est là que Vertex AI entre en jeu…

Annoncée récemment, la plateforme Vertex AI unifie les différents services ML de Google Cloud en un seul environnement permettant de construire et gérer de façon fluide et efficace le cycle de vie des projets ML. Elle fournit des outils optimisés pour chaque étape du flux ML, à travers différents types de modèles, adaptés aux différents niveaux d’expertise des utilisateurs.

La vidéo ci-dessous démontre comment Vertex AI prend en charge l’intégralité d’un flux de travail ML, de la gestion des données jusqu’aux prédictions.

Si cette vidéo vous a intéressée, découvrez d’autres épisodes autour de « l’IA simplifiée » où nous explorons plus en avant Vertex AI de la gestion des différents ensembles de données à la construction d’un flux de travail ML de bout en bout.

En savoir plus sur Google Cloud VMware Engine

Thu, 08 Jul 2021 20:30:00 +0000

Vous avez des workloads VMware et vous envisagez de moderniser votre système en passant au cloud pour améliorer votre agilité et réduire votre coût total de possession ? Alors VMware Engine est fait pour vous ! Il s’agit d’un service de VMware managé reposant sur une infrastructure bare metal qui exécute les piles de logiciels sur Google Cloud – de façon entièrement dédiée et physiquement isolée des autres clients.

Dans ce billet de blog, je vous présente Google Cloud VMware Engine, ses avantages, ses fonctionnalités et ses cas d’utilisation.

Avantages de Google Cloud VMware Engine

Continuité opérationnelle - Google offre un accès natif aux plates-formes VMware. Le service est vendu, fourni et pris en charge par Google : aucune entreprise tierce n’intervient. L’architecture est compatible avec vos applications existantes, ainsi qu’avec vos outils et processus d’exploitation, de sécurité, de sauvegarde, de reprise après sinistre, d’audit et de conformité.
Aucune formation nécessaire - Vos équipes peuvent utiliser leurs compétences et leurs connaissances existantes.
Agilité de l’infrastructure - Le service est fourni dans le cadre de Google Cloud et l’infrastructure peut être modulée sur demande en quelques minutes.
Sécurité - L’accès à l’environnement via Google Cloud assure une protection DDoS et une surveillance de la sécurité intégrées.
Compatibilité des politiques - Vous pouvez continuer à utiliser les outils VMware et les procédures de sécurité, les pratiques d’audit et les certifications de conformité.
Surveillance de l’infrastructure - Vous pouvez compter sur la fiabilité de notre service, grâce à une informatique réseau entièrement redondante et dédiée, fournissant jusqu’à 99,99 % de disponibilité, pour répondre aux besoins de votre pile VMware. Une surveillance de l’infrastructure est également en place, de sorte que le matériel défectueux est immédiatement remplacé.
Plate-forme hybride - Le service offre un accès à haut débit et à faible latence à d’autres services Google Cloud, tels que BigQuery, AI Platform, Cloud Storage, entre autres.
Coût réduit - Parce qu’il est conçu pour l’automatisation, l’efficacité opérationnelle et la modularité, le service est également économique !

Comment fonctionne Google Cloud VMware Engine ?

Google Cloud VMware Engine facilite la migration ou l’extension de votre environnement VMware vers Google Cloud. Voilà comment cela fonctionne : vous pouvez facilement migrer vos instances VMware vers Google Cloud, en utilisant les licences HCX incluses, via VPN cloud ou interconnexion. Le service comprend VMware vCenter, les machines virtuelles, ESXi Hosts, le stockage et le réseau sur bare metal ! Connectez-vous en toute simplicité à d’autres services de Google Cloud, tels que Cloud SQL, BigQuery, Memorystore, etc.

Vous avez accès à l’UI du service, à la facturation, ainsi qu’à la gestion des identités et des accès depuis la console Google Cloud et vous pouvez vous connecter à des services tiers de reprise après sinistre et de stockage, comme Zerto et Veeam.

Cas d’utilisation de Google Cloud VMware Engine

Abandon ou migration des centres de données - Modulez la capacité des centres de données dans le cloud et arrêtez de gérer le renouvellement du matériel. Réduisez les risques et les coûts en migrant vers le cloud, tout en continuant d’utiliser les outils et les compétences VMware que vous maîtrisez. Dans le cloud, utilisez les services de Google Cloud pour moderniser vos applications à votre rythme.
Expansion sur demande - Modulez la capacité pour répondre à des besoins imprévus, comme de nouveaux environnements de développement ou des hausses de capacité saisonnières, et conservez-la seulement tant que vous en avez besoin. Réduisez votre investissement de départ, accélérez votre vitesse d’approvisionnement et réduisez la complexité en utilisant la même architecture et les mêmes politiques dans les infrastructures sur site et dans le cloud.
Reprise après sinistre et bureaux virtuels dans Google Cloud - Des connexions à haut débit vous permettent de téléverser et de télécharger rapidement des données pour rétablir la situation après un incident.
Bureaux virtuels dans Google Cloud - Créez des bureaux virtuels (VDI) dans Google Cloud pour accéder à distance à vos données, vos applications et vos bureaux. Les réseaux à faible latence assurent un temps de réponse court, similaire à celui d’une application de bureau.
Alimentation des charges de travail et des bases de données haute performance - Vous disposez dans Google Cloud d’une architecture hyperconvergente, conçue pour exécuter vos charges de travail VMware les plus exigeantes, comme Oracle, Microsoft SQL Server, les systèmes de middleware et les bases de données noSQL haute performance.
Unification des DevOps entre VMware et Google Cloud - Optimisez l’administration VMware en utilisant les services de Google Cloud qui peuvent être appliqués à toutes vos charges de travail, sans pour autant devoir étendre votre centre de données ou modifier l’architecture de vos applications. Vous pouvez centraliser les identités, les politiques de contrôle d’accès, l’enregistrement et la surveillance pour les applications VMware sur Google Cloud.

Conclusion

Voilà, vous savez tout ! Google Cloud VMware Engine : ses cas d’utilisation, ses avantages, comment ça fonctionne. Si cet article a éveillé votre intérêt, consultez la documentation Google Cloud VMware Engine et la démo pour plus de détails.

Voici une vidéo sur Google Cloud VMware Engine :

Pour plus de #GCPSketchnote, suivez les archives GitHub et pour plus de contenu similaire sur le cloud, suivez-moi sur twitter @pvergadia et jetez un œil à thecloudgirl.dev.