Meça o consumo de cada inquilino

Como provedor de soluções, é importante medir o consumo de cada locatário em sua solução multilocatário. Ao medir o consumo de cada inquilino, pode garantir que o custo dos bens vendidos (CPV), para a entrega do serviço a cada inquilino, é rentável. Nesta página, fornecemos orientações para os tomadores de decisão técnica sobre a importância de medir o consumo e as abordagens que você pode considerar para medir o consumo de um inquilino, bem como as compensações envolvidas.

Há duas preocupações principais que impulsionam a necessidade de medir o consumo de cada inquilino:

• Você precisa medir o custo real para atender cada inquilino. Isto é importante para monitorizar a rentabilidade da solução para cada inquilino.
• Você precisa determinar o valor a ser cobrado do inquilino, quando estiver usando preços baseados no consumo.

No entanto, pode ser difícil medir os recursos reais usados por um locatário em uma solução multilocatário. A maioria dos serviços que podem ser usados como parte de uma solução multilocatária não diferencia ou divide automaticamente o uso, com base no que você define como sendo um locatário. Por exemplo, considere um serviço que armazena dados de todos os seus locatários em um único banco de dados relacional. É difícil determinar exatamente quanto espaço cada locatário usa desse banco de dados relacional, seja em termos de armazenamento ou da capacidade de computação necessária para atender a quaisquer consultas e solicitações.

Por outro lado, para uma solução de locatário único, você pode usar o Microsoft Cost Management no portal do Azure para obter um detalhamento de custo completo para todos os recursos do Azure consumidos por esse locatário.

Portanto, ao enfrentar esses desafios, é importante considerar como medir o consumo.

Nota

Em alguns casos, é comercialmente aceitável assumir um prejuízo na entrega do serviço a um inquilino, por exemplo, quando você entra em um novo mercado ou região. Trata-se de uma escolha comercial. Mesmo nestas situações, continua a ser uma boa ideia medir o consumo de cada inquilino, para que possa planear o futuro.

Métricas indicativas de consumo

As aplicações modernas (construídas para a nuvem) são geralmente compostas por muitos serviços diferentes, cada um com diferentes medidas de consumo. Por exemplo, uma conta de armazenamento mede o consumo com base na quantidade de dados armazenados, nos dados transmitidos e no número de transações. No entanto, o consumo do Serviço de Aplicativo do Azure é medido pela quantidade de recursos de computação alocados ao longo do tempo. Se você tiver uma solução que inclua uma conta de armazenamento e recursos do Serviço de Aplicativo, combinar todas essas medidas para calcular o COGS (custo dos produtos vendidos) real pode ser uma tarefa muito difícil. Muitas vezes, é mais fácil usar uma única medição indicativa para representar o consumo na solução.

Por exemplo, se uma solução multilocatária compartilha um único banco de dados relacional, os dados armazenados por um locatário podem ser uma boa métrica de consumo indicativa.

Nota

Mesmo que você use o volume de dados armazenados por um locatário como uma medida indicativa de consumo, ele pode não ser uma representação verdadeira do consumo para cada locatário. Por exemplo, se um determinado locatário lê muito mais ou executa mais relatórios da solução, mas não grava muitos dados, ele pode usar muito mais computação do que os requisitos de armazenamento indicariam.

É importante ocasionalmente medir e rever o consumo real entre os seus inquilinos, para determinar se as suposições que você está fazendo sobre suas métricas indicativas estão corretas.

Métricas de transação

Uma forma alternativa de medir o consumo é identificar uma transação chave que seja representativa do COGS para a solução. Por exemplo, em uma solução de gerenciamento de documentos, pode ser o número de documentos criados. Isso pode ser útil, se houver uma função ou recurso principal dentro de um sistema que seja transacional e se puder ser facilmente medido.

Esse método geralmente é fácil e econômico de implementar, pois geralmente há apenas um único ponto em seu aplicativo que precisa registrar o número de transações que ocorrem.

Métricas por solicitação

