This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
Os softwares passaram a ser amplamente usados para dar suporte aos negócios das empresas, permitindo que as pessoas usem serviços em vários domínios, como: bancos, comércio eletrônico, entretenimento online, saúde ou meios de pagamentos, apenas para citar alguns. Espera-se que o software opere de maneira robusta ao enfrentar condições inesperadas, pois uma única falha pode afetar fortemente os usuários ou o fornecedor do software. Isso é especialmente verdadeiro em softwares e soluções de missão crítica, onde uma falha pode ter consequências desastrosas para o negócio.
Os modelos arquiteturais usados para novas soluções, como por exemplo Event-driven, Microsserviço, dentre outros, têm tirado bastante vantagem do uso de aplicações distribuídas, buscando a escalabilidade, robustez e desacoplamento. Todos estes benefícios nos levam a um cenário de múltiplas dependências onde mesmo quando todos os serviços individuais em um sistema distribuído estão funcionando corretamente, as interações entre esses serviços podem causar resultados imprevisíveis.
Os cenários expostos anteriormente trazem para o debate: como podemos garantir a resiliência e a tolerância a falha de nossos softwares considerando suas múltiplas dependências?
O Azure Well-Architected Framework, criado pela Microsoft, nos fornece um conjunto de melhores práticas, orientações e recursos para que possamos planejar, construir e operar nossas aplicações com sucesso no Azure. Este framework é composto de cinco pilares: otimização de custos, excelência operacional, desempenho, eficiência, confiabilidade e segurança. Embora todos os pilares sejam extremamente importantes, vamos explorar melhor o pilar de confiabilidade pois está mais relacionado aos requisitos de resiliência e tolerância a falha de nossos softwares.
Para saber mais sobre o WAF – Well Architected Framework e seus cinco pilares consulte este link: https://aka.ms/architecture/framework
Por melhor que sua aplicação esteja projetada, em algum momento ela poderá ser impactada pela indisponibilidade de uma de suas dependências. As falhas e interrupções de serviços que não estão no seu controle podem ocorrer a qualquer momento. O que deve ser feito para evitar falhas nas dependências de nossa aplicação? Nossa aplicação precisa ser projetada para ser resiliente, ou seja, ela deve operar mesmo quando afetada por falhas regionais, zonais, de serviço ou de componentes que estão fora do nosso controle. Parece uma tarefa difícil, certo? Sem dúvida! Mas felizmente dentro do pilar de confiabilidade do Azure Well-Architected Framework podemos encontrar uma série de recomendações para endereçar esses desafios e garantir que nossa aplicação seja resiliente e tolerante às falhas.
Ao projetar sua aplicação para ser resiliente, basicamente você precisará endereçar dois pontos importantes:
- Como preparar os componentes da sua aplicação para falhas?
- Como validar continuamente se sua aplicação é resiliente?
Neste artigo não vamos endereçar as recomendações de como preparar uma aplicação para se tornar resiliente as falhas, mas focaremos em como validar a resiliência.
Validar que sua aplicação é resiliente é tão importante quanto prepará-la para falhas. Por isso, umas das recomendações dentro do pilar de confiabilidade do Azure Well-Architected Framework é a adoção de Engenharia do Caos. Em resumo, a engenharia do caos é um conjunto de práticas que visam submeter sua aplicação às falhas do mundo real e às interrupções de suas dependências que fatalmente ocorrerão em um ambiente produtivo. Estas práticas consistem basicamente em injetar deliberadamente falhas que causam a indisponibilidade ou mau funcionamento dos componentes de sua aplicação. O objetivo é observar, monitorar, responder e melhorar a confiabilidade da sua aplicação em circunstâncias adversas.
E você deve estar se perguntando: em qual momento do processo de desenvolvimento da sua aplicação incluímos as práticas de engenharia do caos? Bom, a recomendação para qualquer tipo de testes é que eles sejam planejados e executados cedo e com frequência. Ao se preparar para colocar um release da sua aplicação em produção, você pode seguir as práticas que são bem disseminadas para testes, executando testes de unidade, funcionais, de stress e de integração. Onde fizer sentido, você pode adicionar os testes de caos, que irão fazer a injeção proposital de falhas para validar o comportamento da sua aplicação.
Por exemplo, podemos criar os seguintes cenários de testes:
- Colocar algumas dependências da aplicação offline, desabilitando serviços ou mesmo desligando máquinas virtuais.
- Restringir determinados acessos, habilitando regras de firewall ou políticas de segurança
- Forçar o failover de alguns serviços, como bancos de dados
Os cenários de teste acima vão certamente nos ajudar a validar se a aplicação é capaz de lidar com falhas.
Em um cenário mais avançado de engenharia do caos, você pode integrar os testes de caos juntamente com testes de carga e stress para validar se a aplicação continua a operar adequadamente nestas circunstâncias. É recomendado realizar os testes em um ambiente de pré-produção antes de realizar experimentos em produção, assim você pode entender como sua aplicação se comporta em um ambiente seguro, mas com uma simulação de carga que reflete os padrões reais de pico de acesso e utilização da sua aplicação.
Já falamos sobre a importância dos testes de caos, porém devemos pensar o como criar e executar estes cenários de teste. A Microsoft disponibilizou em Preview um serviço chamado Azure Chaos Studio. Para aqueles que possuem workloads publicados na Região de Brazil South, já podemos fazer uso do serviço!
O Azure Chaos Studio é uma plataforma de experimentação de engenharia de caos totalmente gerenciada para melhorar a resiliência do aplicativo. Com este serviço, é possível criar experimentos onde você descreve as falhas a serem executadas a partir de uma biblioteca pré-definida (como o desligamento de uma Virtual Machine, falhas em um Pod de AKS, falha de DNS) e os recursos a serem aplicados (quais Virtuais Machines ou AKS do seu ambiente). Após a criação do experimento, você pode usá-lo para executar os testes de caos e então analisar os resultados.
Para acessar o serviço e começar a criar os experimentos, acesse o portal do Azure e procure por Chaos Studio, conforme podemos ver a seguir:
Para poder criar o seu primeiro experimento, siga a documentação disponível aqui! Ou ainda, aguarde nossos próximos posts que falaremos mais sobre aspectos práticos em um famoso cenário “Show me the code” ...
Com as práticas de engenharia do caos, você vai conseguir lidar com a incerteza do ambiente de produção, vai se preparar para eventos raros e imprevisíveis, e no final das contas você irá atuar de maneira proativa para mitigar os riscos e consequentemente minimizar os impactos no seu negócio.
Em breve teremos outros artigos e eventos! Seguem alguns links para quem quiser entender um pouco mais sobre os assuntos falados:
Chaos engineering - Microsoft Azure Well-Architected Framework | Microsoft Learn
Mission-critical workloads - Microsoft Azure Well-Architected Framework | Microsoft Learn
Mission-critical baseline architecture on Azure - Azure Architecture Center | Microsoft Learn
https://principlesofchaos.org/