E agora, galera, a gente vai falar sobre confiabilidade. O que é confiabilidade? Vamos nessa. Vamos falar sobre confiabilidade. O pilar de confiabilidade abrange a capacidade de uma carga de trabalho, um workload, de executar sua função pretendida de forma correta e consistente quando é esperado. Isso inclui a capacidade de operar, testar a carga de trabalho durante todo o seu ciclo de vida. No final das contas, o que isso quer dizer, galera? Aquilo que tem que estar no ar, tem que estar no ar funcionando, independente do tipo de evento que aquilo acontecer. Tive muita visita, a parada tem que funcionar. Legal? Tive que mudar de cloud provider, a parada tem que funcionar. Tive que fazer algumas mudanças nas operações e etc. A minha aplicação tem que estar confiável. Então, isso aí é uma das coisas mais complexas, né? Porque se você pensar bem, é o seguinte, toda vez que você vai falar em confiabilidade é, eu quero rodar minha aplicação, ela tem que estar funcionando. Agora, para fazer isso, é complexo, né? Para que você consiga manter a operação de algo funcionando, que seja confiável, que seja consistente. Ou seja, consistente tem que ser desde nível de performance, desde nível de escalabilidade, desde nível de segurança ali também. Legal? Desde quando a aplicação está sendo deployada, desde quando a aplicação está saindo do ar, você tem que ter esses níveis de confiabilidade ajustados legal quais são os principais novamente né quais são os princípios da confiabilidade primeira coisa recupere se automaticamente de falhas legal o que acontece o que é muito comum legal um serviço falhou, a parada caiu, e daí o que acontece? Você vai precisar de uma pessoa ir lá, sei lá, restartar a aplicação. Ou você vai precisar de uma pessoa ir lá no Kubernetes, remover o pod e subir o pod novamente. Então, esses tipos de coisa, galera, não podem ser de forma manual, legal? Existe um conceito extremamente importante que a gente chama de self-healing, legal? O que é self-healing no final das contas? É você ter a capacidade de autocura, né? Eu vou dar um exemplo muito claro para você. Vamos imaginar que a gente está rodando a aplicação A e B. A aplicação A mandou tanta requisição que a aplicação B travou. Como que eu consigo fazer a aplicação B voltar no ar automaticamente? Então, olha só que interessante. Esse é um princípio de self-healing. Essa aplicação tem que voltar no ar desde que ela tenha as condições de self-healing para ela. Por exemplo, trabalhar com o Circuit Breaker. O que o Circuit Breaker vai fazer? Quando a aplicação está caindo, ela para de receber requisição, termina de processar o que precisava, volta ao ar da maneira como ela estava e depois começa a receber novamente aquelas requisições. Você sempre tem que pensar em estratégias para que quando alguma coisa caia do ar, aquela parada possa voltar sem depender ao máximo de uma intervenção humana. Então isso aí é um ponto importantíssimo para você. Outro ponto, teste de procedimentos de recuperação. Galera, essa é uma das coisas mais, é um dos erros mais, vamos dizer assim, contundentes que a gente pode ter no dia a dia. Teste de procedimento de recuperação. Vamos derrubar esse serviço, o que acontece? Ele consegue se recuperar? Outra coisa, por exemplo, recuperação de dados. Aconteceu alguma coisa, morreu o seu banco de dados. Você vai ter que subir um banco de dados do zero e aplicar o backup dele. Você é capaz de fazer isso? O que acontece se hoje aquele banco de dados estivesse fora do ar e você tivesse que recriar do zero? Como que você ia pegar os dados do backup? Quanto tempo iria demorar para o backup ser importado novamente naquele banco de dados como que você consegue fazer esse teste então existem diversas técnicas e maneiras para que você consiga fazer esses testes e muitas dessas maneiras são simples, é manual, parte do princípio que esse serviço está fora do ar como que você faz agora mata aquele banco de dados faz com que aquela aplicação caia é o que acontece esse cluster fica fora do ar você consegue subir rapidamente uma outra zona de disponibilidade ou seja recuperação pode ser de dados pode ser de serviços pode ser de de aplicações que simplesmente caíram e precisam de autocura. Legal? Outro ponto importante, e é um dos pontos mais comuns quando a gente vê, é escale horizontalmente para aumentar a disponibilidade de carga de trabalho agregada. O que isso significa? Nós temos duas formas de escalar os serviços. que isso significa nós temos duas formas de escalar os serviços né e lembrando que a escalabilidade você consegue aumentar né quantidade de poder computacional para receber uma carga ou você consegue diminuir para receber também uma carga então quando a gente está falando em escalabilidade horizontal significa que ao invés de você sair aumentando a capacidade de uma única máquina, vai adicionando mais memória, mais CPU e etc. para ela ficar mais parruda, você consegue colocar diversas máquinas menores, uma ao lado da outra, recebendo e dividindo essa carga. Quanto mais você faz isso, você minimiza o risco do que de uma única máquina cair e você ficar 100% fora do ar o que é muito diferente você ter várias rodando né e dividindo esse nível de risco aí com você fora que quando você escala horizontalmente você pode escalar de forma geral vamos dizer assim de forma infinita. Não existe infinidade, principalmente quando você está na cloud. Mas você consegue escalar muito mais do que se você fosse escalar verticalmente. Legal? Pare de adivinhar a capacidade. Esse aí é um tema bem interessante. Por quê? Porque na maioria das vezes né você tem que partir do princípio quanto que eu vou precisar de poder computacional para rodar esse workload e daí você vai cair naquele naquela sensação que é a seguinte a não sei eu vou botar uma máquina com 5 vcpu e 30 gigas de memória cara da onde que saiu esse número é você tem um histórico anterior para conseguir corroborar se você tem você não está adivinhando você já está partindo do princípio de um dado que você já tinha agora quando você não tem dado anterior você não sabe como aquilo vai se importar, como que você vai simplesmente chutar algum valor? Você não chuta, você faz teste de carga. Você sobe uma aplicação igualzinha, no ambiente controlado, manda um monte de request, vê como que essa aplicação se comporta, organiza tudo isso, vê se é melhor aumentar a máquina Se é melhor aumentar verticalmente, horizontalmente Você consegue fazer esses ajustes finos E depois disso coloca no ar Raramente você vai acertar tudo de uma vez Por que eu digo isso? Porque acertar pode ser para mais ou pra menos. Se você rodar botando muita padrão computacional, sua empresa vai gastar dinheiro à toa. Mas se você colocar de menos, a aplicação não vai estar confiável, que é o nosso assunto de agora que a gente está trabalhando, legal? Então, teste de carga pra tudo. Tudo que você for fazer. Você tem que ter dados para corroborar a sua decisão em relação à capacidade. Legal? E gerencie mudança de forma automatizada. Novamente, galera, como que eu consigo garantir que todas as alterações, tudo que eu preciso fazer de forma geral, aconteçam automaticamente? Por exemplo, escalar horizontalmente. Você tem que ter um SG, um Out Scale Group, que faça isso automaticamente por exemplo escalar horizontalmente você tem que ter um sg não alto que o grupo que faça isso automaticamente você tem que setar esses limites e tem que diminuir então essas coisas automatizadas elas não só vão facilitar no dia a dia né a operação como ao mesmo tempo vão fazer que a sua aplicação ela rode de uma forma mais eficiente. A gente vai cair na parte de eficiência já já. Legal? Então, é isso aí galera em relação a parte de princípios de confiabilidade. Vamos aí para o nosso próximo princípio.