RAD provisionne l’infrastructure Google Cloud en Terraform standard dans les projets de votre organisation, sous vos propres règles d’administration. Lorsque votre gouvernance l’exige, nous déployons RAD en privé dans votre organisation, votre dossier, votre compte de facturation, réservé à vos collaborateurs. C’est un accélérateur de déploiement, pas un plan de gestion, et il est en version bêta.
Ce qui se passe lorsque six équipes ont chacune besoin d’infrastructure Google Cloud au cours du même trimestre, sans moyen commun de l’obtenir.
Comptes de service, réseau, gestion des secrets : les mêmes, réécrits par une équipe qui n’a pas trouvé la dernière version ou ne s’y est pas fiée.
Six copies identiques au départ, devenues six réponses distinctes à la même question, chacune à corriger à part au moindre changement.
La sécurité revoit sans cesse le même modèle, chaque équipe apportant sa variante. L’effort de revue croît avec le nombre d’équipes, pas de modèles.
Ce qui est déployé, qui l’a déployé, ce que cela a coûté : trois questions, trois sources de vérité différentes, aucune complète à elle seule.
RAD est un catalogue d’options de déploiement Google Cloud prêtes à l’emploi et un moteur qui les provisionne. Le moteur n’héberge rien ; il écrit du Terraform dans un projet que vous désignez.
La plupart des applications existent en variante Cloud Run et GKE : le choix du modèle d’exploitation vous revient au lieu d’être fait à votre place.
Lorsque RAD déploie dans votre projet, il opère dans le périmètre des règles de votre organisation. Il ne peut pas élargir ce périmètre, et un déploiement que vos règles interdisent échoue, tout simplement.
La restriction des régions ne s’applique qu’aux projets que RAD crée et gère. Dans votre propre projet, vous conservez toutes les régions proposées par Google, et vos règles de résidence des données s’appliquent sans changement.
Le mode basique ne demande que les variables réellement obligatoires, et un premier déploiement est toujours en mode basique. L’ensemble complet des variables du module s’ouvre lors d’une mise à jour, dès que votre solde de crédits couvre son coût estimé, pour les cas où une valeur par défaut ne convient pas. Dans un projet géré par RAD, les quelques paramètres non pris en charge sont masqués plutôt que d’échouer à l’application.
La question de la propriété, et la seule chose que vous n’obtenez pas : c’est RAD qui détient l’état Terraform.
Le backend Terraform de chaque déploiement pointe vers le bucket Cloud Storage de RAD, pas vers le vôtre, et le produit ne permet pas aujourd’hui de télécharger l’état. Le projet, les ressources et le code source du module vous appartiennent ; le fichier d’état qui les suit est détenu par nous.
Si vous partez, vous conservez l’infrastructure en service dans votre propre projet, sous vos propres règles. Ce qu’il vous faudrait reconstruire, c’est l’état. Pour une équipe qui garde chaque ressource de production dans son propre fichier d’état, la réponse aujourd’hui est non.
RAD ne le conserve pas indéfiniment. Au terme de la période de conservation, l’enregistrement d’un déploiement inactif, dont le propriétaire ne s’est pas connecté et ne détient aucun crédit acheté, est supprimé avec son état, après l’envoi d’un e-mail d’avertissement. Vos ressources ne sont pas touchées ; seul l’enregistrement de RAD disparaît.
RAD provisionne l’infrastructure, puis se retire. Rien de ce que touchent vos utilisateurs ne pointe vers nous : une panne chez nous n’est pas une panne chez vous.
Les ressources continuent de tourner : elles ont été créées dans votre projet par du Terraform ordinaire. Le fichier d’état ne vous suit pas, donc reprendre ces ressources en code représente un vrai travail.
Quiconque examinera ensuite votre parc (audit interne, revue technique d’un acquéreur ou nouveau responsable plateforme) lira du Terraform qu’il connaît déjà, et non notre abstraction.
Le catalogue contient aussi plus de 60 solutions préconfigurées, qui définissent plus de 280 déploiements membres répartis en douze catégories.
Une solution regroupe de deux à huit applications. Les membres sans prérequis se provisionnent jusqu’à quatre à la fois ; celui qui consomme les sorties d’un autre attend ce déploiement, et non toute une étape.
Pour une paire producteur-consommateur câblée, RAD est conçu pour copier les sorties Terraform du producteur dans la configuration du consommateur avant son déploiement. Sinon, les connexions vous reviennent.
Un projet ou un service partagé est détruit après ce qu’il héberge, pas avant. Un mauvais ordre transforme un démantèlement propre en une série de destructions échouées et de ressources orphelines.
Votre propre projet est l’option par défaut. L’alternative s’adresse aux équipes de votre organisation qui n’en ont pas : une preuve de concept, une promotion de formation, un contributeur externe. Chaque niveau est un dossier Google Cloud distinct doté de ses propres règles, si bien qu’elles ne peuvent pas diverger d’un niveau à l’autre.
Le niveau se choisit au moment du déploiement, et c’est le niveau — non le module — qui détermine les règles d’administration et les plafonds de quota dont hérite le projet. Le minimum de crédits achetés exigé pour ce niveau est indiqué dans le même panneau.
Le niveau Production est encadré et limité par des quotas : il reprend les plafonds du développement. Une charge de travail nécessitant plus de 48 vCPU ou 32 Go de Redis dans une même région est refusée, mais chaque plafond peut être relevé par projet sur demande. Votre propre projet conserve vos propres quotas.
Un projet géré par RAD se déploie dans une région de chacune des huit zones géographiques : us-central1, europe-north2, northamerica-south1, me-west1, africa-south1, asia-east1, australia-southeast2 et southamerica-west1. Chacune est la région disponible la moins chère de sa zone.
Une courte liste fait exception, chaque option étant signalée sur la page du catalogue avec la raison pour laquelle elle ne peut pas y être déployée. Tout le reste peut être déployé dans les deux cas.
Le minimum est fixé par niveau, en fonction de ce que ce niveau permet. Les crédits mensuels gratuits ne comptent pas.
Une alerte prévient lorsque les dépenses approchent puis dépassent le montant fixé. Elle ne bloque aucun appel d’API ; le mécanisme de contrôle est distinct.
Nous ne détenons aucune certification de sécurité ni attestation d’audit tierce. Ce qui suit décrit le mécanisme lui-même, assez précisément pour que votre évaluateur puisse en juger.
Ce qu’un appelant est autorisé à faire est déterminé à partir de son enregistrement utilisateur stocké, jamais de ce qu’envoie le navigateur. Un client ne peut pas revendiquer un rôle qu’il ne détient pas.
Un agent du support ne voit les déploiements d’un client que tant qu’un ticket qui lui est assigné reste ouvert. Résoudre ou fermer le ticket met fin à cet accès ; le rouvrir le rétablit.
Les valeurs de configuration brutes et les sorties de déploiement ne sont jamais lisibles par le support, et aucune action détruisant l’infrastructure ne lui est ouverte. Consulter un déploiement hors des limites de son locataire génère un enregistrement d’audit.
Une attribution de crédits, un prélèvement ou un ajustement manuel est consigné comme entrée d’audit, pas seulement comme ligne de journal.
Si le solde de crédits achetés d’un utilisateur passe sous le minimum du niveau du projet, ou si l’utilisation de Google Cloud reste impayée, RAD est conçu pour désactiver la facturation Google Cloud du projet géré qu’il a créé, puis la rétablir une fois le solde rechargé. Il ne lève que les suspensions qu’il a lui-même appliquées.
Chacun de ces points est un paramètre d’administration de la plateforme, pas un développement sur mesure. Une instance privée, c’est le même RAD, pointé sur votre périmètre.
L’instance est liée à l’ID de votre organisation Google Cloud. Le périmètre peut être restreint à un seul dossier, que les opérations ne dépassent jamais, ou couvrir toute l’organisation.
Le compte de facturation associé aux ressources est le vôtre. Rien de ce que RAD provisionne pour vous n’atterrit sur le nôtre, et les dépenses apparaissent là où vous les suivez déjà.
Le mode privé limite l’accès aux seuls utilisateurs internes. L’instance n’accepte aucune inscription publique : les seuls comptes sont ceux que vous avez créés.
Les modules ne se gèrent que dans GitHub et se synchronisent automatiquement, la publication et la suppression depuis la console étant désactivées. Votre processus de revue devient la seule porte d’entrée.
« Enforce Update Safe » rend en lecture seule, tant qu’un déploiement est actif, tout champ qu’un module n’a pas marqué « update-safe ». Le modifier implique alors de détruire et redéployer, délibérément.
La durée de conservation, le délai de grâce avant suppression définitive, le nettoyage des orphelins et l’avertissement des utilisateurs avant suppression sont tous définis par vos administrateurs.
Ce qui n’existe pas encore, c’est un installateur en libre-service. Un déploiement privé est une mission d’accompagnement : nous le mettons en place avec vous, dans votre organisation et sous votre revue.
Chaque déploiement est imputé sur un solde de crédits, et chaque prélèvement est une ligne que vous pouvez consulter et exporter. L’unité est le crédit : 10 crédits = 1 $.
De 40 à 300 crédits selon la complexité du module, et aucun pour quelques options d’infrastructure. L’étape de confirmation chiffre toute la chaîne, y compris le projet et les services partagés que RAD met en place.
Calculé sur la durée réelle du provisionnement, à un tarif horaire publié en crédits. La plupart des modules se déploient en bien moins d’une demi-heure et, dans la version actuelle, un déploiement échoué n’est pas facturé du tout.
L’historique des crédits est détaillé par transaction et exportable : une équipe plateforme peut imputer les dépenses à l’équipe ou au projet concerné, sans les reconstituer à partir de la seule facturation cloud.
Une solution réserve son coût en une seule somme pour tous ses membres, avec une remise groupée qui augmente avec sa taille : 15 % de trois à quatre modules, 20 % de cinq à six, 25 % à partir de sept.
Le catalogue n’est pas un ensemble fermé. Le circuit de publication qui intègre le module d’un partenaire fonctionne aussi pour les vôtres.
Un administrateur attribue le rôle « Partenaire », et vous connectez un dépôt GitHub contenant vos propres modules via l’application RAD Module Sync. Ils se synchronisent à chaque push, et RAD affiche le même formulaire guidé que vos équipes utilisent déjà pour les modules du catalogue.
Un modèle interne et un module du catalogue sont déployés, facturés et consignés de la même manière, car deux systèmes produisent deux réponses à la question « qu’est-ce qui est déployé ? ».
Un module que vous ne marquez pas comme public reste réservé au compte qui l’a publié et aux personnes qu’il désigne par e-mail. Si un module doit être visible de toute votre organisation et de personne d’autre, abordez-le avec nous lors d’une évaluation plutôt que de le supposer acquis.
Mieux vaut le lire maintenant que le découvrir en troisième semaine d’évaluation.
Tous les modules du catalogue ciblent Google Cloud. Si vous cherchez une console unique couvrant plusieurs fournisseurs cloud, RAD n’est pas cela.
Si votre organisation a standardisé un autre langage d’infrastructure et refuse l’état Terraform comme artefact, le catalogue n’a rien à vous offrir.
Le catalogue, le moteur et la documentation sont en place et opérationnels. Les fonctionnalités plus récentes, comme les sessions d’atelier, sont en accès anticipé.
RAD se rentabilise sur de nombreux déploiements et équipes. Pour une petite application qu’un ingénieur maintient à vie, écrire vous-même le Terraform coûte moins cher.
Un module, dans un projet qui vous appartient déjà, examiné par la personne qui devrait le valider.
Choisissez-en un qui porte vos vraies règles d’administration. Si une règle bloque le déploiement, c’est que l’évaluation fonctionne : RAD ne peut pas élargir votre périmètre.
Ouvrez les ressources dans votre propre console, avec le guide de configuration, les sorties et le journal de build que RAD publie. Jugez ce qui a été créé comme vous jugeriez le travail rendu par une équipe.
C’est dans l’ordre du démantèlement que l’orchestration d’un parc se révèle réelle ou non. Vérifiez que le socle partagé part en dernier.
Exportez l’historique des crédits de la semaine et vérifiez qu’il concorde avec ce que vous avez vu déployé.
Tout ce qu’un évaluateur demande habituellement se trouve sur ce site ou dans la documentation. Rien n’est derrière un formulaire.
Le parcours de déploiement de bout en bout : orchestration du parc, ordre de démantèlement, et les deux cibles de déploiement de RAD.
PlateformePlus de 350 options de déploiement, plus de 180 applications et modules de plateforme, et ceux exclus d’un projet géré.
ModulesPlus de 340 ateliers pratiques, plus de 520 guides de configuration et plus de 40 guides de certification, sur 7 parcours.
Ouvrir la documentationPropriété, dépendance, ce qu’une alerte de dépenses ne fait pas, et qui peut voir vos déploiements, et quand.
FAQLe même argumentaire en un seul document, à diffuser auprès de ceux qui ne liront pas un site web : modèle d’exploitation et coûts.
Lire la brochureIndiquez-nous le projet dans lequel vous souhaitez déployer et le modèle que vos équipes réécrivent sans cesse. Nous vous aiderons à déployer un module dans l’un de vos projets dès cette semaine.