Recomendações para projetar para simplificar e eficiência

  • Artigo

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

RE:01 Crie sua carga de trabalho para se alinhar aos 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 fornecem os resultados desejados. Contenha seu design para as necessidades para reduzir ineficiências e possíveis 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 carga de trabalho. Para diminuir seus encargos de desenvolvimento e gerenciamento, aproveite a eficiência que os serviços fornecidos pela plataforma oferecem. Esse design ajuda você a criar uma arquitetura de carga de trabalho resiliente, repetível, escalonável e gerenciável.

Definições

Termo Definição
Carga de trabalho Uma tarefa de computação ou funcionalidade discreta 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 design de carga de trabalho em atender aos requisitos de negócios para reduzir o risco de complexidade desnecessária ou excesso de sobrecarga. 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 para 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 dá suporte a milhões de usuários ou alguns milhares? Há grandes intermitências de tráfego ou uma carga de trabalho estável? Qual nível de interrupção do aplicativo é aceitável? Os requisitos de negócios impulsionam 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.

Exercícios de design colaborativo

Trabalhe com os stakeholders para:

  • Defina e atribua um nível de criticalidade aos fluxos de usuário e fluxos do sistema da carga de trabalho. Concentre seu design em fluxos críticos para ajudá-lo a determinar os componentes necessários e a melhor abordagem para alcançar 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 desempenho do aplicativo em uma tarefa. Verifique se você entende os requisitos não funcionais, como escalabilidade, disponibilidade e latência. Esses requisitos influenciam as decisões de design e as escolhas de tecnologia.

  • Decompor cargas de trabalho em componentes. Priorize a simplicidade, a eficiência e a confiabilidade em seu design. Determine os componentes necessários para dar suporte aos fluxos. Alguns componentes dão suporte a vários fluxos. Identifique qual desafio um componente aborda conceitualmente e considere remover um componente de fluxos individuais para simplificar o design 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 possíveis riscos. Considere se você precisa considerar situações improváveis, por exemplo, uma área geográfica que experimenta 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. Entenda claramente a tolerância do seu negócio ao risco. Para obter mais informações, consulte Recomendações para executar a análise do modo de falha.

  • Defina destinos de disponibilidade e recuperação para seus fluxos para informar a arquitetura da carga de trabalho. As métricas de negócios incluem SLOs (objetivos de nível de serviço), SLAs (contratos de nível de serviço), MTTR (tempo médio de recuperação), MTBF (tempo médio entre falha), RTOs (objetivos de tempo de recuperação) e RPOs (objetivos de ponto de recuperação). Defina valores de destino para essas métricas. Este exercício pode exigir comprometimento e compreensão mútua entre equipes de tecnologia e 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 destinos de confiabilidade.

Recomendações adicionais de design

Você pode executar as seguintes recomendações sem o envolvimento dos stakeholders:

  • Esforce-se pela simplicidade e clareza em seu design. Use o nível apropriado de abstração e granularidade para seus componentes e serviços. Evite a superengenharia ou subprojetar sua solução. Por exemplo, se você dividir seu código em várias funções pequenas, é 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 escalonáveis e resilientes.

  • Use opções de PaaS (plataforma como serviço) em vez de IaaS (infraestrutura como serviço) quando possível. O IaaS é como ter uma caixa de peças. Você pode criar qualquer coisa, mas deve montar por conta própria. As opções de PaaS são mais fáceis de configurar e de administrar. Você não precisa configurar VMs (máquinas virtuais) 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 desacoplar o produtor de mensagens do consumidor.

  • Infraestrutura abstrata distante da lógica do domínio. Verifique se a lógica de domínio não interfere na funcionalidade relacionada à infraestrutura, como mensagens ou persistência.

  • Descarregar preocupações abrangentes 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 desenvolver 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 para suas necessidades. Evite seguir tendências ou recomendações que podem não ser melhores para seu contexto ou requisitos. Por exemplo, os microsserviços não são a melhor opção para cada aplicativo, pois podem introduzir problemas de complexidade, sobrecarga e dependência.

Desenvolver 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 flexívelmente acoplada e com componentes, 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 atenderem aos seus requisitos de negócios. Por exemplo, para descarregar o desenvolvimento e o gerenciamento, use soluções de baixo código, sem código ou sem servidor oferecidas pelo provedor de nuvem.

  • Use bibliotecas e estruturas.

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

  • Implemente uma abordagem para identificar o código morto. Seja cético quanto ao código que seus testes automatizados não abrangem.

Usar o melhor armazenamento de dados para seus dados

No passado, muitas organizações armazenavam todos os próprios 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 esses bancos de dados vêm com desvantagens:

  • As consultas podem exigir junções caras.

  • Você precisa normalizar os dados e reestruturá-los para o esquema ao gravar.

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

Alternativas a 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:

  • Repositórios de chave-valor

  • Bancos de dados de documentos

  • Bancos de dados de mecanismo de pesquisa

  • Bancos de dados de séries temporais

  • Bancos de dados de família de coluna

  • Bancos de dados de grafo

Cada opção tem prós e contras. Tipos de dados diferentes são mais adequados para diferentes tipos de armazenamento de dados. Escolha a tecnologia de armazenamento mais adequada aos seus dados e como usá-la.

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 no Azure Cognitive Search. O inventário de produtos pode entrar em 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 Noções básicas sobre modelos de armazenamento de dados.

  • Lembre-se de que os dados incluem mais do que apenas os dados de aplicativo persistentes. Eles também incluem logs de aplicativo, eventos, mensagens e caches.

  • 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 em um banco de dados de documento.

    • Telemetria em um banco de dados de série temporal.

    • Logs de aplicativo no Azure Cognitive Search.

    • Blobs em Armazenamento de Blobs do Azure.

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

  • Considere o conjunto de habilidades da sua equipe de desenvolvimento. Há vantagens em usar a persistência poliglota, mas é possível exagerar. Ele requer novos conjuntos de habilidades para adotar uma nova tecnologia de armazenamento de dados. Para aproveitar ao máximo a tecnologia, sua equipe de desenvolvimento deve:

    • Otimize as consultas.

    • Ajustar para desempenho.

    • Trabalhe com os padrões de uso apropriados.

Considere estes fatores ao escolher uma tecnologia de armazenamento:

  • Use transações de compensação. Com a persistência poliglota, uma única transação pode gravar dados em vários repositórios. Se houver uma falha, use transações de compensação para desfazer as etapas concluídas.

  • Considere contextos limitados, que é um conceito de design controlado por domínio. Um contexto limitado é um limite explícito em torno de um modelo de domínio. Um contexto limitado define a quais partes do domínio o modelo se aplica. Idealmente, um contexto limitado é mapeado para um subdomínio do domínio da empresa. 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 de inventário de produtos. Mas, 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:

  • 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.

  • Grade de Eventos do Azure é um serviço de distribuição de mensagens de publicação-assinatura altamente escalonável e totalmente gerenciado que oferece padrões flexíveis de consumo de mensagens que usam os protocolos MQTT e HTTP. Com a Grade de Eventos, você pode criar pipelines de dados com dados do dispositivo, criar arquiteturas sem servidor controladas por eventos e integrar aplicativos.

Para obter mais informações, consulte:

Exemplo

Para obter um exemplo de carga de trabalho que determina componentes e seus recursos com base em requisitos, consulte Padrão de aplicativo Web confiável.

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade