É o fim da Arquitetura de Microsserviços?

0:00O segredo é que a gente também aprendeu que não precisa deixar tudo micro, extremamente pequeno. Acho que esse é o ponto que a gente vem aprendendo. A gente tem hype de tudo, né? A gente precisa ser ter mais parcimônia na avaliação das coisas. Exato. Para quê?

0:16Os comerciais não gostam disso, né?

0:18Porque, pô, como é que eles vão alavancar financeiramente, né? Então, não é sobre o tamanho da aplicação, mas sobre o tamanho do domínio que ela tem.

0:26Mas se você faz uma arquitetura de referência para cobrir 100% dos casos, ou você fez ela incompleta ou você gastou demais. Exato. Então tá errado.

0:36Muito bem. Muito bem. Meus amigos do PPT não compil, estamos aqui para mais um episódio e hoje nós vamos chegar num veredito aqui, meus amigos. Arquitetura de microsserviço morreu ou a gente só deixou de falar dela por causa que a tomou todo o espaço da nossa pauta? Opa, boa noite, W, tudo bem? Fala, Artur.

0:57Tudo bem, cara? Eh, vamos falar a verdade aqui, o só colocou esse título para dar clickbait. Vai, mentira.

1:03Clickbait. Clickbait.

1:06Mais jamais. Vai demorar para morrer.

1:08Vai demorar muito para morrer. Vocês estão dando spoiler do episódio. Veio, veio para ficar, pô. Vocês estão dando spoiler. Então, acompanha o nosso episódio. Valdir, já deu spoiler, mas tudo bem. E e já dou spoiler de quem tá aqui comigo hoje para falar disso. Ô, Diris Carinho. Boa noite. Tudo bem?

1:25Grande cohost. Obrigado, hein, por pelo por mais uma vez estar aqui, pelo convite, né? Acho que é um é um episódio vai ser ótimo. É um podcast que traz muito benefício pra pra comunidade de desenvolvimento de software, né, de TI.

1:40E é um prazer fazer parte disso, cara.

1:42Valeu. Obrigado mesmo por ter vindo, cara. Saudade de você tá aqui no PPTK.

1:45Eu não posso ficar tão longe, tanto tempo longe assim não, né? Não pode não, cara. Isso aí. E aqui do meu lado direito, o nosso bebê reborn do PPT no compiler, o nosso cohost mais fofo. Que isso, cara? Artur suave, cara. Agradeço o convite novamente. Obrigado por estar aqui com a gente de novo, cara. Eu que agradeço. Valeu mesmo. Então vamos lá.

2:05Você quer entender se faz sentido ainda a gente falar de microsserviço, de monolito, se essa discussão ela tá vencida ou não. Então vamos falar um pouco de nuvem também, entender porque que algumas empresas estão voltando, não? Qual que é o impacto disso na arquitetura de soluções, como que a arquitetura corporativa ajuda a definir esse tipo de variável aqui, como tornar de fato uma arquitetura resiliente e efetiva seu problema de negócio. Então é uma discussão muito boa. Vamos discutir isso aqui agora. Tenho certeza que vai agregar aqui para a sua carreira profissional. E se você quiser contribuir com o PPT no compila, você pode ser membro do nosso canal. Para você ser membro, você já tem que ser seguidor do nosso canal. Então, se você não seguiu ainda o PPT no Compila, tanto no Spotify quanto no YouTube, siga a gente. Já deixa o like nesse vídeo, deixa o seu comentário aqui também qualquer momento do episódio. E aí você vai ter lá o botãozinho do lado do inscreva-se tem tornar-se membro.

3:02Tornando membro do PPT no compila, você contribui com um pequeno valor aqui com o PPT no Cupila todos os meses pra gente manter a nossa produção e continuar trazendo conteúdo de qualidade e gratuito para você. Se você não pode contribuir dessa forma, você já contribui demais, ajudando a crescer a nossa comunidade. Joga esse vídeo no Slack, joga esse vídeo no WhatsApp da empresa, no Telegram, no Redis. Que mais? Você quer geração Reddit? Reddit no trads no trad no final do Twitter.

3:35Final do Twitter que eu me recuso a chamar de X. Twitter forever. Então vamos lá que o episódio tá muito bom.

3:42Bora.

3:44[Música] [Aplausos] [Música] [Aplausos] [Música] E aí, meu amigos, vamos começar com a pergunta mais polêmica do episódio. Microsoerviços morreram em 2025? Declarado. Morto. Morto. Acabou.

4:12Claro que não, cara. Pô, isso aí é o o ponto é que agora já não é mais vibe, é fundamental, né? E o segredo é você saber quando usar e como, mas não morreu muito. Pelo contrário, eh, assim, a ideia de diminuir o tamanho dos componentes eh veio para ficar e e o grande que é que você explodiu o que você tinha nos nos grandes servidores de aplicação paraa infraestrutura. Então você conseguiu levar fila direto paraa infraestrutura, né? Você conseguiu levar eh escalabilidade eh horizontal paraa infraestrutura. Então você não precisa colocar um monte de de CPU, memória no mesmo no mesma aplicação, né?

5:00eh gestão de dados concorrentes ali, se conseguiu levar paraa infraestrutura um cash, alguma coisa do gênero. Então, muito pelo contrário, o segredo é que a gente também aprendeu que não precisa deixar tudo micro, extremamente pequeno.

5:17Acho que esse é o ponto que a gente vem aprendendo. Na na época, eu lembro que uma das grandes dúvidas que se existia para implementar a arquitetura de microsserviço era qual o tamanho ideal do do microsserviço, né? Eu acho que com essa maturidade que a gente foi ganhando, começou a ficar claro que não existe uma fórmula perfeita para isso, né? E acho que pra gente vale a gente voltar no contexto por que foi eh criado o padrão de de arquitetura orientada a microsserviço, né? E por que ela não está mais tanto no hype. É importante a gente ter essa visão e eu queria que vocês me ajudassem a complementar, porque fazer software tem eh 100 maneiras de você fazer o software com o mesmo efeito final.

6:11com engenharia e arquiteturas diferentes. Existem razões para você adotar certas engenharias, certas arquiteturas para ter o mesmo resultado de software, seja ela um monolito, seja ela um micosserviço. E geralmente isso é para atender ou uma demanda não funcional, como você colocou bem, né, Valdir, de escalabilidade e etc. recursos de infraestrutura que você eventualmente não precisa implementar ou você tem uma implementação mais fácil reduzindo o tamanho dos componentes ou até a sua própria operação de tecnologia. Quem lembra do modelo Spotify de transformação digital? Tem um monte de squad lá. E isso, cara, isso sua tão 2000 e 2012, né?

7:022013. Eu nem tava na área ainda. Você você já tinha você já tinha terminado o colegial ou já, mas eu não tava na área.

7:09Suave. O suave é o nosso bebê reborn do piteiro Cupino. É, exatamente. É, ele não vi demais. Mas é realmente é o ponto é esse, né? A gente a gente vem aprendendo, né? O negócio é esse. O mercado ele vê essas ele vê as oportunidades. Aí você vê também muito comercial em cima, né? da de uma oportunidade que de fato é real, mas aí vira bala de prata, né? Isso. E esse é o ponto que eu quero chegar, porque a gente começou a reduzir o tamanho dos componentes, por quê? começou a se entender que ter times menores e mais especializados poderiam ter focos melhores. Só que ninguém pensou, poxa, é muito caro. É exato. Caro, então foi tudo para um para um para um extremo.

7:57Para atender esse extremo, eu não podia ter 50 squads, um trabalhando no carrinho, um trabalhando no na tamb, o outro trabalhando no Exatamente. Na thumbnail, né? É, realmente. Ex. E aí com processo que gerava sei lá quantos deploys todo dia, não dá para fazer isso no monolito. Exato, né? E e mas esse aprendizado foi ótimo. Poxa, precisamos quebrar o software, precisamos dar mais agilidade, precisamos eh fazer os times terem mais e no do negócio também, né?

8:27Precisamos fazer os times trabalharem com a ideia do build and run. Então, poxa, a gente constrói, mantém, evolui, né? No passado, no passado. E ainda tem muita empresa assim e não vou falar que tá certo, tá errado, mas tem muita empresa que é, poxa, eu tenho um time que constrói e o time que sustenta e eles não se conversam, aí fica difícil, né? É, ao mesmo tempo esse build em run vem com a desvantagem da pressa dizimar qualidade, né? Ah, sim. Que é um problema constante que tem. Mas será que no outro modelo também não acontece? Não é pior? Porque o cara que só entrega não tá preocupado que ele vai ter que cuidar depois, provavelmente. Deixa, deixa o time de sustentação se virar, né?

9:06Exatamente. Então eu eu acho que o cara que tá no building, ele tem um cuidado um pouco melhor com a qualidade, porque a bomba vai est no colo dele, né, velho?

9:14Né? Eu eu concordo. Inclusive a gente e também práticas de teste, né? Assim, teste automatizado, né? A gente e também já é velho isso, né? Só que você vê microsserviços veio, comercial botou energia em cima e virou um padrão que a gente aprendeu a usar, né? Teste automatizado, eu acho que é fenomenal.

9:37Uma prática que a Vems, ela investe muito. A gente tem bastante eh profissional ali alocado nos nossos clientes, eh, para elevar a qualidade e e a gente ainda é pioneiro, cara. a gente ainda é pioneiro. A gente chega no cliente e mostra para ele que às vezes ter um deve a menos no time e ter um que a que automatiza acaba acaba trazendo mais fluidez pro time, mais entrega e fica mais barato. Sim, sim. Não, sem dúvida. E e aí o ponto que eu quero trazer para pra temática principal do episódio é a gente passou por transformação da operação da TI nos últimos anos, né? Então, a gente teve uma uma expansão muito grande de ventury capital no mercado. Eh, inflacionou os salários, todo mundo contratava a rodo. A gente tinha essa visão de que ter vários times especializados eh ia fazer o ágil ficar mais ágil e etc. E aí o eu o Mixervice ele pegou uma uma carona nessa parada porque a operação é mais fácil se você tiver cada time cuidando do seu asset, do seu do seu binário, digamos assim.

10:52Ela é mais fácil, mas ela precisa ter um volume alto para justificar o investimento de infraestrutura, pelo menos no passado, né? Hoje em dia já com a cloud ela ela ela vem mais barata, né?

11:04Mas eu acho que a complexidade aumenta demais, cara. aumenta muito, aumenta muito ainda, né? E e é esse é o ponto que eu quero chegar, o caminho que normalmente se fazem. Você tem um um monolito ali com domínios às vezes até muito bem definidos. Aí os caras saem quebrando cada domínio em uma aplicação diferente. Essas aplicações se dependem.

11:22Você gera às vezes gera até uma dependência cíclica ali. Para você fazer um teste integrado para isso local, é um é um saco. Tem que subir isso, sobe aquilo e as equipes não se conversam. E aí, cara, vira um bololô do caramba. É, menos você tem uma prática de comunicação via PI muito bem estabelecida, mas uma comunicação humana péssima, sem mais uma comunicação humana péssima vez uma merda. Mas aí o o ponto que eu quero puxar é, acho que a gente teve esse hype do micro serviço, porque a gente tinha esse hype de ter vários times, então tá todo mundo, tá, cada um trabalhando no teu. Eu acho que outro ponto, né, a gente tem hype de tudo, né?

11:57A gente precisa ser ter mais parcimônia na avaliação das coisas. Exato. Para quê?

12:03Os comerciais não gostam disso, né?

12:05Porque, pô, como é que eles vão alavancar financeiramente, né? A a as Exato. Então, eu acho que quando tava caindo muito dinheiro na mão de de da TI e do mercado como um todo, beleza, cria mais um serviço aqui de para essa feature e aloca mais um time. E isso caiu no hype, cara. começamos a ter a época das vacas magras, layoff, e a gente começou a ter uma visão mais racional do da tecnologia como um todo.

12:33E o que eu quero fazer a gente refletir é as opções que a gente faz tecnicamente, muitas delas são em função da nossa operação. Aí você vai ter um time só, né? Você não tem mais vários squads, você tem um time mais enxuto cuidando de 50 m.viços. Faz sentido? É muito difícil, muito difícil. Mas você vê, né? a gente tá metendo pau aqui na no no hype que a gente viveu. Só que tem um ponto que é interessante, né? Porque esse hype também levou dinheiro pras clouds para que elas vissem ali uma oportunidade de fazer eh evoluções tecnológicas. Justificou essas evoluções, né, esses esse PID. E o que a gente tá vivendo hoje é a oportunidade em função daquelas tecnologias que foram lançadas e só foram lançadas porque tinham dinheiro envolvido. Eh, então talvez o que a gente esteja falando aqui é existem ciclos, né? O ciclo ele vem, leva o dinheiro para um para um lugar onde precisa ser modernizado, a gente eh alavanca conhecimento ali e depois a realidade se impõe, né? É, chega a hora de você ter o retorno sobre o investimento e as empresas falam: "Não, legal, vou levar meu dinheiro para outro lugar". Mas a gente só faz isso porque agora sobrou aquela tecnologia toda que deixa a gente trabalhar, né? Lições aprendidas. Lições aprendidas. Então, assim, eh, a gente precisava disso também. Eh, eh, eu, eu tô falando isso porque, poxa, apesar do meu rostinho bonito, eh, diferente do do Artur aqui, é desde 2003, né, que eu que eu trabalho com desenvolvimento. E isso profissionalmente, né, não brincando ali no dia a dia, brincando era desde 99, mas o ponto é ah, mudou muita coisa, cara, mudou demais. E a gente a gente precisava dessas dessas eh novas capacidades, né, para para poder fazer software como a gente faz hoje, que poxa, é muito mais fácil. Nossa, você imagina, eh, próprio Java, poxa, o Java realmente é é tão ruim quanto as pessoas falam. E eu e olha que eu sou apaixonado, né? Mas, pô, no passado era difícil demais, hoje em dia ficou fácil.

14:44Por quê? Porque houve investimento.

14:46Então, acho que é esse o ponto que a gente precisa lembrar, né? E e agora a gente tava vendo isso com a Yat também, tá rolando investimento porque tá no hype. Eh, é legal porque tá tá estão nascendo várias funcionalidades que que tão e permite com que a gente inove e a expectativa é que daqui a pouco também isso fique mais acessível, eh a gente consiga enquadrar mais no no nosso dia a dia empresarial, né? E aí também a gente a gente sai um pouquinho também desse hype, porque hoje tudo é IA, né? Hoje é tudo. Eu achei bacana que você comentou no começo do seu comentário. Comentou no começo do comentário, ficou meio redundante, mas eu sou de TI, então não preciso ser muito português.

15:31Eh, o que você começou a a descrever o movimento que a gente teve de investimento, de expectativa com microerviço, depois as empresas medindo o retorno e a maturidade?

15:45Cara, você descreveu perfeitamente o o hype cycle do Gartner. Eu acho que em relação a a microserviço, a gente tá agora no platô do de produtividade da tecnologia, né? Com certeza. Então acho que a gente teve aquele aquele boom, aquele picolo que [ __ ] tu ia fazer um site WordPress eu queria fazer aquela [ __ ] serviço. Pô, isso aqui bicho é WordPress porque tem que ser cara, tem que ser barato, tem que ser fácil, rápido, né? Se não for WordPress, eu faço HTML e acabou, né? E aí eu acho que a gente traz à tona, quando a gente fala disso, uma discussão que é muito eh, como é que eu posso dizer?

16:27Muito latente e muito apaixonada. na área de arquitetura que é o overing sim, com certeza. E e tomara que os arquitetos tenham aprendido também, né?

16:37A não aprenderam não. Aprender Mas, Porto, hoje você tá pessimista. Fale, fale-me mais sobre isso. Conte-me, conte-me, conte-me mais.

