Análise da workload

Para aplicar o framework, comece analisando a workload que você deseja analisar. Um diagrama da arquitetura do sistema fornece um ponto de partida para documentar os detalhes mais relevantes do sistema. No entanto, tentar analisar toda uma workload pode ser complexo, pois muitos sistemas têm vários componentes e interações. Em vez disso, recomendamos que você se concentre nas histórias de usuários, que são explicações informais e gerais dos recursos do software escritas com base na perspectiva do usuário final. Seu objetivo é articular como um recurso de software fornece valor ao cliente. Você pode então modelar essas histórias de usuário com diagramas de arquitetura e diagramas de fluxo de dados para facilitar a avaliação dos componentes técnicos que fornecem a funcionalidade comercial descrita. Por exemplo, uma solução de compra de jogos para celular pelo aplicativo pode ter duas histórias de usuário, “comprar créditos no aplicativo” e “obter reembolsos no aplicativo”, conforme mostrado no diagrama a seguir. (Esse exemplo de arquitetura destaca como você pode decompor um sistema em histórias de usuários. Ele não se destina a representar um aplicativo altamente resiliente.)

Cada história de usuário consiste em quatro componentes comuns: código e configuração, infraestrutura, armazenamentos de dados e dependências externas. Seus diagramas devem incluir todos esses componentes e refletir as interações entre os componentes. Por exemplo, se houver carga excessiva em seu endpoint do Amazon API Gateway, considere como essa carga tem um efeito cascata em outros componentes do sistema, como suas funções do AWS Lambda ou tabelas do Amazon DynamoDB. O rastreamento dessas interações ajuda você a entender como o modo de falha pode afetar a história do usuário. Você pode capturar esse fluxo visualmente com um diagrama de fluxo de dados ou usando setas de fluxo simples em um diagrama de arquitetura, como na ilustração anterior. Para cada componente, considere capturar detalhes como o tipo de informação que está sendo transmitida, a informação recebida, se a comunicação é síncrona ou assíncrona e quais delimitações contra falhas estão sendo ultrapassadas. No exemplo, as tabelas do DynamoDB são compartilhadas nas duas histórias de usuário, como você pode ver pelas setas que indicam que o componente do Lambda na história de reembolsos no aplicativo acessa as tabelas do DynamoDB na história de compras no aplicativo. Isso significa que uma falha causada pela história do usuário de compra no aplicativo pode ter um efeito cascata na história do usuário de reembolsos no aplicativo como resultado de um destino compartilhado.

Além disso, é importante entender a configuração de linha de base de cada componente. A configuração de linha de base identifica restrições como o número médio e máximo de transações por segundo, o tamanho máximo de uma carga útil, o tempo limite do cliente e as cotas de serviço padrão ou atuais do recurso. Se você estiver modelando um novo projeto, recomendamos que documente os requisitos funcionais dele e considere os limites. Isso ajuda você a entender como os modos de falha podem se manifestar no componente.

Por fim, você deve priorizar as histórias de usuários com base no valor comercial que elas fornecem. Essa priorização ajuda você a se concentrar primeiro na funcionalidade mais crítica da sua workload. Você pode então concentrar sua análise nos componentes da workload que fazem parte do caminho crítico para essa funcionalidade e obter valor ao utilizar o framework mais rapidamente. À medida que você itera no processo, você pode examinar histórias de usuários adicionais com prioridades diferentes.