EP 116 | End of life: desafios de atualizar tecnologias em ambientes de alta escala

Você que é amante da tecnologia, PodDev se aventurar conosco nesse podcast cheio de conhecimento e bom humor que vai transformar o seu dia a dia de trabalho para melhor. Começa agora o PodDev.

Fala, galera. Tudo bem com vocês? Aqui quem fala é Walter, também conhecido como Valtinho. Sou gestor de comunidade aqui dentro da Hotmart. Cuido de comunidades como a HotHackers, que é a nossa comunidade de desenvolvimento. Cuido também da Jedi Community, que é a nossa comunidade de inteligência artificial. Sou mestre de cerimônia do Hot & Code Conference. Inclusive, você já pode adquirir o seu ingresso aí para o nosso evento. É o maior evento de tecnologia da Hotmart. Ele acontece uma vez por ano.

É o grande ápice dos nossos encontros, onde a gente troca conhecimento, traz informação para vocês. Então se você já é ouvinte assíduo do PodDev, você deve adquirir o seu ingresso para o Conference. Ele vai fazer muita diferença para vocês. A gente está trazendo nos episódios como o Conference já fez diferença na vida de diversas pessoas.

pegando o que aprendeu e aplicando dentro das suas empresas. Então, realmente, é um grande investimento que você vai fazer na sua carreira, na sua vida e no seu desenvolvimento pessoal e profissional. E também aqui, host do nosso queridíssimo podcast, o PodDev. E trazendo aqui, mais uma vez, minha queridíssima co-host, também gestora de comunidade da Hotmart, Bruninha.

Fala, galera. Estou muito animada para mais um episódio aqui com vocês. Eu amo o PodDev, estou aqui com o Valtinho trocando muita ideia com todo mundo. E queria só dizer que o conference vai estar muito bacana. Estamos preparando tudo com muito carinho, então você não pode perder.

Para a gente começar hoje, quero chamar aqui nossos convidados. Hoje a gente está aqui, Matinha está participando, já participou muito com a gente, convidado muito especial. Acho que dispensa apresentações, mas acho que é legal você se apresentar também para novos ouvintes, Matinha.

E aí, pessoal, tudo bem com vocês? Espero que vocês estejam animados com esse episódio. A gente vai falar sobre End of Life. Isso me remete muito ao Rei Leão na frase dos ciclos da vida. Sensacional. O voltinho até tá dando gargalhadas aqui.

Pô, aí eu não teve jeito. Te quebrei, né? Eu lembrei do ciclo sem fim. Aí eu falei, não, ciclo aqui tem fim sim. São ciclos da vida. Mas vai ser um episódio bem bacana e é uma coisa recorrente na vida de todo desenvolvedor. Vocês vão ver que todo mundo passa por isso.

Exatamente. Como você mesmo já disse, né? Se tem legado é porque deu bom, né? Exatamente. É sucesso. Se precisou fazer Indie Off-Life é porque foi bom, né? Perdurou, perpetuou. Foi bom enquanto durou. Foi bom enquanto durou, exatamente.

Trazendo aí também, a gente trouxe dois elementos da nossa equipe queridíssima de DevOps, né? Então, ele aí que é o nosso roqueiro oficial que escuta Calcinha Preta Marra.

E aí gente, tudo bem com vocês? Como vai? Quem fala aqui é o Marra, sou coordenador da área de DevOps de Plataforma Financial. Vim falar um pouco sobre E.O.L. junto com esses grandes amigos aqui da Hotmart. E é isso, vamos lá falar de coisa importante, coisa rotineira. Desde que eu voltei para a Hotmart, na verdade, setembro.

De 2024, eu já lido com o EOL aqui. Então, isso é um assunto muito recorrente, muito vivido na nossa rotina aqui do trabalho. E junto comigo, nós trouxemos juntos o Murilão, também meu parceiro de coordenação. Fala, Murilo. Fala, pessoal. Tudo bem?

Prazer, Aço, estar participando aqui do PodDev. Meu nome é Murilo, estou aqui na Hotmart há alguns anos, trabalhando com essa equipe maravilhosa e sempre tratando desses problemas, desses assuntos. Hoje a gente vai conseguir falar um pouquinho dele.

E Murilo, você elogiou tanto a equipe, mas você não sabe o que eles solicitaram pra mim. Eles falam assim, Walter, você vai ter que mexer na saturação da câmera pro episódio? Aí eu falei, gente, mas o episódio é só áudio, não tem vídeo. Ele falou assim, pô, ainda bem, porque senão ia ter que mexer. Porque o jeito que o Murilo tá...

parecendo gringo na praia do Rio de Janeiro. Então, assim, o Murilo foi lá pular um bloquinho de carnaval ontem e está completamente vermelho aqui hoje. É, pessoal, passem protetor solar. Isso, se cuidem. E participem dos bloquinhos aqui de Belo Horizonte. Maravilha, acho que melhor recado. Bom, bloquinhos de carnaval são muito importantes. E End of Life também.

Bom, para a gente começar, vamos falar um pouquinho de qual é a importância de End of Life. Por que a gente está aqui conversando sobre esse assunto hoje? Boa, End of Life está mais retratado a parte de vencimento de versões que passam a ser depreciadas. Seja por algum fornecedor, seja por algum trabalho interno dentro da Hotmart, algum produto que a gente utiliza, até mesmo fabricantes. Por exemplo, Java tem algumas bibliotecas que ficam...

