Vous choisissez une application ou une solution dans le catalogue, et RAD la provisionne dans un projet Google Cloud — un projet qui vous appartient déjà, ou un projet que RAD crée et encadre pour vous.
Cinq étapes. Aucun code d’infrastructure à écrire.
Ces cinq étapes décrivent le cas où vous choisissez vous-même une entrée. L’autre porte d’entrée est « Concevoir une solution par IA », qui pose quatre questions en langage courant — ce que les utilisateurs doivent pouvoir faire, où cela doit tourner, dans quelle partie du monde, et quel nom lui donner — puis compose et chiffre un ensemble d’applications et pré-remplit ce même formulaire avec vos réponses. Elle découvre et chiffre ; elle ne déploie pas par une autre voie, et passe la main au formulaire complet dès que quelque chose requiert vraiment votre intervention, comme une application qui demande un identifiant.
Le devis couvre la chaîne entière, pas la seule entrée. Déployer une application implique souvent plus d’un déploiement — un socle partagé doit parfois être créé d’abord — si bien que l’estimation chiffre toute la chaîne en un seul appel et distingue ce qui est facturé immédiatement de ce qui est mesuré pendant le build. Lorsqu’un solde minimum s’applique, il est présenté comme une somme à détenir, jamais ajouté au total comme une somme dépensée.
Le catalogue compte plus de 350 options de déploiement couvrant plus de 180 applications et modules de plateforme. La plupart des applications existent en variante Cloud Run et en variante GKE.
Utilisez le formulaire de configuration, ou dites à l’assistant conversationnel ce que vous voulez : les deux écrivent les mêmes paramètres. L’assistant conversationnel est inclus avec les crédits achetés ; il propose des paramètres que vous appliquez, et refuse une région qu’un projet géré par RAD ne peut pas utiliser. Un premier déploiement se fait en mode de base ; l’ensemble complet s’ouvre lors d’une mise à jour, une fois des crédits achetés.
La confirmation chiffre toute la chaîne, y compris le projet et les services partagés que RAD crée au préalable, arrondie au montant effectivement facturé. Un déploiement en échec n’est actuellement pas facturé.
RAD exécute Terraform comme une tâche de provisionnement sur votre projet. Les journaux de build s’affichent en continu dans la console pendant l’exécution, pour suivre l’état en temps réel.
Les sorties Terraform du module sont publiées sur le déploiement. L’état, lui, ne l’est pas : il réside dans le bucket Cloud Storage de RAD, d’où les mises à jour peuvent être effectuées.
Chaque formulaire est généré à partir du Terraform du module : il accepte exactement ce que le module accepte. Trois vérifications s’exécutent avant toute mise en file d’attente.
Quand un module déclare une règle pour un champ — un format de nom, une longueur maximale — le formulaire l’applique pendant la saisie et affiche le message du module lui-même. Vous la rencontrez avant le build, et non après plusieurs minutes d’exécution.
Une valeur que le quota du projet cible ne peut pas satisfaire est refusée à l’envoi du formulaire, à la création comme à la mise à jour. Sinon, c’est un apply qui tourne plusieurs minutes avant de buter sur une limite connaissable dès le départ.
Un champ que le module marque comme sensible est masqué et écrit dans Google Secret Manager au lieu d’être stocké avec le reste de la configuration. Lors d’une mise à jour, il affiche « Configured » ou « Not configured » ; laisser vide un champ déjà configuré conserve sa valeur.
L’étape en échec est signalée, les étapes suivantes restent en file d’attente au lieu de s’exécuter sur un socle à moitié construit, et la sortie Terraform à l’origine de l’erreur s’affiche juste en dessous. L’intégralité du journal est consultable par recherche et téléchargeable.
Ouvre une recherche en mode IA de Google, déjà pré-remplie avec la sortie d’erreur de l’étape : inutile de copier une trace d’erreur dans un champ de recherche ou de la décrire de mémoire.
Ouvre un ticket d’assistance avec le contexte de l’échec joint. Une voie est instantanée et en libre-service, l’autre vous met en relation avec une personne ; le choix dépend de la lisibilité de l’erreur.
Un déploiement que vous avez annulé vous-même ne propose aucune de ces actions, puisqu’il n’y a rien à rechercher. Elles n’apparaissent que sur une étape réellement en échec.
Une rangée de SUCCESS en vert vous dit que le build a fonctionné. Elle ne vous dit pas ce qui existe désormais dans votre projet Google Cloud, et la plupart des personnes qui déploient avec RAD ne lisent pas le Terraform. Un bouton y répond.
Ouvre une explication en langage clair des ressources Google Cloud créées par le déploiement, et de leur coût de fonctionnement. Elle s’appuie sur ce que le build a réellement fait — les décomptes d’ajouts, de modifications et de destructions fournis par Terraform, et le total de chaque type de ressource — et non sur une supposition de ce que le module fait d’habitude.
Seuls les types de ressources et leur nombre sont transmis. L’ID de votre projet, les noms des ressources, les adresses e-mail des comptes de service et des utilisateurs, et toutes les valeurs configurées restent chez vous. La structure de l’ensemble suffit à répondre : les identifiants n’ont jamais besoin de circuler.
Sur les six étapes d’un build, seul l’apply a quelque chose à raconter — les autres récupèrent du code et déplacent des archives. Un bouton par étape donnerait cinq haussements d’épaules et une réponse ; il n’y en a donc qu’un, pour le build.
Un déploiement n’est pas un aller simple. Trois actions couvrent son cycle de vie, et l’une d’elles est la sortie.
Modifiez la configuration du module et réappliquez. Terraform planifie et applique la différence au lieu de tout reconstruire, et ce qui tourne déjà reste en place. Le coût de build de la mise à jour est mesuré.
Certains champs ne peuvent changer sans reconstruire ce qu’ils ont créé : en modifier un déclenche une confirmation avant toute exécution. Un administrateur peut aussi rendre ces champs non modifiables tant qu’un déploiement est actif.
Détruit les ressources cloud créées par le module, dans l’ordre des dépendances. Un projet partagé et ses services restent tant que d’autres les utilisent ; supprimer la dernière application vous demande s’il faut les retirer aussi.
Efface l’enregistrement du déploiement dans RAD et son état Terraform, sans exécuter Terraform. Dans votre propre projet, vous pouvez purger pendant que l’infrastructure continue de tourner ; dans un projet géré par RAD, la suppression doit d’abord aboutir, car ces ressources sont facturées à RAD.
Une mise à jour hérite de l’état de tout ce dont dépend le déploiement. Deux de ces états sont traités différemment, et c’est justement là tout l’intérêt.
Si ce déploiement dépend d’un autre qui a échoué, a été annulé ou a expiré, RAD les nomme dans un panneau « Démarrez d’abord ceux-ci » et laisse le bouton d’envoi désactivé jusqu’à leur réussite. La correction du prérequis lui-même n’est jamais bloquée.
La mise à jour est acceptée plutôt que refusée, puis lancée une fois le prérequis terminé. Une dépendance en cours n’est pas une erreur : elle n’est donc pas signalée comme telle, et vous n’avez pas à revenir pour soumettre à nouveau.
Un déploiement peut être annulé dans l’un ou l’autre de ces états, avant le début du build. Annuler un déploiement en attente libère aussi tout ce qui attend derrière lui : rien n’a encore été construit, il n’y a donc rien à défaire.
RAD applique une durée de conservation : lorsqu’un déploiement est resté inutilisé au-delà de cette durée, et que son propriétaire ne s’est pas connecté pendant cette période et ne détient aucun crédit acheté, RAD supprime l’enregistrement ainsi que l’état Terraform associé. Un e-mail d’avertissement est envoyé à chaque utilisateur. Les déploiements dans un projet géré par RAD sont entièrement exclus de ce nettoyage, tout comme les enregistrements des projets gérés eux-mêmes. La conservation ne supprime que des enregistrements de configuration : vos ressources Google Cloud n’en sont pas affectées et continuent de tourner.
Une solution est un ensemble d’applications déployé comme une seule unité ordonnée par dépendances. Prenez l’une des solutions préconfigurées, qui en comptent entre deux et huit, ou décrivez votre besoin et laissez RAD en composer une comptant jusqu’à douze applications.
Les membres sans dépendance sont mis en file dès la confirmation du déploiement, avec par défaut jusqu’à quatre provisionnements simultanés. Un membre qui consomme les sorties d’un autre attend que ses dépendances soient déployées avec succès.
Lorsqu’une recette de câblage est définie pour un couple producteur-consommateur, les sorties du producteur sont lues puis écrites dans la configuration du consommateur avant son déploiement. Les autres membres d’une solution reçoivent leur configuration du formulaire, et certains peuvent nécessiter une configuration manuelle après le déploiement.
Détruire un ensemble ne déclenche pas toutes les suppressions à la fois. Un socle partagé attend que les ressources qui en dépendent soient supprimées. Cet ordre empêche qu’un projet soit supprimé avant ses membres. Dans un projet créé par RAD, la suppression des services partagés peut échouer pendant que Google libère leurs adresses réseau ; la suppression du projet qui suit retire ce qui reste.
Les crédits de déploiement de tous les membres sont réservés avant le lancement du premier, si bien qu’un ensemble ne peut pas s’arrêter à mi-chemin faute de solde. Les solutions multi-modules bénéficient d’une remise.
Plutôt que de choisir une solution préconfigurée, décrivez ce que vous voulez construire. RAD parcourt le catalogue et propose une combinaison en justifiant chaque choix ; vous retenez ceux que vous voulez. L’ensemble enregistré se déploie par ce même pipeline, et RAD ne câble une paire que si une recette existe déjà pour elle.
Le câblage est défini par couple producteur-consommateur. Une configuration complémentaire peut être nécessaire une fois le déploiement terminé. Quelques exemples :
Deux cibles, avec un catalogue et un moteur identiques pour les deux.
RAD déploie en tant que compte principal dans votre projet Google Cloud, soumis aux règles de votre organisation et sans pouvoir les élargir. Toutes les régions Google Cloud vous sont accessibles ; la restriction des régions ne concerne que les projets gérés par RAD. RAD conserve et gère la configuration du déploiement, et l’état Terraform servant à déployer dans votre projet est stocké dans le bucket Cloud Storage de RAD plutôt que dans le vôtre.
Si vous n’avez pas de compte Google Cloud, RAD crée pour vous un projet dans l’un des quatre niveaux, chacun dans son propre dossier Google Cloud avec son propre jeu de règles d’administration. Sa création exige une adresse e-mail vérifiée et un solde minimum de crédits achetés propre au niveau, et vous pouvez détenir un projet géré par niveau à la fois. Les dépenses Google Cloud du projet sont imputées sur votre solde de crédits, au fil des relevés de Google.
Des dossiers séparés, c’est tout l’enjeu : un assouplissement accordé à un niveau ne peut pas déborder sur un autre. Le niveau Lab reprend délibérément les règles du niveau Sandbox, dans un dossier qui lui est propre, pour qu’une promotion ne puisse pas atteindre le projet Sandbox d’un client.
Une région dans chacune des huit zones géographiques. Chacune a été retenue comme la région disponible la moins chère de sa zone, d’après les mesures de l’API Cloud Billing Catalog et non sur sa réputation. africa-south1 est la seule région Google Cloud du continent africain. Dans votre propre projet, rien de tout cela ne s’applique — vous conservez toutes les régions proposées par Google.
Des mécanismes, pas des adjectifs. Voici les contrôles appliqués aux niveaux Sandbox et Lab, les plus stricts.
Les mêmes exigences minimales d’hygiène des identifiants s’appliquent. Une IP externe n’est permise qu’avec OS Login et Shielded VM activés ; un bucket lisible publiquement, qu’avec l’accès uniforme au niveau du bucket ; une IP publique de base de données, que via le Cloud SQL Auth Proxy, car les réseaux autorisés sont purement et simplement bloqués. Les développeurs peuvent configurer les services Google Cloud activés.
Production n’est pas le niveau sans plafond. Il reprend tels quels les quotas du niveau Développement : 48 vCPU Compute Engine et 32 vCPU Cloud Run par région, 32 Go de Memorystore Redis par région, 1 Tio d’analyse BigQuery par jour. Une valeur au-delà de l’un de ces plafonds est refusée à l’envoi du formulaire, avec le nom du plafond dépassé. Les quotas peuvent être relevés sur demande.
Le niveau Lab ne figure dans aucune liste ni sur aucun formulaire de déploiement. Seule une session d’atelier y mène : un formateur la crée depuis la vue « Sessions de lab » de « Environnements gérés », page « Solutions », et l’environnement de chaque participant a son propre projet Lab. La session se paie d’avance, par le formateur ou par chaque participant pour sa place, et les crédits inutilisés reviennent au formateur ; une place dont le chrono ne démarre jamais est remboursée à qui l’a payée. Le projet est supprimé en fin d’atelier.
Ces règles d’accès sont appliquées par le serveur à chaque requête.
Ce que vous êtes autorisé à faire est lu dans votre fiche utilisateur stockée sur le serveur, à chaque requête — jamais dans ce qu’envoie le navigateur. Un client modifié pose les mêmes questions et obtient les mêmes réponses.
Un agent du support ne voit vos déploiements que tant qu’un de vos tickets lui est attribué et reste ouvert. Le résoudre ou le fermer met fin à l’accès — immédiatement dans la console, et sous cinq minutes sur l’API ; le rouvrir le rétablit.
Les valeurs de configuration brutes et les sorties de déploiement sont exclues de l’accès du support, tout comme toute action destructrice — le support ne peut pas supprimer ce qu’il voit.
Les attributions de crédits, les ajustements et les partages de revenus génèrent un enregistrement d’audit, et les consultations inter-locataires par le support de l’état, des journaux ou de l’historique de crédits d’un déploiement sont également enregistrées.
Trois mécanismes distincts, souvent réunis sous un seul mot. Ils font des choses différentes, et l’un d’eux en fait moins qu’on ne le croit.
Vous payez les ressources nécessaires au déploiement, mesurées sur sa durée réelle selon un tarif horaire publié en crédits. Le coût est déduit une fois le build terminé : vous payez le temps réellement passé, pas une estimation. Les frais de module sont distincts, et affichés pour vérification avant confirmation.
Chaque niveau comporte un budget Google Cloud mensuel qui alerte à l’approche puis au dépassement. Ces alertes vont à nos administrateurs et à notre service financier, pas à l’utilisateur du projet, car la dépense est imputée à notre compte de facturation. Un budget notifie ; il ne refuse aucun appel d’API, et le relever n’autorise aucune dépense en plus.
RAD est conçu pour désactiver la facturation d’un projet géré quand le solde de crédits achetés du compte passe sous le minimum de son niveau, ou que son usage de Google Cloud reste impayé, et pour la rétablir une fois le solde rechargé. Il vérifie toutes les quinze minutes et ne lève que ses propres suspensions — jamais celles posées par vous ou par Google.
Mieux vaut le lire maintenant que le découvrir au bout de trois semaines.
Chaque module cible Google Cloud. Une gouvernance répartie entre plusieurs fournisseurs s’en trouve diluée, et les garde-fous décrits plus haut existent parce qu’un modèle de règles par niveau permet de les appliquer.
Si votre standard de plateforme repose sur un autre outil de provisionnement, ce que produit RAD reste lisible pour vous, mais ne sera pas natif dans votre pipeline — vous adopteriez Terraform en plus de ce que vous utilisez déjà.
Les règles d’administration des niveaux gérés par RAD peuvent interdire le déploiement de certains modules et solutions dans un projet RAD. Vous pouvez déployer ces modules dans un projet Google Cloud que vous contrôlez déjà.
Le catalogue, le moteur de déploiement et la documentation sont en place et opérationnels. Les éléments plus récents peuvent être en accès anticipé, et sont signalés comme tels sur les pages qui les décrivent. La console est disponible en anglais et en espagnol.
Si votre besoin se limite à une petite application, un hébergement mutualisé vous coûtera moins cher qu’un projet Google Cloud encadré plus des frais de module. RAD justifie son prix sur des ensembles d’applications, et sur la gouvernance que vous auriez sinon à construire.
Tout ce qui précède vaut pour tous. Ce que RAD vous apporte dépend de ce que vous déployez et à quelle fréquence — choisissez le profil le plus proche.
Un catalogue unique et vérifié, déployé en Terraform standard dans des projets que votre organisation encadre déjà.
L’ensemble dont un produit a besoin, dans votre propre projet ou dans un projet encadré créé par RAD, faute de compte GCP.
Un vrai projet et un vrai déploiement par participant, provisionnés pour une promotion en une action. En accès anticipé.
Rendez votre logiciel déployable sur Google Cloud depuis un simple formulaire, ou publiez et déployez vos propres modules Terraform.
C’est le moyen le plus rapide de vérifier tout cela par vous-même. L’inscription vous donne 300 crédits, sans moyen de paiement demandé.