16:47Cara, o muitos arquitetos eles abrem, escutam a o problema que aquele cliente eventualmente tem. Não, os da VMBS, é claro. Não, lá a gente outra pegada. É outro mundo, outra. tentam entender os domínios que existem ali, os conceitos de negócio, para cada um já aplica uma caixinha. Às vezes nem é o caso de você aplicar uma arquitetura de microsserviço numa empresa dessa. O cara tem, sei lá, 10 desenvolvedores lá. Faz sentido aplicar 10 microsserviços diferentes, 10 codebase diferentes? Sabe sabe por que que aconteceu isso aí? Porque e essa essa juventude aí não tinha irmão, não sabia compartilhar. Fosse lá em casa, bicho, a gente era em cinco, cara. tinha que compartilhar e teria, mas é porque aumenta mais ter próprio brinquedo. É, só eu posso ter o meu microsserviço. Por exemplo, se você hoje com a experiência de arquitetura que você tem, encara o desafio, chega numa empresa e os caras pedem, ó, a gente quer transformar isso aqui num microsserviço, qual que é a primeira coisa que você olha para decidir se vai ou não paraa frente com aquilo? n vejo o retorno sobre o investimento, se vai trazer valor pro negócio, eu escuto a dor do cliente para entender se de fato é o microsserviço o problema dele ou se é ele que não tá sabendo nem pedir, né? Não tá sabendo nem chegar pro time do desenvolvimento e falar: "Poxa, vamos entregar tal funcionalidade". Porque não é só eh construir o software mais rápido, mas é poxa, ele tá orientado a dados, ele tá olhando pro negócio, tá vendo se o que ele quer de fato vai trazer retorno.

18:12Então assim, é uma visão mais eh de negócio, né, cara? Esse acho que esse é o ponto principal.

18:20Quando a gente fala da da adoção de uma de um padrão de arquitetura ou não, como o monolito ou microerviço, ela parece ser uma decisão que é estritamente técnica, mas ela é muito menos técnica do que parece, porque eh a adoção do da arquitetura que você vai ter depende do objetivo de negócio, sobre demanda, volumetria, se aquele produto vai ter evolução ou não, sobre orçamento, cara. Nem cloud é caro para [ __ ] Exato. Então, eh, isso é uma decisão que se você não tiver arquitetura de solução muito bem conectada com a arquitetura corporativa e com os objetivos da companhia para você definir de fato o que vai o o como é a evolução daquele produto, cara, você tá tomando decisão meramente escolhendo A ou B de um padrão técnico que os dois vão funcionar, só que eles podem ter futuros diferentes. E normalmente você leva o gosto pessoal em conta. E aí é um problema, cara. Um problema. Com certeza. Eu mesmo escolheria usar Java em tudo, cara. Mas porque eu sou Javeiro. Mas aí você tá certo. Obrigado.

19:27Agora, agora o ele ia escrever em PHP.

19:30Cara, se us se usar só Jav está certo, eu quero ser o único errado. CGI.

19:40CG. Tem Clipper Clipper da Web 3 plus.

19:45né? Mas o ponto que você trouxe, Artur, é fundamental, né? Custo e custo, cara, ele ele impacta gigant e assim de uma forma gigantesca na na solução. E e também eu eu discordo muito daqueles arquitetos que acham que, ah, eu tenho que fazer aqui só o que é primor técnico. Não, pô, o custo é fundamental, cara. Quanta gente você vê indo paraa cláudando, bicho. Mas até o custo eu acho que é discutível e vocês vão entender meu ponto. Eu acho que é aí que tá a beleza da da arquitetura corporativa, sabe? O cara ele tem uma limitação de custo, mas se ele quer ter, por exemplo, uma um alto nível de transação, se ele quer ter uma escalabilidade maior e um produto com uma alta volumetria, a gente tem que chegar pro cara falar: "Bicho, esse produto não se sustenta nesse custo? Se eu te fazer um produto com esse custo agora, você vai gastar duas vezes mais depois." Sim, com certeza. Então, até o custo ele tem que ser discutido à luz da expectativa do retorno do produto, né?

20:47você tá expectativa, né? Ou ou o custo tá fora do do da realidade, né? O cara tá com poxa, muito baixo ou o arquiteto tá fazendo overer pensando numa coisa que, meu, não vai acontecer, né? Eh, fundamental isso.

21:05Então, acho que tem que ser uma uma balança, né? Sim. Mas, mas o legal é que eu acho que a arquitetura cloud ela tá vindo com capacidades que atendem os dois mundos, né? Então, poxa, você vai usar um contêiner, poxa, pode usar um container maiorzinho, menorzinho, ah, é uma function, usa uma function. Ah, eu tenho o cloud run para rodar um contêiner durante um período, depois morre, né?

21:30Tem essas questões dessas máquinas efêmeras que que ela ela fica disponível só por até 24 horas. Isso também diminui bastante o custo. Eh, então assim, o arquiteto, ele tem que olhar para todos esses serviços e e assim até olhar paraos serviços de cloud que eh sempre com o cuidado do lockin, né? Assim, também você não pode casar com a Cláudia ali e não poder trocar, né? Mas isso isso vem meio que naturalmente às vezes, né? Ah, não tem cloud tem cloud que tem serviço próprio e você não consegue mudar. Poxa, então o lockin vem acaba acontecendo naturalmente no processo de o errado. Qual é naturalmente? Você quer dizer naturalmente tem razão. É a comodidade, né, cara? É. Por exemplo, um um exemplo que eu sempre dou, você quer usar um banco não relacional, você tem algumas configurações, tem que fazer ali e e prover um setup de um Reds ou algum tipo de banco de dados que você vai subir na nuvem, vai ter que gerenciar, etc. Eh, e fazer essa configuração no teu software. Beleza? Mas é sedutor para [ __ ] botar o SDK do Dynamo DB e a mágica acontecer sozinho. E aí, cara, você abraçou o capeta e você tá no confortinho do do loquin, entendeu? Você sabe, ó, eu vou trazer aqui um um ponto interessante, né? Eh, a Vberg tem um a Natura como cliente, né? E a gente tá lá eh fazendo uma solução mirabolante de promoções, né? Um motor de promoções.

23:02Inclusive, a gente já gravou um podcast aqui, tá? aqui, ó, do aqui. Pera aí, pera aí que agora ten aí, acerta aí. E cara, a gente precisa implantar o nosso motor tanto no Brasil, eh, como na Latã inteira, né? E e hoje parte do software tá na, na Oracle e parte tá na WS. Eh, nós nós estamos rodando multicloud 100% Multicloud. A gente tem e e além de tudo a gente tem um banco que é fenomenal, que a gente fala bastante nesse nesse episódio. Dem tá aqui, ó, que é o Sila, é o Sila DB, cara. E ele faz sincronização entre as duas cláusulas e resolve o nosso problema. Zero lockin, né? Aplicação online, ativo, ativo, disaster recovery, né? Se cai uma bomba lá em Vinhedo, onde tá o data center, meu, tá rodando na WS.

23:55Se cairinha na WS daqui do de São Paulo, tá rodando na Virgínia. e zero loquin.

24:01Então, esse tipo de coisa traz pra gente a possibilidade do quê? Chegar pra Cláudio e falar: "Meu, vocês estão muito caro. Você, poxa, olha esse custo aqui. 100 e $.000 por mês.

24:15Não, cara, a outra Cláudia ali tá me assediando, vou pagar 50.000 por mês." E é assim, a gente às vezes não tem noção de de negociação de contrato, né?

24:26principalmente o time de desenvolvimento, às vezes não tem noção.

24:29Isso é uma uma característica que eu fui aprendendo quando eu fui me aproximando mais do time de infraestrutura. Os caras são bons de negociar preço. Eh, e cara, eh, é desse jeito.

24:40Você consegue 50%, 60% se você tiver uma boa negociação de preço. Então você precisa est apto para isso, né? E e o o e o fornecedor de software, cara, o vendor, né? Ele é ele é muito sem vergonha. O negócio dele é: vou fazer ficar sedutor tudo que eu tenho aqui para você casar comigo, porque na hora que você casar, bicho, o contrato prédupicial é monstruoso, cara. Não, e geralmente é os três primeiros anos de casamento seus vão ser maravilhosos. Você vai viver uma lua de mel de 3 anos. A primeira renovação, meu amigo, aí você vai sentar no colo, né?

25:18Aí você senta aqui, esse negócio de café na manhã, café da manhã na cama, acabou.

25:23É, agora é você que vai me trazer o café da manhã. Exato. Então não tem almoço grátis em lugar nenhum, né? Exatamente.

25:32Mas, cara, eh, é interessante a gente falar isso pelo seguinte, né?

25:37A gente sempre brinca que a frase mais utilizada pelo arquiteto é depende. É, inclusive hoje eu recebi no no LinkedIn uma imagem que tem um gerador de livro da Aurel. Sabe aquele livro que tem uma sempre um bicho e um título, né? Aí tinha um de um bicho preguiça e tava assim, Its. É o manual perfeito da arquitetura, né? Mas e mas isso é muito fato, cara. É muito real. Porque quando a gente fala, por exemplo, de de Loquim, vou dar dois exemplos que o Depende ele é muito claro. Quando eu falo de Loquim, era era um bicho preguiça ou era uma lesma? Era um bicho preguiça. É, é, mas podia ser uma lesma. Podia, né? O tipo de arquitetura também é complicado, cara.