depreciadas e precisam ser atualizadas. E conforme as coisas vão evoluindo, não só, por exemplo, um banco precisa ser atualizado, mas toda a forma de fazer conexão de uma forma recursiva, porque acaba... A tecnologia evolui muito rápido. Com isso vem vários updates. E com isso vem trabalho, que é trabalhar com a EOL.

Isso acontece de várias fases e de várias maneiras. Tem diversas bibliotecas on-pensource, a comunidade vai depreciando algumas versões antigas e vai mantendo suporte só nas versões mais recentes, cada biblioteca tem uma política.

A gente usa bastante o nosso background em Java, que na Hotmart é bem extenso, bem forte. A maioria das aplicações usam Java. Então, tem os end-of-lides das versões da JVM. A gente usa como framework o Spring e o Spring Boot.

O Spring tem uma política de a cada seis meses ter uma versão nova, normalmente em maio, em novembro. Aí quando lança uma versão nova do ano anterior, ela é depreciada, então ela já entra em end of life. O que significa isso? Significa que se for encontrado algum bug, alguma vulnerabilidade naquela versão, a comunidade não vai disponibilizar uma correção para aquela versão. Então se tiver alguma coisa, a gente tem que atualizar para uma versão que está com suporte corrente ainda.

Então, a gente deixar uma aplicação presa em uma versão muito antiga é um risco, principalmente relacionado à segurança, porque ela não está recebendo mais correções de bugs. Se acontecer alguma vulnerabilidade bem grave, bem alta, a gente vai ter que correr para atualizar aquela aplicação para a versão corrente. E se está em uma versão muito antiga, significa que a atualização não vai ser fácil e imediata, ela vai dar trabalho.

Quanto mais, eu brinco assim, atualizações, quando a gente está mantendo atualizado, é muito mais fácil do que você ficar, por exemplo, uns dois, três anos com a versão desatualizada e lascou. Sim, eu acho que isso é muito importante, né? Como o Matinha falou, a parte de segurança, nós sempre estamos olhando para isso, né? A gente tem a equipe de cyber aqui que sempre está apontando para a gente.

Nós temos a ferramenta aqui do handle que a gente consegue identificar, algumas libs que a gente usa nas aplicações. Eu acho que é um trabalho... Todo ciclo tem o início e o fim, né? Assim como as libs. Então, é sempre bom a gente estar olhando isso, se preocupando, vendo que isso pode ter algum impacto nas nossas aplicações.

Creio eu também que quando a gente fica muito tempo sem essas atualizações e precisa pular para uma versão mais nova, gera um monte de breaking changes e aí a gente tem que refatorar código, repensar naquela aplicação. Eu acho que é sempre importante a gente estar trabalhando de pertinho com isso.

O Murilo citou bem a questão do renda e ele é fundamental dentro da Hotmart. E para quem não ouviu, a gente falou dele no episódio de dívidas técnicas. Para quem não ouviu, eu recomendo escutar para vocês entenderem um pouco mais sobre o renda.

Mas como ele é um grande catálogo, ele facilita muito a gente detectar quais versões de biblioteca são usadas por quais aplicações e aonde precisa de atualizar. Então, por exemplo, se a AWS solta que a gente precisa de atualizar uma versão do Elastic Cache para uma versão XPTO.

Aí a gente vai olhar todo mundo que está usando a versão anterior que realmente precisa ser atualizado. E por aí vai, né? Uma versão específica de banco de dados, uma versão específica de cache ou algum componente específico do Kubernetes, né? Então, isso aí a gente consegue rastrear muito fácil usando o handle. Isso ajuda demais.

Boa! Além disso, a gente tem também muitos benefícios com relação a features. O Martin ressaltou um ponto importante sobre correções de bugs e vulnerabilidades. Mas também, se a gente não acompanha a tecnologia, a gente fica à mercê de boas features.

seja uma otimização de queries, seja uma nova forma de fazer uma query, seja, não sei, um pipeline mais ágil, a gente acaba abrindo mão de bons benefícios. Então, por isso, é importante ter um controle de EOL. Como eu costumo dizer aqui, a gente tem que estar, pelo menos aqui em DevOps, um lema que eu levo para dentro das equipes, a gente tem que estar à frente do tempo. Então, é cobrar que as coisas sejam atualizadas no tempo que elas precisam ser atualizadas.

Por que? Isso evita um retrabalho que pode ser grande, evita estresse tanto da equipe de DevOps quanto do desenvolvimento. Porque a gente entende que existem vários roles. Alguns são bons, todos são bons na verdade, mas alguns são mais rápidos de serem feitos. Outros exigem um pouco mais de cautela. A gente está passando por um agora, por exemplo, vou citar aqui o do MySQL do 8.4.

que algumas lives do Java ou de outras aplicações não são compatíveis com o banco. Então, exige um update dessa biblioteca de conexão. Isso tudo porque o MySQL 9, que o EO dele é assim daqui muitos anos ainda,

mas já está mudando a forma de autenticação. Então isso exige muita cautela da gente a partir do 8.4. Óbvio, até o 9 a gente tem muita água para correr ainda, mas a gente tem que estar à frente do tempo já vendo lá na frente o que vai ser preciso mudar para ir já colocando no radar da equipe de desenvolvimento.

