Venda seu SaaS no Google Marketplace

Se você tem um Software as a Service para vender, o Google Cloud Marketplace é um caminho. A decisão de compra do cliente fica muito mais simples, porque ele paga direto na fatura do Google.

Este artigo é um guia de alto nível para engenheiros que vão criar uma solução no Marketplace. Dá para oferecer imagens de VM ou containers Kubernetes no Marketplace, mas a maioria dos fornecedores vende Software as a Service, e é nisso que vamos focar. Não buscamos cobrir tudo nem entrar em detalhes, mas sim apontar os principais pontos de dificuldade que não ficam claros de imediato na documentação.

Leve seus produtos ao mercado

No uso comum do Google Cloud Platform, você simplesmente chama APIs de nuvem disponíveis publicamente. Integrar com o sistema de vendedores do Marketplace é bem diferente: parece mais uma integração corporativa, conduzida por conversas de negócios entre a sua organização e o Google. Tecnicamente, seus sistemas vão participar de fluxos bidirecionais e em várias etapas com os próprios sistemas de negócios do Google. Em comparação ao GCP em si, há muito menos informação pública na documentação e em fóruns abertos.

Antes de começar a integração, você vai precisar da aprovação do Google. O time de engenharia fica bloqueado até que ela saia.

Para conseguir a aprovação, a área de negócios da sua organização trabalha com o Google pelo programa Partner Advantage. O processo costuma levar várias semanas. Se você for cliente do DoiT Cloud Solve, nossos account managers acompanham seu time nesse caminho.

Esse processo de aprovação existe porque o Google quer manter a qualidade. Há alguns anos, o Google Marketplace era um mar de ofertas aparentemente abandonadas, já que os fornecedores não investiam na integração com os sistemas do Google. Hoje, o Google avalia as ofertas com rigor e aceita só algumas soluções selecionadas, de alta qualidade e alto volume.

Você vai saber que a aprovação saiu quando tiver acesso ao Producer Portal, onde configura sua solução, em https://console.cloud.google.com/producer-portal?project=PROJECT_ID

Depois que a aprovação chegar, você poderá fazer chamadas de API ou usar a funcionalidade nativa do Producer Portal para preview, testes e implantação privada. Até lá, vale se preparar estudando a arquitetura. Sugiro ler a documentação e estudar o projeto no GitHub DoiT-Easily.

O DoiT-Easily é um projeto open source que mostra como fazer a integração. Tem vários colaboradores da DoiT, mas não é um produto com suporte oficial nem um sistema completo, pronto para produção. É, antes, uma integração funcional que serve de exemplo para você estudar e dar fork. A documentação do DoiT-Easily traz uma boa visão geral, e você também pode conferir um segundo post no blog com uma discussão de alto nível.

A integração com a Procurement API é obrigatória; já o uso da Service Control (Usage) API é opcional.

A Procurement API cuida do cadastro e do cancelamento de usuários, além dos entitlements — ou seja, do momento em que um usuário compra um serviço ou nível de serviço. A API é chamada num fluxo de várias etapas, em que tanto a sua aplicação quanto os sistemas do Google precisam aprovar os entitlements. Mais detalhes a seguir.

A Service Control API serve para reportar ao Google quanto de um recurso cobrado foi usado, para que o cliente possa ser faturado: por exemplo, número de mebibytes processados, horas online ou número de chamadas à sua API. Como dá para oferecer planos de preço que não dependem de uso, você pode pular essa API numa primeira implementação enxuta.

Este diagrama de arquitetura do DoiT Marketplace mostra os componentes.

Arquitetura de integração com o Marketplace

Você vai integrar tanto suas aplicações de front-end quanto as de back-end. Elas rodam no seu projeto dedicado ao Marketplace; quaisquer outros componentes de nuvem que não sejam dedicados à integração podem rodar nesse mesmo projeto ou em outro, como preferir. Se você tiver várias listagens no Marketplace, use esse mesmo projeto de integração para todas.

Front-end

Seu front-end permite que os usuários façam login, se cadastrem e, em seguida, comprem uma assinatura do seu serviço ("entitlement"). O front-end é o seu próprio web app; o cliente vê a sua identidade visual.

Quando o usuário clica para se registrar, a página do Google Marketplace o envia para o seu front-end (cuja URL pública você registrou no Marketplace). Essa requisição inclui um token JWT assinado pelo Google para autenticar que a indicação realmente veio do Google Marketplace. Seu app cliente-servidor de front-end permite que os usuários se cadastrem nos seus sistemas e depois notifica o Google pela Procurement API.

Back-end

Quando o usuário seleciona um plano de preço na interface do Google Marketplace, o Google publica um evento de entitlement no Pub/Sub, que o seu back-end recebe.

Aí você decide se aprova ou rejeita esse entitlement (compra). A aprovação pode ser imediata e automática ou ter intervenção humana. Se for demorar um pouco, chame a Procurement API para enviar uma mensagem de status ao usuário. Quando a decisão estiver pronta, o back-end chama a Procurement API para aprovar ou rejeitar o entitlement.

Você pode oferecer seu produto em vários modelos de preço, e isso impacta na complexidade da integração. Oferecer o produto de graça ou cobrar por assinatura mensal significa que você não precisa reportar uso. Já se você cobrar por uma métrica de uso como tempo de armazenamento, volume de dados processados ou qualquer métrica customizada, vai precisar criar uma integração para reportar isso à Service Control API.

Você pode dispensar o desenvolvimento de front-end se vender apenas por ofertas privadas: numa oferta privada, você cria o preço para um cliente específico, em vez de deixar que ele escolha uma oferta no site do Google Marketplace. Isso elimina parte da integração de front-end, já que as contas podem ser aprovadas diretamente pela mensagem do Pub/Sub que o Google envia ao seu back-end. Uma limitação dessa abordagem é que, se você tem ofertas privadas, precisa ter também pelo menos uma oferta pública; mesmo assim, dá para pedir uma dispensa ao Google. Outro desafio é que você vai precisar criar algum mecanismo — em geral um web app interno — para montar e disponibilizar suas ofertas privadas.

Se você habilitar a aprovação automática (um recurso disponível só para ofertas privadas), o desenvolvimento de back-end também deixa de ser necessário, na prática.

Como há dois projetos em duas empresas envolvidos — o Google e o seu —, você vai precisar conceder permissões nas duas direções.

Sua service account

Crie uma service account no seu projeto. Registre essa service account no Procurement Portal, como parte da definição do seu produto, para dar a ela permissão de chamar a Procurement API e se inscrever no Cloud Pub/Sub para receber os eventos de entitlement enviados pelo Google.

O usuário que implanta sua solução precisa conseguir representar (atuar como) a sua service account, usando serviceAccountTokenCreator.

Service accounts do Google

No IAM do seu projeto, conceda papéis para que as service accounts do Google acessem seu projeto: três para produção (detalhes aqui) e uma para testes (veja aqui).

Depois de desenvolvida e testada, sua integração ainda precisa passar por uma revisão do Google antes do lançamento — então reserve tempo para isso.