26:24Eu sou arquiteto, né? Adoro, adoro meominar arquiteto. Mas podia ser um bicho preguiça. Podia ser o bicho preguiça. Podia ser o o lesminha também, né? Pô, não, isso é tartaruga. Tartaruga também. Você tá, você tá desvalorizando a Não, pô, eu sou arquiteto, mas a gente podia ser mais rápido, mas a gente podia ser mais rápido. Pelo amor de Deus.

26:44Então é que a gente pensa demais. Pensar queima muita energia. Então eh, perdi até o fio da Você perdeu o fio da piada e o Artur perdeu a piada, né? Ele olhou pro tamanho da sua cabeça, ele falou: "Pô, a sua a sua cabeça queimou mais energia que a o resto, né?" Então é, mas é aí do Lim. Então veja, quando a gente fala do do Lquim, qual que é a melhor forma de você não ter LQIM? É você trabalhar com IAS, trabalhar com infraestrutura. Ele quer trazer o assunto para Iá de novo. Não, IAS, infraestrutura como serviço. Iá. Tá bom.

27:20Acho que era inteligência artificial.

27:22Não é você que tá viciado e falar de I.

27:25Então se se você mantém a nuvem como infraestrutura, eu subo um cubernetes em qualquer nuvem, eu subo um banco de dados em qualquer nuvem, eu subo uma fila em qualquer nuvem. Perfeito. Então eu arquiteto na nuvem no nível de as e eu fico mais vendor free, digamos assim.

27:46Ao mesmo tem desenho de código envolvido também, né? Seu código precisa ter ali no mínimo uma arquitetura exagonal para poder separar al o códigozinho que tá a ver tem a ver com com as portas, né? E aí você isolar você poder trabalhar de alguma forma uma arquitetura agnóstica que não depende de produto. Is exatamente. Se você precisar de ajuda, chama VMBERS. Isso. Qual que é o ponto principal disso? Quando você tá num nível mais baixo como infraestrutura, como código, como serviço, você tem uma operação mais exige mais da sua operação, né? Então você tem um custo eh eh correlato para manter essa infraestrutura. Você vai ter que ter um cara para administrar esse banco de dados, administrar essa essa essa infraestrutura mesmo na nuvem. Conforme você sobe para um nível de plataforma como serviço ou serviço como serviço, você tá mais, você tende mais ao o o lockin. Então você vai usar uma plataforma de uma nuvem ou você vai usar, por exemplo, um produto, um exemplo que eu sempre falo de loquin, que é o próprio Big Queen, entendeu? É um loquin tão gostoso. É um loquin que as pessoas amam, né? E roda bem, viu?

28:56Salva direto. Salva. Eh, só que cara, você não precisa de DBA para cuidar, você não precisa de gente para fazer fine tunning, é uma maravilha. Só que tá usando uma plataforma. É. E na hora que a consulta errada roda, né? Aí você vê o preço depois, né? Exatamente. Porque a ferramenta é tão monstruosa que até consulta ruim ele retorna rápido. Exato.

29:15Exatamente. Então, quanto mais você sobe no no conforto da solução da nuvem, mais preso você tá no loquin, só que mais operação você demanda.

29:25Então, cara, é o é o clássico depende, né? Você tem que saber, pô, aqui o meu loquim ele se justifica porque o meu benefício é maior do que a operação que eu que eu que eu vou ter para manter aquela infraestrutura, para manter aquele serviço que não seja gerenciado.

29:42A gente fez um episódio aqui com Dari, que a gente falou bastante sobre Cláudio também, né? E o o Dari é o cara das metáforas, né? E ele fez uma analogia que assim, você vai entrar num quarto sem porta de saída, bicho. É, o ponto é esse, né?

29:58Então você tem que entrar no quarto e saber para onde é a saída. Se alguma coisa der de errado, você sabe para onde você vai correr, né? E é é sobre isso que a gente tá conversando aqui. Então, eh, microsserviço também não é isso, né?

30:13A gente poder usar o padrão a nosso favor, né?

30:18Um outro ponto que que a gente comentou sobre custo, né, e que aí volta no depende. Eh, a gente falou muito, a gente tem até um outro episódio aqui, eu nunca sei se é aqui, aqui, sim, acho que é aqui, sim.

30:38Eh, sobre empresas que estão saindo da nuvem, voltando pro data center, né? E aí é o inverso do que a gente tá falando do overinering. Porque veja o o que você falou, Arthurzinho, cara, às vezes eu adoto uma arquitetura de microsserviço e aumento a complexidade e aumentando a complexidade eu naturalmente aumento a a a minha operação de tecnologia para ter aquela aplicação funcionando. Então, a se eu aumento a minha operação, aumento o meu custo, né? Sim. E não é só custo de infra que a gente fala, é custumando, cara. Mano, é operação, um monte de dev júor lá rodando. É a operação como todo.

31:18A a manter aquilo em pé vai me custar mais caro, mas ao mesmo tempo a maior parte das empresas que fizeram o de volta para casa, digamos assim, da nuvem de volta pro DC, são empresas que não se modernizaram para ter arquiteturas que fossem cloud native e que levaram seus legados as is, com o famoso lift and shift para dentro da nuvem. Eh, tem um ponto também, né? É que não pensar no multicloud, eh, porque esse tráfego de informação de um lado pro outro, né? Eh, se for mal pensado, acaba ficando caro também, né? Então, isso é que é o a banda de entradas e de saída.

31:55Exatamente. Aí você traz muita latência pro software, aí você vai ter uma experiência péssima e além de custo, você vai não vai conseguir operar no dia a dia, né? Quando quando vocês falam isso, a gente tá falando de empresas de qual tamanho aproximadamente? Porque quando você fala de multicloud, de dezenas de serviços, de uma infraestrutura a code muito grande, cara, são coisas imensas, certo? Porque o custo financeiro de você manter isso numa empresa pequena ou até média, às vezes é um absurdo, não é?

32:27Eh, vou passar para você, o comparativo financeiro não não acaba saindo ficando ruim pro para quem tá contratando aquilo no fim das contas, mais ou menos, mas é proporcional. E aí vou pedir tua opinião também, Valdir. Mas imagina, vou dar um exemplo muito pequeno. Eu tenho uma aplicação muito pequena que roda na no meu DC lá no no meu eu tenho um servidor dedicado que custa, sei lá, tantos reais na na no meu servidor Colocation lá. Tô no uma empresa pequena.

33:02Se eu pegar essa pequena empresa ali que tá, eu já paguei o meu servidor, isso entra como um custo eh já na minha parte contábil já como um custo de investimento. Então é como se eu não pagasse mais a linha do tempo, mesmo que seja um servidor de 1.000.

33:19E se eu não não pegar, se eu pegar essa aplicação pequena e eu entender como ela funciona, deixar ela cloud native, rodar, por exemplo, num cloud run, ali, divido meus domínios, etc. escalo ela automaticamente e uso a nuvem de uma forma razoavelmente organizada e racional, ela tende a ficar mais barata do que eu pagar todo ano .000 por aquela máquina, porque eu vou pagar por transação, eu vou ter uma estrutura razoavelmente organizada. Agora, se eu pegar a mesma capacidade ociosa dessa máquina de $. dólares e ligar com o taxímetro ligado na nuvem para ficar 24x7 fazendo o mesmo serviço da máquina que eu já comprei no DC, inevitavelmente ela vai ficar mais cara, porque eu só peguei ela de um DC simples para um DC de luxo, tá direto na nuvem, entendeu?

34:17Só que aí eu tô falando de uma diferença de 1.000 aqui e sei lá 00 no por exemplo.

34:25Percentualmente eu vou, eu tô falando de valores pequenos, mas com diferenças que são muito semelhantes se eu aplicar isso para um parque de tecnologia inteiro.

