Desenvolva de acordo com as necessidades dos negócios

  • Artigo

Todas as decisões de design devem ser justificado por um requisito de negócios. Esse princípio de design pode parecer óbvio, mas é crucial ter em mente ao projetar aplicativos do Azure.

Seu aplicativo deve oferecer suporte a milhões ou a alguns milhares de usuários? Há grandes picos de tráfego ou uma carga de trabalho constante? Qual nível de interrupção de aplicativos é aceitável? Em última análise, os requisitos de negócios orientam essas considerações de design.

As recomendações a seguir ajudam você a projetar e criar soluções para atender aos requisitos de negócios:

  • Defina os objetivos de negócios, incluindo o RTO (objetivo de tempo de recuperação), o RPO (objetivo de ponto de recuperação) e a MTO (interrupção máxima tolerável). Esses números devem informar decisões sobre a arquitetura.

    Por exemplo, suponha que sua empresa exija um RTO muito baixo e um RPO muito baixo. Você pode optar por usar uma arquitetura com redundância de zona para atender a esses requisitos. Se sua empresa pode tolerar um RTO e RPO mais altos, a inclusão de redundância pode adicionar custo extra sem nenhum benefício comercial.

  • Considere os riscos de falha que você precisa mitigar. Siga a orientação Design para recuperação automática para projetar sua solução para ser resiliente a muitos tipos de modos de falha comuns. Considere se você precisa levar em conta situações menos prováveis, como uma área geográfica que está passando por um grande desastre natural que pode afetar todas as zonas de disponibilidade na região. Mitigar esses riscos incomuns geralmente é mais caro e envolve compensações significativas, portanto, tenha uma compreensão clara da tolerância do negócio ao risco.

  • Documente os SLAs (contratos de nível de serviço), e os SLOs (objetivos de nível de serviço), inclusive as métricas de desempenho e disponibilidade. Por exemplo, uma solução proposta pode oferecer 99,95% de disponibilidade. Se esse SLO atende ao SLA é uma decisão de negócios.

  • Modele aplicativos para seu domínio de negócios. Analise os requisitos de negócios e use esses requisitos para modelar a solução. Considere o uso de uma abordagem de design orientado a domínio (DDD) para criar modelos de domínio que refletem os processos de negócios e os casos de uso.

  • Defina requisitos funcionais e não funcionais. Os requisitos funcionais determinam se um aplicativo executa sua tarefa. Os requisitos não funcionais determinam o desempenho do aplicativo. Certifique-se de entender os requisitos não funcionais, como escalabilidade, disponibilidade e latência. Esses requisitos influenciam as decisões de design e opções de tecnologia.

  • Decomponha cargas de trabalho. Carga de trabalho neste contexto significa um recurso discreto ou uma tarefa de computação que pode ser logicamente separada de outras tarefas. As cargas de trabalho diferentes podem ter diferentes requisitos de disponibilidade, escalabilidade, consistência de dados e recuperação de desastres.

  • Planeje o crescimento. Uma solução pode oferecer suporte às necessidades atuais de número de usuários, volume de transações e armazenamento de dados, mas também precisa lidar com o crescimento sem grandes alterações de arquitetura. Além disso, considere que o modelo de negócios e os requisitos de negócios provavelmente serão alterados ao longo do tempo. Se o modelo de serviço e modelos de dados de um aplicativo forem muito rígidos, ficará difícil desenvolver o aplicativo para novos casos de uso e cenários.

  • Gerencie os custos. Em um aplicativo local tradicional, você paga antecipadamente pelo hardware como uma despesa de capital. Em um aplicativo de nuvem, você paga pelos recursos consumidos. Certifique-se de que compreende o modelo de preços dos seus serviços. Os custos totais incluem o uso de largura de banda de rede, armazenamento, endereços IP e consumo de serviço.

    Além disso, considere os custos operacionais. Na nuvem, você não precisa gerenciar o hardware ou outra infraestrutura, mas ainda precisa gerenciar DevOps de aplicativos, resposta a incidentes e recuperação de desastres.

Próximas etapas