Estratégias de arquitetura para projetar para simplicidade e eficiência

Aplica-se a esta recomendação da lista de verificação de Fiabilidade do Azure Well-Architected Framework:

Este guia descreve as recomendações para minimizar a complexidade e a sobrecarga desnecessárias para manter suas cargas de trabalho simples e eficientes. Escolha os melhores componentes para executar as tarefas de carga de trabalho necessárias para otimizar a confiabilidade da sua carga de trabalho. Para diminuir os encargos de desenvolvimento e gerenciamento, aproveite as eficiências oferecidas pelos serviços fornecidos pela plataforma. Esse design ajuda a criar uma arquitetura de carga de trabalho resiliente, repetível, escalável e gerenciável.

Definições

Um princípio fundamental do design para confiabilidade é manter as coisas simples e eficientes. Concentre seu projeto de carga de trabalho em atender aos requisitos de negócios para reduzir o risco de complexidade desnecessária ou sobrecarga excessiva. Considere as recomendações neste artigo para ajudá-lo a tomar decisões sobre seu design para criar uma carga de trabalho enxuta, eficiente e confiável. Cargas de trabalho diferentes podem ter requisitos diferentes de disponibilidade, escalabilidade, consistência de dados e recuperação de desastres.

Você deve justificar cada decisão de design com um requisito de negócios. Esse princípio de design pode parecer óbvio, mas é crucial para o design da carga de trabalho. Seu aplicativo suporta 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? Os requisitos de negócios orientam essas considerações de design.

Compromisso: uma solução complexa pode oferecer mais funcionalidades e flexibilidade, mas poderá afetar a fiabilidade da carga de trabalho, porque exige mais coordenação, comunicação e gestão dos componentes. Como alternativa, uma solução mais simples pode não atender totalmente às expectativas do usuário ou pode ter um efeito negativo na escalabilidade e extensibilidade à medida que a carga de trabalho evolui.

Colabore com as partes interessadas em exercícios de design

Trabalhar com as partes interessadas para:

• Defina e atribua um nível de criticidade aos fluxos de usuários e fluxos do sistema da sua carga de trabalho. Concentre a sua conceção nos fluxos críticos para o ajudar a determinar os componentes necessários e na melhor abordagem para atingir o nível de resiliência necessário.

• Definir requisitos funcionais e não funcionais. Considere os requisitos funcionais para determinar se um aplicativo executa uma tarefa. Considere os requisitos não funcionais para determinar o quão bem o aplicativo executa uma tarefa. 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 componentes. Priorize a simplicidade, a eficiência e a confiabilidade em seu projeto. Determine os componentes de que você precisa para dar suporte aos seus fluxos. Alguns componentes suportam vários fluxos. Identifique qual desafio um componente aborda conceitualmente e considere remover um componente de fluxos individuais para simplificar o projeto geral e, ao mesmo tempo, fornecer funcionalidade completa. Para obter mais informações, consulte Recomendações para realizar a análise dos modos de falha.

• Use a análise do modo de falha para identificar pontos únicos de falha e riscos potenciais. Considere se você precisa levar em conta situações improváveis, por exemplo, uma área geográfica que sofre um grande desastre natural que afeta todas as zonas de disponibilidade na região. É caro e envolve compensações significativas para mitigar esses riscos incomuns. Compreenda claramente a tolerância da sua empresa ao risco. Para mais informações, consulte Recomendações para realizar a análise dos modos de falha.

• Defina metas de disponibilidade e recuperação para seus fluxos para informar a arquitetura da carga de trabalho. As métricas de negócios incluem SLOs (Service Level Objetives, objetivos de nível de serviço), contratos de nível de serviço (SLAs), tempo médio de recuperação (MTTR), tempo médio entre falhas (MTBF), RTOs (Recovery Time Objetives, objetivos de tempo de recuperação) e RPOs (Recovery Point Objetives, objetivos de ponto de recuperação). Defina valores de destino para essas métricas. Esse exercício pode exigir compromisso e entendimento mútuo entre as equipes de tecnologia e de negócios para garantir que as metas de cada equipe atendam aos objetivos de negócios e sejam realistas. Para obter mais informações, consulte Recomendações para definir objetivos de fiabilidade.

Privilegie escolhas de design mais simples