34:34Hum. Então essas empresas muito grandes, elas têm tendem a ter uma discrepância muito maior, com valores absolutos maiores do que percentualmente com empresas pequenas. Mas empresas pequenas percebem menos porque o valor absoluto é menor e aí o valor e a operação que você tem na nuvem mais simples acaba se justificando. Mas quando o valor absoluto é muito grande numa empresa grande, aí você começa a ter um problema maior, entende? Acaba que pros menores a o contra não é necessariamente financeiro da infra, né? É, você acaba tendo uma diferença percentual que é semelhante a do da empresa grande, mas que como a operação é mais fácil, acaba se justificando, porque a empresa não tem capacidade de operacionalizar aquilo de uma forma mais simples. A empresa grande tem, vou te vou te falar aqui assim, né, um você falou, poxa, quem tem problema de multidata center realmente é uma empresa média, né? Acho que hoje uma empresa pequena, ela já começa cloud e acabou ou começa em casa e acabou, né? Uma empresa média, ela já começa a ter talvez um esse problema de poxa, vou colocar a coisa lá e aqui, né?

35:48Então vem vem essas dores. Eh, mas sua pergunta é extremamente pertinente mesmo, né? o tamanho da do problema, ele vai, na verdade assim, ele vai ele vai doer tanto pro grande como o pequeno quando faltar dinheiro. Aí ele vai começar a apertar as coisas, né? Quando e eu acho que a gente tá nesse momento, o mercado tá nesse momento, tá tá tá claro que é um momento de austeridade e a gente precisa mostrar mais eficiência, né? Então, racionalidade no curso de TI, né? Exato.

36:26Quero falar com você agora que ainda não conhece a Clever. Clever é uma empresa que já tem mais de 3 milhões de usuários em 30 países com 30 idiomas diferentes, que tem trazido soluções em blockchain, criptomoedas e ativos digitais. O objetivo da Clever é te dar liberdade financeira para operar esse mercado de cripto. Então, se você acredita nisso, se você acredita nessa liberdade, você já pensa como a Clever, vai conhecer os caras, é clever.Ou AO estão contratando também pessoal para trabalhar com cripto, com blockchain. Então, se você tem interesse, se você tem conhecimento nessa área, procura a Clever. Se você gosta de criptomoedas, se você opera no mercado, você precisa conhecer a Clever, precisa conhecer as soluções da Clever.

37:06Então, o endereço tá aqui embaixo no vídeo. Para quem não tá no YouTube, é clever. Vai lá, vai conhecer que realmente é um mercado sensacional.

37:14[Música] Tem um ponto interessante também, Artur, quando a gente fala do porte na empresa, que é a barreira de entrada que a nuvem eh reduziu muito, né? Você pagar por um servidor dedicado em 2005, por exemplo, no como era o nome? Soft não, não era soft layer, era 2005 era Intelig.

37:42Inteligata. Esse colocation que você falou aí era era moderno, né?

37:49Você soft layer, soft layer é você comprar um servidor dedicado, por exemplo, um soft layer, era muito caro, né? E mesmo assim, tipo, se o servidor travasse, você tinha que abrir um chamado para um cara ir lá e não descer e meter o reset na mão para você ter um rot de um servidor de fato e usar um servidor de para você. Eh, o normal era você ter hospedagem web só simplesmente com servidor compartilhado, etc.

38:16e era uma barreira de entrada muito grande. Então, ter uma máquina dedicada para você rodar a sua aplicação para ter disponibilidade e ter a capacidade computacional que algumas empresas começavam a a ter que que que disponibilizar era muito caro. A nuvem com o modelo de payer começou a reduzir essa barreira de entrada. Então, cara, você consegue botar sua empresa, sua startup hoje com muito pouco rodando na numa nuvem e ela vai escalar a tua fatura conforme você escalar sua quantidade de transação, etc. Desde que você faça bom uso dela e não coloque 400.000 mensagens numa fila com o desenvolvedor. Por exemplo, cara, botou um for lá. Como é que é a história? Tem tem um for, tem um forzinho perdido lá.

39:03Tem um forzinho. Farzinho perdido lá.

39:06Só que não é não, não sou antimicrosserviços, pelo contrário, gosto, até tenho amigos que trabalham com é a arquitetura que eu trabalho atualmente, inclusive, mas me parece que um monolito, por exemplo, de novo, essa palavra domínios bem definidos e responsabilidades bem incerteiras pode até levar uma redução de custo, principalmente pela complexidade. Cara, um monol, quando eu tenho muitos microsserviços, a premissa do do mercado era qual? Pô, eu tenho um time que cuida do microsserviço A, um time que cuida do B, um time que cuida do C. Cada tem, sei lá, seis pessoas, seis desenvolvedores. Eles não andam juntos.

39:44Cada equipe tem o seu processo. É tudo muito caro, cara. Tudo muito custoso.

39:48Mas você concorda que aí existe, por exemplo, um fator que é não funcional e que pode fazer toda a diferença na nuvem.

39:56Se o teu o teu processo de negócio e o teu domínio A na sua no seu fluxo de de transação, ele demanda muito mais do que o domínio B e o domínio C, não faz sentido eu ter um acet só e escalar junto capacidade oceosa se eu posso ter um ácido só pro domínio A e escalar ele muito mais do que os outros. E aí na nuvem eu tenho economia se eu fizer isso. Ah, com certeza. Entendeu? Porque aí eu posso ter, foi traduzindo isso em no nosso dia a dia, eu posso ter um serviço com 16 podes e os outros que demandam menos com dois, com quatro. E aí eu posso reduzir o meu custo total de uso de nuvem, entendeu? E aí faz sentido. Por isso que depende, né? Não é só a questão da minha operação, se eu vou ter times que vão operar em domínios diferentes ou não, mas também existe a essa questão da demanda, a questão da escalabilidade de cada do Mas eu acho que o que o Arthurinho tá falando é um monolito bem escrito é até atraente e e para quem tá começando, eh, talvez seja a melhor pedida mesmo, né? Então você conseguir ali fazer um um design de código, escolher uma arquitetura com os elementos eh de infraestrutura adequado, tal, e ter ali um monolito, um módulo, alguma coisa assim, né, mais gordinho mesmo. Eh, pode fazer sentido. E aí conforme o negócio vai pedindo, vai mudando, aí você puf, é você vai evoluindo, você não precisa começar com até porque, como vocês já falaram, ó, infraestrutura evoluiu muito nos últimos anos. você consegue com um mesmo o mesmo binário ali, um car ou a mesma base de código, utilizar estratégias, por exemplo, segmentação de tráfego para você desviar requisições muito volumosas para que um char, por exemplo, atenda requisições com volume alto, aplicar estratégias de rate limite, sei lá, para segurar uma paulada e derivar melhor disso daí. Acho que o o monolito ele não é o vilão. Normalmente quando você fala monolito, as pessoas associam aqueles Java nojento, Java 6 que tinha cheio de JB, sabe? Que bancão usa, que as empresas mais legadas usam.

42:13E não é necessariamente isso. Não acho que seja o fim do mundo também.

42:17Concordo. E se você precisar de ajuda para quebrar esses caras, chama Vers, cara. Tá parecendo botinha. Botinha.

42:28Não, mas assim, eu acho que uma aplicação, ela tem que ser e isso é um padrão, né, de desenvolvimento, ela tem que ser autocontida e tem que ser concisa. Se você não tem necessidade de segregar aqueles domínios no nível menor do que o própria aplicação, ela é um monolito por si só, cara. Sim. E beleza.

42:51E tudo bem. Entendeu? Tudo bem, você pode dormir tranquilo, né? Você vai ter paz de espírito, velho. Tudo bem. É isso. E se eu tenho uma aplicação que era do tamanho do meu domínio, tipo, pode ser uma loja inteira, mas cara, a loja inteira são três programadores, cara. Mas sabe uma coisa que eu gostei muito assim, que mudou bastante, né, na ideia do de trabalhar com microsserviço e tal, é a gente manter o container stateless.

43:19Isso. E e assim, o monolito, ele pode ser stat, entendeu? Então, e é talvez é trazer algumas coisas boas que vieram com junta lá com o seu códigozinho antigo que você tem e vai melhorando, né? Essa ideia do do melhorar é importante assim, os times de desenvolvimento que tem aqueles códigos mais antiguinhos não pode ter medo. Acho que o medo é é o é o grande vilão aqui.

43:42Eu concordo com você. Eu só faria um adendo que eu acho que não foi nem tanto mic serviço, mas o cloud native fez a ser mais mais status, né? Então eu poder ter escala horizontal sem depender do estado da transação é é é imprescindível para você poder fazer isso. Então então explica aí Arturzinho, para quem tá escutando a gente, que que é o stateless além do fiquei fiquei nervoso agora.

44:08Acho que cai justamente nesse cenário de você conseguir fazer um escalonamento horizontal ali sem que você trave tudo ou que você eh cause quebra nos dados, por exemplo, que o o cliente tá mandando eh requisição lá pro servidor, né? E aí você não tem isso guardado dentro do servidor, daquele servidor que tá atendendo, né? Fica num lugarzinho separado lá. Exatamente. E aí se uma dessas instâncias tá quebrada, com outra consigo fazer essa entrega sem problemas ou até essa persistência.

44:35Perfeito. E pode ser o meu monolitozinho bonitinho que subiu duas, três vezes, acabou, né? Em três contêinerzinhos diferentes. Pronto. Sendo babacamente acadêmico, stateless e conceito de que uma aplicação não guarda o estado da transação. Isso. O stateful guarda o estado da transação. E sobre isso, cara, o se você tudo depende do nível de zoom.

44:57Se você, se você der um zoom no, no microsserviço, ele é um monolitinho.

45:04Não à toa, existem muitos monstrinhos por aí, né? Exatamente. Exatamente.

45:09Então, não é sobre o tamanho da aplicação, mas sobre o tamanho do domínio que ela tem. Ele tem as mesmas capacidades, né, tecnológicas. Ele pode usar as mesmas funções ali, né? Só que vai da gente, do ponto de vista de design escolher o que que a gente vai usar ou não, né? É isso, é isso que ele tá dizendo, né?

45:25Então se você não importa o tamanho do do da aplicação que você tá desenvolvendo, se você usa os mesmos conceitos de ser status, primeiro que se você fizer começar com um serviço só, com uma aplicação só e você seguir os padrões adequadamente, depois não tem que ser difícil você dividir isso em dois assets ou em duas aplicações, né?

45:49Isso deveria ser razoavelmente simples.

45:51Sim, sim. Eu acho que você começar com microsserviço é matar a formiga com bala de canhão, mas você começar um monolito a moda caramba também não não faz melhor sentido. Você vai sofrer três vezes mais depois. É, você começa com com micoserviço. Eu já cheguei a ver isso, tá? O cara tinha um asset para persistência e um asset pr pra leitura.

46:12É. É. Pô, o cara divide um crude em Pois é. Caraca, acho que esse cara não falar no que é CQRS, né? Você pode fazer um serviço só com CQRS e fazer isso muito bem organizadinho, né? [ __ ] Então, e esse é é onde a gente chega no nível do overiny, né, cara, que que é tão imagina a complexidade que isso vai trazer. O cara precisa, sei lá, se se uma tabela muda de estrutura, cara, você adiciona uma coluna, ele tem que mexer em três repositórios diferentes para poder aí ele aí feri outro, ele feri o outro eh princípio, né, que é do encapsulamento, né? Sim. e do domínio da da coão do domínio, porque ele dividiu um domínio em três serviços e aí quando ele for fazer o deploy até replicar isso para tudo, vai quebrar em algum momento ali. Exato. Pois é. Então algum lugar vai tentar persistir e não vai existir, sabe? É uma tormenta, cara. E assim, né?

47:03Eh, a gente tá aqui falando as coisas, mas é uma eh é uma coisa que a gente também já disse aqui, né? A gente precisa ter paz de espírito de tentar e se não der certo, ajusta depois, né? eh, junta ou separa o código, tal, é ter mais assim, eh, como o mineiro fala, né? Vê com a mão, é, vê com a mão, né? Então você vai lá, testa e aí você vai lá, poxa, faz alguma coisa, não deu certo, troca, né? Ajusta, não, não deixa, tá, tá ruim, mas tá funcionando, né? Vai, vai colocando, vai gerindo o seu backlog. que é errado, mas tá funcionando. É errado, mas tá certo.

47:42Do nosso querido do da caixa. Lembrei errado, mas tá funcionando.

47:50E se você for ver bem, isso daí resume boa parte da c base corporativa que existe no Brasil hoje. Exatamente.

47:59Exatamente. Você que tá aí escutando esse episódio bacana e quer levar toda essa tecnologia, essas novidades paraa sua empresa e não sabe como, chama o time da VMBERS. A gente pode ajudar vocês com desenvolvimento de software, com arquitetura de soluções, a entender os problemas que vocês estão vivendo e sair do outro lado com uma solução bem bacana. E se você tá escutando o podcast para aprender coisas novas, faz o seguinte, manda um e-mail pra gente no peoplecare@vemers. E você pode fazer parte também do nosso grupo de talentos.

48:33Valeu. Agora o time do Relações Públicas vai gostar mais de mim.

48:43Mas é é isso, né? Acho que a gente tem que olhar as nossas decisões muito pelo critério de de aplicabilidade e de demanda do negócio naquele momento, né? E eu acho que, e agora opinião polêmica, é por isso que eu não sou tão favorável, apesar de eu entender o motivo e porque é ela é necessária, mas é por isso que eu não sou tão fã da arquitetura de referência, que nem todos os problemas técnicos semelhantes se resolvem da mesma forma, porque eles podem ter características diferentes que demandam outras soluções que Não são só técnicas. Então, use arquitetura de referência com parcsimônia. Nem toda aplicação é igual e demanda mesmo arquitetura. É, mas se você faz uma arquitetura de referência para cobrir 100% dos casos, ou você fez ela incompleta ou você gastou demais.

49:45Exato. Então tá errado. O ponto é, ela tem que vir como um start para que as suas aplicações saibam como nascer e elas vão se especializando, né? Eu já eu já disse, mas é um guidance, não é uma arquitetura de referência, né? É uma arquitetura de referência, cara. Você só tá trocando o nome aí que você quis dar.

50:05Ah, arquitetura referência. Eu vou falar em inglês agora. Tomar padrão. Padrão dizendo padrão ou padrão. Ou padrão desenvolv. Ah, rapaz.

50:15O o ponto é o seguinte, cara. É importante que as empresas elas tenham eh direcionadores para desenvolver as coisas, senão vira terra de terra de ninguém, bicho. E mas o o quanto ela faz isso eh é o segredo, né? O tal da parcimônia aí que você usou. Eh, o o Então vamos lá. Se eu acho que eu vou construir um um framework em Java para resolver todos os problemas da minha da minha empresa, pô, não tá certo, porque só só se minha empresa for tipo, sei lá, IBM que ela vai vender isso, né? Eh, mas meu, se isso é empresa de negócio, meu, foca no negócio, cara.

50:59Esquece. O mercado já tem muitos aceleradores aí pr para te ajudar de Java. a gente tem o Spring, você tem o Quarcos, né? Eh, meu, usa isso aí, cara.

51:10É, eu acho que a gente tem que ter um um uma visão da arquitetura assim, eu tenho o big architectory e o small architectury. Então, o big é onde meu meu componente vive e o small é dentro do meu componente. Cara, dentro do meu componente, sei lá, você tem que fazer o que for melhor aí para ele entregar, né?

51:30Ah, mas ele tem que se comunicar via rest. Pronto. Pô, eu tenho que comunicar via rest para fazer integrações internas, tal, não sei o quê. Ah, eu tenho aqui um um BF, eu tenho um BFF.

51:39Ah, pro BFF eu vou fazer um graphic L.

51:42Eh, pô, eu vou usar o Alf. Ah, beleza. O Alf já é bigatory, né? Então tem que saber separar as coisas porque, cara, senão sua empresa gasta demais, desenvolvendo um monte de framework, um monte de coisa que não não vai não vai trazer benefício pro curto prazo, porque ela nunca vai est pronta o suficiente e no longo prazo ela vai ficar cara, porque você vai ter que manter tudo que você já fez. Então, eh, conheço empresa, cara, infelizmente eu conheço empresa que investiu demais e em fazer framework, inessou tudo que ela tinha e aí faz 7 anos que esse framework tá de pé e aí você não muda, você não consegue evoluir, não consegue nem mudar a versão do Java, porque, [ __ ] se eu for mudar a versão do Java, eu tenho que testar tudo, a compatibilidade do que tá para trás e aí eu não consigo fazer mais nada novo. você colocou um ponto importantíssimo que é a questão da da arquitetura interna das aplicações, que tu chamou de small architetur e concordo. Acho que eh você não deveria mais reinventar a roda para nada disso, mas a a minha crítica eh não é uma crítica, porque para que não pareça que somos contra arquitetor de referência, mas o meu contraponto é mais no no big architecturing, né? eh, para que você tenha discernimento de como utilizar e como oferecer pra companhia, né? Porque é muito comum você ver que você tem lá um catálogo de arquitetura e aí, ah, essa aplicação qu ah uma aplicação web.

