Economia para aplicações na cloud

Concluído

Os CSP estão a esforçar-se bastante para atrair os utilizadores das suas implementações tradicionais. Os preços da cloud pública IaaS têm vindo a cair constantemente desde o lançamento dos seus serviços. Em média, para a maioria dos principais CSP, os preços caíram 20 a 30% por ano desde 2013.

No entanto, apesar destes preços decrescentes, a adoção da cloud ainda deve ser feita com cuidado. Para obter verdadeiramente os benefícios de custo da cloud, é importante compreender, orçamentar, planear, monitorizar e analisar cuidadosamente a sua utilização. Além disso, é difícil escolher entre CSP para casos de utilização individual, uma vez que não existe uma forma padrão de os CSP empacotarem recursos e nem sempre seguem os mesmos modelos de preços.

Modelos de preços

Os fornecedores de cloud cobram geralmente por recursos com base num dos seguintes três tipos de parâmetros:

  • Com base no tempo: os recursos são cobrados com base na quantidade de tempo que são provisionados para o usuário. Por exemplo, paga-se um determinado valor por hora/dia/mês/ano para ter uma máquina virtual a funcionar numa cloud IaaS. A granularidade do período de cobrança varia de fornecedor de cloud para fornecedor de cloud. A Amazon, por exemplo, cobra aos utilizadores por hora de forma não proporcional.
  • Baseado na capacidade: os usuários são cobrados com base na quantidade de um determinado recurso que é utilizado ou consumido. Este é um modelo de cobrança popular para sistemas de armazenamento na cloud. Por exemplo, é cobrado aos utilizadores um certo valor para armazenar um gigabyte em sistemas de armazenamento de objetos na cloud, como o armazenamento de Blobs do Azure.
  • Com base no desempenho: em muitos provedores de nuvem, os usuários podem selecionar um nível de desempenho mais alto para os recursos pagando uma taxa mais alta. Para máquinas virtuais, máquinas maiores e mais potentes com mais CPU, memória e capacidade de disco podem ser aprovisionadas a uma taxa horária mais elevada.

Com base nestes parâmetros de cobrança, os CSP utilizam um dos seguintes modelos de preços comuns:

  • Preços sob demanda e pré-pagos: Este é geralmente o modelo de preços mais caro para uso a longo prazo. Os pagamentos são efetuados por um período de utilização muito curto (geralmente medido em minutos ou horas). A vantagem é que não há necessidade de um contrato a longo prazo, o que o torna muito flexível para aumentar e reduzir horizontalmente com base na necessidade atual. Embora não seja comum, os CSP podem aumentar os custos durante a procura elevada e diminuir durante a procura reduzida. Este é um ótimo modelo para os fornecedores de serviços, bem como para os utilizadores de cloud que estão apenas a começar a utilizar a cloud.
  • Instâncias reservadas e preços baseados em assinatura: em vez de pagar uma taxa por hora ou por minuto, um usuário pode optar por pré-pagar e reservar um recurso por um período de tempo bastante longo (semanas ou meses). Tal conduz muitas vezes a markdowns reduzidos (20-50%), mas exige um compromisso a longo prazo. Dentro dos modelos de preços reservados, os esquemas de pagamento podem variar de pagamentos pré-pagos a pagamentos periódicos obrigados contratualmente.
  • Precificação spot: A precificação spot é uma maneira de os CSPs lidarem com o excesso de capacidade não utilizada, oferecendo-a para venda a preços significativamente mais baixos do que os recursos sob demanda. Os preços são determinados por um leilão de utilizadores, no qual os utilizadores licitam o valor máximo que estão dispostos a pagar por um recurso. A maior desvantagem é que os recursos podem muitas vezes ser encerrados a qualquer momento se o preço pontual aumentar para além do preço real da oferta. Os recursos pontuais são ideais para tarefas de curta duração e não críticos que podem ser executados especulativamente.

