 Maravilha! E olha só, na hora 7h15, deixa eu compartilhar minha tela aqui com vocês. Ótimo! Então, me perdoem, os slides estão em inglês, mas pra ser honesto, não tem muito texto, não. Então, talvez não faça muita diferença. Então, hoje o tema é que eu escolhi pra falar com pra vocês From DevOps to the Cloud and Kubernetes. Então, de DevOps pra Cloud e Kubernetes, é uma discussão aí um pouco sobre DevOps, algumas histórias interessantes que eu tenho e essa jornada que nós temos aí pra implantar software na nuvem e agora implantar software em Kubernetes, que pra muita gente acaba sendo uma evolução natural do fato de você estar desenvolvendo aplicações para a nuvem. O meu nome é Edson Yanaga, meu Twitter é Aroba Yanaga, vocês podem ver no topo da tela. Eu sou um Java Champion, um Microsoft, um VPN, um TDC Rockstar e sou um Nipo Brasdeiro natural de Maringá-Paraná. E lá em Maringá-Paraná, você pode ver o André aqui no chat, o André foi meu aluno, lá em Maringá, acho que por mais de uma oportunidade, não, André. Nossa, faz tanto tempo, mas é muito bom a gente poder ver e rever os amigos, rever e rever os amigos aqui, mesmo que seja em plataformas virtuais. Sucesso pra você e André e pra todos os meus amigos ao redor do mundo. E o meu jabazinho aqui é que vocês têm a oportunidade de ter esse livro de graça pra vocês, Migrating to Microservices Databases. Esse é um dos, esse é o último livro que eu publiquei, o que lida mais ou menos como você tem que lidar, lidar como você quebra o banco de dados relacionado, o monolítico alegado em bancos de dados de microserviços e depois como você integra essas informações. Eu tenho um capítulo que fala um pouquinho sobre DevOps, um pouco que fala sobre outras arquiteturas, então espero que seja uma literatura bastante interessante e vocês têm o link aqui na tela, o Bitly Mono 2 MicroDB, mas se tiver complicado, vocês podem vir no meu perfil do Twitter, o primeiro tweet, o tweet marcado lá, opinado, tem um link para o livro. Vamos começar a discussão aqui com essa frase da Forbes. Now every company is a software company. Essa frase nem é tão nova assim, provavelmente já tem quase dez anos, mas representa por que a gente está vivendo essa transformação digital. E o interessante é que a gente está falando de transformação digital aí há quase dez anos, mas o que provocou mesmo transformação digital para a maioria das empresas foi a pandemia, foi o Covid. Lembra antigamente quando o pessoal falava que não dá para trabalhar remoto, não dá para fazer isso pela internet, não dá isso, não dá aquilo? Bom, a pandemia provou que sim, dá para trabalhar remoto, a produtividade não diminuiu, tem muita coisa que a gente pode que a gente faz pela internet. Então, ao invés de desculpas que nós tínhamos antes, agora que com a pandemia, como nós fomos obrigados a não dar mais desculpas e resolver os problemas, nós tivemos transformação digital e é por isso que nós tivemos tanto investimento em soluções digitais nos últimos dois anos e vamos continuar porque o pessoal viu que traz resultado e esse é um dos motivos também, transformação digital, investimento em transformação digital é um dos motivos que fez com que o mercado de trabalho, de tecnologia explodisse tanto. Eu tenho acompanhado algumas notícias aí do Brasil, eu sei que isso está acontecendo em geral no mundo inteiro, programadores estão sendo cada vez mais demandados, com salários cada vez maiores, por que? Porque hoje em dia todo mundo precisa de transformação digital, o pessoal viu que com transformação digital agora é uma necessidade, e as pessoas perceberem que com software você consegue fazer muito mais. E uma parte dessa transformação digital que vocês podem ver em exemplos super simples aqui, que a maior empresa de transporte através de carros do mundo não tem carros, que é o Uber, a maior empresa de hospedagem no mundo não tem nenhum imóvel, que é o Airbnb, e a maior, o maior varejista do mundo não tem estoque olibaba, e a maior rede produtora de conteúdo no mundo não produz conteúdo, que é o Facebook. Todo conteúdo é feito pelos seus usuários. O que todas as empresas têm em comum? Elas só existem por causa de software e o software que elas envolvem está mudando a vida das pessoas. Pra melhor e pra pior, em alguns desses casos a gente já pode até discutir qual que é qual. Mas é importante notar que tudo isso mudou a forma como a sociedade interage. Essas empresas mudam a forma como humanos interagem com seres humanos, e acho que tudo isso que a gente considera como sendo transformação digital. Então a transformação digital é você mudar a vida das pessoas através de software. E até para uma reflexão, eu estava constantemente dizendo que nos livros de história, daqui a 100 anos, daqui a 200 anos, o pessoal vai perceber que a pandemia de 2020, 2020-2020, ela vai mudar a forma como a gente conta a história da humanidade. A gente está na idade contemporânea? Tenho certeza que a pandemia de 2020 vai terminar um ciclo da humanidade e 2021 vai começar um outro ciclo da humanidade. E não somente por causa da pandemia que mudou como as pessoas relacionam, mas eu ouso dizer que 2020 vai ficar considerado nos livros de história como o ano da transformação digital. A nossa sociedade, antes ela tinha um misto, tinha o pessoal mais velho, tinha o pessoal que era mais reticente, o pessoal que era mais atrasado. A partir de 2021 a gente vai conseguir ver nos livros de história daqui para frente, que vai ser uma sociedade criada no software, uma sociedade baseada no software. E, cabe a nós, desenvolvedores, criamos uma sociedade melhor com o código que nós estamos fazendo hoje. E eu vou tentar dar mais alguns números para vocês sobre a importância dessa transformação digital na vida das pessoas e na vida das empresas. 15 anos atrás, a expectativa média de vida de uma empresa no ranking da Fortune 500, as 50 maiores empresas do mundo, baixou de 70 a 50 anos atrás para menos de 15 anos hoje. Então o tempo médico, uma empresa fica lá no ranking da Forbes, são 15 anos. Ou seja, a competição está muito mais assinrada. Por quê? Porque também diminuiu a barreira de entrada. Com software, a quantidade de capital que você precisa para entrar em determinados negócios é muito menor. Nós estou dizendo que seja baixo, porque para muitos mercados em investimento de software acaba sendo um capital bastante alto, mas a barreira de entrada com certeza acabou diminuindo. Até 2020, todo negócio vai ser uma presa digital ou um predador digital. A 2020 até está atrasado, a gente está em 2021, mas virou certeza. Ou você está tirando o mercado dos outros através de software, ou você está perdendo o mercado para os seus concorrentes, porque você não tem software o suficiente. E uma pesquisa do MIT de 2016, mas que representa muito bem o que está acontecendo hoje, é que 87% dos executivos pesquisados pelo MIT acredita que tecnologias digitais vão provocar a desrupção nas suas indústrias, vão mudar drasticamente as indústrias em que eles trabalham. Mas somente 44% indicou que as suas organizações estavam fazendo alguma coisa. E 11% deles acreditava que as pessoas, o talento dentro da companhia tinha as habilidades necessárias para sucesso na economia digital. Tudo isso em 2016, vamos tentar fazer um resumo aqui. 87% dos executivos se levam para cima, presidente, CEO, CFO, CIO, CTO. 87% das pessoas sabem que o negócio vai mudar, que o bicho vai pegar, 44% deles está fazendo alguma coisa e 11% acredita que o pessoal que trabalha na empresa tem a capacidade de proporcionar transformação digital. Esses números são alarmantes e ficou super evidente que a grande maioria das empresas foi pega desprevenida quando a pandemia surgiu e talvez muitos deles ainda estejam sendo pegos de modos prevenidos. E aí o grande evento que mudou todas as vidas, transformação digital, a gente vai lembrar da pandemia e da transformação de software. E por que o pessoal está sofrendo tanto para passar por essa transformação? Simplesmente porque mudança é difícil. Tudo que é mudança é difícil. Já pensou mudar, por exemplo, você está acima do peso? Ou você queria amalhar, queria ganhar um pouco de massa muscular, etc. E você coloca aqui na sua cabeça, mas mudar é difícil. Já tentou mudar a opinião das pessoas com que você trabalha? Já tentou mudar o âmbio de trabalho? Já tentou mudar o processo da sua empresa? Mudança é difícil e está se tornando cada vez mais difícil. Por que? Porque muitas dessas mudanças hoje em dia também precisam de software. E peguei uma informação antiga, mas esse número explodiu por causa da pandemia. Entre 2019 e 2020, o pessoal projetava que haveria um aumento de demanda de 25% no número de programadores das empresas. Eu acredito que esse número, na verdade, em 2020 deve ter batido aí o 75% ou 100%. E nós percebemos que adicionar gente a um projeto de software atrasado na verdade torna o projeto mais lento. Tirei essa citação aqui do Fred Brooks do livro, do clássico livro, The Mythical Man Month. E olha só que interessante, eu não sabia, mas depois que o meu filho entrou na Universidade de Carolina do Norte em Chapel Hill aqui no ano passado, ele estuda no departamento chamado Fred Brooks. Fred Brooks foi o cara que criou o Departamento de Computação aqui da UNCC de Chapel Hill. E eu estou brigando para o meu filho para ele catar o meu livro aqui e pedir para ele autografar. Parece que ele não está muito, como que eu digo, são. As faculdades conectivas dele talvez tenham diminuído um pouco, mas o Fred Brooks é um grande cara, fez muito para a área da computação, fez muito para a área da tecnologia e é dele a situação. Não adianta colocar mais gente num projeto de software atrasado, que o projeto só fica mais atrasado ainda. Então, temos a demanda por transformação digital. Está faltando programador no mercado, já era realidade, mas agora sim o negócio explodiu. Percebemos que também não adianta só colocar mais gente num projeto, que um projeto que já está atrasado acaba ficando mais atrasado. E a grande pergunta que fica é, como que a gente lidera essa mudança? Como é que a gente faz essa mudança, essa transformação digital acontecer nas empresas, nas equipes em que nós trabalhamos no dia a dia? E para poder dar a resposta para vocês, eu vou ter que apresentar primeiro para vocês o Círculo de Ouro, o Círculo Dourado, The Golden Circle, do Simon Sinek. Não sei quanto de vocês já leram o livro, que é bem curtinho. Eu ouviram a palestra do Ted Talk dele, que é 7 minutinhos. Bem interessante. Mas o Simon Sinek, basicamente, ele explica que para tudo que você faz na vida, você tem três grandes círculos. Você tem o Círculo do o quê, o Círculo do como e o Círculo do por quê. E se você quer realmente conversar com as pessoas para mudar, você sempre começa pelo Círculo do por quê. Sabe por quê? Porque se as pessoas sabem o por quê daquilo que elas estão fazendo, elas automaticamente encontram o como fazer aquilo e o o quê. Quais são os passos que elas têm que tomar para conseguir chegar naquele por quê? Então, você, muitas vezes, quando está no trabalho lá e alguém manda você fazer alguma coisa, aquela tarefa não parece sem sentido. Você não faz aquele negócio sem a mesma hipogação, sem a mesma edificação que você teria? Se alguém te explicasse o por quê, qual é o objetivo de você estar fazendo aquela tarefa? Quando você percebe que as suas ações fazem parte de um todo maior para alcançar o objetivo, você automaticamente, você muda o seu comportamento para alcançar aquele seu objetivo. E é por isso que a gente sempre começa pelo por quê. E é por isso que a partir de agora, essa palestra se concentra no por quê você tem que mudar, por que você tem que passar por transformação digital, por DevOps, para nuvem e para o Kubernetes. Assim você vai conseguir ficar ainda mais motivado e encontrar as etapas do como e no o quê na sua organização. Vamos pegar outra estação. Eu gosto muito de estação de gente famosa aqui. Os dois dias mais importantes da sua vida são o dia em que você nasceu e o dia em que você descobriu o por quê. É óbvio que a gente está aqui e todo mundo nasceu, mas não sei quanto de vocês já descobriram o por quê que você nasceu. Eu acredito que durante muito tempo da minha carreira eu fiquei perdido sem saber o por quê eu estava fazendo o que estava fazendo, mas alguns anos atrás, não muito tempo, na verdade, eu decidi que o por quê eu estava fazendo o que eu estou fazendo é porque eu amo desenvolver software, eu amo desenvolver código e eu decidi que eu gastaria a boa parte do meu tempo fazendo o melhor trabalho que eu pudesse e ajudando outros desenvolvedores ao redor do mundo a também se tornarem cada vez melhores. E essa é a missão que eu tomei para mim. Eu espero que você possa encontrar uma outra missão para você que seja super significativa para você e para o restante do mundo. E vamos começar essa discussão aqui com um pouco de DevOps. Quando a gente fala de DevOps, a gente tem ali, quando é que o seu trabalho está feito? Quando você terminou o seu trabalho? É quando você ganhou, pegou um ticket lá na agira ou pegou o seu post-it e mudou para a coluna do dano? Será que é aí que o seu trabalho termina? E o problema dessa abordagem é que quando a gente considera que o nosso trabalho simplesmente é codar e comitar as coisas no nosso repositório, consequências ruins acontecem com o nosso projeto. Consequências do tipo, esse mime aqui, que aliás Game of Thrones já está ficando um pouco desatualizada, mas representa muito bem a situação. Você comita um monte de código no repositório, vai lá, chega o famoso dia do deploy, você tem que colocar a código em produção e é aquele Deus me livre. Aquele dia que você nem dorme direito, você acorda porque sabe que vai ser um estresse o dia inteiro, vai ter ticket, vai ter telefone tocando o dia inteiro porque colocar código em produção acaba sendo um evento. E essa realidade, infelizmente, mesmo mais de dez anos depois do começo do movimento de DevOps, isso ainda é uma realidade para a maioria das empresas. Ou seja, segura aí, gente, que está vindo uma nova versão para ser colocada em produção. Vocês já devem ter ouvido também no mundo de DevOps que, ah não, colocar software em produção tem que ser um não-evento, etc. Tudo bem, mas isso aí é o que as pessoas deveriam fazer para melhorar a vida. As pessoas não explicam o porquê que você teria que fazer isso. Vamos ver se a gente consegue chegar no porquê aqui durante essa palestra. E uma das explicações para a gente ter esse momento de que, oh meu Deus, estava vindo em uma versão nova, é porque, tradicionalmente, equipes de software dentro de uma organização são divididas em dois grupos separados. Você tem o pessoal do Dev e você tem o pessoal do Ops. Você tem o Developers e você tem o IT Operations. Quem criou essa dicotomia? O pessoal do Gartner. Então o Gartner, lá para a década de 70, creio eu, ele colocou lá que não uma empresa bem estruturada, etc. E tal, vai ter dois times dentro da mesma empresa. Um time vai ser o time de Developers, outro time vai ser o time de Operações. E desde a década de 70 foi assim que as pessoas, que as equipes, acabaram sendo organizadas nas grandes empresas. E em 2009 o nosso amigo Patrick de Boa criou esse termo Dev Ops para dizer que não, gente, não era para ter dois grandes apartamentos da sua empresa. Você tem que ter o Dev e tem que ter o Ops e eles têm que estar trabalhando junto para alcançar o mesmo objetivo para você ter uma qualidade de software melhor na sua empresa. E a grande maioria dos problemas causados pela distinção do Dev Ops é causada por esse muro da confusão que nós temos aí. O que esse muro da confusão representa? Representa que a dificuldade de comunicação que as equipes de Dev e de Ops têm uma com outra. E eu entendo muito bem por que isso acontece, porque você tem esse muro da confusão. Porque, na maioria das vezes, os Developers, simplesmente os desenvolvedores, simplesmente estão lá cometando o código, ele gera um artefato, joga o artefato por cima da parede, cai no colo do Ops e a galera do Ops tem que colocar o código na produção e o negócio explode na cara deles. Muitas vezes, quando isso acontece, o pessoal de Dev não está nem aí. E por que que ainda existe essa parede da confusão? Vou dizer que o motivo econômico pelo qual Dev e Ops não são amigos é, primeiro, a galera de Ops não gosta do pessoal de Dev porque você não tem como ser amigo da galera que lá toda sexta-feira na hora de deploy está fudendo com a sua vida. Porque a galera Dev aqui encomita, Ops coloca em produção e o negócio explode e a galera do Ops tem que ficar até mais tarde tentando resolver os problemas. Então não tem como ser amigo nessa situação. E o motivo é econômico. Por que? O pessoal do desenvolvimento, os desenvolvedores, eles são medidos pelo que? A produtividade deles é linha de código, número de eixo de vida, novas funcionalidades adicionadas na ferramenta, no seu software. Então os developers, os desenvolvedores, eles são produtivos quando eles mudam muito o código, certo? E do outro lado, o pessoal de operações. O pessoal de operações, ele é produtivo quando ninguém lembra deles. O que é não lembrar deles? É quando as coisas funcionam. Então o meu sistema funciona, o meu e-mail funciona, a minha rede funciona, o meu meu individual funciona, tudo funciona dentro da empresa. E nós já aprendemos desde criança que é a melhor coisa para você manter o negócio funcionando é não mexer nas coisas. Se a coisa você não mexe, deixa quieto, a coisa vai continuar funcionando. Então esse é um conceito fundamental de Ops. Você é produtivo quando as coisas estão funcionando e o melhor jeito de deixar as coisas funcionando é não mexendo nas coisas. Os devs, por outro lado, eles são medidos por produtividade. Eles têm que estar mexendo e mudando nas coisas todos os dias para ser produtivos. Como esses dois grupos de pessoas têm objetivos diferentes, não tem como eles serem amigos, não tem como eles se dar bem nesse processo de dev e Ops. E essa briga constante entre dev e Ops gera alguns memes super interessantes. Essa aqui é a Disaster Girl e eu fiz esse meme aqui há muitos anos atrás. Tem até várias cópias aí na internet, mas representa muito bem o fato, o dia a dia, dos desenvolvedores. Eu não sei quantos de vocês são desenvolvedores, imagino que a maioria. Eu sou um desenvolvedor e esse meme da Disaster Girl diz o quê? Funcionou, é o famoso da minha máquina funciona. Funcionou bem aqui em desenvolvimento, agora é um problema de Ops. E por que a gente diz que é o da minha máquina funciona? Vou contar uma história para vocês aqui. Uma história interessante, creio eu, de uma história que aconteceu verídica muitos anos atrás comigo. Eu já tive uma pequena empresa de software, a gente vivia software para outras empresas e uma delas era uma empresa de plano de saúde. E nós passamos meses criando a nova versão do software, etc. Nós achamos que aquele software ia ser a melhor coisa do mundo e ia mudar a vida das pessoas para melhor. E realmente o pessoal ia considerar o mundo antes do software e depois do software. E nós fizemos o deploy do software na sexta-feira, no final de semana, passamos o final de semana inteiro garantindo que as coisas iam funcionar na segunda, mas na segunda-feira de manhã. Eu já estava prevendo que ia ser um dia ótimo. Então, era 5h30 da manhã, eu já estava no escritório esperando o telefone tocar para receber os elogios. Mas, naquele dia, deu seis horas da manhã, os laboratórios começaram a abrir, os hospitais, etc. O pessoal começou a chegar para fazer exame e ninguém conseguia autorizar exame e deu um monte de problema e o software começou a dar um monte de pipoco, etc. Ou seja, foi um dia terrível, terrível, terrível. E nós tentando apagar incêndio, tentando identificar o que estava acontecendo e tínhamos ali milhares de pessoas tentando usar o sistema ao mesmo tempo naquela manhã e ninguém estava conseguido fazer nada. Ou seja, aquele foi um dia de merda para nós e para os usuários. E lá pelas 9h00 e 10h00 da manhã, o negócio já estava pegando fogo e a gente não conseguia remenso e resolver o sistema, ou seja, das 6h00 da manhã, nada. Pouquíssimas pessoas estavam conseguindo autorizar ali os procedimentos e os exames de sangue, etc. Eram umas 9h00 e 10h00 da manhã, mais ou menos, o presidente da empresa pega e liga no meu celular. A gente ia falar, e essa ligação eu vou ter que pegar. Atendiu o celular e o Sílvio, que hoje eu tenho muito carinho por ele, mas naquele dia foi difícil. E ele ligou lá, depois de como há uns 5 minutos, me xingando mais ou menos no celular, até que eu conseguisse falar alguma coisa. E quando eu finalmente consegui tentar gaguejar alguma coisa, uma resposta de sugesticado do que está acontecendo, eu acabei soltando uma dessa. Mas, Sílvio, eu não sei o que está acontecendo, mas se eu tivesse que falar alguma coisa para você agora, eu só queria me explicar e dizer que na minha máquina funciona. Ele me xingou mais uns 2 minutos, mais ou menos depois disso, e ele me ensinou uma das lições mais importantes que eu carrego na vida até hoje. Ele falou, ianaga, vai tomar no copo, e eu não estou te pagando para fazer esse negócio funcionar na sua máquina. Eu estou te pagando para fazer esse negócio funcionar na minha máquina. E eu fiquei absolutamente mudo por 30 segundos. Ele ficou gritando, ianaga, ianaga, ianaga, você está aí ainda. Eu falei, estou aqui, estou aqui e você está certo. Tem que funcionar na sua máquina. Não faz a diferença mínima se está funcionando na minha máquina ou não, mas, infelizmente, hoje não é isso que está acontecendo e eu vou ter que desligar para poder tentar resolver o problema. Então, aí, gente, não tem que funcionar na sua máquina. Tem que funcionar em produção. Produção é que faz a diferença. Jóia! E como que a gente tenta resolver esse problema, então, do que a máquina funciona? Primeiro, agora é parte da resposta. Primeiro, a gente tem um negócio no mundo de software, que na verdade acontece em todas as áreas humanas, mas em software é super relevante para o nosso caso, que é o chamado feedback loop. Quanto menor o feedback loop, quanto melhor o feedback loop que a gente tem no nosso processo de software, melhor é a qualidade do software que a gente coloca em produção. Por que isso? Porque nós seres humanos, nós somos super eficientes para estabelecer correlação entre eu fiz isso aqui e agora e estou tendo esse resultado lá em produção. Se nós mudamos pouca coisa no software e se nós levamos pouco tempo entre o que a gente fez e o resultado que a gente tem em produção. Por outro lado, se a gente muda um monte de coisa e leva um tempão para a gente ter o resultado, nós seres humanos somos terríveis em estabelecer esses ciclos de feedback. É para isso que a gente usa outras técnicas, mas máquinas são muito boas para esse tipo de coisa. Por isso que a gente usa o processo de machine learning. Mas quando o tempo é pequeno e a quantidade de informação é pequena, seres humanos são especialistas em conseguir reconhecer padrões de feedback, ok? É por isso que é importante ter um feedback loop bom. É por isso que a gente sabe, opa, deixa eu dar essa mudadinha aqui que vai melhorar. Se você consegue ter um tempo curto entre a pequena mudança que você fez e o resultado em produção, você consegue facilmente estabelecer essa correlação. Então esse é o lado bom do ser humano. O lado ruim do ser humano é quando leva muito tempo e muda muita coisa. Nós somos super ruins naquilo. Então feedback loop bom é quando a gente consegue pegar a parte boa das nossas habilidades. E uma outra pergunta que eu costumava fazer muito quando eu era um consultor independente, quando eu visitava a empresa de software, eu visitei empresas de bancos financeiras, startups, empresas de internet, varedista. Já prestei consultoria para empresas dos mais diversos setores e eu sempre fiz essa pergunta quando o pessoal me chamava para resolver um problema de DevOps de processo. A gente sabe que a gente tem que ter um feedback loop bom. E todo mundo diz que você tem que fazer o deploy cada vez mais rápido. Mas se você sabe que você tem que fazer deploy cada vez mais rápido, o que te impede de fazer esse deploy cada vez mais rápido? E eu tenho certeza que eu fizesse uma pesquisa agora com todo mundo e todo mundo ia me dar a mesma resposta. Quer o quê? Quer um bugs. A gente não consegue colocar software mais rápido em produção porque a gente tem muito bug. Toda vez a gente coloca software novo em produção a gente tem um monte de pau, tem um monte de erro, etc. E é por isso que a gente não consegue acelerar o processo. A gente passa mais tempo corrigindo o bug do que colocando nova funcionalidade no nosso código. E eu vou estabelecer agora, vou dar para vocês agora uma regra de ouro do DevOps. E eu vou colocar ali. Por quê que você não consegue colocar código mais rápido em produção? O jeito natural da gente resolver, o jeito humano da gente tentar resolver o problema de bugs em produção é evitar colocar software em produção. Por quê? Porque se eu coloco software em produção a cada mês, se eu faço um deploy por mês e dá pau, e dá muito pau, você pensa ah, dá pau porque não deu tempo de testar. Se não tem tempo de testar, então precisa de mais tempo para testar. Você acaba o quê? Levando dois meses agora para testar sua aplicação. Você faz deploy a cada dois meses, continua dando pau na sua aplicação, continua tendo bugs quando você faz o deploy. Então você pensa, ah, não tive tempo suficiente para testar de novo. Em vez de fazer deploy a cada dois meses, você vai fazer deploy a cada três meses. E por aí vai. Nada a nada daqui a pouco você está fazendo deploy a cada seis meses, a cada um ano. E eu achei que um ano era tempo suficiente, mas eu descobri uma empresa lá na Europa que fazia deploy a cada quatro anos. Ah, mas esse não é um exemplo que a gente deva acabar seguindo. Então por que isso acontece? Pessoal não percebe que quanto mais tempo você leva para fazer deploy, quanto mais tempo você tem para testar, mais tempo você tem para codar também. Enquanto mais código você muda, mais bugs você tem em produção quando você coloca. Então a gente percebe que o que causa bugs em produção são mudanças. Quanto mais mudanças você tem no seu código, no seu software entre uma versão e outra, mais bugs você acaba introduzindo no seu software em produção. E tecnicamente falando, essas mudanças podem ser em três lugares. As mudanças podem ser no código, o que significa que você está mudando o comportamento. As mudanças podem ser no estado da aplicação, ou seja, você está mudando os dados que estão sendo armazenados e manipulados pela aplicação, ou essas mudanças podem ser na configuração da sua aplicação. Ou seja, você está mudando o ambiente em que a sua aplicação está sendo executada. Então tecnicamente no mundo de DevOps diz que mudanças causam problemas em produção e essas mudanças podem ser em três áreas. Código, Dados e Ambientes. Ok? Essa é a correlação que eu gostaria de fazer. Gente, se mudanças e vamos tentar simplificar aqui para vocês entenderem melhor. Se mudanças causam problemas em produção e essas mudanças são casadas por código, quando mais código você coloca entre uma versão e outra, mais bugs você tem em produção e esse jeito que a gente tem de resolver problemas que a gente tem nos últimos 20 anos. 30, 40 anos. O modo DevOps de você tentar resolver esse problema é o contrário. Você tentar diminuir o número de mudanças que você tem entre cada uma das versões para você poder diminuir o número de bugs que você coloca em produção. Como é que você diminui o número de mudanças? Diminuindo o batch size. O que é o batch size? Batch size é o número de mudanças, mas você tem mais mudanças em linhas de código e número de features. Eu não me importo. O jeito mais simples de você resolver o problema de DevOps é mudando o tamanho das mudanças que você tem entre cada uma das versões. Você vai perceber que automaticamente quando você muda o seu batch size automaticamente outras métricas do DevOps acabam sendo melhoradas automaticamente. O seu tempo de ciclo diminui quando você diminui o batch size. Então tudo acaba entrando em um círculo virtuoso. Então diminua o tamanho das mudanças entre as versões que você vai diminuir o número de bugs, vai diminuir o risco de colocar em produção e vai acabar melhorando todo o seu processo de software. Isso é o problema. Fazer uma referência aqui. DevOps procede de software. Tem esse livro Continuous Live. Tem mais de 10 anos. Foi escrito já. E ele envelheceu assim super bem. Eu já li esse livro algumas vezes mas a última vez que eu li faz algum tempo mas se eu me recordo bem mais da metade do livro do Continuous Live trata de testes automatizados. Não adianta nada você ter um processo de software. Você tentar fazer DevOps etc. Se você não tem um processo automaticado de software. O processo de teste automatizado teste automatizado faz parte da jornada de Continuous Live e faz parte da jornada de DevOps. Se não teste não escala. Test manual tem que ser um percentual muito pequeno do seu software. O ideal é 100% de teste automatizado para que você consiga fazer o deploy cada vez mais rápido e tem um betsize cada vez menor. E a segunda parte a gente descobriu que não dá para colocar software mais rápido em produção por causa de mudanças. Por causa de bugs. E a segunda causa que previne pessoa de colocar em software em produção cada vez mais rápido. Pessoas não dá para colocar software mais rápido em produção porque a galera não deixa. Porque o DBA não muda as coisas que eu peço para ele no tempo correto. Eu não consigo colocar software porque eu não tenho a senha de root do servidor. Não dá por causa disso. Não dá por causa daquilo. Não dá porque eu tenho um processo que impede que eu faça mais rápido. Gente, para que fazer com que todo mundo trabalhe com o mesmo objetivo em produção só tem um jeito. Fazer todo mundo ser medido pela mesma métrica. Enquanto desenvolvedores forem cobrados por mudança. Gente, tem que codar. Você não vai conseguir fazer esse devolpe funcionar. Essa cultura de devolpe funcionar. Então, em todos os lugares que eu citei o jeito mais fácil de você fazer todo mundo virar amiguinho, todo mundo trabalhar junto é fazer com que todo mundo seja cobrado pelo mesmo objetivo. Devops tem que ter a mesma métrica. Ops não pode ser só cobrado por estabilidade. Dev não pode ser só cobrado por mudança de código. Todo mundo tem que estar com eu falar um palavrão aqui mas todo mundo tem que estar com a carreira na reta. Para não usar outra palavra que começa com C. Todo mundo tem que estar com a carreira na reta ali para quando você coloca software em produção caso contrário para ter essa diferença entre dev e ops porque eles têm objetivos diferentes. Essa foi a parte do cloud native for a parte do devops e o cloud native. Cloud native é esse termo que a gente tem utilizado nos últimos 10 anos para determinar que software coloca na nuvem. Ah, mas software coloca na nuvem, que que é cloud native, qual é a definição que a gente tem e eu vou explicar para vocês a origem do termo cloud native. Cloud native surgiu quando o Netflix pioneiro nessa adoção de software para a nuvem. O Netflix iniciou essa migração dele de on premises para a nuvem em 2009 e finalizou essa migração lá no ano de 2010. Então em 2009 para 2010 ninguém sabia o que era esse trozo cloud native. A nuvem ainda era uma novidade que a pessoa estava experimentando, como é que eu faço software em larga escala distribuído que aproveita as capacidades da nuvem. E no meio do caminho a Netflix acabou criando um monte de ferramentas e criou o conceito daquilo que a gente chama hoje de cloud native. Mais tarde uma empresa ali chamada Heroku criou o que a gente chama de hoje de 12 factor apps os 12 fatores para aplicações cloud native e também sim as características de aplicações cloud native pelo menos das aplicações de 10 anos atrás. Só que o Netflix criou o cloud native o conceito de cloud native como uma ferramenta para eles se basearem em quais seriam as capacidades que eles tinham que adicionar na plataforma para poderem ser bem sucedidos nesse mundo de nuvem. E algumas das principais características de cloud native é que cloud native tem que ser escalável tem que conseguir escalar facilmente para milhões de usuários e requisições tem que ser global, tem que ser uma plataforma global que não pode ser confinada a uma determinada geografia tem que ter alta disponibilidade porque quando você lidera e com múltiplos time zones não tem aquela janela de manutenção no caso de Netflix por exemplo a galera está assistindo vídeo de Netflix no tempo todo porque o horário é que o pessoal assiste vídeos, filmes e séries ele é mais ou menos o mesmo mas como o relógio como o dia vai passando ao redor das geografias você sempre tem acesso tem que ter alta disponibilidade não tem mais aquele horário que ninguém mais está usando e tem que ser orientada a consumo ou seja você tem que poder consumir você como desenvolvedor você tem que ser um usuário de forma que você está utilizando tem que ser self service você não pode pedir para ninguém tudo tem que estar na sua mão os recursos estão disponíveis quando você precisa e é uma coisa que o pessoal percebeu porque desenvolvedor é caro fazer um desenvolvedor e esperar por um recurso é muito caro para a empresa vocês não viram no twitter aí em semana passada que surgiu essa thread Uber e Spotify estão trocando todos os notebooks dos desenvolvedores o último MacBook Pro top de linha mas é uma máquina que custa 5, 6 mil dólares cada uma é dinheiro mas o custo de ter uma máquina lenta comparada com o salário desenvolvedor é muito caro é por isso que comprar uma máquina nova uma top de linha mesmo que custe 6 mil dólares acaba sendo um investimento que se paga rapidamente porque os nossos desenvolvedores acabam sendo mais produtivos então fazer desenvolvedor e esperar é custoso para a empresa e aplicações de 12 fatores foi perfeito para a época foi perfeito para 10 anos atrás mas hoje já não são mais suficientes então não basta você ter ali os 12 fatores checados no seu processo e na sua aplicação você precisa de boas ferramentas para poder no seu processo de software você precisa de boas ferramentas para colocar software e produção e infraestrutura tem que ser chata que que é infraestrutura chata infraestrutura chata que é a infraestrutura que funciona não é aquela infraestrutura empolgante aquela infraestrutura kinderogo que todo dia é uma surpresa diferente que todo dia você tem um problema que não teve antes e você tem que ficar descobrindo o que está acontecendo com essa infraestrutura não, infraestrutura tem que ser chata infraestrutura tem que ser aquele negócio que você sabe como funciona que sempre vai funcionar desse jeito e que você confia eu sei que se eu fizer isso esse é o resultado que eu vou conseguir e esse é o objetivo da infraestrutura e para conseguir alcançar esse novo mundo que nós estamos vendo nós precisamos de boas ferramentas infraestrutura tem que ser chata nós precisamos de bons padrões também de processo quais são esses padrões alguns padrões importantes que eu poderia citar no mínimo são que nós precisamos de padrões de disponibilidade ah como assim a disponibilidade como é que eu faço o rollout de uma aplicação como é que eu faço o release de um software em produção como é que eu faço o rollback como é que eu garanto que o número mínimo de instâncias esteja disponíveis de produção padrões de automação que eu automatizo determinados processos dentro do meu ambiente de produção dentro da minha infraestrutura de entrega qual que é o melhor jeito de eu conseguir criar pipeline de entrega será que eu tenho 500 mil ferramentas aí ou será que eu posso seguir um padrão e que uma vez e olha só a importância de você ter padrões pra tudo isso é que padrões se tornam em boas e mais práticas e acaba sendo muito mais fácil pra comunidade desenvolvedores mundial uma vez que você tem os padrões e você reconhece quais são os bons padrões pra poder adotar esses bons padrões e boas práticas nos seus processos você acaba podendo divulgar o que é bom dentro do seu processo da sua comunidade e portabilidade o seu software, os seus padrões a sua infraestrutura tem que ser portável não importa onde você esteja rodando a sua aplicação e o jeito que nós resolvemos em 2021 pra poder resolver todos esses problemas tem que ter padrões do clowner tem que ter mais do que 12 fatores tem que ter boas ferramentas tem que ter uma infraestrutura chata e tem que ter padrões, bons padrões de descolabilidade, automação entrega, portabilidade o jeito que nós encontramos pra alcançar isso em 2021 foi Kubernetes Kubernetes se tornou aí a plataforma e a experiência mundial é a plataforma em que todo esse ecossistema está sendo criado e pra poder mostrar pra vocês um pouquinho desse ecossistema olha só essa aqui é uma figura desatualizada é de março de 2021 do ecossistema que está sendo criado ao redor de Kubernetes essa aqui é a cloud native landscape da cloud native computing foundation mas quando você der cloud native computing foundation entenda é Kubernetes e o resto porque todo o restante do ecossistema basicamente ele é criado pra suportar esse ambiente do Kubernetes então é isso que torna infraestrutura chata é isso que torna uma infraestrutura que funciona quando você tem um ecossistema e você tem aí centenas, dezenas de empresas trabalhando com o mesmo objetivo pra garantir que o seu software rode bem e que seja colocado bem em produção ok e é claro não vou ter tempo vou falar que tem 2 minutos ah tá isso aí é deixar o gancho aqui porque eu acho que o Roberto que é o próximo ele vai falar de Quarkus não é? vai falar de Quarkus perfeito então o gancho que eu gostaria de falar pra vocês é que não somente Kubernetes é a resposta pra boa parte dos desafios que nós temos hoje nesse mundo novo pra alguns Kubernetes é o problema pra outro Kubernetes é a solução e eu digo que o lado da moeda que você está só depende do quanto você conhece o ecossistema se você não sabe o suficiente da ferramenta, ela é um problema se você sabe o suficiente da ferramenta, ela é parte da solução então decidem de que lado vocês querem falar desse problema mas não somente em infraestrutura você ter bons resultados nesse mundo em que nós vemos hoje colocando software em produção em Kubernetes ou não eu recomendo que vocês tenham uma olhadinha no Quarkus ah o Quarkus na minha opinião representa a maior revolução que nós tivemos aí nos últimos 20 anos de desenvolvimento de software pelo menos o pessoal no mundo java prestar atenção na palestra do Roberto que logo a seguir vocês vão perceber que o Quarkus representa a revolução não somente pra quem trabalha com Java mas pra quem trabalha com outras plataformas também porque o negócio é muito bom e não adianta eu ficar falando isso aqui porque vocês tem que ver o negócio em ação e é por isso que eu gostaria de encerrar essa primeira palestra do dia e deixar vocês eu vou deixar o Roberto com vocês pra ele mostrar pra aquela que realmente empolga que é código e colocar o negócio pra rodar beleza gente muito obrigado obrigado Helder obrigado pessoal do Dev Nation Latam e eu faço os boas-vindas para o Roberto que já deve estar disponível ele tá no back stage acho que tem um minutinho pra você responder a pergunta se você puder tem uma do Jefferson eu vou ler aqui pra você tem mais de 30 anos de informática e presença à evolução da TI sempre atuei na parte de Ops opa, pera, que rolou a tela mas com a evolução acabei ficando defasado assistindo vídeos no youtube pra tentar me atualizar com esse feras como Wesley Williams, Fabio Aquita e Hetsu Yanaga o Yanaga me incentivou a migrar pra DevOps e desde então tenho estudado muito pra suprir minha deficiência em dévio e a pergunta é, qual sua opinião de um profissional com 50 anos de idade entrando no mercado DevOps Alessair, Jefferson eu vou dizer que, embora eu confesse que algumas pessoas relatam pra gente que tem, existe um certo preconceito em relação com a idade eu no mercado de tecnologia eu com certeza considero que essa opinião de que idade influencia automática um absurdo até porque uma das coisas que eu mais valorizo hoje no mercado software é a experiência eu vejo que no nosso mercado software ainda bem que a gente tem um monte de gente nova ainda bem que a gente tem um monte de gente junior no mercado mas, infelizmente nós não temos pessoas seniors o suficiente nós não temos pessoas experientes o suficiente no mercado pra gente dar o suporte a esses juniors então se a gente fala que tem muito junior fazendo cagada e muito processo etc porque não existem essas pessoas experientes pra dar o suporte pra que não gente, não é poimém por aí talvez se a gente fizer de outro jeito vai ficar melhor então a gente falta esse pessoal pra dar mentoria pra essa galera mais nova então Jefferson, eu acho que esse é o papel que você tem que ter nesse mundo de DevOps e o conhecimento que você tem nesse mundo de DevOps aí continua sendo válido porque tenho certeza que essa galera de Dev e essa galera de Ops não conhecem não tem todas as cicatrices que você tem passando por essas batalhas se eu tivesse que te dar uma dica é conhecer um pouco do mundo do momento ajuda bastante mas como você veio do mundo de Ops conhecer e divulgar as ferramentas de automação que vão facilitar a vida de outros outros galera de Ops e a vida dos desenvolvedores eu acho que esse é um bom passo pra você tentar encurtar ali essa distância entre o mundo do Dev e o mundo do Ops ok é isso aí cara, brigadão, obrigado mesmo a galera tá dando aí os parabéns uma grande anaga, muito bom, valeu obrigado, palminhas etc então, obrigada a galera curtiu e obrigado por estar com a gente aqui hoje prazer em meu gente, obrigadão e um ótimo Dev Nation Day pra vocês beleza, valeu, anaga um abraço até mais