Vende tu SaaS en Google Marketplace

Si tienes un Software as a Service para vender, Google Cloud Marketplace te da el canal para hacerlo. La decisión de compra del cliente se simplifica bastante, porque puede pagarlo en su factura de Google.

Este artículo es una guía general, dirigida a ingenieros, sobre cómo crear tu solución en Marketplace. Puedes ofrecer imágenes de VM o contenedores de Kubernetes, pero la mayoría de los proveedores vende Software as a Service, así que en eso nos vamos a enfocar. No buscamos ser exhaustivos ni entrar en detalle: queremos señalar los principales puntos complicados que no quedan claros de entrada en la documentación.

Lleva tus productos al mercado

En el uso habitual de Google Cloud Platform, basta con invocar APIs de la nube de acceso público. Integrarse con el sistema de vendedores de Marketplace es bastante distinto: se parece más a una integración empresarial, impulsada por conversaciones de negocio entre tu organización y Google. A nivel técnico, tus sistemas participarán en flujos bidireccionales de varios pasos junto a los propios sistemas de negocio de Google. En comparación con el núcleo de GCP, hay mucha menos información pública en la documentación y en los foros.

Antes de empezar la integración necesitas la aprobación de Google. El equipo de Engineering quedará bloqueado hasta que llegue.

Para conseguirla, el área de negocio de tu organización trabajará con Google a través del programa Partner Advantage. El proceso suele tardar varias semanas. Si trabajas con DoiT Cloud Solve, nuestros account managers acompañan a tu equipo en ese camino.

Este proceso de aprobación existe porque Google quiere mantener la calidad. Hace algunos años, Google Marketplace era un mar enorme de ofertas aparentemente abandonadas, porque los proveedores no trabajaban en la integración con los sistemas de Google. Hoy Google revisa las ofertas con rigor y solo acepta unas pocas soluciones seleccionadas, de alta calidad y alto volumen.

Sabrás que la aprobación llegó cuando tengas acceso al Producer Portal, donde se configura la solución, en https://console.cloud.google.com/producer-portal?project=PROJECT_ID

Una vez aprobada, podrás hacer llamadas a la API o usar las funciones integradas del Producer Portal para vista previa, pruebas y despliegue privado. Mientras tanto, puedes ir adelantando trabajo aprendiendo la arquitectura. Te recomiendo leer la documentación y revisar el proyecto de GitHub DoiT-Easily.

DoiT-Easily es un proyecto de código abierto que muestra cómo hacer la integración. Tiene varios contribuyentes de DoiT, pero no es un producto con soporte ni un sistema completo y listo para producción. Es, más bien, una integración funcional que sirve como ejemplo para aprender y para hacerle fork. La documentación de DoiT-Easily ofrece una buena visión general, y también puedes leer un segundo artículo del blog con una discusión más amplia.

Integrarse con la Procurement API es obligatorio; usar la Service Control (Usage) API es opcional.

La Procurement API gestiona el alta y la baja de usuarios, así como los entitlements; es decir, cuando un usuario contrata un servicio o un nivel de servicio. La API se invoca dentro de un flujo de varios pasos en el que tanto tu aplicación como los sistemas de Google deben aprobar los entitlements. Más detalles abajo.

La Service Control API sirve para reportarle a Google cuánto se consumió de un recurso facturable, y así poder cobrarle al cliente: por ejemplo, los mebibytes procesados, las horas en línea o el número de invocaciones a tu API. Como puedes ofrecer planes de precios que no dependen del consumo, en una primera implementación mínima puedes omitir esta API.

Este diagrama de arquitectura de DoiT Marketplace muestra los componentes.

Arquitectura de integración con Marketplace

Vas a integrar tanto tus aplicaciones de front-end como las de back-end. Estas se ejecutan en tu proyecto dedicado de Marketplace; cualquier otro componente en la nube que no sea parte de la integración puede correr en este proyecto o en otro distinto. Si tienes varios listings en Marketplace, usa el mismo proyecto de integración para todos.

Front-end

Tu front-end permite a los usuarios iniciar sesión, registrarse y luego contratar una suscripción a tu servicio ("entitlement"). El front-end es tu propia aplicación web; el cliente conserva tu identidad visual.

Cuando un usuario hace clic para registrarse, la página de Google Marketplace lo redirige a tu front-end (cuya URL pública registraste previamente en Marketplace). Esa solicitud incluye un token JWT firmado por Google que autentica que la referencia viene efectivamente de Google Marketplace. Tu aplicación cliente-servidor de front-end deja que el usuario se registre dentro de tus sistemas y luego avisa a Google a través de la Procurement API.

Back-end

Cuando un usuario elige un plan de precios en la UI de Google Marketplace, Google publica un evento de entitlement en Pub/Sub, que recibe tu back-end.

A partir de ahí decides si aprobar o rechazar ese entitlement (la compra). La aprobación puede ser inmediata y automática, o pasar por una intervención humana. Si va a tomar tiempo, invoca la Procurement API para mandarle un mensaje de estado al usuario. Cuando la decisión esté lista, el back-end invoca la Procurement API para aprobar o rechazar el entitlement.

Puedes ofrecer tu producto bajo varios modelos de precios, lo que repercute en la complejidad de la integración. Si lo ofreces gratis o lo cobras por suscripción mensual, no necesitas reportar el consumo. Si cobras por alguna métrica de uso —tiempo de almacenamiento, cantidad de datos procesados o cualquier métrica personalizada— tendrás que crear una integración para reportarla a la Service Control API.

Puedes saltarte el desarrollo del front-end si solo vendes mediante ofertas privadas: en una oferta privada armas el precio para un cliente concreto, en lugar de que sea él quien elija una oferta en el sitio de Google Marketplace. Eso vuelve innecesaria parte de la integración del front-end, ya que las cuentas se pueden aprobar directamente con el mensaje de Pub/Sub que Google envía a tu back-end. Una limitación de este enfoque es que, si tienes ofertas privadas, también debes tener al menos una oferta pública; aun así, puedes pedirle a Google una excepción a ese requisito. Otro reto es que vas a tener que armar algún mecanismo —normalmente una aplicación web interna— para crear y gestionar tus ofertas privadas.

Si activas la aprobación automática (una funcionalidad exclusiva de las ofertas privadas), tampoco hace falta desarrollo de back-end.

Como hay dos proyectos de dos compañías distintas —Google y la tuya— tendrás que otorgar permisos en ambas direcciones.

Tu cuenta de servicio

Crea una cuenta de servicio en tu proyecto. Regístrala en el Procurement Portal como parte de la definición de tu producto, para darle permiso de invocar la Procurement API y suscribirse a Cloud Pub/Sub para recibir los eventos de entitlement que envía Google.

El usuario que despliegue tu solución debe poder suplantar (actuar como) tu cuenta de servicio mediante el rol serviceAccountTokenCreator.

Las cuentas de servicio de Google

En el IAM de tu proyecto, otorga los roles necesarios para que las cuentas de servicio de Google accedan a tu proyecto: tres para producción (detalles aquí) y una para pruebas (ver aquí).

Una vez desarrollada y probada tu integración, Google la revisará antes del lanzamiento, así que reserva tiempo para esa etapa.