Vendez votre SaaS sur Google Marketplace

Si vous avez un Software as a Service à commercialiser, Google Cloud Marketplace vous offre un canal de vente. La décision d'achat des clients s'en trouve grandement simplifiée, puisqu'ils peuvent régler via leur facture Google.

Cet article propose aux ingénieurs un guide synthétique pour créer leur solution Marketplace. Vous pouvez proposer des images de VM ou des conteneurs Kubernetes sur le Marketplace. Cependant, la plupart des éditeurs commercialisent du Software as a Service ; c'est donc sur ce modèle que nous nous concentrerons. Sans viser l'exhaustivité ni le détail, nous mettrons en lumière les principales difficultés qui ne ressortent pas immédiatement de la documentation.

Mettez vos produits sur le marché

Dans une utilisation classique de Google Cloud Platform, il suffit d'invoquer des API cloud accessibles publiquement. L'intégration au système de vente du Marketplace est très différente : elle s'apparente à une intégration entreprise, pilotée par des échanges commerciaux entre votre organisation et Google. Techniquement, vos systèmes participeront à des workflows bidirectionnels en plusieurs étapes avec les systèmes métier de Google. Comparé au cœur de GCP, la documentation et les forums publics offrent beaucoup moins d'informations.

Avant de démarrer l'intégration, vous devrez obtenir l'approbation de Google. L'équipe d'ingénierie restera bloquée tant que cette approbation n'aura pas été reçue.

Pour l'obtenir, le côté business de votre organisation collaborera avec Google via le programme Partner Advantage. Le processus prend généralement plusieurs semaines. Si vous travaillez avec DoiT Cloud Solve, nos account managers accompagneront votre équipe tout au long de cette démarche.

Cette procédure d'approbation traduit la volonté de Google de maintenir un haut niveau de qualité. Il y a quelques années, Google Marketplace ressemblait à un vaste océan d'offres apparemment abandonnées, les éditeurs n'investissant pas dans l'intégration aux systèmes Google. Aujourd'hui, Google examine rigoureusement les offres et n'accepte qu'un nombre restreint de solutions de haute qualité et à fort volume,

Vous saurez que l'approbation est arrivée lorsque vous aurez accès au Producer Portal, où vous configurez votre solution, à https://console.cloud.google.com/producer-portal?project=PROJECT_ID

Une fois l'approbation reçue, vous pourrez effectuer des appels d'API ou utiliser les fonctionnalités intégrées du Producer Portal pour la prévisualisation, les tests et le déploiement privé. En attendant, vous pouvez vous préparer en assimilant l'architecture. Je vous suggère de lire la documentation et de vous inspirer du projet GitHub DoiT-Easily.

DoiT-Easily est un projet open-source qui illustre la marche à suivre pour réaliser l'intégration. Il compte plusieurs contributeurs de DoiT, mais ne constitue ni un produit pris en charge ni un système complet prêt pour la production. Il s'agit plutôt d'une intégration fonctionnelle servant d'exemple à étudier et à forker. La documentation de DoiT-Easily en donne une bonne vue d'ensemble, et vous pouvez également consulter un second article de blog pour une discussion synthétique.

L'intégration à l'API Procurement est obligatoire ; l'utilisation de l'API Service Control (Usage) est facultative.

L'API Procurement gère l'inscription et la résiliation des utilisateurs, ainsi que les entitlements — c'est-à-dire le moment où un utilisateur achète un service ou un niveau de service. Elle est invoquée dans un flux à plusieurs étapes au cours duquel votre application et les systèmes Google doivent tous deux approuver les entitlements. Plus de détails ci-dessous.

L'API Service Control permet de signaler à Google la quantité d'une ressource facturée qui a été consommée, afin de pouvoir facturer le client : par exemple, le nombre de mébioctets traités, les heures en ligne ou le nombre d'invocations de votre API. Comme vous pouvez proposer des plans tarifaires qui ne suivent pas l'usage, cette API peut être laissée de côté pour une première implémentation minimale.

