Projetar com uma mentalidade de eficiência de custo

Gaste apenas o que você precisa para obter o maior retorno sobre o investimento.

Cada decisão arquitetônica afeta seu orçamento, como criar ou comprar, quais ferramentas você usa ou como licenciar e treinar. É importante avaliar essas opções e fazer compensações que ainda atendam às necessidades do seu aplicativo sem gastos excessivos.

Cenário de exemplo

A Contoso Manufacturing executa um WMS (sistema de gerenciamento de armazéns personalizado) que manipula seus quatro armazéns em toda a América do Sul. Eles querem atualizar e mover o WMS para a nuvem. Eles estão decidindo entre uma migração do tipo lift-and-shift da solução atual ou uma construção totalmente nova com ferramentas de nuvem modernas. A liderança quer manter os custos sob controle, de modo que a equipe precise de um plano que mantenha a eficiência de custos.

A solução WMS é um aplicativo .NET executado nos Serviços de Informações da Internet (IIS) e usa o SQL Server para seus bancos de dados.

Entender o custo total do seu design

Medir o custo total incorrido pelas escolhas de tecnologia e automação, levando em conta o impacto no retorno sobre o investimento (ROI). O projeto deve funcionar dentro dos limites aceitáveis para todos os requisitos funcionais e não funcionais. O projeto também deve ser flexível para acomodar a evolução prevista. Leve em conta o custo de aquisição, treinamento e gerenciamento de alterações.

A implantação de uma abordagem equilibrada que leve em conta o ROI evita o excesso de engenharia, o que pode aumentar os custos.

Desafio da Contoso

• A equipe de engenharia da Contoso está animada para mover seu sistema de armazéns para a nuvem, assim como outras equipes fizeram.

• Eles sabem que o aplicativo atual tem alguma dívida técnica, portanto, eles estão planejando reescrever grande parte do código do aplicativo e mudar para ferramentas nativas de nuvem mais recentes.

• A equipe de engenharia deseja reprojetar tudo em microsserviços e executá-lo no AKS (Serviço de Kubernetes do Azure), que é uma plataforma nova e empolgante para eles.

Aplicando a abordagem e os resultados

• A equipe está animada em fazer uma reformulação significativa durante a movimentação na nuvem, mas sabe que precisa manter o ROI da carga de trabalho. Portanto, eles devem manter as ferramentas que já conhecem e evitar grandes reescritas que exijam treinamento extra da equipe de engenharia.

• A equipe de carga de trabalho adota uma abordagem prática para projetar o sistema. Eles querem que seja econômico, atenda às expectativas e evite complicar demais as coisas. Para manter o ROI sob controle e tornar a migração tranquila, eles decidem usar uma solução equivalente na nuvem, como o Serviço de Aplicativo do Azure.

• Eles estabelecem uma linha de base de custo que contabiliza a infraestrutura, o licenciamento e os custos operacionais, bem como fatores menos óbvios, como treinamento para novas plataformas, regravação de código herdado e gerenciamento de alterações entre equipes. Eles ganham uma visão mais clara do que é viável dentro de seu orçamento, o que confirma sua decisão do Serviço de Aplicativo como o caminho mais familiar e de menor risco.

• Durante a migração, a equipe planeja limpar parte da dívida técnica que faz sentido enfrentar agora. Dessa forma, depois que tudo estiver em execução no Azure, eles estarão em um lugar melhor para continuar melhorando a plataforma, mantendo o ROI em mente ao fazer essas escolhas.

Refinar o projeto

Faça o ajuste fino do projeto priorizando os serviços que podem reduzir o custo geral, que não precisam de investimento adicional ou que não têm um impacto significativo na funcionalidade. A priorização deve levar em conta o modelo de negócios e as opções de tecnologia que geram alto ROI.

Você pode explorar opções mais baratas que podem habilitar a flexibilidade de recursos ou o dimensionamento dinâmico ou pode justificar o uso de investimentos existentes. Os parâmetros de priorização podem levar em conta os custos necessários para cargas de trabalho críticas, runtime e operações, além de outros custos que possam ajudar a equipe a trabalhar com mais eficiência.

Desafio da Contoso

• A carga de trabalho existente é hospedada em um dispositivo hiperconvergente (HCI) e o centro de custos da equipe é cobrado pelos custos de computação, rede e armazenamento.

• A carga de trabalho implantou os ambientes de pré-produção e produção em máquinas virtuais do Windows.

• O GitHub Actions com executores auto-hospedados é usado para executar trabalhos do GitHub Actions.

Aplicando a abordagem e os resultados

• Depois de avaliar várias opções nativas de nuvem, a equipe decide que mover os componentes da Web para o Serviço de Aplicativo forneceria compatibilidade de aplicativos do Windows IIS sem alterações significativas e não exigiria treinamento significativo.

• A equipe decide continuar usando o GitHub Actions com executores auto-hospedados, mas eles migrarão para um conjunto de dimensionamento de máquina virtual com capacidade de dimensionar para zero nós quando não estiverem sendo usados.

Projete sua arquitetura para suportar barreiras de custo

Configure limites de custo em sua arquitetura para manter os gastos dentro de um intervalo seguro e garantir que os custos do ambiente de nuvem sejam mantidos abaixo desses limites.

A imposição de limites ajuda a evitar encargos surpresa e garante que você use apenas o que realmente é orçado.

Desafio da Contoso

• O sistema atual não tem limites de custo, mas como raramente muda, ninguém é pressionado a adicioná-los.

• Os proprietários do ambiente HCI definiram um limite de recursos, portanto, a carga de trabalho não pode usar mais computação ou armazenamento do que o permitido.

• A equipe está preocupada que a mudança para a nuvem possa levar a custos inesperados, e eles não têm certeza de como evitar isso.

Aplicando a abordagem e os resultados

• A equipe aprende a usar soluções de Gerenciamento de Custos da Microsoft.

• Eles planejam definir limites de escala para os planos do Serviço de Aplicativo.

• Eles planejam configurar uma política de negação para impedir que determinadas SKUs de máquinas virtuais caras sejam usadas.

• Eles planejam adicionar automação para economizar no armazenamento. Dados mais antigos ou menos usados serão movidos automaticamente para camadas de armazenamento mais baratas, como frio ou arquivo morto. Esse tipo de automação não era possível em seu antigo ambiente de HCI.