Geralmente, as instâncias reservadas devem ser utilizadas para satisfazer os requisitos base do sistema. Se uma aplicação precisar de 2 instâncias 80% do tempo, 3 instâncias 15% do tempo e 4 instâncias 5% do tempo, geralmente reserva 2 instâncias para a duração da aplicação e aumenta horizontalmente através de instâncias a pedido ou pontuais. Como referido, as instâncias a pedido devem ser escolhidas durante o aumento horizontal apenas se a aplicação for crítica para a empresa ou se o diferencial entre o preço a pedido e o preço pontual atual for compensado pelo risco de encerramento súbito. Esta decisão é muitas vezes específica ao caso de negócio.

Como otimizar a utilização de custos

Para utilizar a cloud de forma rentável, as empresas necessitam de desenvolver um processo maduro para escolher os recursos a implementar, monitorizar e visualizar a utilização, bem como um mecanismo claro para identificar o desperdício e otimizar a utilização.

Processo de otimização de custos.

Figura 11: Processo de otimização de custos

Antes de considerar os requisitos de custo, uma organização deve planejar a quantidade de trabalho que é capaz de concluir em um determinado período com base em recursos fixos, como a quantidade de pessoal, enquanto lida com restrições físicas como gerenciamento de estoque, despesas gerais devido ao transporte, manuseio de materiais, etc. O provisionamento de recursos de TI deve ser projetado para atender ou exceder a capacidade física da organização. Isto é extremamente importante porque a elasticidade proporcionada pela cloud tenta as equipas de desenvolvimento a simplesmente adicionarem recursos conforme necessário, sem considerar as implicações de custos das suas decisões.

O primeiro passo para tentar reduzir as despesas na cloud é através da combinação dos tipos de recursos com o requisito real para a aplicação. Isto pode significar ter de selecionar entre VM com configurações de memória ou número de núcleos diferentes. Não há uma forma simples de o fazer, para além de testar e comparar a aplicação em diferentes tipos de recursos.

Mesmo que uma aplicação tenha um melhor desempenho numa classe de recursos mais cara, é importante verificar se a melhoria do desempenho é proporcional ao aumento de custos. Por exemplo, se houver uma melhoria de 1,2x numa aplicação com uma VM que seja 7,5x mais cara do que a base, talvez faça mais sentido aumentar horizontalmente o recurso base para melhorar o desempenho.

É importante construir um sistema de monitorização e visualização para monitorizar os vários recursos utilizados. O sistema de monitorização tem de ser concebido para acionar eventos de dimensionamento em resposta aos padrões observados de sobrecarga ou inatividade. Muitas vezes, as equipas de infraestruturas optam por aumentar vertical ou horizontalmente de forma agressiva, enquanto reduzem verticalmente ou de forma mais conservadora. Embora esta abordagem seja mais cara em termos de aprovisionamento de recursos, teoricamente fornece uma maior qualidade de serviço do que operar perto da capacidade máxima o tempo todo.

Dito isto, as organizações muitas vezes subestimam a necessidade de reduzir verticalmente e encerrar recursos raramente utilizados. No planeamento da execução de diferentes componentes de uma aplicação, é importante categorizar a utilização em diferentes caixas, com base na duração aproximada para a qual será utilizada. Por exemplo, quaisquer tarefas que sejam executadas por um curto período de tempo, todas as noites ou semanalmente, não devem utilizar recursos 24 horas por dia, 7 dias por semana. Os recursos inativos também devem ser sinalizados e encerrados (com base em determinadas regras) pelo sistema de monitorização.

Uma técnica importante associada à otimização de custos é a identificação de recursos. A identificação é o processo de atribuição de etiquetas a recursos que lhes permitam ser identificados através de ferramentas de monitorização e análise. A identificação também permite definir regras personalizadas por etiqueta, incluindo listas de controlo de acesso a recursos, alertas de faturação e políticas específicas de dimensionamento. As tags comumente usadas especificam o proprietário (usuário ou grupo) de um determinado recurso, o ambiente ao qual ele pertence (por exemplo, produção, backup, preparação e teste), o centro de custo responsável pelo pagamento da conta, etc. Na análise de despesas, isso permite a geração de visualizações agrupadas com base em aplicativos específicos, bem como em equipes específicas de desenvolvimento ou teste.