Você pode executar as seguintes recomendações sem o envolvimento das partes interessadas:

• Procure simplicidade e clareza no seu design. Use o nível apropriado de abstração e granularidade para seus componentes e serviços. Evite sobredimensionar ou subdimensionar a sua solução. Por exemplo, se você dividir seu código em várias funções pequenas, será difícil entender, testar e manter.

• Admita que todos os aplicativos bem-sucedidos mudam ao longo do tempo, seja para corrigir bugs, implementar novos recursos ou tecnologias ou tornar os sistemas existentes mais escaláveis e resilientes.

• Utilize opções de plataforma como serviço (PaaS) em vez de infraestrutura como serviço (IaaS), quando possível. O IaaS é como ter uma caixa de peças. Pode criar o que quiser, mas a montagem está a seu cargo. As opções de PaaS são mais fáceis de configurar e administrar. Não é necessário configurar máquinas virtuais (VMs) ou redes virtuais. Você também não precisa executar tarefas de manutenção, como instalar patches e atualizações.

• Reduzir as dependências fortemente acopladas entre componentes da carga de trabalho para ajudar a diminuir o risco de falhas em cascata durante interrupções parciais. Por exemplo, a mensagem assíncrona é uma boa abordagem para desacoplar o produtor da mensagem do consumidor.

• Abstraia a infraestrutura da lógica do domínio. Certifique-se de que a lógica do domínio não interfira com a funcionalidade relacionada à infraestrutura, como mensagens ou persistência.

• Passe as questões transversais para um serviço separado. Minimize a necessidade de duplicar código em diferentes funções, prefira reutilizar serviços com interfaces bem definidas que podem ser facilmente consumidas por diferentes componentes. Por exemplo, se vários serviços precisarem autenticar solicitações, você poderá mover essa funcionalidade para seu próprio serviço. Em seguida, você pode evoluir o serviço de autenticação. Por exemplo, você pode adicionar um novo fluxo de autenticação sem tocar em nenhum dos serviços que o usam.

• Avalie a adequação de padrões e práticas comuns às suas necessidades. Evite seguir tendências ou recomendações que possam não ser as melhores para o seu contexto ou requisitos. Por exemplo, os microsserviços não são a melhor opção para todos os aplicativos porque podem introduzir problemas de complexidade, sobrecarga e dependência.

Desenvolva apenas código suficiente

Os princípios de simplicidade, eficiência e confiabilidade também se aplicam às suas práticas de desenvolvimento. Em uma carga de trabalho fracamente acoplada e componentizada, determine a funcionalidade que um componente fornece. Desenvolva seus fluxos para aproveitar essa funcionalidade. Considere estas recomendações para suas práticas de desenvolvimento:

• Utilize os recursos da plataforma quando estes satisfizerem os seus requisitos empresariais. Por exemplo, para descarregar o desenvolvimento e o gerenciamento, use soluções low-code, no-code ou sem servidor que seu provedor de nuvem oferece.

• Use bibliotecas e estruturas.

• Introduza programação em pares ou sessões dedicadas de revisão de código como uma prática de desenvolvimento.

• Implemente uma abordagem para identificar código morto. Seja cético em relação ao código que seus testes automatizados não cobrem.

Selecione o armazenamento de dados correto

No passado, muitas organizações armazenavam todos os seus dados em grandes bancos de dados SQL relacionais. Os bancos de dados relacionais fornecem garantias atômicas, consistentes, isoladas e duráveis (ACID) para transações de dados relacionais. Mas estas bases de dados apresentam desvantagens:

• As consultas podem exigir junções dispendiosas.

• Você precisa normalizar os dados e reestruturá-los para esquema na gravação.

• A contenção de bloqueio pode afetar o desempenho.

Alternativas aos bancos de dados relacionais

Em uma solução grande, uma única tecnologia de armazenamento de dados provavelmente não atende a todas as suas necessidades. As alternativas aos bancos de dados relacionais incluem:

• Armazenamentos de chave-valor

• Bases de dados de documentos

• Bases de dados de motores de pesquisa

• Bases de dados de séries temporais

• Bancos de dados da família de colunas

• Bases de dados de grafos