É, porque se pegar a minicidão de aplicações que usam essa versão do banco de dados, não vai ser de uma hora para outra que a gente vai conseguir atualizar. Então tem que colocar no backlog das equipes, os times têm que combinar a priorização dessas tarefas para ir ao pouco e ao pouco se preparando para essa mudança de versão, não é da noite para o dia.

Não, não é da noite para o dia. É por isso que exige muito o trabalho de DevOps. Falando assim, eu e o de Murilo aqui especificamente, da nossa equipe de DevOps, que a gente tem que estar sempre em comunicação com a equipe de desenvolvimento justamente para fazer alinhamento de expectativa. A gente tem SEO, quando que entra na sprint, quando que a gente vai poder alinhar essas migrações. Então, são pontos que a gente tem sempre em conversa com os coordenadores e os desenvolvedores das equipes.

E tem a criticidade da própria migração, né? Que nem você disse, por exemplo, o MySQL perde conectividade com Java e tal. Mas também tem a criticidade inerente à própria aplicação. Por exemplo, você fazer uma migração dentro de uma aplicação que é raramente utilizada é uma coisa. Você fazer a migração, por exemplo, do Hotmart Bank ou do Checkout é outro tipo de atenção também que você tem que ter.

É importantíssimo você se manter atualizado, ligado com os end of life, até por questão de segurança, já que são críticas, mas também não dá para você tocar essas migrações de qualquer forma. Tem que ser feito com atenção, com cuidado e com muito foco da equipe. Sim, a gente precisa de um trabalho em conjunto sempre.

Então, geralmente aqui, nós identificamos através de algumas ferramentas, por exemplo, o End of Life do MySQL, como o Marra disse. Então, nós já começamos um trabalho de comunicação com os devs, já fazemos alguns alinhamentos, geralmente realizamos POCs e disponibilizamos para a galera. Então, a gente sempre está em comunicação, a gente sempre precisa muito da ajuda dos devs também. Isso é muito importante.

Sim, um exemplo que a gente teve disso, que eu me recordo foi um dos maiores desafios que eu tive quando eu voltei para a Hotmart, que foi fazer a atualização no banco do Marketplace. É um banco enorme, várias aplicações conectam nele e nós não podemos ter downtime, ponto final. Como que a gente faz isso? Como a gente faz isso? Então, foi um trabalho complexo junto com Elton Matador, junto com uma equipe de desenvolvimento muito importante para a gente.

E nós conseguimos fazer. Mas foi um E.O.L. que, pela complexidade do negócio, a gente demorou muito para executar. Mas foi pela complexidade. Justamente por ser um banco muito grande, que conecta várias coisas ao mesmo tempo, a gente tinha que ter um olhar muito mais crítico em cima dele do que só pôr na sprint. Porque não é um banco que vai resolver uma sprint. Então, esse é um tipo de cuidado que a gente tem que ter.

Esse tipo de atualização requer muito ensaio. Por exemplo, toda banda de um bloco de carnaval, agora está fazendo ensaios porque o carnaval está chegando. Então, para esse tipo de manutenção, exige muito ensaio, simulação, plano de contingência, se der alguma merda durante a atualização, como é que a gente vai fazer o rollback, como é que volta para o estado anterior.

e a gente sempre olhando a data, se a data do End of Life, vamos supor, nós estamos em fevereiro, se a data do End of Life é no final do ano, a gente estipula que pelo menos um trimestre antes a gente tem que já estar meio que movimentado para poder já migrar, para a gente não deixar chegar na cara do gol.

de não ter data mais porque passou o prazo. Então, nesse caso, a gente antecipa e envolve muitas pessoas e vai mitigando esses problemas, esses riscos. Para na hora H, no dia D, o processo ir suave, mesmo assim, dar aquele frio na barriga, a mão soa, daquela emoçãozinha. É, dá muita emoção, principalmente trabalhar com um banco tão grande. Emoção é uma palavra boa.

Gente, e assim, o Marra falou bem ali que a gente tem que estar à frente do tempo, né? E pensando na Hotmart, assim, quais libs a gente tem hoje que a gente precisa monitorar quando a gente está falando de Age of Life? Então, falando de biblioteca, de ferramentas internas, contem um pouquinho aí para a gente.

Boa, eu consigo falar mais sobre ferramentas internas, né? Eu e Murilo aqui, a gente tem muitas coisas em DevOps hoje. Por exemplo, a gente já trabalhou com o Jenkins muitos anos atrás. É algo que nós já não damos tanto suporte. Chegou no end of life dele. Chegou no end of life dele, não é dado mais suporte nele.

É só um parêntese aí, que nesse caso não significa que o Jenkins morreu, deu End of Life. Foi uma decisão da Hotmart de não manter mais o Jenkins e migrar para outras soluções. Isso acontece, isso faz parte. Sim, certamente, porque o mundo evolui, a tecnologia evolui. Todo mundo sabe disso. E vão surgindo cada vez mais ferramentas melhores que atendem melhor a necessidade da Hotmart. Então a gente acaba migrando para outra tecnologia.

Então, o Jenkins é uma ferramenta muito boa, mas nós vimos que outra coisa consegue nos auxiliar melhor. Então, foi decretado um final de suporte, a gente não mais dar suporte em Jenkins, justamente por ser uma ferramenta depreciada, digamos assim. Então, não cabe mais a gente utilizar.

Isso, e há alguns anos a gente já não dá suporte no Jenkins. Nesse meio tempo a gente acabou aderindo ao drone, que é uma outra ferramenta do CICD. E esse ano a gente também vai fazer o EOL dela. Então, diversas reuniões que nós tivemos, fizemos vários alinhamentos aqui, e a gente decidiu que principalmente...

Esse ano a gente vai aplicar bastante End of Life aqui em algumas ferramentas internas. Isso é muito importante para a nossa evolução. Já está vindo outras ferramentas, Argo CD. Então nós precisamos fazer essa movimentação. A gente vem comunicando aí com a galera, se planejando, avisando que a gente não vai parar com o suporte. E já saiu um comunicado da morte do drone.

Então, isso é muito importante para a gente evoluir aqui internamente mesmo, sempre estar trabalhando com uma tecnologia mais nova. E além dessas ferramentas internas, a gente tem uma pancada de outras coisas que a gente vem atualizando, EKS, bancos. A gente sempre está bem de olho em outras tecnologias que a gente acaba utilizando. Então, é sempre importante estar trabalhando em cima disso.

Esse negócio é muito positivo e saudável, porque ferramentas, times de plataforma no geral, DevOps, que fornecem mecanismos que dão suporte para os outros times de desenvolvimento, quanto mais ferramentas e mais versão suportar, mais trabalho de manutenção o time vai ter. Então, como as coisas estão evoluindo, já tem novos mecanismos.

e coisas melhores, e práticas melhores de se fazer, não faz sentido você manter uma prática, dando suporte a uma prática antiga, que a empresa já decidiu não evoluir mais. Então, a gente precisa decretar essas coisas para finalizar ciclos mesmo, e focar no que é novo, e o time também ter espaço para trazer mais coisas novas, mais evoluções, porque senão você fica...

preso e afogado ali, só dando manutenção, dando manutenção, aí você tem que atualizar o Jinx, porque o Jinx também tem as versões dele, as máquinas dele lá que você precisa olhar, porque ele vai sofrer atualização, aí você tem que ir lá atualizar outra ferramenta, e dar suporte nas imagens do GitHub Actions lá, e tudo mais, ver compatibilidade entre versões de CSD com versões do Kubernetes e tudo mais.

Isso é saudável, né? A gente internamente determinando, tipo assim, diversos períodos, diversos ciclos e alinhando com as equipes, né? Pra elas irem se preparando, se atualizando, pra não ficar preso em algo que não tem suporte mais.

Até também para a equipe de DevOps não virar um pato, né? Porque aí fica ali com drone, jenks, GitHub Actions e tal, e aí a equipe não consegue focar em nenhuma das três, não consegue aprofundar em nenhuma das três, não consegue trazer automatizações para facilitar...

o deploy do desenvolvedor, esse acompanhamento da nuvem, da nossa infra e tudo mais, e acaba a própria equipe deixando as próprias políticas defasadas dentro da empresa. Imagina uma analogia, você só está abrindo porta, só está abrindo porta, só está abrindo porta. Você tem que fechar as portas que você abriu, encerrar ciclo mesmo, fez parte.

serviu ao propósito, deu muito certo, agora a gente evoluiu, a gente já está no ambiente. O Jinx era de uma época que a gente não trabalhava com container, hoje ninguém imagina como era há 10 anos, o Jinx era a ferramenta mais ativa há 10 anos atrás.

Eu lembro bem, quando eu trabalhei aqui em 2017-2018, eu fiz instalação de cluster de Jenkins para a galera do Vulcano fazer deploy. Então, assim, é legal voltar e ver o quanto de contexto foi alterando ao longo do tempo com relação à tecnologia. Hoje a gente usa GitHub Actions, por exemplo, que já é algo que já está muito mais à frente do tempo das outras tecnologias que a gente já utilizou. E assim, no dia a dia a gente vê o quanto é benéfico para a gente.

Isso só reforça que a Hotmart não ficou parada no tempo. A Hotmart tem constante mudança e constante evolução. Porque dependendo do contexto, estaria presa uma tecnologia usada há 10, 20 anos atrás. Mas não é o caso. A gente está vendo o que a tecnologia evolui, como ela evolui, sendo útil, a gente traz aquela para dentro, começa a usar e vai depreciando os jeitos antigos de fazer.

A gente está falando bastante de um contexto aqui de infra e tudo, mas lembrando também que muitas das mudanças ocorrem ali dentro das aplicações e às vezes por causa de uma versão do Java, você precisa subir a lib do AWS CLI, isso já causa algumas coisas, assim como outras libis, às vezes uma conexão ali com um banco que é uma versão nova, a gente já precisa fazer essa atualização dentro da aplicação.

Então, todo o contexto de tecnologia, o EOL sempre está muito presente ali, seja infra, seja desenvolvimento. Isso acaba tendo esse trabalho em conjunto sempre bom. Sim, e a gente tem que ficar sempre antenado, porque o EOL de atualização de bibliotecas está respondendo a pergunta da Bruninha, depende muito da tecnologia que a gente está trabalhando. Então, tem EOL de MySQL, que é o que a gente está trabalhando atualmente. Então, tem que ficar antenado as Libs, do Java e das outras aplicações relacionadas ao MySQL.

a gente está fazendo uma transição entre MongoDB e DocMDB. Tem que ficar antenado aos drivers que são compatíveis com o DocMDB, que é da AWS. E também os EOS de outras coisas. Por exemplo, o Lambda, que a gente estava conversando aqui até antes de começar a gravação com o Murilo. O Lambda da AWS, que a gente tem que ter compatibilidade com o Python 3.6, o JVM, etc. Então tem que ficar...

Isso aí é legal porque uma coisa é ligada na outra. Tipo assim, a gente tem uma necessidade de fazer a migração do SQL para o 8.4 por conta do end of life do 8.0. Aí, imagina só hipoteticamente, existe uma aplicação na Hotmart usando o Node 14.

que a biblioteca, a versão do Node 14 de uma lib, uma SQL, não vai dar suporte a uma SQL 8, porque na época do Node 14 era uma SQL até o 5.7. Tô só fazendo algo hipotético, viu gente? Não tô afirmando que é assim não. Aí o que acontece? Pra esse end of life eu sou obrigado a pegar essa minha aplicação que é em Node 14, atualizar ela pro Node 20, Node 18, antes...

de colocar a Lib que vai dar suporte àquele banco. Então, tipo assim, é meio que uma matriz, que você tem que fazer na rastreadibilidade das mudanças e tudo mais. E a parte mais crítica disso, Matinho, é que quanto maior o gap de uma atualização mundial, pior fica o trabalho para ser atualizado.

Isso gera um débito técnico enorme. Às vezes tem que refatorar código porque as formas que são feitas as queries ou utilização de instância de classe são diferentes. Então, assim, por isso que eu falo que EOL tem que ser trabalhado. É um trabalho constante. É um trabalho constante. Por exemplo, quando a gente tem o Kubernetes, a gente tem que atualizar ele. Cara, todo quarter praticamente a gente tem um update do Kubernetes para fazer.

E com ele vem vários updates juntos que são ferramentas que a gente utiliza dentro do Kubernetes. Façam sempre para não ser muito penoso, né?

E se a gente não atualiza, a gente paga por isso. Tem esse problema também. Então, assim, passou do EOL, a gente paga o suporte estendido. Ou, em casos mais críticos, não atendemos o EOL. A Amazon vira e fala assim, tá, você não atualizou, eu vou atualizar para você então.

E aí, a gente vai ficar na mão da Amazon? Acho que é perigoso, então por isso que a gente tem que estar sempre... Não compensa você ficar preso em algo muito antigo, porque quando você precisar, vai dar muito mais trabalho, né? É muito melhor você se programar, beleza, todo quarta ou a cada seis meses. Eu sempre falo com todos os times de desenvolvimento, trabalha com Java, aplicação, usa Spring Boot, programa de atualizar pelo menos uma vez por ano, porque aí você vai estar sempre numa versão coberta.

o Java tem uma versão de LTS que dá suporte há mais tempo, mas o Spring Boot, se a gente não paga nada de suporte, nem nada, e aqui na Hotmart a gente usa sempre a versão Open Source, então você tem sempre pelo menos um ano só, porque você vai estar naquela versão, por exemplo, eu estou usando a versão de maio, essa versão de maio vai estar ativa até maio do ano que vem.

Então, eu posso me programar de atualizar uma vez a cada seis meses, aí eu vou estar sempre na versão mais atual do Spring, ou uma vez a cada um ano, que aí eu vou estar numa versão ativa, mas não necessariamente na última versão, né? E por aí vai, sabe? Assim, é um ciclo, é meio que programático, né? Se você deixa para ficar numa versão muito antiga, aí lascou.

Dá para a gente ver que tem bastante alinhamento, bastante treta, bastante perrengue envolvido aí no End of Life. E agora vamos falar um pouquinho disso, dos perrengues, né? Acho que já deu para ter noção aqui. Vocês já pincelaram bastante aí que não é simples, não dá para a gente fazer sem alinhar muito bem com todas as equipes. Então, para a gente começar, quais são os maiores perrengues que vocês listariam nesse processo de End of Life?

Eu acho que cabe muito falar aqui sobre alinhamento entre nós que trabalhamos com a gestão do End of Life junto com as equipes de desenvolvimento, os coordenadores, etc. Porque muitas vezes a gente tem uma lista de EOLs para ser feita.

E a gente precisa de um apoio do desenvolvedor para acompanhar a gente ou fazer um trabalho de atualização de biblioteca. E o que a gente tem feito com os coordenadores foi, cara, vamos tentar alinhar isso numa sprint, que aí tanto vocês quanto a gente sabem como fazer isso no melhor momento.

sabe? Mas pra mim esses são um dos fatores assim que são mais complexos de serem trabalhados porque entra produto, lançamento de feature, correção, então a gente tem que sempre colocar na balança ali como deve ser feito.

É, existe uma coisa que é um desafio muito grande, né? Quando a gente trabalha com feature, então são os times de produto, eles estão muito... Eles estão buscando algo que vai impactar o usuário, que vai trazer algo novo, né? E a Hotmart tem os...

os lançamentos periódicos delas de produto e tudo mais, tem eventos. Então, isso tem que ser muito bem combinado, né? Porque, assim, quem usa a plataforma, quem usa as ferramentas da Hotmart, não quer saber qual versão de banco que está usando, não interessa por isso, né?

Só que internamente, para a gente ter um tempo de resposta saudável, ter uma experiência do usuário sempre boa, e ter uma plataforma mais estável também, sem tantos problemas, resiliente, a gente também precisa dessas atualizações serem correntes. Se a gente fecha o olho muito para uma coisa e foca só na outra, só lançar feature, feature, feature, feature, feature.

Às vezes, para a gente resolver algo técnico depois, a gente tem que parar muito tempo, porque o gap ficou muito grande. Então, tem que ir combinando uma coisa com a outra. E isso é interessante, porque às vezes, você tem o end of life que é negociável. Por exemplo, o end of life de uma ferramenta interna. Você explica e negocia. Falando, agora eu tenho uma entrega importante, assim que eu terminar essa entrega, eu vou fazer esse end of life. Agora, tem o end of life de data forte.

Tem que atualizar até dia tal, senão a AWS vai atualizar automaticamente no painel e com certeza vai dar ruim, porque a aplicação, todo o ambiente não está preparado para aquele update forçado, digamos assim. Então tem coisas e coisas, aí você tem que negociar e dar prazo para isso. E as pessoas têm que... Algumas coisas às vezes têm que cair. Dependendo do end of life, ele ganha prioridade acima de uma entrega.

Porque não adianta, eu tenho que querer entregar algo, senão na frente o End of Life pode mudar uma versão e dar alguma instabilidade, não adianta. Por exemplo, quando fizemos o End of Life do MySQL 5.7 no Marketplace, nós ficamos pagando o Extended Support por um tempo. Por quê? Porque a nossa preocupação era tão grande de a gente estar tão alinhado, tão planejado com a virada.

Por causa do impacto que isso podia ter aqui dentro, que nós demoramos, eu acho que, cerca de três meses, se eu não me engano. Eu e o Mar, a gente participou dessa migração. A gente enviou e-mails para um monte de gente, alinhou, combinou data, horário, fizemos testes. Então, eu acho que isso... A comunicação é muito importante para a gente não gerar algum impacto.

Creio eu também que ferramentas de observabilidade nos ajudam muito. Então, através delas que nós conseguimos ter esses horários, ficar sabendo também de EOLs. Então, acho que é um conjunto de fatores aí que vem nos ajudando bastante nessa questão desse assunto. Eu acho que isso é muito importante para a gente sempre estar alinhado.

Lembrei de uma coisa que tem muito a ver com esses updates, né? Às vezes a gente posterga uma atualização, negocia e paga o suporte estendido pelo tempo, pelo time ali. Por quê? Às vezes aquele período ali está rolando uma data crítica, por exemplo, a Black Friday. Aí na Black Friday a gente não vai subir, né? Colocar uma atualização dessa que tem um grau de complexidade.

Correndo um risco, né? Então, durante esse período, a gente congela essa atualização e espera para realizar depois. Então, tem End of Lives que tem como a gente ter essa flexibilização, né? De acordo com o período, aquela data, a gente não vai atualizar, né? E vai segurar a onda ali um tempo, né? Quando existe essa opção.

E acontece muito, recente a gente estava fazendo umas atualizações de Spring, o Spring agora lançou no final do ano passado, novembro, a versão 4 dele. E a gente tem algumas aplicações na Hotmart que ficaram legadas, que estavam na última release da versão 2. Então a gente começou a acelerar toda a atualização delas para a versão 3 primeiro.

para depois a gente ir para a versão 4. Por que a gente não está indo para a versão 4 direto? Porque a gente precisa de atualizar algumas Libs internas para elas suportarem a versão 4 do Spring Boot, aí a gente entra com o End of Life dessas versões internas para as versões mais antigas do Spring, porque senão entra naquele mesmo critério. O time precisa de dar suporte a tanta versão ativa do Spring que começa a ficar difícil no código.

é muito ruim isso, então você vai e faz um corte ali e fala assim, a partir dessa versão para frente, eu vou dar suporte, e provavelmente vai ser da versão 3 para frente, né? Aí em maio, já lança uma outra release do Spring Boot, e a versão 3 já entra em End of Life, então existem esses cortes. Aí foi muito legal, porque o time de DevOps lançou recente o mecanismo de kernel deploy, inclusive tem um episódio sobre isso aqui no PodDev, eu recomendo vocês ouvirem também.

E a gente usou o Candid Deploy justamente para poder validar isso, para fazer a troca de versão mais suave. Eu vou levando o tráfego para ali, vou testando, porque normalmente uma versão de Spring, às vezes a gente muda muito a configuração.

E aí fica muito difícil você rastrear tudo. Apesar de ter teste na aplicação, você testa tudo. Mas imagine você de uma hora para outra subir todas as versões da sua aplicação ali. Você troca para a nova versão. É bom fazer algo gradual. Tem um caro no deploy, um blue green deploy. Porque a gente vai testando ali para validar se a versão nova está funcionando adequadamente. Para depois julgar todo o tráfego para ela.

e não dá tanto problema, não dá tanto perrengue. Uma pergunta que me veio à mente é que esse processo de End of Life não necessariamente é um processo que vai fazer a Hotmart vender mais. Porém, se eu tiver um End of Life defasado, pode fazer a galera sair da Hotmart.

que é o churn. Só que esse processo muitas vezes não é visto, esse processo de manutenção. Ele não é um processo muito valorizado. Muitas vezes tipo assim, aumentou o custo aqui, mas esse aumentar o custo fica uma coisa meio etérea. Aumentou o custo, mas não sei também quanto que é, então também tanto...

faz se aumentou o custo. Como é que a equipe de desenvolvimento entra pra negociar, por exemplo, com uma equipe de CX, com uma equipe de CX, entra pra negociar com uma equipe de produto, falando, não, a gente realmente precisa parar aqui o que a gente tá fazendo, a gente não vai entregar a feature nova, a gente precisa

fazer uma atualização aqui de um sistema por conta de end of life. Sim, eu acho que o fator que precisa ser ponderado aí é o quão crítico a gente está trabalhando em determinado produto e o quão crítico é o EO que a gente tem que trabalhar. Então a gente tem que colocar sempre na balança onde está mais pesado. Por exemplo, temos casos críticos.

que às vezes tem alguma falha, não sei, em algum dos produtos, ou um grande produtor ou um creator está precisando de uma feature específica para fazer um lançamento daqui a 20 dias, e a equipe não tem como trabalhar nesse EOL. Agora, existem outros EOLs que são bem mais complexos, que são esses que a gente falou bastante aqui, que é o que a Amazon vira e fala, a última data é dia 30, e é isso.

Se chegar dia 1º e não tiver, qualquer dia, sem aviso prévio, nós vamos atualizar. Então, assim, isso entra muito no trade-off. Então tem que ser... Por isso que a gente ressalta muito comunicação. Tem que ter alinhamento de expectativa constante. Por isso que a gente faz acompanhamentos constantes com as equipes. Assim, eu com as minhas equipes, o Murilo com as dele. Justamente para a gente trocar figurinha, falar o que foi feito e falar assim, olha pessoal, está lembrando daquele, olha, como é que está a sprint? Então a gente está sempre em negociação com eles.

Dá para a gente perceber que é sobre hard skill, mas também sobre soft skill. É sobre alinhar, sobre comunicar, sobre trazer todo mundo junto. A gente falou sobre isso também em um outro episódio, em um outro tema, mas sobre como é importante ter essa comunicação, esse alinhamento, essa clareza também de diversas equipes.

E aí, para a gente já caminhar aqui para o final do nosso episódio, vamos fazer a nossa pergunta poddev. Então, o que os nossos ouvintes podem e devem fazer para deixar o DevOps feliz? Põe na sprint e eu peguei.

É, por favor. Faz deploy na cesta. É isso. Não dá ideia, Valdir. Depois a gente vai ligar pra você no plantão. Mas eu acho que é muito importante a disponibilidade. É entender que, óbvio que tem ferramentas que a gente está fazendo EOL, mas a maioria dos EOLs não vem de DevOps.

Então, entendam que a gente também está tentando trabalhar em cima disso, que a gente precisa da ajuda de vocês. Eu sei que às vezes a gente pode parecer um pouco chato de ficar cobrando ali, a gente precisa atualizar esse banco, a gente precisa atualizar o EKS. Então, eu acho que a questão é entender que tudo que a gente vem fazendo é para proteger mais nosso ambiente, é para evitar custos, é para a gente estar evoluindo dentro da tecnologia.

Então, a gente solicita muita ajuda e disponibilidade nas validações, que eu acho que isso é muito importante. Não tem como a gente atualizar em staging e não validar, e aí subir em prod e quebrar tudo. Então, é isso, eu acho que é muito importante.

Isso, é um trabalho cooperativo, sabe? Nós temos que trabalhar com os end of life, nós precisamos dar ajuda dos devs, dos coordenadores, dos devs, justamente para a gente fazer esse trabalho em conjunto, para que a gente entenda os problemas, tanto da parte de infraestrutura, a parte de ICD, etc., até a aplicação com a ajuda do dev, para a gente ter um sucesso com relação a esses erros.

Para fechar, o melhor momento que a gente consegue ler a expectativa é quando entra na sprint para você. Porque tem muitos CEOs, pelo menos dentro de DevOps, que são tratados com prioridade. MySQL, por exemplo, vai vencer a versão agora em junho ou julho, se eu não me engano.

Então, depois disso, não é que a Amazon vai atualizar, não é um hard update, digamos assim. A gente vai pagar um preço a mais para manter aquela versão. Ou seja, vai entrar um custo que a gente não espera tê-lo em seis meses, caso não sejam feitos esses updates. Então, a gente está correndo contra o tempo para não pagar mais grana do bolso da companhia. É um dinheiro jogado fora, né? A verdade é essa. Exatamente.

Assim, né, dependendo da época, se acontecer alguma outra coisa mais prioritária que vale, né, esse custo, ok, mas simplesmente ter esse custo por inércia é que não dá, né? Não dá. Então, baseado na pergunta que a Bruninha fez, eu penso o seguinte, assim, olhando um pouco de soft skill, né, eu acho que os times, eles precisam se organizar.

para ter clareza da demanda do que vem de produto, de feature, e o que vem que é algo técnico, não funcional ali, e uma coisa tem que encaixar com a outra, não adianta dar prioridade só para um lado e não olhar o outro, então essa parte é muito importante.

E na parte da execução, na hard skill ali, eu acho que vale muito o ensaio, ter um ambiente para homologar isso, muito semelhante ao de produção, que dá para a gente ensaiar essas atualizações, esses ciclos de update, de maneira que a gente consiga pegar no ensaio problemas e poder mitigar e corrigir eles, para a gente não ter surpresa na hora de estar fazendo em produção.

mesmo com os ensaios é muito importante a gente ter um plano e é um plano mesmo, é tipo um roteiro do que cada um vai fazer mais ou menos qual tarefa começa depois daquilo, porque é um script mesmo um roteiro

E esse roteiro é muito importante porque normalmente os mais críticos, esses são feitos de um horário deslocado, geralmente de madrugada e tudo mais, e às vezes envolve várias pessoas. Pessoas de mais um time de desenvolvimento, pessoas de DevOps. Então, se você não tem um roteiro ali muito separado, que cada um vai fazer, às vezes tem uma pessoa fazendo duas coisas, aí alguém acha que fulano vai fazer uma coisa, mas acabou que não fez porque ele achou que o ciclano ia fazer. Então, ter esse plano é muito importante.

e tem que ter também um plano de rollback, tipo assim, tô indo eu sempre brinco, é retroceder nunca render-se jamais você tem que ir dar um passo à frente, mas é preciso às vezes, encontrando um obstáculo é preciso dar o passo pra atrasse, tem que ser possível pra deixar o ambiente estável e depois recomeça de novo, né aprende com aquele erro ali e depois faz o processo de novo, o que não pode e

A gente brinca assim, não sei se vocês já entraram numa canoa, você está na parte da terra, tipo num dica assim, você vai pôr o pé numa canoa. Você não pode pôr o pé na canoa e ficar com outro pé na terra, porque senão a canoa vai, você vai fazendo a abertura, de repente você cai dentro da água. Então você vai com o pé, você tem que ir com o outro, você não pode titubear não, entendeu? Então isso aí você tem que aprender e aprender fazendo.

Para na hora H não te tubiar e ter um plano de voltar. Porque se você cair na água, ou seja, a versão ficar offline, ficar danado para os olhos, vai ser o caos. Aí é o caos, né? Então a gente tem que prever e ter planos para isso. Porque se a gente tem um plano, a gente consegue seguir aquele plano. Na hora H não vai aparecer nenhum plano na cabeça. Vai estar todo mundo preocupado com a cabeça inchada, cheia. Então a gente não pensa nada, né? Tem esse plano, faz toda a diferença.

Exatamente, Matinho. É muito importante falar disso, porque inclusive existem updates que eles não têm rollback. Então por isso acabam sendo mais críticos e exigem mais tempo. Por exemplo, o update do MySQL, não tem como voltar. Kubernetes, não tem como voltar. Então a gente, por isso, precisa ter um ambiente de homologação, do stage no nosso caso, muito bem para equiparar muito com produção, para ser bem testado. Porque tem coisas que a gente não consegue voltar.

É, aí a comunicação, no caso de update desse, ela é muito crítica, né? Porque todo mundo envolvido ali tem que estar ciente da criticidade e até mesmo para escolher a data, né? Uma outra coisa de perrengue aqui, não se deve começar um update e sair para o almoço.

Ou começar um update, ir embora da empresa. Você tem que estar ali acompanhando por algumas horas a cinco aqui para ver se está realmente tudo certo. Porque você faz o update, executa uma ação, e depois vai dormir, porque às vezes você está de madrugada, e o negócio começa a dar pau, o pessoal vai tentar te acionar ali, e às vezes você não está disponível. Então você tem que planejar isso para fazer em um momento que você esteja realmente pronto para ficar focado naquilo. Não pode ter distração.

É, pra você fazer então o seu deploy feliz, joga End of Life no peito do estagiário, já que não é muito importante mesmo, faz deploy na sexta, não segue... Pré-carnaval ainda, sexta-feira de carnaval. Apaga o ambiente em staging, do banco de dados, direto.

Direto do servidor, né? Apaga o staging direto do servidor. Não siga nenhum processo de DevOps. Faz o CICD no Jenks. E não siga nenhum conselho do Valtinho. Acho que é isso. Acho que isso é o mais importante. Então esse aí é o resumo do nosso episódio de hoje.

Porém, se você quiser boas indicações e bons conteúdos, igual você escuta aqui no PodDev, você pode e deve adquirir o seu ingresso para o Conference, que vai estar aí animal, com muito conteúdo. Inclusive, a gente vai ter ali um dia falando muito sobre essa parte de infraestrutura e segurança, que é o segundo dia.

Então vocês podem e devem acompanhar. Então o ingresso que você adquire, você já tem acesso aos três dias. Um primeiro dia falando muito sobre arquitetura, outro sobre infraestrutura e segurança e o terceiro sobre inteligência artificial e novas tecnologias, para você estar sempre atualizado no nosso mercado de desenvolvimento.

Lógico que quem escuta PodDev tem cupom de desconto, que é o PodDev10, que te dá 10% de desconto no ingresso. Então não tem desculpa para você não adquirir seu ingresso e acompanhar o Hot In Code Conference. Quero agradecer os nossos ouvintes que nos escutam, os nossos painelistas que chegaram aqui tão humildemente compartilharam o seu conhecimento.

E acompanhe o PodDev e nos vemos aí nos próximos episódios. Muito obrigado, galera. Valeu, pessoal. Valeu, pessoal. Abraço. Valeu, moçada. Abraço. Boxing complete. Deploy complete. Shutting down system. See you next time.