Criando Aplicações Resilientes : Introdução

(Versão em Inglês )

O que é Resiliência? Se procurarmos por uma definição no dicionário (Google) veremos:

Na física: propriedade que alguns corpos apresentam de retornar à forma original após terem sido submetidos a uma deformação elástica.
No sentido figurado: é capacidade de se recobrar facilmente ou se adaptar à má sorte ou às mudanças.

Nesta série de posts iremos tratar de resiliência como:

a capacidade da aplicação de se recuperar de falhas e continuar a funcionar

Dizemos que:

  • No melhor cenário: a aplicação se recupera sem o usuário/cliente perceber
  • No pior cenário: a aplicação oferece serviços de forma limitada (que chamamos de graceful degradation)

Falhas

As falhas em sistemas distribuídos podem ser classificadas de acordo com sua duração em:

  • Transientes: Ocorrem uma vez e desaparecem com curta duração. Se você repetir a operação é provável que terá sucesso;
  • Intermitentes: São falhas transientes que ocorrem repetidamente, elas acontecem e desaparecem por “vontade própria”; e
  • Permanentes: São as falhas que permanecerão até que alguma ação seja tomada como, por exemplo, trocar um equipamento ou corrigir o software;

Também podemos classificar essas falhas segundo seu comportamento:

  • Travamento ou queda: o recurso parou de funcionar devido a um travamento ou perda do estado interno;
  • Omissão: o recurso não responde às requisições;
  • Temporização: as respostas estão fora da sincronia esperada; e
  • Bizantinas ou Aleatórias: o recurso responde forma totalmente arbitrária;

Por vezes quando projetamos e desenvolvemos nossos sistemas não levamos em consideração que eles poderão falhar. Peter Deutsch e James Gosling elencaram oito itens que normalmente são assumidos como verdadeiros em projetos de sistemas distribuídos e que a longo prazo se mostram errados e podem resultar em problemas (8 falácias de sistemas distribuídos), são eles:

  • A rede é de confiança. 
  • A latência é zero. 
  • Largura de banda é infinita.
  • A rede é segura. 
  • A topologia não muda. 
  • Há somente um administrador. 
  • Custo de transporte é zero. 
  • A rede é homogêneo.

Microsserviços

Está cada vez mais comum a construção de aplicações baseadas em arquitetura microsserviços ou a migração de monolíticos para essa arquitetura. A arquitetura de microsserviços tem promessas interessantes e entre elas é favorecer a alta disponibilidade

Porém, uma arquitetura de microsserviços com erros de modelagem em que existirem muitas chamadas HTTP encadeadas sincronamente, pode levar a um cenário oposto.

Vejam a imagem e os cenários a seguir, sendo simplista mas com o propósito de demostrar essa questão. 

  • Monolítico: um servidor tem uma disponibilidade calculada em 99.5% para servir uma sistema monolítico. 
  • Microsserviços: 5 servidores, também com 99.5% de disponibilidade cada. Porém, nessa arquitetura um serviço faz chamadas encadeadas e síncronas a outros serviços, logo, acrescenta outros pontos de falhas e a disponibilidade do sistema se dá pelo fator da disponibilidade de todos os serviços envolvidos. Neste cenário será 97.5%, sendo menor que a disponibilidade do cenário Monolítico. 

Em microsserviços as falhas podem ser diversas, desde falhas em hardware à movimentações de contêineres entre nós.

A questão que alguns podem ter é mesmo com uma disponibilidade alta como as dos nossos cenários, as falhas realmente podem acontecer? Devo me preocupar com isso?

Lei de Murphy: Se algo pode dar errado, vai dar errado!

Logo, não é uma questão de “se as falhas vão acontecer” e sim “quando elas vão acontecer”.

No livro “.NET Microservices: Architecture for Containerized .NET Applications” diz:

A falha intermitente é garantida em um sistema distribuído e baseado em nuvem, mesmo quando cada dependência têm uma disponibilidade excelente. Esse um fato que você precisa considerar.

Concluindo, ser Resiliente é aceitar que falhas irão acontecer e tratá-las da melhor maneira.

Nos próximos artigos veremos padrões aplicáveis à software para construir aplicações resilientes. 

Deixe seu feedback e acompanhe a série…

4 respostas para “Criando Aplicações Resilientes : Introdução”

    1. O que veremos nos posts seguintes dessa série é como ser resiliente a nível de software.
      Porém, temos muitas outras maneiras de alcançar a resiliência, seja fazendo load-balance, usando containers, usando caches como Redis, etc.
      No fim, um conjunto destas técnicas vai tornar nossa aplicação resiliente.
      Continue acompanhando 😉

  1. Pingback: Em desenvolvimento

Deixe uma resposta

O seu endereço de e-mail não será publicado.