Compromissos da Otimização de Custos

Quando cria uma carga de trabalho para maximizar o retorno do investimento (ROI) sob restrições financeiras, primeiro precisa de requisitos funcionais e não funcionais claramente definidos. Uma estratégia de atribuição de prioridades de trabalho e esforço é essencial. A fundação é uma equipa que tem um forte sentido de responsabilidade financeira. A equipa deve ter uma forte compreensão das tecnologias disponíveis e dos seus modelos de faturação.

Depois de compreender o ROI de uma carga de trabalho, pode começar a melhorá-lo. Para melhorar o ROI, considere como as decisões baseadas nos princípios de design da Otimização de Custos e as recomendações na lista de verificação de revisão de design para Otimização de Custos podem influenciar os objetivos e otimizações de outros pilares do Azure Well-Architected Framework. Para a otimização de custos, é importante evitar concentrar-se numa solução mais barata. As escolhas que se focam apenas na minimização dos gastos podem aumentar o risco de minar os objetivos empresariais e a reputação da sua carga de trabalho. Este artigo descreve as desvantagens de exemplo que uma equipa de carga de trabalho pode encontrar ao considerar a definição de destino, a estrutura e as operações para otimização de custos.

Compromissos de Otimização de Custos com Fiabilidade

O custo de uma interrupção do serviço tem de ser medido em relação ao custo de impedir ou recuperar de uma. Se o custo das interrupções exceder o custo da conceção de fiabilidade, deve investir mais para evitar ou mitigar interrupções. Por outro lado, o custo dos esforços de fiabilidade pode ser superior ao custo de uma interrupção, incluindo fatores como requisitos de conformidade e reputação. Neste cenário, deve considerar o desinvestimento estratégico na conceção de fiabilidade.

Desvantagem: resiliência reduzida. Uma carga de trabalho incorpora medidas de resiliência para tentar evitar e suportar tipos e quantidades específicos de avarias.

  • Para poupar dinheiro, a equipa de carga de trabalho pode subaprovisionar um componente ou sobrecarregar o dimensionamento, o que torna o componente mais propenso a falhar durante picos repentinos na procura.

  • Consolidar recursos de carga de trabalho (densidade crescente) para otimização de custos torna os componentes individuais mais propensos a falhar durante picos de procura e durante operações de manutenção, como atualizações.

  • Remover componentes que suportam padrões de conceção de resiliência, como um barramento de mensagens, e criar uma dependência direta reduz as capacidades de auto-preservação.

  • Poupar dinheiro ao reduzir a redundância pode limitar a capacidade de uma carga de trabalho de lidar com avarias simultâneas.

  • A utilização de SKUs orçamentais pode limitar o objetivo máximo de nível de serviço (SLO) que a carga de trabalho pode alcançar.

  • Definir limites de gastos rígidos pode impedir que uma carga de trabalho seja dimensionado para satisfazer a procura legítima.

  • Sem ferramentas ou testes de teste de fiabilidade, a fiabilidade de uma carga de trabalho é desconhecida e é menos provável que cumpra os objetivos de fiabilidade.

Compromisso: estratégia de recuperação limitada. Uma carga de trabalho fiável tem um plano de recuperação e resposta a incidentes testado para cenários de desastre.

  • Testes reduzidos ou exploração do plano de recuperação após desastre de uma carga de trabalho podem afetar a velocidade e a eficácia das operações de recuperação.

  • Criar ou reter menos cópias de segurança diminui os pontos de recuperação possíveis e aumenta a probabilidade de perder dados.

  • Um contrato de suporte menos dispendioso pode aumentar o tempo de recuperação da carga de trabalho devido a potenciais atrasos na assistência técnica.

Desvantagem: maior complexidade. Uma carga de trabalho que utiliza abordagens simples e evita complexidades desnecessárias ou sobreengenhadas é geralmente mais fácil de gerir em termos de fiabilidade.

  • A utilização de padrões de cloud de otimização de custos pode adicionar novos componentes, como uma rede de entrega de conteúdos (CDN) ou transferir tarefas para dispositivos edge e cliente para os quais uma carga de trabalho tem de fornecer destinos de fiabilidade.

  • O dimensionamento baseado em eventos pode ser mais complicado de otimizar e validar do que o dimensionamento baseado em recursos.

  • A redução do volume de dados e do arrumo de dados através de ações de ciclo de vida de dados, possivelmente em conjunto com a implementação de pontos de dados agregados antes de um evento de ciclo de vida, introduz fatores de fiabilidade a considerar na carga de trabalho.

  • A utilização de regiões diferentes para otimizar os custos pode dificultar a gestão, a rede e a monitorização.

Compromissos de Otimização de Custos com Segurança

O custo de um compromisso com a confidencialidade, integridade e disponibilidade numa carga de trabalho deve ser sempre equilibrado face ao custo do esforço para evitar esse compromisso. Um incidente de segurança pode ter uma vasta gama de impactos financeiros e legais e prejudicar a reputação de uma empresa. Investir em segurança é uma atividade de mitigação de riscos. O custo de experienciar os riscos tem de ser equilibrado em relação ao investimento. Por regra, não se comprometa com a segurança para obter otimizações de custos que estejam abaixo do ponto de responsabilidade e aceites sobre a mitigação de riscos. Otimizar os custos de segurança ao atribuir direitos a soluções é uma prática de otimização importante, mas tenha em atenção as desvantagens como as seguintes ao fazê-lo.

Compromisso: controlos de segurança reduzidos. Os controlos de segurança são estabelecidos em várias camadas, por vezes redundantes, para fornecer defesa em profundidade.

Uma tática de otimização de custos é procurar formas de remover componentes ou processos que acumulem custos unitários ou operacionais. Tenha em atenção que a remoção de componentes de segurança, como os seguintes exemplos, para poupar dinheiro, afeta a segurança. Tem de efetuar cuidadosamente uma análise de risco sobre este impacto.

  • Reduzir ou simplificar técnicas de autenticação e autorização compromete o princípio verificar explicitamente a arquitetura de confiança zero. Exemplos destas simplificações incluem a utilização de um esquema de autenticação básico, como chaves pré-partilhadas, em vez de investir tempo para aprender as abordagens OAuth da indústria ou utilizar atribuições simplificadas de controlo de acesso baseado em funções para reduzir a sobrecarga de gestão.

  • A remoção da encriptação em trânsito ou inativo para reduzir os custos dos certificados e dos respetivos processos operacionais expõe dados a potenciais falhas de integridade ou confidencialidade.

  • Remover ou reduzir a análise de segurança, as ferramentas de inspeção ou os testes de segurança devido ao investimento de custo e tempo associados pode afetar diretamente a confidencialidade, integridade ou disponibilidade que as ferramentas e os testes se destinam a proteger.

  • Reduzir a frequência de aplicação de patches de segurança devido ao tempo operacional investido na catalogação e na execução da aplicação de patches afeta a capacidade de uma carga de trabalho lidar com ameaças em evolução.

  • Remover controlos de rede, como firewalls, pode levar a uma falha ao bloquear o tráfego de entrada e saída malicioso.

Desvantagem: maior área de superfície da carga de trabalho. O pilar Segurança prioriza uma área de superfície reduzida e contida para minimizar os vetores de ataque e a gestão de controlos de segurança.

Por vezes, os padrões de conceção da cloud que otimizam os custos exigem a introdução de componentes adicionais. Estes componentes adicionais aumentam a área de superfície da carga de trabalho. Os componentes e os dados dentro dos mesmos têm de ser protegidos, possivelmente de formas que ainda não são utilizadas no sistema. Estes componentes e dados estão, muitas vezes, sujeitos à conformidade. Exemplos de padrões que podem introduzir componentes incluem:

  • Utilizar o padrão Alojamento de Conteúdo Estático para descarregar dados para um novo componente da CDN.

  • Utilizar o padrão Chave Valet para descarregar o processamento e proteger o acesso a recursos à computação do cliente.

  • Utilizar o padrão de Redistribuição de Carga Queue-Based para suavizar os custos ao introduzir um barramento de mensagens.

