SaaS Factory (A série) — Otimização de custos e fluxos de trabalho de locatário SaaS

Neste post, falaremos sobre Otimização de custos e fluxos de trabalho de locatário SaaS.

Digamos, por exemplo, que somos um produto de comércio eletrônico e usamos o tamanho do catálogo como a métrica de definição que separa as camadas do nosso sistema. Nesse cenário, a empresa simplesmente começaria a adquirir clientes e a colocá-los no sistema sem se preocupar com o impacto disso nos resultados. Agora, se pegarmos este sistema e começarmos a coletar dados de custo por locatário, a divisão do consumo de infraestrutura pode acabar se parecendo com o gráfico de barras mostrado abaixo. Aqui, você notará que a maioria dos locatários se inscreveu no nível básico. No entanto, os custos de infraestrutura associados ao nível básico excedem em muito os dos outros dois níveis.

Dando as opções de negócios

O exemplo anterior destaca a estreita ligação que muitas vezes existe entre as equipes SaaS comercial e técnica. As escolhas arquitetônicas feitas pelos desenvolvedores de SaaS têm o potencial de moldar e influenciar o menu de preços e opções de embalagem oferecidos pelo negócio. Quanto mais flexibilidade você for capaz de fornecer ao negócio, maior será a probabilidade de responder rapidamente aos diversos requisitos dos locatários — cada um dos quais pode ter sua própria escala, desempenho e perfis de consumo.

O objetivo mais amplo aqui é fazer escolhas em sua arquitetura SaaS que melhor alinhe as expectativas de um inquilino com sua experiência. Se um inquilino for um inquilino de nível básico de US$ 29/mês, é provável que ele entenda que sua experiência será diferente da do inquilino de nível profissional de US$ 5.000/mês. O suporte a esse modelo geralmente significa introduzir variações nas políticas e, em alguns casos, modelos de arquitetura que oferecem experiências de locatário distintas para cada camada de sua solução. Exemplos de como isso pode ser alcançado são descritos em uma postagem de blog sobre como otimizar fluxos de trabalho e custos de locatários de SaaS, bem como uma apresentação sobre como otimizar soluções de SaaS na AWS .

A parte difícil: instrumentar sua solução

Analisando Custos em um Modelo de Silo

Alguns provedores de SaaS dependem exclusivamente de um modelo de particionamento em silos em que cada inquilino é alojado em uma infraestrutura praticamente isolada. Esse isolamento pode ser obrigatório para alguns domínios que possuem regulamentos rígidos que proíbem a infraestrutura compartilhada. Para esses ambientes, limites mais pronunciados entre cada inquilino podem simplificar os esforços para agregar e derivar análises de custos.

O outro esquema de isolamento comum envolve a criação de VPCs separadas para cada inquilino. Com essa abordagem, você pode isolar inquilinos sem criar contas separadas para cada inquilino. Isso geralmente é dimensionado melhor e simplifica o modelo de provisionamento. No entanto, também adiciona um grau de complexidade à instrumentação de custos. Em vez de depender de contas vinculadas para resumir os gastos do locatário, você precisará aplicar tags da AWS à sua infraestrutura para associá-la aos seus locatários. Essas tags serão usadas para agregar o gasto de cada locatário.

Em um modelo mais isolado, você pode querer considerar o aproveitamento de soluções de parceiros para simplificar a agregação e a análise de seus custos de locatário. Parceiros da rede de parceiros da AWS (APN), como CloudHealth e Cloudability, por exemplo, fornecem ferramentas de análise de custos que podem simplificar sua capacidade de realizar análises de locatários.

Analisando custos em um modelo Pool

Em um modelo Pool, onde os recursos do inquilino são compartilhados, a atribuição dos custos do inquilino pode ser mais desafiadora. Aqui, você deve empregar estratégias mais especializadas para capturar e classificar adequadamente a atividade do inquilino. Você precisará confiar nas medições das interações reais do inquilino com os recursos do sistema para repartir a carga e o consumo e derivar uma aproximação dos custos do inquilino. Isso normalmente exige mais esforço para instrumentar sua solução e agregar as métricas resultantes.

Vamos considerar como, em um ambiente em pool, você pode derivar o consumo de um locatário de sua atividade. O diagrama abaixo descreve uma visão simplificada de um cluster do Amazon EC2 Container Service (Amazon ECS) executando serviços em um ambiente multilocatário em pool. Este cluster inclui dois serviços que estão sendo executados em contêineres (Checkout e Catalog), sendo que ambos estão sendo chamados por locatários individuais.