53:20A aplicação web é assim, ela tem aqueles componentes, acabou. Cara, às vezes ela pode ter um overin para isso, ou às vezes ela pode estar simplificada demais pra demanda do produto que você precisa.

53:31Então, eh, nem todas as aplicações são iguais. né? Mesmo no nível mais amplo de de nível de de componentes, tem que ter alguém olhando para e esse cara é o arquiteto, olhando para essas outras variáveis externas que não são só técnicas para ou preparar para uma escala pro futuro ou simplificar até uma uma aplicação, por exemplo, uma aplicação web que você tá fazendo um portal interno, cara, você vai precisar dividir de fato front end, camada de persistência, etc. Cara, talvez não. Às vezes você sobe o WordPress, acabou o problema. Sim. E esse ponto que você falou é interessante, né? Eh, tem que ter um arquiteto olhando, porque nem todo nem tudo é tão diferente assim. E você vai ter muita coisa diferente e você vai ter um grupo para manter isso, vai ficar muito caro.

54:20Então, poxa, será que não dá para fazer um abrir mão um pouquinho de uma coisa, abrir mão de outra para ficar mais parecido, né? Eh, e aí a gente poder ter um uma questão de manutenabilidade mais barata. Poxa, ah, eu quero o meu microsservço em Python. Ah, eu quero o meu em Node JS. Ah, o meu eu quero em Java, o meu eu quero em PHP, né? Eh, e aí acaba que você vai ter que ter quatro cara bom para caramba em quatro linguagens diferentes. Será que eu precisava disso? E cai num ponto que você tava reclamando no off aqui, que é difícil de encontrar profissionais que já estão prontos. Na VBERS você tem, se vocês tem, mas eventualmente você tem dificuldade de encontrar profissionais que estão aptos para executar isso com certeza sem a curva de aprendizado muito grande. E eu acho que é isso porque o mercado correu demais, cara. Cara, pensa só, você tem uma empresa que você gastou uma bica fazendo um framework lá, aí você precisa de um cinco cara, aí você vai no mercado trazer cinco cara, os caras são bons em Java, hein? Ou os caras são bons em Ness, os caras são não sei o que lá. Aí você vai, pô, os caras chega aqui é tudo Juninho porque não conhece o teu arcabolso gigantesco e eh eh lançador de foguete, né? Então, pô, será que não dá para você olhar melhor, com mais carinho pro pro mercado e ficar em padrões, né, para você não ter essa curva de aprendizado tão custosa?

55:38Porque, cara, é dinheiro. Pega aí um desenvolvedor. Os desenvolvedores são todo mundo ganha muito bem, pô. Põe um cara três meses parado só porque tá pondendo sua arquitetura sem entregar. Ficou caríssimo. Ah, um squad para começar a rampar e entregar aqui. É, é para rampar e começar a entregar são 4 meses, 5 meses. Poxa, sai muito caro. Então é uma é uma questão de eh engenharia de software, gestão de TI, né? Eh, e é isso que eu falar, cara.

56:08Isso é um isso é um ponto que não é nem nenhuma discussão tão técnica, na questão de estratégia de tecnologia. É que daí o cara entra, ele precisa, precisa e ele quer mostrar serviço, ele quer mudar o mundo, quer migrar, pô, vamos tirar isso aqui, desse, desse, vamos jogar no AWS pá, cara, o cara não consegue fazer nada, todo mundo se frustra, a empresa gasta um dinheiro moado, porque é muito caro para fazer isso. É o exemplo que o Valdir deu, acho que é o extremo assim, sabe? O cara fazer um framework do zero, cara, se amigo, se você tá fazendo isso em 2025, mas sempre tem um abençoado que tem uma ideia dessa, cara. Pense a sua vida, sua vida. Você não tem abençoado, cara. Hoje TI ela tem que ser segmentada entrega de negócios. Você já tem um framework que faz o básico que você precisa e você quer desenvolver, vamos usar o que as cois é tipo o médico não querer usar exames já pré-definidos, protocolos prédefinidos. Não vou usar o bisturi, cara. Eu não vou usar o bisturi, eu vou fazer com fazin os maias. Exatamente. Não, cara. Não, a gente, a ciência e a tecnologia, ela evolui assim. Coisas são criadas em cima de coisas que já existem, né? Então, por favor, não seja esse cara, né? Esqueço.

57:22Vira um corte, por favor. Não reinvente a roda. Não reinvente a roda.

57:27Exatamente. Mas eu acho que é é isso, né, cara? Assim, a gente tá sujeito a novidades da tecnologia. a gente tá as nossas opções de tecnologia, elas não são condicionadas só à primazia técnica. Acho que isso é um ponto muito importante. A gente não pode querer que as nossas soluções sejam o estado da arte o tempo todo, né? Acho que isso deveria est escrito na Qual que é o ditado? O perfeito é inimigo do feito? Alguma coisa assim. É, eu eu não gosto muito dessa também porque essa também dá dá uma margem pro outro lado, tipo, eu pelo menos eu fiz, tá ligado? Então, mas às vezes esse preciosismo te trava, cara.

58:07É, é comum esse tipo de preciosismo travar uma entrega. Sim. O feito é melhor que o perfeito, né? Esse mesmo.

58:14Exatamente. Mas eu acho que o só feito também às vezes podia ser melhor sem ser perfeito, entendeu? Mas às vezes você precisa colocar um negócio no ar para ontem. Você viu uma oportunidade, sabe?

58:26Cara, tá feito. Tem que tá feito, sim.

58:29Você fica lá buscando os lendo o solid, você vai abre abre o clean code para ver se seu código tá bonitinho. Não, aí assim, cara, eu acho que você tá perdendo dinheiro, pô. Nada que é de comum acordo está errado, tá ligado? Tá todo mundo comprado dos riscos do Gente, vamos fazer aqui um negócio no HTML com Google Drive para testar uma hipótese. Bora. Tá todo mundo ciente que se essa [ __ ] funcionar, a gente vai ter que voltar a desenvolver direito? Beleza. O problema é quando você faz isso, não deixa claro, aí chega no presidente da empresa e fala: "Cara, beleza, amanhã eu quero mais 3.000 clientes nisso daí, porque vendeu para caramba ontem, agora tem que vender três vezes mais amanhã e você tá pendurado o Google Drive." Aí o cara pede as contas e vaza. É, é bem por aí. E aí, Botini, se o cara precisa de uma ajuda dessa, quem que ele procura? O cara ber resolve, cara. Bers, eu acho que é é uma coisa que a gente eh tá sempre preocupado lá com a comunicação, né? Transparência e isso acontece a todo momento, né? Então, quando você tá desenhando uma solução, quando você tá estudando um problema, né? Quando você entrega a as opções pro cliente, você vai colocando ele a par dessas escolhas, né? E e a VBS é muito boa nisso, arquitetura de solução, eh desenvolvimento de software, alocação de profissionais, squads, a gente pode e a gente ajuda, né, muitas empresas com isso. paraa gente encerrar esse episódio que eu acho que foi o que a gente conseguiu falar de tecnologia o mais tempo possível sem abordar o assunto IA, mas agora eu vou ter que trazer esse assunto pra gente pra gente discutir pois tudo que a gente falou aqui, o que me preocupa um pouco com o uso de daná é um pouco dessa falta de sensibilidade que a gente pode ter na hora de desenvolver código utilizando somente a inteligência artificial, tomando decisões arquiteturais somente com inteligência artificial sem essas variáveis que a gente colocou aqui. Quem que, cara, quando você tá lá no INT surf, tá lá no chat ept cara você não tá tendo esse olhar que a gente colocou aqui sobre escalabilidade, sobre contrato de vendor, sobre opção de de uso de linguagem com disponibilidade de profissionais, etc. Eu acho que isso talvez amadureça de alguma forma, porque a gente tá no no pico do hype da da tá tá nós estamos levando dinheiro para Iá, né? Levando dinheiro para ela. Muitas pessoas já assinam eh o software eh no modelo pessoal. Poxa, é difícil, né? A gente a gente vê isso assim, sei lá, até 2010 o pessoal comprava software pirata, né? 2010 paraa frente o pessoal usou muito open source. Poxa, agora a gente tá tendo a a a gente vê as pessoas fazendo assinatura do chat de PT, por exemplo. Isso é muito bom. Então você leva dinheiro para que a Isa desenvolva, né? E e hoje o que eu sinto, tá, eu uso, poxa, eu uso muito eh a IA para me ajudar a Esse episódio, por exemplo, não tem um host, é uma que tá ruim, mas eu eu uso muito ela para me ajudar a elaborar as minhas ideias, mas ela não tem ainda uma um contexto tão amplo como nós, né? Então não dá. você conversa com a Iá e vai pedindo as coisas, ela é sempre muito simplista, ela objetiva, né? Então é simplista, não é só objetiva, não. Se ela fosse objetiva e falasse sobre tudo que você quer, beleza, mas ela te dá uma resposta ali parcial. E aí o que que você faz? Você vai elaborando, vai elaborando, vai fazendo mais perguntas e essas perguntas vêm da nossa vivência, né? Então, hoje eu uso a IA como uma assistente e aí eu eu vou trabalhando ali, vou evoluindo os assuntos para trazer a personalidade. Ela não tem isso e não aí assim vai ter, eu acho que vai, mas vai demorar um pouco porque o contexto que a gente trabalha de informação é muito grande. Ela não consegue fazer isso ainda, né? É, quando o pessoal vem com aquele papo, ah, vai roubar o seu emprego. Cara, eu acho que de desenvolvedor de fábrica, sim, sim. O cara que precisa receber tudo mastigado, especificado, esse cara vai rodar com toda certeza. O fechador de gira, né? O fechador de gira ele ele vai rodar, cara, com toda a certeza. Mas você precisa ter contexto de negócio. Você não é simplesmente um cuspidor de corte, você não é pedreiro de software, né?

