Economia dos aplicativos de nuvem
Os CSPs estão trabalhando duro para atrair os usuários de suas implantações tradicionais. Os preços da nuvem pública de IaaS têm sido reduzidos de maneira constante e acentuada desde o lançamento de seus serviços. Em média, para a maioria dos principais CSPs, os preços foram reduzidos em 20 a 30% por ano desde 2013.
No entanto, apesar dos preços em queda, a adoção da nuvem ainda precisa ser feita com cuidado. Para realmente obter os benefícios de custo da nuvem, é importante entender, orçar, planejar, monitorar e analisar o uso atentamente. Além disso, é difícil escolher entre os CSPs para casos de uso individuais, uma vez que não há uma forma padrão dos CSPs empacotarem os recursos e eles nem sempre seguem os mesmos modelos de preço.
Modelos de preço
Os provedores de nuvem geralmente cobram pelos recursos com base em um dos três seguintes tipos de parâmetros:
- Baseado em tempo: os recursos são cobrados com base no tempo durante o qual são provisionados para o usuário. Por exemplo, você paga um determinado valor por hora/dia/mês/ano para ter uma máquina virtual em execução em uma nuvem de IaaS. A granularidade do período de cobrança varia de acordo com o provedor de nuvem. A Amazon, por exemplo, cobra os usuários por hora de maneira não rateada.
- Baseado em capacidade: os usuários são cobrados com base na quantidade de um determinado recurso que é utilizada ou consumida. Esse é um modelo de cobrança popular para sistemas de armazenamento em nuvem. Por exemplo, é cobrado dos usuários um determinado valor para armazenar um gigabyte em sistemas de armazenamento de objetos na nuvem, como o Armazenamento de Blobs do Azure.
- Baseado em desempenho: em muitos provedores de nuvem, os usuários podem selecionar um nível de desempenho mais elevado para os recursos pagando um valor mais alto. Para máquinas virtuais, máquinas maiores e mais potentes com mais capacidade de CPU, memória e disco podem ser provisionadas por uma taxa por hora mais alta.
Com base nesses parâmetros de cobrança, os CSPs usam um dos seguintes modelos de preço comuns:
- Preço sob demanda e pago conforme o uso: geralmente, esse é o modelo de preço mais caro para uso de longo prazo. Os pagamentos são feitos por um período muito curto de uso (geralmente medido em minutos ou horas). A vantagem é que não há necessidade de um contrato de longo prazo, tornando-o muito flexível para escalar e reduzir horizontalmente com base na necessidade atual. Embora não seja comum, é possível que os CSPs aumentem os custos em períodos de alta demanda e os diminuam em períodos de baixa demanda. Esse é um excelente modelo para os provedores de serviço, bem como para usuários que estão apenas começando a usar a nuvem.
- Preço por instâncias reservadas e baseados em assinatura: em vez de pagar uma taxa por hora ou por minuto, o usuário pode optar por pagar antecipadamente e reservar um recurso por um período mais longo (semanas ou meses). Geralmente, isso gera descontos grandes (20 a 50%), mas exige um compromisso de longo prazo. Dentro de modelos de preços reservados, os esquemas de pagamento podem variar de pagamentos pré-pagos a pagamentos baseados em contratos.
- Preços pontuais: os preços pontuais são uma forma dos CSPs lidarem com o excesso de capacidade inutilizada, oferecendo-a para venda por preços significativamente mais baixos do que os recursos sob demanda. Os preços são determinados por um leilão para os usuários, em que eles indicam o valor máximo que estão dispostos a pagar por um recurso. A maior desvantagem é que os recursos geralmente podem ser encerrados a qualquer momento se o preço pontual supera o preço oferecido real. Recursos pontuais são ideais para trabalhos não críticos de curta execução que podem ser executados de maneira especulativa.
Geralmente, instâncias reservadas devem ser usadas para atender aos requisitos básicos do sistema. Se um aplicativo precisasse de duas instâncias por 80% do tempo, três instâncias por 15% do tempo e quatro instâncias por 5% do tempo, normalmente você reservaria duas instâncias para o tempo de vida do aplicativo e escalaria horizontalmente usando instâncias pontuais ou sob demanda. Conforme mencionado, instâncias sob demanda deverão ser escolhidas ao escalar horizontalmente somente se o aplicativo for comercialmente crítico ou se a diferença entre o preço sob demanda e o preço pontual atual for compensada pelo risco do encerramento repentino. Essa decisão geralmente é específica para o caso empresarial.
Como otimizar a utilização de custos
Para usar a nuvem de maneira econômica, as empresas precisam desenvolver um processo maduro para escolher os recursos a serem usados para implantar, monitorar e visualizar o uso, bem como um mecanismo claro para identificar o desperdício e otimizar a utilização.
Figura 11: processo de otimização de custo
Antes de considerar os requisitos de custo, a organização deve planejar a quantidade de trabalho que é capaz de concluir em um determinado período com base em recursos fixos, como o tamanho da equipe, enquanto lida com restrições físicas, como gerenciamento de estoque, sobrecarga devido ao transporte, manuseio de material etc. O provisionamento de recursos de TI deve ser projetado de maneira a atender ou exceder a capacidade física da organização. Isso é extremamente importante, pois a elasticidade proporcionada pela nuvem incentiva as equipes de desenvolvimento a apenas adicionar recursos conforme necessário, sem considerar as implicações de suas decisões quanto ao custo.
A primeira etapa na tentativa de reduzir despesas com a nuvem é combinar os tipos de recursos com o requisito real do aplicativo. Isso pode significar escolher entre VMs com diferentes configurações de memória ou números de núcleos. Não há uma forma simples de fazer isso, além de testar e avaliar o desempenho do aplicativo com diferentes tipos de recursos.
Mesmo que o aplicativo tenha um desempenho melhor em uma classe de recursos mais cara, é importante verificar se o aprimoramento de desempenho é proporcional ao aumento do custo. Por exemplo, se houver um aprimoramento de 1,2 vezes em um aplicativo usando uma VM 7,5 mais cara do que a base, poderá fazer mais sentido escalar horizontalmente o recurso base para aprimorar o desempenho.
É importante criar um sistema de monitoramento e visualização para monitorar os vários recursos que estão sendo usados. O sistema de monitoramento deve ser projetado para disparar eventos de escala em resposta a padrões observados de sobrecarga ou ociosidade. Muitas vezes, as equipes de infraestrutura optam por escalar horizontal ou verticalmente de maneira agressiva, enquanto reduzem horizontal ou verticalmente forma mais conservadora. Embora essa abordagem seja mais cara em termos do provisionamento de recursos, teoricamente, ela fornece uma qualidade de serviço mais alta do que operar quase no pico de capacidade o tempo todo.
Dito isso, as organizações geralmente subestimam a necessidade de reduzir verticalmente e encerrar recursos raramente usados. Ao planejar a execução dos diferentes componentes de um aplicativo, é importante categorizar a utilização em diferentes compartimentos, com base no período aproximado durante o qual eles serão usados. Por exemplo, trabalhos executados por um curto período em um cronograma noturno ou semanal não devem usar recursos permanentes. Recursos ociosos também devem ser marcados e encerrados (com base em determinadas regras) pelo sistema de monitoramento.
Uma técnica importante que se une à otimização de custos é a marcação de recursos. A marcação é o processo de atribuir etiquetas a aos recursos que permitem que eles sejam identificados por ferramentas de monitoramento e análise. A marcação também permite que regras personalizadas sejam definidas por marca, incluindo listas de controle de acesso para recursos, alertas de cobrança e políticas específicas de escala. As marcas que costumam ser usadas especificam o proprietário (usuário ou grupo) de um recurso específico, o ambiente a que ele pertence (por exemplo, produção, backup, preparo e teste), o centro de custo responsável pelo pagamento da fatura etc. Ao analisar as despesas, isso permite gerar exibições agrupadas com base em aplicativos específicos, bem como em equipes específicas de desenvolvimento ou teste.