Ce diagramme d'architecture issu de DoiT Marketplace présente les composants.

Architecture d'intégration Marketplace

Vous intégrerez à la fois vos applications front-end et back-end. Celles-ci s'exécutent dans votre projet Marketplace dédié ; tout composant cloud autre que ceux dédiés à l'intégration peut éventuellement s'exécuter dans ce projet ou dans un autre. Si vous disposez de plusieurs annonces Marketplace, utilisez le même projet d'intégration pour toutes.

Front-end

Votre front-end permet aux utilisateurs de se connecter, de s'inscrire, puis d'acheter un abonnement à votre service (entitlement). Le front-end est votre propre application web ; le client adopte votre identité visuelle.

Lorsque les utilisateurs cliquent pour s'inscrire, la page Google Marketplace les redirige vers votre front-end (dont l'URL publique a été enregistrée auprès de Marketplace). Cette requête inclut un jeton JWT signé par Google permettant d'authentifier que la redirection provient bien de Google Marketplace. Votre application client-serveur front-end permet aux utilisateurs de s'inscrire dans vos systèmes, puis notifie Google via l'API Procurement.

Back-end

Lorsqu'un utilisateur sélectionne un plan tarifaire dans l'interface Google Marketplace, Google publie un événement d'entitlement sur Pub/Sub, que votre back-end reçoit.

Vous décidez ensuite d'approuver ou de rejeter cet entitlement (achat). L'approbation peut être immédiate et automatique, ou nécessiter une intervention humaine. Si elle prend du temps, invoquez l'API Procurement pour envoyer un message de statut aux utilisateurs. Une fois la décision prise, le back-end invoque l'API Procurement pour approuver ou rejeter l'entitlement.

Vous pouvez proposer votre produit selon plusieurs modèles tarifaires, ce qui influe sur la complexité de votre intégration. Proposer votre produit gratuitement ou facturer un abonnement mensuel signifie que vous n'avez pas besoin de remonter l'usage. Si vous facturez selon une métrique d'usage telle que le temps de stockage, le volume de données traitées ou toute métrique personnalisée, vous devrez créer une intégration pour la remonter à l'API Service Control.

Vous pouvez faire l'impasse sur les développements front-end si vous ne vendez qu'au travers d'offres privées : dans une offre privée, vous définissez la tarification pour un client précis, plutôt que de le laisser choisir une offre sur le site Google Marketplace. Une partie de l'intégration front-end devient ainsi superflue, car les comptes peuvent être approuvés directement via le message Pub/Sub envoyé par Google à votre back-end. Une limite de cette approche : si vous proposez des offres privées, vous devez également proposer au moins une offre publique ; vous pouvez toutefois demander une dérogation à Google. Autre défi : vous devrez mettre en place un mécanisme, souvent une application web interne, pour créer et diffuser vos offres privées.

Si vous activez l'approbation automatique (une fonctionnalité réservée aux offres privées), le développement back-end n'est pas vraiment nécessaire non plus.

Étant donné que deux projets relevant de deux entreprises — Google et la vôtre — sont impliqués, vous devrez accorder des permissions dans les deux sens.

Votre compte de service

Créez un compte de service dans votre projet. Enregistrez-le dans le Producer Portal au titre de la définition de votre produit, afin de lui accorder l'autorisation d'invoquer l'API Procurement et de s'abonner à Cloud Pub/Sub pour les événements d'entitlement envoyés par Google.

L'utilisateur qui déploie votre solution doit pouvoir endosser l'identité de votre compte de service (agir en son nom), via serviceAccountTokenCreator.

Les comptes de service de Google

Dans l'IAM de votre projet, attribuez des rôles permettant aux comptes de service de Google d'accéder à votre projet : trois pour la production (détails ici) et un pour les tests (voir ici)

Une fois votre intégration développée et testée, elle devra être examinée par Google avant la mise en production : prévoyez du temps pour cette étape.