63:01Sim. Você tem que ser um engenheiro, você tem que interpretar o problema e transformar aquilo em solução, sabe?

63:06Pedreiro de software foi maravilhoso.

63:07Acho que essa sua analogia foi o ápice do nosso Gostou? Obrigado ao baiano. Ele falou isso para mim ali fora. É verdade. Abraço baiano.

63:17Então, então a sua provocação, né, sobre poxa, a IA fazendo fazendo arquitetura, fazendo microsserviço e tal, né, ainda não faz. Eu acho que vai demorar um pouco, porque a gente tá aprendendo muita coisa com a a trabalhar com contextos muito grandes de software. Eh, eu eu às vezes eu vou brincar, né, e aí eu peço lá uma ajuda, ah, faz tal coisa para mim. É, o código não compila de primeira, vem com uns gaps ali, né? E tudo bem, né? Já me ajudou muito. Sim. Agora, agora eu vou investir um software de 75 milhões que a minha empresa gastou para, para, para fazer e garante que tá funcionando. Vou jogar lá e falar: "Moderniza isso aqui para mim". Aí eu tenho que ser muito louco, né, bicho? A deles tem que ser a VMB.

64:07E vamos combinar assim, não vai ser IA, né? vai ser muita gente boa, muito profissional, é competente. Valdíria, Valdíria é tipo isso. Eh, mas assim, a gente precisa ter consciência, né? E esse é nosso papel de TI, gente. A gente precisa olhar para isso e, poxa, eh, interpretar para passar para quem não é de TI, poxa, vamos usar com parcimônia, não é a gente de TI também fala: "Não, agora é tudo isso e acabou", né, cara?

64:36É, eu acho sinceramente, cara, que a gente tá a gente tá num num pico de expectativa tão absurdo que eu acho que as pessoas tão tão cara, o que tem de guru de a primeiro no ninquedinho é absurdo, né? Cara que é futurista, que acha que você não vai precisar nem respirar, é acordar de manhã para ir no banheiro, porque aá vai fazer isso para você.

64:58Calma, né? Eu acho que a gente tá num ponto de de disrupção de fato, que as a nossa eh profissão vai mudar de fato de um de uma maneira que não vai ser como era antes, mas a gente vai aprender a lidar melhor com a certeza. Então eu acho que da mesma forma que a gente falou aqui sobre mix serviço, sobre uso de nuvem, que muita gente errou e tá voltando, cara, isso vai acontecer com IA, né? a gente vai aprender a fazer um uso melhor dela e falar: "Não, pera aí, gente, aqui a gente, esse tipo de decisão, acho que a gente tem que o fornecer melhor informações pro modelo e utilizar ela de acordo com a minha base de conhecimento e explorar outras possibilidades ou isso daqui tem que ser supervisado supervisionado por humano." O meu trabalho ele é probabilístico ou determinístico. for probabilístico, poxa, IA vai me ajudar, porque ela precisa interpretar um monte de coisa e ela ela vai gerar um resultado ali, eh, que que vai trazer um um Q de probabilidade. Perfeito. Agora é determinístico, ele sempre tem que gerar o mesmo resultado. Então, talvez ainda não seja a talvez esteja que ser e tenha que ser algo mais eh contextualizado. Exatamente. Aí você vai lá, produz um software ou faz um processo. Aí você não precisa daí a assim, você pode usar ela em em pontos específicos, mas exato. Você pode usar ela para analisar o dado do teu processo, do teu software e aí ela gerar insights, mas ela não tá executando o processo padrão ali, né? Eh, então assim, é, e aí quem que vai te ajudar a fazer isso hoje? É o arquiteto, é o desenvolvedor de software, é assim, alguém preparado, né? Eu fiquei muito triste você não falava MB. Agora eu tava esperando.

66:46Pra perdeu o gancho. Perdeu o gancho. Na verdade, na verdade eu já fui colocando, você foi sugestionando tanto vocês, ó, que o o funcionou. O cara falou: "Pá, perna, ajuda, perna, ajuda." Pronto. Legal, gente. Muito bem, meus amigos. Obrigado pela participação de vocês novamente aqui. Acho que o papo foi muito bom pra gente revisitar esses pontos, né, de eh olhar para trás, né? Porque, cara, nosso podcast já tem mais de 3 anos, né?

67:16A gente já gravou episódios sobre como modelar microserviços. É verdade, verdade. Microserviços, APIs, desenvolvimento, design de software, cloud. É, é assim, esse aqui é mais um um compiladão, né, que a gente vai trazendo. Sim. E a gente vê como três anos depois a tecnologia já evoluiu, a nossa operação de tecnologia já evoluiu, o mercado tá diferente e a gente tá aqui para trazer essas novidades, essas reflexões para vocês. Então, acho que foi um episódio muito bom pra gente passar limpo algumas algumas partes e revisitar com com olhar de 2025 total.

67:52Obrigado. Valeu, obrigado, cara. Esse episódio vai ter que ser gravado em 4K por causa do tamanho da sua cabeça. Vai ter. Obrigado por ter aparecido aqui novamente. O pessoal tá com saudade de você, cara. Então fazia tempo, né? Acho que a última vez que eu vim aqui foi no começo do ano, bicho. Verdade. Obrigado por ter vindo, mano. Tamo junto, Turzinho. Muito obrigado. Obrigado, mano. Valeu. Até a próxima. Você que acompanhou a gente até agora, muito obrigado pela audiência de vocês. Se você ainda não segue a gente no canal do BPT no compil, siga, deixa o like nesse episódio, encaminhe esse episódio pro para aquele arquiteto que quer fazer tudo em micoserviço ou aquele que quer fazer tudo em monolito também pode mandar para ele também. Manda lá no slack da empresa, manda no grupo da família, ninguém vai entender nada, mas você pelo menos você mostra que o seu cara de TI.

68:44E se você quer contribuir um pouco mais com o PPT no com Pila, se você gosta do nosso trabalho, se você entende que a gente pode contribuir com a sua vida profissional, você pode ser membro do PPT no Cupila. Sendo membro lá no canal do YouTube do PPT no Cupila, você vai contribuir todos os meses com pequeno valor aqui pro PPT e você vai e ajudar a gente a fomentar aqui o nosso ecossistema e manter a nossa produção em pé. Então, obrigado pela audiência de vocês e valeu.

69:27[Música]