Vendi il tuo SaaS su Google Marketplace

Se hai un Software as a Service da vendere, Google Cloud Marketplace ti offre un canale per farlo. Per il cliente la decisione d'acquisto diventa molto più semplice, perché può pagare direttamente tramite la fattura Google.

Questo articolo è una guida di alto livello, pensata per gli Engineers, su come costruire la propria soluzione per il Marketplace. Sul Marketplace puoi proporre immagini di VM o container Kubernetes, ma la maggior parte dei vendor vende Software as a Service ed è proprio su questo che ci concentreremo. Non puntiamo alla completezza né al massimo dettaglio: vogliamo piuttosto mettere in evidenza i principali nodi critici che dalla documentazione non emergono in modo immediato.

Porta i tuoi prodotti sul mercato

Nell'uso ordinario di Google Cloud Platform basta invocare le API cloud disponibili pubblicamente. Integrarsi con il sistema di vendita del Marketplace è tutta un'altra storia: assomiglia a un'integrazione enterprise, guidata da trattative di business tra la tua organizzazione e Google. Sul piano tecnico, i tuoi sistemi parteciperanno a workflow bidirezionali a più passaggi con i sistemi di business di Google. Rispetto al core di GCP, le informazioni pubblicamente disponibili nella documentazione e nei forum sono molto più scarse.

Prima di avviare l'integrazione dovrai ottenere l'approvazione di Google. Fino a quel momento il team di engineering resta bloccato.

Per ottenerla, il lato business della tua organizzazione lavorerà con Google attraverso il programma Partner Advantage. Il processo richiede in genere diverse settimane. Se ti affidi a DoiT Cloud Solve, i nostri account manager affiancheranno il tuo team lungo tutto il percorso.

Questo iter di approvazione esiste perché Google vuole mantenere alta la qualità. Qualche anno fa, Google Marketplace era un mare di offerte di fatto abbandonate, perché i vendor non investivano nell'integrazione con i sistemi Google. Oggi Google seleziona le offerte con grande attenzione e accetta solo un numero ristretto di soluzioni di alta qualità e ad alto volume.

Saprai che l'approvazione è arrivata quando avrai accesso al Producer Portal, dove configurerai la tua soluzione, all'indirizzo https://console.cloud.google.com/producer-portal?project=PROJECT_ID

Una volta ricevuta l'approvazione, potrai effettuare chiamate API o usare le funzionalità integrate del Producer Portal per anteprima, test e deployment privato. Nel frattempo, puoi prepararti studiando l'architettura. Ti consigliamo di leggere la documentazione e di approfondire il progetto GitHub DoiT-Easily.

DoiT-Easily è un progetto open-source che mostra come realizzare l'integrazione. Ha diversi contributor da DoiT, ma non è un prodotto supportato né un sistema completo e production-ready. È piuttosto un'integrazione funzionante che fornisce un esempio da cui imparare e da cui partire con un fork. La documentazione di DoiT-Easily offre una buona panoramica e per una discussione di alto livello puoi consultare anche un secondo articolo.

L'integrazione con la Procurement API è obbligatoria; l'uso della Service Control (Usage) API è facoltativo.

La Procurement API gestisce la registrazione e la cancellazione degli utenti, oltre agli entitlement, ovvero il momento in cui un utente acquista un servizio o un livello di servizio. L'API viene invocata in un flusso a più passaggi in cui sia la tua applicazione sia i sistemi di Google devono approvare gli entitlement. Maggiori dettagli più avanti.

La Service Control API serve a comunicare a Google quanto è stato consumato di una risorsa fatturabile, in modo da poter addebitare l'importo al cliente: ad esempio il numero di mebibyte processati, le ore online o le invocazioni della tua API. Dato che puoi proporre piani di pricing che non tracciano l'utilizzo, per una prima implementazione minima puoi tralasciare questa API.

Questo diagramma di architettura tratto da DoiT Marketplace illustra i componenti.

Architettura di integrazione con il Marketplace

Dovrai integrare sia le applicazioni front-end sia quelle back-end. Girano nel tuo progetto Marketplace dedicato; gli altri componenti cloud non specificamente legati all'integrazione possono, a tua scelta, essere eseguiti in questo stesso progetto o in un altro. Se hai più listing sul Marketplace, usa lo stesso progetto di integrazione per tutti.

Front-end

Il tuo front-end consente agli utenti di accedere, registrarsi e poi acquistare un abbonamento al tuo servizio (l'"entitlement"). Il front-end è la tua web app: il client mantiene il tuo look and feel.

Quando gli utenti cliccano per registrarsi, la pagina di Google Marketplace li indirizza al tuo front-end (il cui URL pubblico hai registrato sul Marketplace). La richiesta include un token JWT firmato da Google, che certifica che il referral arrivi davvero da Google Marketplace. La tua applicazione client-server di front-end consente agli utenti di registrarsi all'interno dei tuoi sistemi e poi notifica Google tramite la Procurement API.

Back-end

Quando un utente seleziona un piano di pricing nella UI di Google Marketplace, Google pubblica un evento di entitlement su Pub/Sub, che il tuo back-end riceve.

Sta a te decidere se approvare o rifiutare questo entitlement (acquisto). L'approvazione può essere immediata e automatica, oppure prevedere un intervento umano. Se richiede del tempo, invoca la Procurement API per inviare un messaggio di stato agli utenti. Quando la decisione è pronta, il back-end invoca la Procurement API per approvare o rifiutare l'entitlement.

Puoi proporre il tuo prodotto con diversi modelli di pricing, che incidono sulla complessità dell'integrazione. Se offri il prodotto gratuitamente o lo fatturi tramite un abbonamento mensile, non devi riportare l'utilizzo. Se invece addebiti in base a una metrica di utilizzo come il tempo di storage, la quantità di dati processati o una metrica personalizzata, dovrai realizzare un'integrazione che la riporti alla Service Control API.

Puoi evitare lo sviluppo del front-end se vendi soltanto tramite offerte private: in un'offerta privata definisci il pricing per uno specifico cliente, invece di lasciargli scegliere un'offerta sul sito di Google Marketplace. Questo rende superflua parte dell'integrazione front-end, dato che gli account possono essere approvati direttamente tramite il messaggio Pub/Sub inviato da Google al tuo back-end. Un limite di questo approccio è che, se proponi offerte private, devi avere anche almeno un'offerta pubblica; puoi però chiedere a Google una deroga a questo requisito. Un'altra difficoltà è che dovrai predisporre un meccanismo, spesso una web app interna, per creare e gestire le tue offerte private.

Se abiliti l'auto-approvazione (una funzionalità riservata alle offerte private), in pratica non serve nemmeno lo sviluppo del back-end.

Visto che sono coinvolti due progetti appartenenti a due aziende diverse — Google e la tua — dovrai concedere permessi in entrambe le direzioni.

Il tuo service account

Crea un service account nel tuo progetto. Registralo nel Procurement Portal come parte della definizione del prodotto, per autorizzarlo a invocare la Procurement API e a sottoscrivere il topic Cloud Pub/Sub degli eventi di entitlement inviati da Google.

L'utente che effettua il deployment della tua soluzione deve poter impersonare (agire come) il tuo service account, tramite serviceAccountTokenCreator.

I service account di Google

Nell'IAM del tuo progetto, assegna i ruoli che permettono ai service account di Google di accedere al progetto: tre per la produzione (dettagli qui) e uno per il testing (vedi qui).

Dopo lo sviluppo e i test, l'integrazione dovrà passare una review da parte di Google prima del rilascio: tieni conto di questi tempi nella pianificazione.