Projeto para otimização do uso

Obtenha o máximo de suas ferramentas e operações. Verifique se eles atendem aos requisitos funcionais e não funcionais da solução.

Diferentes serviços vêm com diferentes recursos e pontos de preço. Depois de escolher um plano, não deixe esses recursos serem desperdiçados. Encontre maneiras de usá-los completamente e obter o valor do seu dinheiro. Além disso, fique de olho em seus modelos de cobrança. É inteligente verificar se há um modelo de cobrança melhor que se ajuste a como você está realmente usando o serviço.

Cenário de exemplo

A Contoso University hospeda um sistema comercial off-the-shelf (COTS) que ajuda os docentes a gerenciar cursos e permite que os alunos se registrem. Ele está conectado a um sistema de gerenciamento educacional baseado em nuvem para o qual eles planejam mudar totalmente em alguns anos. Por enquanto, eles querem otimizar os custos nas partes de integração personalizadas.

A solução de tecnologia da oferta do 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 do Serviço de Aplicativo standard do Azure que costumava hospedar o site da universidade, mas não o faz mais. A função durável é um aplicativo Python que usa o Armazenamento do Azure. Ele sincroniza dados todas as noites do banco de dados MySQL com a API baseada em nuvem.

Usar o valor completo de seus recursos

Compre apenas o que você precisa, e use tudo o que você está pagando.

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

Desafio da Contoso

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

• A equipe nunca reavalia o SKU, portanto, 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.

Aplicando a abordagem e os 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 camada inferior que ainda dá suporte a funções duráveis, mas custa muito menos.

• Eles também verificam a SKU do MySQL e confirmam que ela tem direitos para a carga de trabalho atual.

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

Otimizar seu projeto de alta disponibilidade

Priorize a implantação de modelos ativo-ativo ou somente ativo em vez de ativo-passivo, como parte de seu plano de recuperação, se você já tiver pago pelos recursos.

Se seu projeto tiver como padrão o uso de modelos ativo-passivo, você poderá ter recursos ociosos que poderiam ser usados. A conversão para ativo-ativo pode permitir que você atenda aos requisitos de nivelamento de carga e intermitência de escala sem gastar demais. Se você conseguir atingir suas metas de recuperação com um modelo somente ativo, os custos desses recursos poderão ser completamente removidos.

Desafio da Contoso

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

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

• 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 cumprir as metas nesse cenário.

Aplicando a abordagem e os resultados

• A equipe de carga de trabalho reavalia o benefício do design de alta disponibilidade versus o custo do serviço ser o dobro de 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 eles estão satisfeitos de que ainda estarão em conformidade com seus destinos de recuperação, para que eles decidam eliminar a instância em espera.

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

Dimensionar inteligente com demanda

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

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

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 verticalmente ou pausar o serviço quando ele não estiver em uso.

Aplicando a abordagem e os resultados

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

• Eles exploram a movimentação da 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 regras de dimensionamento conforme necessário.

• Essas alterações ajudam a alinhar os custos com o uso real e reduzir o desperdício.