 A Invertación é uma honra estar aqui e ver que a comunidade de OpenShift cresceu tanto. Em 2015, quando estivemos no primeiro OpenShift Gathering, iniciado, era quase como 30 ou 40 pessoas e é uma explosão que nos deixa muito felizes. Como podem ver, eu não falo espanhol. Achei a noite, eu falava muito bem, depois da primeira botiga, mas acordei e não sei o que passa. Bom, o tema principal da charla é Engenharia de Caos. Eu vou mostrar um pouco o que é Github Cloud e depois vamos ao tema principal. Github Cloud é uma empresa especializada em tecnologias e arquiteturas de nube. Como já sabe, recebemos em 2017 um prêmio que nos deixa muito orgulhosos, que é o Cool Vendor de Gardner, que não é algo tão fácil de alcançar. Empecemos com OpenShift na versão 2. Na verdade, era a versão 1 que se transformou em 2 e depois estamos agora na 3, como todos sabem. Em 2013, seguimos toda a sua evolução desde a implementação inicial de containers que na época não havia Docker. Para nós, o software é o novo hardware e quanto mais se converte no papel da infraestrutura em as entregas de serviços, mais importante se converte em criar formas de usuário não ter que pensar em tecnologia, se espera que simplesmente funcione. O que passa é que OpenShift é um exemplo de software que funciona. A isso o chamamos de infraestrutura invisível. Em os últimos anos, temos ajudado a empresas a entender essa nova mundo de nube, como sair da máquina virtual ou da máquina física e também como, em algum caso, como sair de seus data centers até a nube. Usando arquiteturas sempre de nube para sacar o máximo de benefícios que este câmbio pode oferecer. Nuestros serviços vão desde instalaciones, treinamento, suporte, acismand, criação de containers, de templates, migrações completas de sistemas. Criamos uma consola web que é mais simples que a consola de OpenShift porque o que queremos lograr é que os usuários não necessitavam entender de containers, de deployments, de serviços. Então, a consola que criamos se parece muito com a consola tradicional. Eu tento isso ser uma transição mais simples. Há também um back-end desenvolvido em Python para controlar as faturas integradas por projetos, por áreas de negócios. Então, a parte que OpenShift ainda não provei, desenvolvemos para que tenhamos essa observação. Para que o cliente possa enxergar quanto gasta cada projeto e possa dividir seus custos por áreas internas da empresa. Um caso interessante que ocorreu a pouco é com o telefone de Brasil, onde o time de Big Data tinha um projeto novo, queriam testar algo ou provar algo. Eles tinham que fazer uma requisição para um departamento que se vai provisionar as máquinas e outro que vai testar a segurança, o outro que vai instalar os paquetes. E isso acia com que se perdeça em dois dias. Então, quando chegamos, a primeira coisa foi fazer um cluster para aprovar a tecnologia e construir templates que passaram dois dias de provisionamento a dois horas. Então, se ganhou muito a realidade no processo que não é a especialidade dos desacogeadores de Big Data. Acá, eu creio que começa a luchar. Hoje existe uma disciplina nova chamada Chaos Engineering que é uma disciplina parte dos sistemas distribuídos em que o objetivo é aumentar a confiança de um sistema manter-se stable enquanto passa por problemas em produção. Essa parte em sistemas produtivos é muito importante. O que se faz é, literalmente, romper costas em produção para aprender como construir um sistema mais resiliente. Esse conceito começou em 2010 com engenheiros da Netflix. Quando a empresa saiu da sua infraestrutura física e passou para a 9 de Amazon. A ideia é generar falhas em um entorno real, em um ambiente real, de forma controlada. Não vai sair a chutar os computadores porque não é bom. E, desta forma, podemos garantir que a perda de uma instância não haria o sistema de Netflix cair-se, virar barro. Então, a primeira implementação que começou todo o movimento foi a herramienta Chaos Monkey. A ideia é que lança um grupo de macacos, simbios, em data center e eles arrebentam os cabos e assim, um horror. No próximo ano, em 2011, 2012, uma suíte completa de herramientas foi desenvolvida pela mesma equipe que se chamou Simeon Army. E estas herramientas agregam novas inrecções, fault injections no sistema. Por exemplo, há Chaos Monkey, o mais conhecido, e o Chaos Gorilla, onde se barra toda na zona de disponibilidade da Amazon. É só uma instância, mas todo data center Brasil se destrói. É muito perigoso. Depois, apareceu a Latence Monkey, que injeita a latência na transmissão de redes e discos. O Doctor Monkey, que faz health checks no serviço, o Genitor Monkey, que limpe recursos que não se gostam mais. Muitas vezes, temos máquinas, instâncias rodando, executando, e não há nada em elas. Então, para que se reduz o custo da operação. O Conform Monkey faz pruebas por conformidade, onde a pessoa define o que, como deve se comportar, como deve se quedar uma instância, e se não é conforme com a declaração, com a definição, se saca do clúster. E, por último, o Security Monkey, que desliga instâncias que apresentam vulnerabilidades de segurança. Bem, isso não é só uma injeção de erros, é muito mais. É a filosofia de como se pode manter todo um sistema estable, mesmo que o pior aconteça. Então, como eu disse antes, criar erros, falhas, como uma região inteira sendo desactivada, pode ser adicionar latência entre serviços. Outras coisas que nunca nos passam por a cabeça, que como dois computadoras com os relógios desalinhados, em clocks queue. Esse tipo de coisa acontece, e dificilmente alguém se da cuenta de que pode acontecer e que pode promover uma falha no sistema. Você pode também engretar e emolar erros no disco ou na rede para ver como o software até o sistema operacional se comporta. Bem, há cinco princípios básicos da engenharia de caos, que é, primeiro, construir uma hipótese sobre a cerca do que é o sistema estable. The steady state behavior define como que quer que o sistema se comporte. O que é um sistema estable? É importante saber que essa hipótese não define como o sistema funciona. Não olhamos para dentro, olhamos desde fora, então quer saber se o sistema funciona. A segunda é variar, ou cambiar eventos do mundo real, como desativar um disco ou barrar um serviço de banco de datos. São coisas que se podem acontecer a qualquer momento em um sistema online. A terceira princípio é rodar experimentos em produção. Isso parece... Não parece algo bom, mas não há outra forma de testar um sistema que está sem uso. Não se pode testar um sistema sem uso. Então, aqui está um dos pilares básicos da engenharia de caos. Isso faz com que a síndrome funcione em minha computadora, seja... Não a tenho mais. Também a nova síndrome que é funciona em meu container. Esta nova. É como a Grip. A quarta princípio é que é mais uma recomendação, porque todo o trabalho que é manual cansa, está subjeto a errores, a falhas humanas. Então, o ideal é que os testes sejam executados com uma herramienta de delivery ou um Jenkins ou algo assim. Por último, temos que começar pequenos com o mínimo possível de impacto e à medida que os testes se vão passar, aumentamos o impacto no sistema até que se pegue todo o sistema. Então, aqui está uma representação visual onde defino que é o bom sistema como o sistema estable para criar uma hipótese onde simula eventos do mundo real para tentar quebrar o sistema por baixo e inteiro. Sempre como uma espiral, abrindo a área de impacto. E como podemos fazer isso? Há uma herramienta chamada Kells Toolkit que é uma implementação em Python que é muito fácil de usar. O intuito dessa herramienta é exatamente isso, começar pequeno com pouca abrangência dos testes e poder, através de um sistema de plugins, expandir toda a gama de testes que se pode fazer. Se começou em meio de 2017, é algo muito novo, e há pouco que se criou um Working Group de Engenharia de Kells e a herramienta, se não me engano, está concorrendo a ser parte de CNCF para uma das implementações da fundação. Bom, a herramienta Kells Toolkit permite que hables com diversos tipos de sistemas externos com Amazon, com GCI, com Kubernetes, e o bom é que as implementações são sempre muito fáceis de fazer. Se programas em Python já é um bom candidato para aumentar, crescer a lista. O conceito clave de Kells Toolkit é que vamos realizar experimentos. Um experimento tem todos os componentes do conceito de Kells Engineering. Primeiro, se declara em um arquivo JSON, um arquivo de texto, o que é como deve responder, como deve parecer o sistema em seu estado normal. Podemos usar props e acções para fazer perguntas ao sistema ou gerar algum evento externo. Estes props e acções respondem a condições que são usadas para validar se o prop foi bom ou mal ou se a acção foi com sucesso ou não. Você pode fazer rollbacks ao término do teste, então se minimiza a necessidade de alguém ter que intervir manualmente para corrigir alguma coisa que se rompiu. Você pode analisar depois um jornal e um report de PDF ou HTML. Então, na representação visual, onde se define o estado estable do sistema, se aplica um método, que é a execução de acções e props. Depois, se roda novamente o script que testa se o sistema está estable ou não, se o sistema está estable, podemos aumentar o raio de impacto. Se não, se há algum erro, era o que queríamos encontrar errores. Então, sucesso. No final, um rollback. Quem são desenvolvedores aqui? Poucos, muito poucos. Necessitamos mais. Se não são desenvolvedores, podem cerrar os olhos por um pouco, porque vou mostrar isto, monstruosidade. Estos são exemplos de props e acções do sistema, onde pode fazer uma requisição HTTP. Bom, aqui. Então, declara um provider que é do tipo HTTP com time alt e URL. E pode também usar um probe do tipo Python, onde define um módulo, qualquer módulo de Python, e uma função com seus argumentos. Então, depois que isto executa e se me retorna true, então, o probe foi um sucesso. Pouco também usar processos, scripts ou binários externos, da mesma forma que uso o Python ou HTTP, e pode fazer referências a props e acções declaradas antes. Eu vou mostrar aqui um exemplo de uma implementação demo que está em um sítio de Kalosu Kit, que é um sistema de 2 microserviços, bem micro, micro, micro mesmo, que só tem uma coisa. Aqui em cima tem um HTTP client, Curl, e tem um serviço de front-end, Sunset, que me retorna uma frase com o horário, a hora certa em que o sol se põe. Eu passo o nome da cidade, e ele me retorna em Buenos Aires. O sol se põe nas seis, e aqui abaixo tem um microserviço que comunica-se com o Sunset em HTTPS com SSL, que faz o calculo. Mas não printa nada de texto, só o calculo de quanta hora que retorna para Sunset e nos mostra na consola. O que vamos fazer é quebrar o SSL, reinstalar um certificado inspirado, que não é válido, e dizer o que acontece com o nosso sistema. Eu já sei porque... A descrição do experimento é simples. Eu começo aqui abaixo com o passo A, onde define a hipótese do estado estable do sistema. Para esse sistema o que preciso fazer é saber se o serviço está up, o serviço Sunset está up, e se pode fazer uma requisição ao serviço Sunset. Então, se passa tudo, o sistema está estable. Depois, em momento B, o método vai fazer o câmbio do certificado e reinpesar todos os serviços para que se ejecute novamente o serviço hipótese, que é o momento C. E por final, há um serviço D que volta o certificado e reinpesa os serviços com as actões em verde. Aqui em cima, em esta pantalla, eu tenho o serviço Sunset. Então, ele é... Não está gravando, não? Então, aqui eu tenho o serviço Sunset. O que é o front-end? Eu tenho aqui o serviço astre, que é só uma chamada do Python em um arquivite, em um fichero. E vou mostrar primeiro uma chamada no serviço Sunset. Então, aqui é a frase com um... muito fácil de ler. O que é o... O Sunset vai acontecer com esta monstruosidade em Buenos Aires. Então, o que vamos fazer é sair aqui. Bom, se está aprovado que o serviço funciona, eu vou executar o experimento que é solamente este comando, chaos-run-experiment.json. Então, o que se faz aqui é o experimento do passeado, nada mais, a hipótese é que as aplicações respondem, está bem, porque se ejecutou o prove de teste de serviço astre, de Sunset, e se pode fazer uma requisição. Então, a hipótese está... está boa. Depois, para o método, se faz o câmbio de certificados, se faz uma leitura do certificado, da data, do certificado, para que se quede no jornal, e faz... começa os dois serviços. Espera um pouquinho. Se faz depois a prova da hipótese que necessita que os dois serviços estéssem executando, é que se pode fazer uma requisição, mas agora não se pode mais. Então, o elemento se rompiu. Então, se faz o rollback, volta os certificados, e reempeça os serviços. Isso é tudo de demo. Aqui é o arquivo do experimento, onde é um JSON muito simples, onde tem a hipótese, onde eu escrevo as provas para testar o sistema. Eu tenho o método, onde fazem acções e provas para tentar romper o sistema. E, por último, o rollback com as referências para que não necessite escrever mais de uma vez o mesmo. Onde está que? Bom, se há só uma ideia que eu gostaria que dasse com você, é que empiecem sempre tiquitos. Não há sistema complejo que se empieçou complejamente. Entendeu? Então, é isso. Obrigado.