Desenvolva de acordo com as necessidades dos negócios
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 em funcionalidades discretas. Uma carga de trabalho é uma coleção de recursos de aplicativos, dados e infraestrutura de suporte que funcionam juntos para alcançar resultados de negócios definidos. Uma carga de trabalho consiste em componentes e também em procedimentos operacionais e de desenvolvimento. As cargas de trabalho geralmente podem ser decompostas em funcionalidades discretas que se alinham com fluxos de usuários, dados ou sistemas e esses fluxos podem receber valor e ter requisitos não funcionais.
Diferentes fluxos de usuários, dados ou sistema geralmente têm diferentes requisitos de disponibilidade, escalabilidade, consistência de dados e recuperação de desastres. Sistemas bem projetados permitem otimizar seu projeto por fluxo. Para conseguir isso, você deve dividir as cargas de trabalho em componentes ajustáveis. Uma estratégia típica envolve categorizar componentes com base em seu valor. Por exemplo, os componentes de Nível 1 são cruciais e devem ser otimizados sem levar em conta as despesas. Os componentes de nível 2 são significativos, mas podem ser reduzidos temporariamente com consequências mínimas. Os componentes de nível 3 são opcionais. Mantenha-os econômicos e facilmente gerenciáveis. Estabelecer uma compreensão compartilhada do valor dos fluxos ajuda todos a projetar e desenvolver uma carga de trabalho para a manter um equilíbrio entre custo e outros requisitos não funcionais.
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.
Alinhe o modelo de negócios e o custo. A longevidade de um sistema é influenciada pela eficácia com que seus custos se alinham com o modelo de negócios. Como arquiteto, você deve considerar os geradores de valor e usar esse insight para orientar suas decisões. Você deve identificar a dimensão na qual sua solução fornecerá valor (como lucratividade) e, em seguida, garantir que a arquitetura siga o fluxo de valor. Dessa forma, sua arquitetura pode maximizar o valor do investimento, gerando um retorno sobre o investimento (ROI) alinhado às expectativas de negócios.
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.