Recomendações para conceber a simplicidade e a eficiência

  • Artigo

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

RE:01 Crie a carga de trabalho para se alinhar com os objetivos empresariais e evitar complexidades ou sobrecargas desnecessárias. Utilize uma abordagem prática e equilibrada para tomar decisões de design que fornecem os resultados pretendidos. Contenham a sua estrutura para as necessidades de reduzir ineficiências e potenciais problemas.

Este guia descreve as recomendações para minimizar a complexidade e a sobrecarga desnecessárias para manter as cargas de trabalho simples e eficientes. Escolha os melhores componentes para realizar as tarefas de carga de trabalho necessárias para otimizar a fiabilidade da carga de trabalho. Para diminuir os encargos de desenvolvimento e gestão, tire partido das eficiências que os serviços fornecidos pela plataforma oferecem. Este design ajuda-o a criar uma arquitetura de carga de trabalho resiliente, repetível, dimensionável e gerível.

Definições

Termo Definição
Carga de trabalho Uma capacidade discreta ou tarefa de computação que pode separar logicamente de outras tarefas.

Principais estratégias de conceção

Um princípio fundamental da conceção de fiabilidade é manter as coisas simples e eficientes. Concentre a estrutura da carga de trabalho em cumprir os requisitos empresariais para reduzir o risco de complexidade desnecessária ou excesso de sobrecarga. Considere as recomendações neste artigo para o ajudar a tomar decisões sobre a sua estrutura para criar uma carga de trabalho magra, eficiente e fiável. Diferentes cargas de trabalho podem ter diferentes requisitos de disponibilidade, escalabilidade, consistência de dados e recuperação após desastre.

Tem de justificar todas as decisões de conceção com um requisito empresarial. Este princípio de design pode parecer óbvio, mas é crucial para o design da carga de trabalho. A sua aplicação suporta milhões de utilizadores ou alguns milhares? Existem grandes picos de tráfego ou uma carga de trabalho estável? Que nível de indisponibilidade da aplicação é aceitável? Os requisitos empresariais impulsionam estas considerações de design.

Desvantagem: uma solução complexa pode oferecer mais funcionalidades e flexibilidade, mas pode afetar a fiabilidade da carga de trabalho porque requer mais coordenação, comunicação e gestão de componentes. Em alternativa, uma solução mais simples pode não corresponder totalmente às expectativas dos utilizadores ou pode ter um efeito negativo na escalabilidade e extensibilidade à medida que a carga de trabalho evolui.

Exercícios de conceção colaborativo

Trabalhe com os intervenientes para:

  • Defina e atribua um nível de criticidade aos fluxos de utilizador e aos fluxos de sistema da carga de trabalho. Concentre a sua estrutura em fluxos críticos para o ajudar 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 uma aplicação executa uma tarefa. Considere os requisitos não funcionais para determinar a forma como a aplicação executa uma tarefa. Certifique-se de que compreende os requisitos não funcionais, como escalabilidade, disponibilidade e latência. Estes 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 fiabilidade na sua estrutura. Determine os componentes de que precisa para suportar os fluxos. Alguns componentes suportam vários fluxos. Identifique o desafio que um componente aborda conceptualmente e considere remover um componente de fluxos individuais para simplificar o design geral, ao mesmo tempo que fornece todas as funcionalidades. Para obter mais informações, veja Recomendações para realizar a análise do modo de falha.

  • Utilize a análise do modo de falha para identificar pontos únicos de falha e potenciais riscos. Considere se precisa de ter em conta situações improváveis, por exemplo, uma área geográfica que vive um grande desastre natural que afeta todas as zonas de disponibilidade na região. É caro e envolve compromissos significativos para mitigar estes riscos incomuns. Compreenda claramente a tolerância da sua empresa ao risco. Para obter mais informações, veja Recomendações para realizar a análise do modo de falha.

  • Defina os destinos de disponibilidade e recuperação para os fluxos para informar a arquitetura da carga de trabalho. As métricas empresariais incluem objetivos de nível de serviço (SLOs), contratos de nível de serviço (SLAs), tempo médio de recuperação (MTTR), tempo médio entre falhas (MTBF), objetivos de tempo de recuperação (RTOs) e objetivos de ponto de recuperação (RPOs). Defina valores de destino para estas métricas. Este exercício pode exigir um compromisso e uma compreensão mútua entre a tecnologia e as equipas empresariais para garantir que os objetivos de cada equipa cumprem os objetivos empresariais e são realistas. Para obter mais informações, veja Recomendações para definir destinos de fiabilidade.

Recomendações de conceção adicionais