À medida que os locatários usam esses serviços, eles consomem recursos de computação. A questão é: quanto desses recursos estão realmente sendo consumidos por cada inquilino? O inquilino 1, por exemplo, pode estar pressionando muito o sistema e vendendo muitos itens, forçando a escala para fora do cluster ou consumindo um número desproporcional de contêineres no cluster. O inquilino 2, por outro lado, pode estar impondo uma carga mínima.

O diagrama abaixo fornece um modelo conceitual de como você pode agregar uma série de chamadas a um serviço e usar esses dados para determinar o consumo de um locatário. Aqui, simplesmente usamos a frequência das chamadas para determinar uma porcentagem de atividade para um inquilino. Isso fornece um modelo para distribuir os custos de computação associados a esse serviço para cada locatário com base nessas porcentagens.

Isso representa uma versão altamente simplificada do que você pode construir. Ainda assim, dá uma noção do que pode estar envolvido na obtenção de uma distribuição razoável dos custos de computação do locatário. A boa notícia aqui é que os mecanismos necessários para dar suporte à coleta desses dados se sobrepõem fortemente às ferramentas analíticas gerais que você deseja implementar para analisar e avaliar a atividade do inquilino. A chave é garantir que você coletou os dados necessários com o contexto necessário para dar suporte ao seu modelo de alocação de custos.

Cálculo dos custos de armazenamento

Embora o exemplo anterior tenha nos dado uma noção de como podemos calcular o consumo de computação, esse mesmo modelo pode não ser uma boa opção para analisar os custos de armazenamento. Um locatário pode, por exemplo, consumir quantidades significativas de computação e ainda ter um impacto mínimo nos custos de armazenamento. Não há correlação garantida entre computação e consumo de armazenamento em ambientes SaaS.

A análise de uma métrica como IOPS tem paralelos com o que discutimos para analisar o consumo de computação. O objetivo seria derivar alguma noção da atividade de armazenamento do inquilino a partir das interações de um inquilino com os dados. Essas métricas podem ser derivadas das interações de cada inquilino com uma camada de acesso a dados empregada por sua solução (conforme representado no diagrama a seguir). Com essa abordagem, cada chamada para adquirir ou gerenciar dados seria processada por uma estrutura comum que capturaria e agregaria a atividade de armazenamento do locatário. Essa atividade seria então usada para repartir os custos para cada inquilino.

Determinar o impacto de um locatário no espaço de armazenamento do sistema é um processo menos dinâmico. Aqui, você pode ter dados armazenados em alguns serviços da AWS (Amazon DynamoDB, Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Amazon Elastic Block Store (Amazon EBS) e assim por diante) e você precisará determinar qual porcentagem de esse armazenamento pertence a cada inquilino. A avaliação desses dados geralmente requer um processo que pode analisar periodicamente a distribuição de dados para determinar o consumo de armazenamento de um locatário. O mecanismo usado para essa análise varia de acordo com seu modelo de particionamento de dados e o tipo de recurso de armazenamento que está sendo avaliado. O Amazon S3 e o DynamoDB, por exemplo, exigiriam estratégias muito diferentes para analisar o consumo de armazenamento do locatário.

Medição de faturamento x consumo do locatário

A medição é um aspecto essencial de muitos ambientes SaaS. Os provedores de SaaS geralmente desenvolvem uma estratégia de cobrança e classificação em torno de alguma dimensão do consumo. Essas dimensões de consumo cobrem uma ampla gama de possibilidades. Largura de banda, número de usuários, uso de armazenamento — todos esses são tipos de modelos de cobrança usados ​​para correlacionar a atividade do locatário com alguma construção de cobrança.

Métricas importam

A maioria dos negócios de SaaS depende fortemente de métricas. Ter o pulso dos padrões de uso geralmente complexos de seu cliente é essencial para entender como comercializar, precificar, posicionar e construir sua solução. A sobrecarga de infraestrutura geralmente representa uma porcentagem significativa dos custos de um provedor de SaaS. Assim, ter uma visão precisa de como os locatários estão impondo carga em seu sistema dá às equipes técnicas e de negócios outra variável que pode moldar as estratégias de preços e níveis que você escolhe oferecer.

Ao examinar estratégias para capturar e analisar métricas de custo, você deve ver isso como um processo iterativo. Você pode começar com alguns mecanismos muito básicos para obter informações sobre as pegadas dos inquilinos que, de outra forma, poderiam passar despercebidas. Então, com o tempo, você pode evoluir e amadurecer esse modelo para adicionar profundidade à sua análise de custos.

A chave é trazer visibilidade para a métrica de custo por inquilino e torná-la parte da matemática mental do negócio.

No próximo post, falaremos sobre Estratégias de migração de arquiteturas SaaS.

SaaS Factory (A série) — Como construir soluções de Software como Serviço na AWS

Até o próximo post! =)