Desvantagem: segmentação removida. O pilar Segurança prioriza a segmentação forte para suportar a aplicação de controlos de segurança direcionados e para controlar o raio de explosão.

Partilhar recursos, por exemplo, em situações multi-inquilinos ou colocalizar múltiplas aplicações numa plataforma de aplicações partilhadas, é uma abordagem para reduzir os custos ao aumentar a densidade e reduzir a superfície de gestão. Este aumento de densidade pode levar a preocupações de segurança como estas:

  • É mais fácil mover lateralmente entre componentes que partilham recursos. Um evento de segurança que compromete a disponibilidade do anfitrião da plataforma de aplicações ou de uma aplicação individual também tem um raio de explosão maior.

  • Os recursos colocalizados podem partilhar uma identidade de carga de trabalho e ter registos de auditoria menos significativos nos registos de acesso.

  • Os controlos de segurança de rede têm de ser suficientemente amplos para abranger todos os recursos colocalizados. Esta configuração pode violar o princípio do menor privilégio para alguns recursos.

  • A colocalizar aplicações ou dados diferentes num anfitrião partilhado pode levar à extensão dos requisitos de conformidade e controlos de segurança a aplicações ou dados que, de outra forma, estariam fora do âmbito. Este alargamento do âmbito requer um controlo de segurança adicional e um esforço de auditoria nos componentes colocalizados.

Compromissos de Otimização de Custos com Excelência Operacional

Compromisso: capacidades de ciclo de vida de desenvolvimento de software comprometidas (SDLC). O processo SDLC de uma carga de trabalho fornece rigor, consistência, especificidade e atribuição de prioridades à gestão de alterações numa carga de trabalho.

  • Reduzir os esforços de teste para poupar tempo e o custo associado ao pessoal de teste, recursos e ferramentas pode resultar em mais erros na produção.

  • Adiar o pagamento da dívida técnica para concentrar os esforços do pessoal em novas funcionalidades pode levar a ciclos de desenvolvimento mais lentos e a uma agilidade globalmente reduzida.

  • Privar a documentação para focar os esforços de pessoal no desenvolvimento de produtos pode levar a um tempo de integração mais longo para os novos funcionários, afetar a eficácia da resposta a incidentes e comprometer os requisitos de conformidade.

  • A falta de investimento na formação conduz a competências estagnadas, reduzindo a capacidade da equipa de adotar tecnologias e práticas mais recentes.

  • Remover as ferramentas de automatização para poupar dinheiro pode fazer com que o pessoal gaste mais tempo nas tarefas que já não são automatizadas. Também aumenta o risco de erros e inconsistências.

  • A redução dos esforços de planeamento, como o âmbito e a atribuição de prioridades à actividade, para reduzir as despesas pode aumentar a probabilidade de reformulação devido a especificações vagas e a uma implementação deficiente.

  • Evitar ou reduzir atividades de melhoria contínua, como retrospetivas e relatórios pós-incidente, para manter a equipa de carga de trabalho focada na entrega pode criar oportunidades perdidas para otimizar processos de rotina, não planeados e de emergência.