Pode efetuar as seguintes recomendações sem o envolvimento dos intervenientes:

  • Esforce-se pela simplicidade e clareza na sua estrutura. Utilize o nível adequado de abstração e granularidade para os seus componentes e serviços. Evite sobreengenharia ou subengenharia da sua solução. Por exemplo, se dividir o código em múltiplas funções pequenas, é difícil compreender, testar e manter.

  • Admita que todas as aplicações bem-sucedidas mudam ao longo do tempo, seja para corrigir erros, implementar novas funcionalidades ou tecnologias ou tornar os sistemas existentes mais dimensionáveis e resilientes.

  • Utilize as opções de plataforma como serviço (PaaS) em vez de infraestrutura como um serviço (IaaS) sempre que 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 precisa de configurar máquinas virtuais (VMs) ou redes virtuais. Também não tem de efetuar tarefas de manutenção, como instalar patches e atualizações.

  • Utilize mensagens assíncronas para desassociar o produtor de mensagens do consumidor.

  • Abstraia a infraestrutura da lógica do domínio. Certifique-se de que a lógica de domínio não interfere com a funcionalidade relacionada com a 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 de autenticar pedidos, pode mover esta funcionalidade para o seu próprio serviço. Em seguida, pode desenvolver o serviço de autenticação. Por exemplo, pode adicionar um novo fluxo de autenticação sem tocar em nenhum dos serviços que o utilizam.

  • Avalie a adequação de padrões e práticas comuns para as 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 cada aplicação porque podem introduzir problemas de complexidade, sobrecarga e dependência.

Desenvolver código suficiente

Os princípios de simplicidade, eficiência e fiabilidade também se aplicam às suas práticas de desenvolvimento. Numa carga de trabalho livremente conjugada e componente, determine a funcionalidade fornecida por um componente. Desenvolva os seus fluxos para tirar partido dessa funcionalidade. Considere estas recomendações para as suas práticas de desenvolvimento:

  • Utilize as capacidades da plataforma quando cumprirem os seus requisitos empresariais. Por exemplo, para descarregar o desenvolvimento e a gestão, utilize soluções de baixo código, sem código ou sem servidor que o seu fornecedor de cloud oferece.

  • Utilizar bibliotecas e arquiteturas.

  • 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 código inativo. Seja céptico quanto ao código que os seus testes automatizados não abrangem.

Utilizar o melhor arquivo de dados para os seus dados

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

  • As consultas podem exigir associações dispendiosas.

  • Tem de normalizar os dados e reestruturá-lo para o esquema na escrita.

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

Alternativas às bases de dados relacionais

Numa solução grande, é provável que uma única tecnologia de arquivo de dados não satisfaça todas as suas necessidades. As alternativas às bases 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

  • Bases de dados da família de colunas

  • Bases de dados de grafos

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

Por exemplo, pode armazenar um catálogo de produtos numa base de dados de documentos, como o Azure Cosmos DB, que suporta um esquema flexível. Cada descrição do produto é um documento autónomo. Para consultas em todo o catálogo, pode indexar o catálogo e armazenar o índice no Azure Cognitive Search. O inventário de produtos pode entrar numa base de dados SQL porque esses dados requerem garantias ACID.

Recomendações

  • Considere outros arquivos de dados. As bases de dados relacionais nem sempre são adequadas. Para obter mais informações, veja Compreender os modelos do arquivo de dados.

  • Lembre-se de que os dados incluem mais do que apenas dados de aplicações 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 utilizam uma combinação de tecnologias de arquivo de dados.

  • Considere o tipo de dados que tem. Por exemplo, armazene:

    • Dados transacionais numa base de dados SQL.

    • Documentos JSON numa base de dados de documentos.

    • Telemetria numa base de dados de série temporal.

    • Registos de aplicações no Azure Cognitive Search.

    • Blobs no Armazenamento de Blobs do Azure.

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

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

    • Otimizar consultas.

    • Ajuste o desempenho.

    • Trabalhe com os padrões de utilização adequados.

Considere estes fatores quando escolher uma tecnologia de armazenamento:

  • Utilize transações de compensação. Com a persistência poliglota, uma única transação pode escrever dados em vários arquivos. Se ocorrer uma falha, utilize as transações de compensação para anular quaisquer passos que tenham sido concluídos.

  • Considere contextos vinculados, que é um conceito de estrutura baseado em domínio. Um contexto vinculado é um limite explícito em torno de um modelo de domínio. Um contexto vinculado define as partes do domínio a que o modelo se aplica. Idealmente, um contexto vinculado é mapeado para um subdomínio do domínio empresarial. Considere a persistência poliglota para contextos vinculados no 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, muito provavelmente, estes 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ção com código mínimo.

  • O Azure Logic Apps é uma plataforma de integração de fluxos de trabalho sem servidor que pode utilizar para criar orquestração com uma GUI ou ao editar um ficheiro de configuração.

  • Azure Event Grid é um serviço de distribuição de mensagens publicação-subscrição altamente dimensionável e totalmente gerido que oferece padrões flexíveis de consumo de mensagens que utilizam os protocolos MQTT e HTTP. Com o Event Grid, pode criar pipelines de dados com dados do dispositivo, criar arquiteturas sem servidor condicionadas por eventos e integrar aplicações.

Para obter mais informações, consulte:

Exemplo

Para obter um exemplo de carga de trabalho que determina os componentes e as respetivas funcionalidades com base nos requisitos, veja Reliable Web App pattern (Padrão do Reliable Web App).

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade