Construa de acordo com as necessidades do negócio
Cada decisão de conceção tem de ser justificada por um requisito comercial. Esse princípio de design pode parecer óbvio, mas é crucial ter em mente ao projetar aplicativos do Azure.
Seu aplicativo deve suportar milhões de usuários ou alguns milhares? Há grandes explosões de tráfego ou uma carga de trabalho constante? Que nível de interrupção de aplicação é 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 objetivos de negócios, como RTO (Recovery Time Objetive, objetivo de tempo de recuperação), RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e MTO (Maximum Tolerable Outage, interrupção máxima tolerável). Estes números devem informar as 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 a sua empresa pode tolerar um RTO e RPO mais altos, adicionar redundância pode adicionar um custo extra sem nenhum benefício comercial.
Considere os riscos de falha que você precisa mitigar. Siga a orientação Design for self-healing 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 da empresa ao risco.
Documente contratos de nível de serviço (SLAs) e objetivos de nível de serviço (SLOs), incluindo métricas de disponibilidade e desempenho. 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 aplicações para o seu domínio de negócio. Analise os requisitos de negócios e use esses requisitos para modelar a solução. Considere o uso de uma abordagem de design controlado por domínio (DDD) para criar modelos de domínio que reflitam seus processos de negócios e casos de uso.
Definir 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 as escolhas tecnológicas.
Decomponha cargas de trabalho em funcionalidade discreta. 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ário, dados ou sistema e esses fluxos podem ser atribuídos valor e ter requisitos não funcionais.
Diferentes fluxos de usuários, dados ou sistemas geralmente têm requisitos diferentes de disponibilidade, escalabilidade, consistência de dados e recuperação de desastres. Sistemas bem projetados permitem que você otimize 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; mantê-los rentáveis e facilmente gerenciáveis. Estabelecer uma compreensão compartilhada do valor dos fluxos ajuda todos que projetam e desenvolvem uma carga de trabalho a manter um equilíbrio entre o custo e outros requisitos não funcionais.
Planeie o crescimento. Uma solução pode suportar as 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 na arquitetura. Considere também que seu modelo de negócios e requisitos de negócios podem mudar ao longo do tempo. É difícil desenvolver uma solução para novos casos de uso e cenários se o modelo de serviço e os modelos de dados do aplicativo forem muito rígidos.
Alinhe o modelo de negócios e o custo. A longevidade de um sistema é influenciada pela eficácia com que os seus custos se alinham com o modelo de negócio. Como arquiteto, você deve considerar os fatores de valor e usar essa perceção para orientar suas decisões. Você deve identificar a dimensão na qual sua solução fornecerá valor (como rentabilidade) e, em seguida, certificar-se de 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 do negócio.
Faça a gestão dos custos. Em um aplicativo local tradicional, você paga antecipadamente pelo hardware como uma despesa de capital. Em um aplicativo na nuvem, você paga pelos recursos que consome. Certifique-se de que compreende o modelo de preços dos seus serviços. Os custos totais podem incluir o uso da largura de banda da rede, armazenamento, endereços IP e consumo de serviço.
Considere também os custos operacionais. Na nuvem, você não precisa gerenciar hardware ou infraestrutura, mas ainda precisa gerenciar DevOps de aplicativos, resposta a incidentes e recuperação de desastres.