Desvantagem: observabilidade reduzida. A observabilidade é necessária para ajudar a garantir que uma carga de trabalho tem alertas significativos e uma resposta a incidentes com êxito.

  • Diminuir o volume de registos e métricas para poupar nos custos de armazenamento e transferência reduz a observabilidade do sistema e pode levar a:

    • Menos pontos de dados para criar alertas relacionados com fiabilidade, segurança e desempenho.
    • Lacunas de cobertura nas atividades de resposta a incidentes.
    • Observabilidade limitada em interações ou limites relacionados com segurança ou conformidade.
  • Os padrões de conceção da otimização de custos podem adicionar componentes a uma carga de trabalho, aumentando a sua complexidade. A estratégia de monitorização da carga de trabalho tem de incluir esses novos componentes. Por exemplo, alguns padrões podem introduzir fluxos que abrangem vários componentes ou processos de mudança do servidor para o cliente. Estas alterações podem aumentar a complexidade de correlacionar e controlar informações.

  • Um investimento reduzido nas ferramentas de observabilidade e na manutenção de dashboards eficazes pode diminuir a capacidade de aprender com a produção, validar escolhas de design e informar a conceção do produto. Esta redução também pode dificultar as atividades de resposta a incidentes e dificultar o cumprimento do objetivo de tempo de recuperação e do SLO.

Troca: Manutenção diferida. Espera-se que as equipas de carga de trabalho mantenham código, ferramentas, pacotes de software e sistemas operativos corrigidos e atualizados de forma oportuna e ordenada.

  • Permitir que os contratos de manutenção com fornecedores de ferramentas expirem pode resultar em funcionalidades de otimização perdidas, resoluções de erros e atualizações de segurança.

  • Aumentar o tempo entre patches de sistema para poupar tempo pode levar a correções de erros perdidas ou à falta de proteção contra ameaças de segurança em evolução.

Compromissos da Otimização de Custos com a Eficiência de Desempenho

Os pilares Otimização de Custos e Eficiência de Desempenho priorizam a maximização do valor de uma carga de trabalho. A Eficiência de Desempenho realça o cumprimento dos objetivos de desempenho sem gastar mais do que o necessário. A Otimização de Custos realça a maximização do valor produzido pelos recursos de uma carga de trabalho sem exceder os objetivos de desempenho. Como resultado, a Otimização de Custos geralmente melhora a Eficiência de Desempenho. No entanto, existem compromissos de Eficiência de Desempenho associados à Otimização de Custos. Estas desvantagens podem dificultar o alcance dos objetivos de desempenho e dificultar a otimização contínua do desempenho.

Contrapartida: recursos subaprovisionados ou subescalados. Uma carga de trabalho eficiente em termos de desempenho tem recursos suficientes para servir a procura, mas não tem sobrecarga excessiva não utilizada, mesmo quando os padrões de utilização flutuam.

  • Reduzir os custos ao reduzir os recursos pode privar aplicações de recursos. A aplicação poderá não conseguir lidar com flutuações significativas do padrão de utilização.

  • Limitar ou atrasar o dimensionamento para limitar ou reduzir os custos pode resultar numa oferta insuficiente para satisfazer a procura.

  • As definições de dimensionamento automático que reduzem verticalmente de forma agressiva para reduzir os custos podem deixar um serviço despreparado para picos repentinos na procura ou causar flutuações frequentes de dimensionamento (oscilação).

Contrapartida: falta de otimização ao longo do tempo. Avaliar os efeitos das alterações na funcionalidade, alterações nos padrões de utilização, novas tecnologias e abordagens diferentes na carga de trabalho é uma forma de tentar aumentar a eficiência.

  • Limitar o foco no desenvolvimento de conhecimentos especializados na otimização do desempenho para priorizar a entrega pode causar oportunidades perdidas para melhorar a eficiência de utilização de recursos.

  • Remover ferramentas de monitorização ou teste de desempenho de acesso aumenta o risco de problemas de desempenho não detetados. Também limita a capacidade de uma equipa de carga de trabalho executar em ciclos de medida/melhoria.

  • Negligenciar áreas propensas à degradação do desempenho, como os arquivos de dados, pode deteriorar gradualmente o desempenho das consultas e elevar a utilização geral do sistema.

Explore as vantagens dos outros pilares: