Recomendações para projetar com simplicidade e eficiência
Aplica-se a esta recomendação da lista de verificação de Fiabilidade do Azure Well-Architected Framework:
| RE:01 | Projete sua carga de trabalho para se alinhar com os objetivos de negócios e evitar complexidade ou sobrecarga desnecessárias. Use uma abordagem prática e equilibrada para tomar decisões de design que entreguem os resultados desejados. Contenha o seu projeto de acordo com as necessidades para reduzir ineficiências e potenciais problemas. |
|---|
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
| Termo | Definição |
|---|---|
| Carga de trabalho | Uma capacidade discreta ou tarefa de computação que você pode separar logicamente de outras tarefas. |
Principais estratégias de design
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.
Compensação: uma solução complexa pode oferecer mais recursos e flexibilidade, mas pode afetar a confiabilidade da carga de trabalho porque requer mais coordenação, comunicação e gerenciamento de 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 seu projeto em fluxos críticos para ajudá-lo a determinar os componentes necessários e a 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 executar a análise do modo 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 obter mais informações, consulte Recomendações para executar a análise do modo 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 metas de confiabilidade.
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 a engenharia excessiva ou insuficiente da 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.
Use 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.
Use mensagens assíncronas para separar o produtor de mensagens 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:
Use os recursos da plataforma quando eles atenderem aos seus requisitos de negócios. 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:
Arquivos 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 obter mais informações, consulte Compreender 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, armazene:
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.
Logs de aplicativos na Pesquisa Cognitiva do Azure.
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.
Sintonize para o 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 as transações de compensação para desfazer todas as etapas 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 vinculado é mapeado para um subdomínio do domínio empresarial. 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:
O Azure Functions é um serviço de computação sem servidor que você pode usar para criar orquestração com código mínimo.
Os Aplicativos Lógicos do Azure são uma plataforma de integração de fluxo de trabalho sem servidor que você pode usar para criar orquestração com uma GUI ou editando um arquivo de configuração.
A Grade de Eventos do Azure é um serviço de distribuição de mensagens de publicação-assinatura altamente escalável e totalmente gerenciado que oferece padrões flexíveis de consumo de mensagens que usam 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
- Rever as opções de dados
Exemplo
Para obter um exemplo de carga de trabalho que determina componentes e seus recursos com base nos requisitos, consulte Padrão de aplicativo Web confiável.
Ligações relacionadas
Lista de verificação de fiabilidade
Consulte o conjunto completo de recomendações.