Design para otimização de uso

Tire o máximo partido das suas ferramentas e operações. Certifique-se de que eles atendem aos requisitos funcionais e não funcionais da solução.

Diferentes serviços vêm com diferentes características e preços. Depois de escolher um plano, não deixe que esses recursos sejam desperdiçados. Encontre maneiras de usá-los plenamente e obter o valor do seu dinheiro. Além disso, fique de olho nos seus modelos de faturamento. É inteligente verificar se há um modelo de faturamento melhor que se adapte à forma como você está realmente usando o serviço.

Cenário de exemplo

A Universidade Contoso hospeda um sistema comercial pronto para uso (COTS) que ajuda o corpo docente a gerenciar cursos e permite que os alunos se registrem. Ele está conectado a um sistema de gerenciamento de educação baseado em nuvem para o qual eles planejam mudar totalmente em alguns anos. Por enquanto, eles querem otimizar os custos nas peças de integração personalizadas.

A solução tecnológica da oferta COTS é geralmente tratada como uma caixa preta, exceto por seu banco de dados, que é executado no Banco de Dados do Azure para MySQL. A integração personalizada é uma função durável do Azure que é executada em um plano padrão do Serviço de Aplicativo do Azure que costumava hospedar o site da universidade, mas não mais. A função durable é um aplicativo Python que usa o Armazenamento do Azure. Ele sincroniza dados todas as noites do banco de dados MySQL para a API baseada em nuvem.

Utilize o valor total dos seus recursos

Compre apenas o que precisa e use tudo o que está a pagar.

Alguns SKUs de recursos vêm com recursos internos para desempenho, segurança ou confiabilidade. Se estiver a pagar por eles, certifique-se de que os está a utilizar. E se você não precisar desses recursos, escolha um SKU mais simples para economizar dinheiro.

O desafio da Contoso

• A função durável é executada em um plano do Serviço de Aplicativo Padrão que foi originalmente dimensionado para um site público, mas esse site foi desativado desde então.

• A equipe nunca reavaliou o SKU, então eles ainda estão pagando por recursos e capacidade que não usam.

• Eles não têm certeza de quais recursos são realmente necessários para a carga de trabalho de integração.

Aplicação da abordagem e dos resultados

• A equipe analisa o plano atual do Serviço de Aplicativo e conclui que a integração não requer o mesmo nível de escalabilidade ou desempenho e pode ser suportada por uma configuração de camada inferior.

• Eles movem a função para um plano de nível inferior que ainda suporta funções duráveis, mas custa muito menos.

• Eles também verificam seu SKU MySQL e confirmam que ele está protegido para a carga de trabalho atual.

• Essas alterações ajudam a reduzir custos sem afetar o desempenho ou a confiabilidade.

Otimize seu projeto de alta disponibilidade

Priorize a implantação de ativo-ativo ou somente ativo sobre modelos ativo-passivo, como parte do seu plano de recuperação, se você já pagou pelos recursos.

Se o seu design usar como padrão modelos ativo-passivo, você pode ter recursos ociosos que poderiam ser usados de outra forma. A conversão para ativo-ativo pode permitir que você atenda aos seus requisitos de nivelamento de carga e dimensionamento sem gastar demais. Se você puder atingir suas metas de recuperação com um modelo somente ativo, os custos desses recursos poderão ser removidos completamente.

O desafio da Contoso

• O aplicativo COTS usa o Banco de Dados do Azure para o Servidor Flexível MySQL configurado para alta disponibilidade na mesma zona, que fornece um servidor em espera na mesma zona de disponibilidade que o servidor primário. Eles também habilitaram backups automáticos.

• O objetivo de ponto de recuperação (RPO) da carga de trabalho é relativamente longo em 12 horas, e o objetivo de tempo de recuperação (RTO) é de três horas durante o dia letivo.

• Com base em testes de recuperação anteriores, a equipe sabe que pode atingir suas metas de RPO e RTO por meio de failover automático para o servidor em espera. Eles também testaram a recuperação do banco de dados a partir de um backup e podem atingir as metas nesse cenário.

Aplicação da abordagem e dos resultados

• A equipe de carga de trabalho reavalia o benefício do design de alta disponibilidade em comparação com o custo do serviço ser duas vezes maior do que uma única instância.

• A equipe testa a criação de uma nova instância e a recuperação de um banco de dados do backup e está satisfeita de que ainda estará em conformidade com suas metas de recuperação, por isso decide eliminar a instância em espera.

• A equipe atualiza o plano de recuperação de desastres para refletir a nova estratégia de recuperação e realizar a economia de custos por meio da nova configuração.

Dimensione de forma inteligente com a demanda

Ajuste a capacidade com base no que você realmente precisa.

Em vez de provisionar para uso de pico o tempo todo, aumente a escala quando a demanda aumentar e diminua quando ela cair. Essa abordagem mantém seus custos alinhados com o uso real.

O desafio da Contoso

• A função de integração é executada todas as noites, mas o plano do Serviço de Aplicativo sempre permanece ativo.

• Eles estão pagando por recursos de computação que ficam ociosos a maior parte do dia.

• Eles não exploraram opções para reduzir ou pausar o serviço quando ele não está em uso.

Aplicação da abordagem e dos resultados

• A equipe configura o plano do Serviço de Aplicativo para reduzir o horário de expediente.

• Eles exploram mover a função para os Aplicativos de Contêiner do Azure ou o plano de Consumo do Azure Functions, que pode ser dimensionado para zero.

• Eles também configuram alertas para monitorar o uso e ajustar as regras de dimensionamento conforme necessário.

• Estas alterações ajudam-nos a alinhar os custos com a utilização real e a reduzir o desperdício.