Atribuyendo los costos en un SaaS: Cómo alinear la tecnología con los negocios

Por Roi Ravhon, Co-Fundador y CEO — Finout
Por Oren Reuveni, Arquitecto Principal de Soluciones — AWS SaaS Factory

Un reto clave que enfrentan los proveedores de software como servicio (SaaS) es comprender el perfil de costos de su entorno SaaS y de los clientes dentro de él.

Medir el costo de cada tenant en el sistema, comprender la rentabilidad de las características del producto y medir con precisión el margen en una solución SaaS son ejemplos de habilidades que son críticas para el éxito de una solución SaaS.

Se trata de medidas centrales para refinar el modelo de precios, la arquitectura de la solución (en términos de costo) e influir en la estrategia de una organización.

El punto más importante aquí, tal vez, es que estas capacidades permiten a los proveedores de SaaS discutir el costo de una manera clara y basada en datos.

En nuestra experiencia, la obtención de visibilidad sobre la actividad del tenant y el uso de recursos en dichos entornos permite a los proveedores de SaaS tomar decisiones empresariales y técnicas informadas, evolucionar sus productos y priorizar su hoja de ruta. Para permitir una visibilidad en profundidad, los proveedores de SaaS necesitan atribuir el uso de los recursos de infraestructura a los tenants individuales (ya sea parcial o completamente), y generar insights a partir de estos datos.

En este post, revisaremos los desafíos para obtener visibilidad detallada relacionada con los costos en un producto SaaS de múltiples tenants, discutiremos los posibles métodos para resolverlos y explicaremos el valor de esta visibilidad en los entornos SaaS.

Asignación de costos en entornos SaaS

Entender la atribución de costos de una solución SaaS de múltiples tenants puede ser un reto. La arquitectura de la solución y las diferentes características del producto generalmente se construyen sobre múltiples servicios y recursos que atienden a múltiples tenants, cada uno de los cuales puede tener su propio modelo de precios.

Un ejemplo típico en un entorno de Amazon Web Services (AWS) es una solución SaaS que almacena datos de tenants en Amazon Simple Storage Service (Amazon S3) y utiliza Amazon DynamoDB para administrar el perfil de usuario junto con un clúster de contenedores como la solución de cómputo que genera informes para los usuarios.

El hecho de que las soluciones SaaS multitenants utilicen entornos compartidos (pool) para atender a múltiples tenants agrega un desafío único para implementar esta capacidad.

Figura 1 — Arquitectura típica de soluciones SaaS.

El nivel de visibilidad es clave para optimizar y gestionar los costos óptimos. Cuanto menos granular y menos precisa tenga un proveedor de SaaS el consumo individual del tenant, menor será el valor que obtendrán de sus métricas de costos.

La visibilidad que no es lo suficientemente granular (por ejemplo, no poder rastrear la interacción de los tenants individuales como la cantidad de datos de cada tenant en S3) puede causar brechas significativas. Las decisiones se pueden tomar en base a estimaciones más que a datos, y la medición del uso del producto se basa en la aproximación.

El modelo de precios del cliente podría basarse en estimaciones, como la visibilidad actual sin embargo esta situación impacta la efectividad de un proveedor de SaaS en términos de operación e impide tener un análisis detallado de costos y capacidades de optimización. El resultado es la capacidad limitada para determinar los elementos de costo de manera precisa.

Ganando visibilidad sobre patrones de consumo de tenants

Al operar una solución de múltiples tenants, los proveedores de SaaS desean medir la cantidad de consumo de recursos y el patrón de uso de cada tenant (y a veces incluso de usuarios individuales dentro de un tenant). Esto ayuda a calcular el costo por tenant, a identificar tendencias y gastos generales en el sistema (para los tenants y los Niveles/Planes por ejemplo), y a crear el modelo de precios óptimo para su solución.

Según el AWS Well-Architected SaaS Lens, la práctica más básica para la medición del consumo de tenants es aproximar el consumo de tenants con la actividad que este representa en la solución. Si bien este es un buen punto de partida y permite a los proveedores de SaaS comprender y optimizar el costo de la solución y el modelo de precios solo con una precisión limitada. Pero para crear un perfil más preciso de consumo de tenants, los proveedores de SaaS necesitan invertir en crear una estrategia más granular.

El siguiente paso es construir una visión enriquecida del consumo de los tenants, que ayuda a los proveedores de SaaS a medir el uso de componentes y a atribuirlo a cada tenant en el entorno. Esto crea una estimación detallada del consumo de recursos del tenant. También proporciona información sobre el patrón de uso de cada uno, y el uso real y la utilización de cada característica del producto, lo que puede afectar directamente las decisiones relacionadas con los costos y los modelos de precios.

Según lo expuesto en el blog post ¿Qué es una Métrica Unitaria?, calcular el costo unitario es la forma de entender cuánto paga un proveedor de SaaS por cada “unidad de producción”. Una unidad de producción puede ser el precio de cada unidad de producto que una empresa esté fabricando, como un asiento, evento, transacción, stream, o reporte.

Al usar este método, los proveedores de SaaS pueden adquirir conocimientos importantes sobre los patrones de uso en su solución, medirlos contra este precio y asegurarse de que puedan comprender mejor sus costos mientras mantienen un margen bruto sano y estable.

Dicho esto, en escenarios de la vida real, al utilizar múltiples servicios —ya sea dentro de AWS y fuera del mismo— el precio unitario puede ser inexacto.

Si bien un proveedor de SaaS puede pensar que el precio del recurso para un mes determinado es constante, puede haber una disminución en el uso de la base de datos, por ejemplo, que es ligeramente mayor que un aumento en la cantidad de transmisión de datos. No obstante, el costo de la transmisión está aumentando a una tasa no proporcional al precio unitario. Pueden pasar meses hasta que descifren ese “costos ocultos”.

Para resolver esto, los proveedores de SaaS necesitan crear una mejor granularidad y distinguir entre cada recurso, como la base de datos y los costos unitarios separados de flujo.

Figura 2 — Definir KPI y unidades de medida.

Atribuyendo costos del tenant

Para crear la conexión entre el consumo de tenants y el uso de recursos, los proveedores de SaaS necesitan un mecanismo que correlacione el consumo de tenants con los costos. Aquí algunos ejemplos de cómo lograr esto:

• Construyendo este mecanismo por su cuenta. Los proveedores de SaaS pueden construir el mecanismo que correlaciona los datos, y luego aprovechar herramientas de inteligencia empresarial (BI) como Tableau para analizarlo y generar insights.
• Aprovechar AWS Application Cost Profiler para facilitar este proceso. Esta herramienta recopila metadatos del tenant e informa el desglose por hora del costo por tenant de manera diaria y mensual.
• Utilizar una solución de socio de AWS como:
  • Finout: Una solución SaaS que se integra con AWS, almacenes de datos y plataformas de observabilidad. Finout combina métricas de negocio con su costo, dividiendo clientes, características y métricas de unidad.
  • CloudZero: Una solución SaaS que ofrece detección de anomalía de costos en tiempo real y detección de residuos para optimizar los costos de la nube y evitar gastos excesivamente accidentales.

Cuando la visibilidad granular está disponible, está permite a los proveedores de SaaS utilizar los conocimientos sobre el consumo de tenants para dar forma a la eficiencia operativa y arquitectónica en términos de costo. Medir cada unidad y servicio en un entorno multitenant con la correspondencia con un indicador clave de desempeño (KPI) al que se le atribuye, ayuda a lograr una visibilidad más clara de cómo se distribuye el costo del proveedor.

Entender cómo se está comportando cada tenant en el sistema, y luego conectar este comportamiento con los costos de infraestructura, nos acerca a la verdadera rendición de cuentas de costos en la nube.

Para los proveedores de SaaS, sin embargo, esto no siempre es suficiente. Las soluciones SaaS necesitan poder responder preguntas más avanzadas, como:

• ¿Es rentable esta característica?
• ¿Qué segmentos de clientes son los mejores para nosotros?
• ¿Cuál es la productividad de mi equipo de ingeniería para este característica de la solución?
• ¿Quiénes son los usuarios más activos/inactivos o más exigentes de recursos dentro de un tenant?

Este tema se debe a que las empresas de ritmo rápido tienen tres ejes relacionados con los costos que se están cambiando constantemente con el riesgo de no ser descubiertos de manera oportuna:

Eje 1 — Desarrolladores

Cada desarrollador o ingeniero de plataforma (infraestructura) puede, con un commit de código o función de toggle en la AWS Management Console, romper el margen objetivo de la empresa, sin siquiera saberlo.

Ejemplos de tales cambios incluyen cambiar la configuración de una tarea programada para que se ejecute tres veces al día en lugar de dos; cambiar “Acceso infrecuente” en un bucket de Amazon S3; o agregar cinco milisegundos de validaciones en cada solicitud.

El equipo de I+D tiene una responsabilidad significativa en la sostenibilidad empresarial y no sólo en las nuevas características y disponibilidad.

Eje 2 — Clientes

No todos los clientes fueron creados iguales, y no todos los clientes mantienen sus patrones de uso. Una solución SaaS puede alojar clientes con un margen de 99% y clientes con un 20%. Esto puede estar bien, pero es importante estar al tanto y actuar de acuerdo con los datos.

Si bien estas diferencias de margen no están directamente relacionadas con la medición del costo de la infraestructura, afectan directamente las consideraciones relacionadas con los costos. Por ejemplo, como resultado de estos insights el proveedor de SaaS puede querer dirigirse a segmentos específicos de clientes, realizar cambios de arquitectura para mejorar estas métricas, o retirar una función que está siendo utilizada por el 2% de los clientes pero que atribuye el 20% del costo.

Los proveedores de SaaS necesitan monitorear constantemente los patrones de actividad de los clientes. Los clientes pueden (y lo harán) cambiar su comportamiento y usar características de manera que puedan provocar que pasen de 90% a 20% de márgenes en un corto periodo de tiempo.

Eje 3 — AWS

Un entorno basado en la nube ofrece múltiples servicios y habilidades. Permite a los proveedores de SaaS utilizar diferentes recursos para diferentes necesidades.

Por ejemplo, mientras que el entorno de nivel gratuito puede utilizar recursos que proporcionan rendimiento básico, los niveles premium pueden disfrutar de recursos con mayor rendimiento. Los precios pueden cambiar, las instancias reservadas pueden terminar y pueden ser lanzados nuevos servicios que ayuden a optimizar la solución SaaS constantemente.

Los proveedores de SaaS deben monitorear el “piso de la planta SaaS” para asegurarse de que sea lo más eficiente posible. El uso de los servicios y habilidades de AWS adecuados puede marcar la diferencia entre un objetivo de margen bueno o malo.

Figura 3 — Asignación de costos.

Prestaciones e Impacto Organizacional

Hasta el momento, hemos discutido consideraciones y prácticas relevantes de atribución de costos. Vamos a profundizar en cómo esto puede influir en las decisiones empresariales y por qué los equipos de negocios y técnicos deben cuidar estos datos.

Obtener un desglose de costos preciso es clave para entender la forma en que los clientes de una solución SaaS consumen recursos en su entorno. Cada recurso debe tener un KPI asociado a él, y siempre que haya discrepancias la discusión sobre ellos puede ser tan focalizada como una flecha y datos impulsados. Por ejemplo, “El costo S3 del bucket X en la región Y es 20% más de lo que debería tener por la cantidad de KPIs producidos, a partir del lunes a las 11:00 horas”.

Una vez que el proveedor de SaaS logre suficiente visibilidad, pueden comenzar a usarlo dentro de la organización para construir una solución SaaS más rentable. Ahora es posible un diálogo más claro, y llegar al equipo de plataforma con datos KPI es accionable y menos frustrante.

Esta es también una buena manera de reducir la fricción entre los equipos de finanzas e I+D. Los proveedores de SaaS ya no necesitan estimar un presupuesto que I+D es el único que controla. Por ejemplo, el equipo de finanzas puede afirmar que con base en sus proyecciones, la factura de AWS el próximo trimestre debería aumentar un 15%.

Al tener este diálogo dentro de la organización, los proveedores de SaaS pueden determinar con precisión el mejor modelo de precios para la solución, comprender cómo el uso de funciones de producto afecta el consumo de recursos y el costo de la solución, y planificar movimientos empresariales y técnicos de manera consciente de los costos.

Otro beneficio de tener a la mano estos insights es poder discutir presupuestos y coordinar entre las unidades de negocio de la organización.

Por ejemplo, si el equipo de marketing tiene la meta de obtener un 50% más de leads en el nivel gratuito de la aplicación, puede resultar en que I+D tenga que gastar más dinero apoyando a tenants de nivel gratuito adicionales. Esta acción puede rebasar su presupuesto e interferir con sus propios objetivos —implicación que debe examinarse.

Dado que el proveedor de SaaS ahora tiene una mejor visibilidad de los elementos SaaS como los tenants individuales y los niveles, establecer presupuestos y pronosticar ingresos y costos basados en el precio de economía unitaria puede ayudar al equipo de finanzas a recuperar el control del gasto, formar una mejor alineación organizacional y planificación presupuestaria, y hacer que los equipos de plataformas se sientan más cómodos construyendo un producto mejor y más estable.

Un ejemplo práctico para eso puede ser reflejar el valor de cada nivel en el sistema. Dado que el equipo de plataforma puede comprometerse a “$1.23 por GB que estamos almacenando en la infraestructura de nivel gratuito (free tier)”, o “$4.2 por eventos de 1M tanto en niveles gratuitos como premium”, el equipo de finanzas puede medir rápidamente el retorno de la inversión (ROI) para cada componente, característica y tenant en el sistema.

Tenga en cuenta que una vez que el proveedor de SaaS tiene acceso a insights de costo por tenant, se pueden usar para hacer preguntas más amplias sobre cómo ese costo se relaciona con otras tendencias de actividad, como los datos de uso de funciones y visibilidad en la forma de uso.

Conclusión

Las empresas de SaaS necesitan comprender su estructura de costos para poder entender su negocio.

Para muchos, el costo de la nube es la mayor parte de su Costo de Bienes Vendidos (COGS), y dejarlo como una “caja negra” significa que los proveedores de SaaS están ciegos a la hora de tomar decisiones impulsadas por datos sobre aspectos críticos del negocio.

Desglosar el costo a diferentes métricas unitarias, clientes, características, segmentos y unidades de negocio es un requisito para cualquier negocio SaaS moderno.

Acerca de Finout

Finout es un socio de AWS y una plataforma de observación de costos en la nube de autoservicio, código cero que combina métricas comerciales con costos de infraestructura, dividiéndolo en clientes, características y métricas de unidad.

La plataforma de Finout se integra con AWS, almacenes de datos y plataformas de observabilidad para correlacionar y analizar los datos de costos en un solo lugar y asegurarse de que se contabilice cada dólar.

Acerca del SaaS Factory

AWS SaaS Factory ayuda a las organizaciones en cualquier etapa del proceso de SaaS. Ya sea que desee crear nuevos productos, migrar aplicaciones existentes u optimizar las soluciones SaaS en AWS, podemos ayudarlo. Visite AWS SaaS Factory Insights Hub para descubrir más contenido técnico, comercial y mejores prácticas.

Este artículo fue traducido del Blog de AWS en Inglés.

Sobre el autor

Oren Reuveni es Principal Solutions Architect y miembro del equipo de SaaS Factory. Ayuda a guiar a los socios de AWS a crear sus productos SaaS en AWS. Oren tiene más de 15 años de experiencia en los dominios modernos de TI y nube. Le apasiona dar forma a la dinámica adecuada entre la tecnología y los negocios.

Sobre los traductores

Robert García es Arquitecto de Soluciones para Socios de Negocio (PSA). En los últimos 10 años, ha apoyado a equipos de ventas a diseñar, implementar y operar soluciones para superar sus retos técnicos y de negocios. Actualmente, se dedica a apoyar a ISVs a desarrollar nuevas soluciones, o a migrarlas, hacia AWS.

Armando Barrales es Arquitecto de soluciones en AWS, con más de 15 años de experiencia en desarrollo, bases de datos, infraestructura, Actualmente, se dedica a apoyar a ISVs a modernizar, desarrollar nuevas soluciones, o a migrarlas, hacia AWS.