Em soluções baseadas principalmente em API, pode fazer sentido usar uma métrica de consumo baseada no número de solicitações de API feitas à solução. Isso geralmente pode ser bastante simples de implementar, mas requer que você use APIs como a interface principal para o sistema. Haverá um aumento do custo operacional da implementação de uma métrica por solicitação, especialmente para serviços de alto volume, devido à necessidade de registrar a utilização da solicitação (para fins de auditoria e faturamento).

Nota

Soluções voltadas para o usuário que consistem em um aplicativo de página única (SPA) ou um aplicativo móvel que usa as APIs, podem não ser uma boa opção para a métrica por solicitação. Isso ocorre porque há pouca compreensão por parte do usuário final da relação entre o uso do aplicativo e o consumo de APIs. Seu aplicativo pode ser tagarela (faz muitas solicitações de API) ou volumosa (faz poucas solicitações de API), e o usuário não notaria diferença.

Aviso

Certifique-se de armazenar métricas de solicitação em um armazenamento de dados confiável projetado para essa finalidade. Por exemplo, embora o Azure Application Insights possa rastrear solicitações e até mesmo rastrear IDs de locatário (usando propriedades), o Application Insights não foi projetado para armazenar todas as partes da telemetria. Ele remove dados, como parte de seu comportamento de amostragem. Para fins de faturamento e medição, escolha um armazenamento de dados que lhe dará um alto nível de precisão.

Estimativa de consumo

Ao medir o consumo de um inquilino, pode ser mais fácil fornecer uma estimativa do consumo para o inquilino, em vez de tentar calcular a quantidade exata de consumo. Por exemplo, para uma solução multilocatária que atende milhares de locatários em uma única implantação, é razoável aproximar que o custo de atender o locatário é apenas uma porcentagem do custo dos recursos do Azure.

Você pode considerar estimar o COGS para um locatário, nos seguintes casos:

• Você não está usando preços baseados no consumo.
• Os padrões de uso e o custo para cada locatário são semelhantes, independentemente do tamanho.
• Cada locatário consome uma baixa porcentagem (digamos, <2%) dos recursos totais na implantação.
• O custo por inquilino é baixo.

Você também pode optar por estimar o consumo em combinação com métricas indicativas de consumo, métricas de transação ou métricas por solicitação. Por exemplo, para um aplicativo que gerencia principalmente documentos, a porcentagem de armazenamento geral usada por um locatário para armazenar seus documentos fornece uma representação próxima o suficiente do COGS real. Esta pode ser uma abordagem útil, quando a medição do COGS é difícil ou quando acrescentaria demasiada complexidade à aplicação.

Cobrar os seus custos

Em algumas soluções, você pode cobrar de seus clientes o COGS pelos recursos de seus locatários. Por exemplo, você pode usar marcas de recursos do Azure para alocar recursos faturáveis do Azure para locatários. Em seguida, você pode determinar o custo para cada locatário para o conjunto de recursos dedicados a eles, além de uma margem de lucro e operação.

Nota

Alguns serviços do Azure não suportam etiquetas. Para esses serviços, você precisará atribuir os custos a um locatário, com base no nome do recurso, grupo de recursos ou assinatura.

A Análise de Custos do Azure pode ser usada para analisar os custos de recursos do Azure para soluções de locatário único que usam tags, grupos de recursos ou assinaturas para atribuir custos.

No entanto, isso se torna proibitivamente complexo na maioria das soluções multilocatárias modernas, devido ao desafio de determinar com precisão o COGS exato para atender a um único locatário. Esse método só deve ser considerado para soluções muito simples, soluções que tenham implantações de recursos de locatário único ou recursos de complemento personalizados específicos do locatário em uma solução maior.

Alguns serviços do Azure fornecem recursos que permitem outros métodos de atribuição de custos em um ambiente multilocatário. Por exemplo, o Serviço Kubernetes do Azure dá suporte a vários pools de nós, onde cada locatário recebe um pool de nós com tags de pool de nós, que são usadas para atribuir custos.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Daniel Scott-Raynsford - Brasil | Estrategista de Tecnologia de Parceiros

Outros contribuidores:

• John Downs - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Chade Kittel - Brasil | Engenheiro de Software Principal
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

Considere o modelo de implantação de atualização que você usará.