Cada opção tem prós e contras. Diferentes tipos de dados são mais adequados para diferentes tipos de armazenamento de dados. Escolha a tecnologia de armazenamento mais adequada aos seus dados e à forma como os utiliza.

Por exemplo, você pode armazenar um catálogo de produtos em um banco de dados de documentos, como o Azure Cosmos DB, que dá suporte a um esquema flexível. Cada descrição do produto é um documento independente. Para consultas em todo o catálogo, você pode indexar o catálogo e armazenar o índice na Pesquisa Cognitiva do Azure. O inventário de produtos pode ir para um banco de dados SQL porque esses dados exigem garantias ACID.

Recomendações

• Considere outros armazenamentos de dados. Os bancos de dados relacionais nem sempre são apropriados. Para mais informações, consulte Compreender os modelos de armazenamento de dados.

• Lembre-se de que os dados incluem mais do que apenas dados de aplicativos persistentes. Também incluem as caches, as mensagens, os eventos e os registos da aplicação.

• Adote a persistência poliglota ou soluções que usam uma combinação de tecnologias de armazenamento de dados.

• Considere o tipo de dados que você tem. Por exemplo, guarde:

  • Dados transacionais em um banco de dados SQL.

  • Documentos JSON numa base de dados documental.

  • Telemetria em um banco de dados de séries temporais.

  • Registos da aplicação no Azure Cognitive Search.

  • Blobs no Armazenamento de Blobs do Azure.

• Priorize a disponibilidade em detrimento da consistência. O teorema CAP implica que você tem que fazer compensações entre disponibilidade e consistência em um sistema distribuído. Você não pode evitar completamente as partições de rede, que é o outro componente do teorema CAP. Mas você pode adotar um eventual modelo de consistência para obter maior disponibilidade.

• Considere o conjunto de habilidades de sua equipe de desenvolvimento. A utilização da persistência poliglota tem as suas vantagens, mas é muito fácil cair no exagero. Requer novos conjuntos de habilidades para adotar uma nova tecnologia de armazenamento de dados. Para tirar o máximo proveito da tecnologia, sua equipe de desenvolvimento deve:

  • Otimize consultas.

  • Otimize para um melhor desempenho.

  • Trabalhe com os padrões de uso apropriados.

Considere estes fatores ao escolher uma tecnologia de armazenamento:

• Utilize transações de compensação. Com a persistência poliglota, uma única transação pode gravar dados em vários armazenamentos. Se houver uma falha, use transações de compensação para desfazer quaisquer etapas que tenham sido concluídas.

• Considere contextos limitados, que é um conceito de design orientado por domínio. Um contexto delimitado é um limite explícito em torno de um modelo de domínio. Um contexto delimitado define a quais partes do domínio o modelo se aplica. Idealmente, um contexto delimitado corresponde a um subdomínio do domínio de negócio. Considere a persistência poliglota para contextos limitados em seu sistema. Por exemplo, os produtos podem aparecer no subdomínio do catálogo de produtos e no subdomínio do inventário de produtos. Mas, muito provavelmente, esses dois subdomínios têm requisitos diferentes para armazenar, atualizar e consultar produtos.

Facilitação do Azure

O Azure oferece os seguintes serviços:

• Funções do Azure é um serviço de computação sem servidor que pode utilizar para criar orquestrações com o mínimo de código.

• Azure Logic Apps é uma plataforma de integração de fluxos de trabalho sem servidor que pode utilizar para criar orquestrações com uma GUI ou através da edição de um ficheiro de configuração.

• Azure Event Grid é um serviço de distribuição de mensagens de publicação-subscrição, altamente escalável e totalmente gerido, que oferece padrões flexíveis de consumo de mensagens que suportam os protocolos MQTT e HTTP. Com o Event Grid, você pode criar pipelines de dados com dados de dispositivo, criar arquiteturas sem servidor orientadas a eventos e integrar aplicativos.

Para obter mais informações, consulte:

• Escolher um serviço de computação do Azure
• Escolha uma opção de computação para microsserviços
• Reveja as opções de dados

Exemplo

Para obter um exemplo de carga de trabalho que determina os componentes e os respetivos recursos com base nos requisitos, consulte Padrão de Aplicação Web Fiável.

Ligações relacionadas

• Azure serverless
• Aplicações nativas da cloud
• Tipos de bases de dados no Azure

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.