Como arquiteto de nuvem, uma das minhas principais responsabilidades é projetar a arquitetura de serviços SaaS. Essa responsabilidade tem se mostrado desafiadora, até mesmo complicada, especialmente ao lidar com arquiteturas Serverless.
Já tive vários casos em que conseguia pensar em várias soluções candidatas para um problema e precisava escolher entre elas.
Devo usar o padrão SNS->SQS? ou EventBridge?
Devo usar o DynamoDB ou o Aurora RDS Serverless?
Devo usar Elasticache ou DynamoDB com DAX?
Veja bem, às vezes não fica claro qual solução candidata é melhor.
Todos os candidatos à solução atendem aos requisitos, mas cada candidato tem seus prós e contras.
Nesses casos de uso, eu precisava de diretrizes claras para me ajudar a diferenciar as soluções e tomar uma decisão. Meu gerente sugeriu que eu escrevesse um modelo de design para me ajudar na tomada de decisão.
Foi assim que esse modelo surgiu.
Então, nesta postagem do blog, você encontrará meu modelo de design de alto nível recomendado que ajudará você a definir e inspecionar suas soluções e, eventualmente, escolher aquela que melhor se adapta às suas necessidades.
A documentação é a chave
Sim, não é divertido escrever documentação e pode ser exaustivo, MAS tem muitos benefícios.
Para começar, documentar seu processo de pensamento e escolhas de design pode ajudar você a escolher entre soluções e oferecer uma visão clara e desobstruída de suas escolhas.
Em segundo lugar, serve como justificativa para qualquer futura parte interessada quanto às considerações e opções no momento da redação.
Terceiro, os requisitos do produto podem mudar no futuro e podem afetar sua solução e arquitetura. É sempre bom especificar os requisitos que você tinha então, pois eles afetam a solução escolhida.
E, por fim, a nuvem está sempre mudando. Novas arquiteturas, serviços e capacidades de serviço são lançados o ano todo. Uma documentação concreta e clara pode ajudar você a refatorar a arquitetura no futuro, pois aponta limitações, hacks ou soluções alternativas que você considerou e implementou.
Estrutura do modelo
Abaixo está minha recomendação para uma estrutura de modelo de design de alto nível.
Sinta-se à vontade para alterá-lo como achar melhor.
Status
Valores possíveis: [Rascunho, Em revisão, Aprovado, Implementado, Retirado]
É essencial manter o controle sobre seu design. É fácil se perder em designs antigos que não são mais relevantes.
Certifique-se de iniciar o design com o status 'Rascunho'.
Uma vez feito, ele muda para o status 'Under Review' e, uma vez aprovado, para o status 'Approved'. Uma vez que a implementação é concluída, o status é alterado para o status 'Implemented'.
No entanto, o estado mais crucial, na minha opinião, é o status de "Aposentado".
Ao criar um novo design que substitua o atual 'Implementado' e o torne redundante, defina o status como 'Retirado' e adicione um link para a página de design atualizada.
Terminologia
Nesta seção, você deve explicar quaisquer expressões comuns, definições e descrições de partes interessadas relacionadas ao seu serviço.
Imagine que sua documentação de design seja lida por desenvolvedores e arquitetos que não estão familiarizados com seu serviço ou domínio de problema e desejam revisá-lo.
Contexto
Nesta seção, você deve descrever o problema que deseja resolver de maneira orientada ao cliente.
Suposições
Descreva todas as suposições que são consideradas durante o processo de design.
A equipe do produto deve aceitar essas suposições, pois elas provavelmente afetam a experiência geral do usuário.
Requisitos funcionais
É aqui que fica interessante.
Nesta seção, você precisa definir o que o serviço deve fazer e seus recursos e funções.
"Geralmente, os requisitos funcionais descrevem o comportamento do sistema sob condições específicas". - altexsoft.com
Seria útil vincular aqui a documentação de requisitos de qualquer equipe de produto para referência.
Sinta-se à vontade para desafiar a equipe do produto e exigir um conjunto claro e direto de requisitos funcionais, pois eles são essenciais para diferenciar entre possíveis soluções.
Por exemplo:
Manipule X sessões de usuários simultâneas por segundo.
Suporte as seguintes consultas de filtro na sua chamada de API: filter1, filter2, filter3...
Implante o serviço em regiões específicas: região1, região2.
Quanto mais precisos forem os requisitos, melhor será sua pesquisa e comparação de soluções.
Requisitos não funcionais
Nesta seção, você precisa descrever as propriedades gerais da arquitetura, também conhecidas como atributos de qualidade.
Você deve levar em consideração os seguintes parâmetros:
Custo - estimativa de custo por mês, considerando a arquitetura e os requisitos concretos do produto (sessões de usuário por segundo, etc.). Para AWS, use a calculadora de preços da AWS.
Testes de desempenho - defina um conjunto de testes/consultas/valores numéricos que podem ajudar a estimar o desempenho/gargalos no mundo real.
Resiliência
Ele tem um mecanismo de backup automático? Você precisa construí-lo você mesmo?
É totalmente gerenciado pela AWS? É altamente disponível? Por quantos 9's?
Ele suporta multirregiões?
Multi-tenancy (se aplicável) - defina a abordagem recomendada para multi-tenancy na solução (silo, pool, bridge). Leia mais aqui .
Conformidade - defina o mínimo necessário, FedRamp High, SOC2, etc. Sua solução oferece suporte ou exige isso?
Cotas - especifica limites de arquitetura e cotas essenciais.
É necessária uma nova dependência do SDK?
É simples de integrar e usar no seu código de serviço?
Facilidade de implantação - AWS CDK/Serverless/Terraform:
Ele tem uma construção AWS CDK de alto nível?
É necessária uma VPC?
Demora muito para implantar?
É preciso mais tempo para pesquisar as melhores práticas (pesquisa de esquema de banco de dados, políticas de segurança)?
Opções consideradas
Para cada solução candidata, forneça uma breve descrição com links para subpáginas onde você fornece:
Diagramas completos de arquitetura/fluxo do candidato à solução.
Descreva como ele responde aos requisitos funcionais.
Descreva em detalhes todas as especificações de requisitos não funcionais, desde resultados de testes de custo e desempenho até cada uso e implantação.
Inclua qualquer imagem relevante do console da AWS.
Forneça resultados detalhados de teste de desempenho. O candidato à solução é viável em termos de desempenho?
Análise de risco - você está usando um SDK alfa? O serviço AWS é novo? A documentação/experiência do usuário está faltando? Liste qualquer possível contratempo que venha à mente.
Matriz de decisão ponderada
A matriz de decisão ponderada transforma suposições e pressentimentos em uma conclusão científica apoiada por números.
Como todas as soluções candidatas devem satisfazer os requisitos funcionais, o foco nesta matriz deve ser os requisitos não funcionais.
Os pesos são o multiplicador de valor para cada critério e representam a importância do critério aos nossos olhos.
Cada um dos requisitos não funcionais (de um a oito) recebe um peso.
Para nosso exemplo, vamos usar pesos de 1 a 5.
É essencial discutir isso internamente com sua equipe e obter a aprovação de todos, pois esses pesos afetam a pontuação final da solução.
Cada solução recebe uma nota por critério. Uma nota pode ser entre um e três.
Por exemplo, 1-3 marcas significam:
Um representa a satisfação mínima necessária.
Dois representa satisfação razoável.
Três representa o melhor da classe.
Depois que a nota for definida como um critério, você pode calcular a pontuação do critério multiplicando o peso pela nota.
Vamos examinar a tabela abaixo:
Queremos distinguir entre duas soluções: A e B.
Nossos requisitos não funcionais, neste caso, são 'resiliência', 'facilidade de uso' e 'custo'.
Cada requisito recebe um peso:
A resiliência recebe um peso de 3 em 5
Facilidade de uso 1 (menos importante para a equipe neste caso)
O custo recebe nota 5 de 5, o que o torna o requisito mais importante para a equipe.
A solução A recebeu as seguintes notas: 3 de um máximo de 3 para resiliência, 3 de um máximo de 3 para facilidade de uso e 3 de 3 para custo. Que superdotado!
A solução B, por outro lado, recebeu 2 de um máximo de 3 para resiliência, 3 de um máximo de 3 para facilidade de uso e 2 de 3 para custo.
A solução com maior pontuação será aquela que você declarará como a solução escolhida.
Neste caso, a solução A é a solução preferida com 27 pontos.
Resumo da decisão
Nesta seção, você explica por que escolheu a solução selecionada.
Deve ser a solução que recebeu mais pontos na tabela de comparação ponderada.
Descreva brevemente os prós e os contras da solução.
Pronto, o documento de design está concluído.
Eu esqueci de alguma coisa? Se você tiver alguma sugestão ou comentário, por favor, escreva-os na seção de comentários abaixo.
Obrigado, Meitar Karas, por sugerir que eu criasse este modelo e por me apresentar o conceito de matriz ponderada na tomada de decisões.
Comments