Olá, pessoal, tudo bem? Hoje eu estou aqui com o Eduardo Dias. O Eduardo trabalha na Amazon e tem uma experiência enorme nessa área de TI. Provavelmente já passou por os mais diversos cargos, desde o desenvolvedor de sistema de locadora até trabalhar na área de gestão da Amazon. Então, durante essa trajetória, o Eduardo já teve a oportunidade de ter a experiência, de trabalhar e atuar como arquiteto de solução e provavelmente tem contatos, está em contato a todo momento, provavelmente, com profissionais desse tipo. Então, Wesley, é que a gente estava conversando sobre os projetos. Então, conforme fui progredindo, fui trabalhando em diferentes projetos de consultoria, acabei tendo a chance de ir para trabalhar em várias indústrias. Então, automobilística, eu trabalhei de manufatura e também de finanças. Mas por uma ordem cronológica ali, eu vou colocando um pouco, quando trabalhando em Curitiba, nesses projetos de consultoria principalmente, eu acabei me tornando um team lead. De um team lead, acabei ajudando a facilitar o processo de scrum dentro da equipe. E aí, automaticamente, comecei a ser mais responsável pelo como que a arquitetura de aplicação daquela minha equipe acontecia. Arquitetura de aplicação, não arquitetura de solução, mas daquele componente. E com isso, acabei expandindo. Então, foi assim que, naturalmente, fui entrando na vida de arquiteto dentro de componente de aplicação, para depois de solução e conforme essa parte de arquitetura, também tive a chance de trabalhar com vendas que aí nas vendas, você começa a ter um pouco mais de expansão você tem que vender o negócio você tem que falar como que o software entendeu o que ele faz para vender o projeto. Você tem que falar como que o software entendeu o que ele faz para vender o projeto, para apresentar uma solução. Conectando agora em termos cronológicos, você vai ter Nokia Siemens, Volvo, onde eu trabalhei com o sistema com desenvolvimento. Trabalhei com a SYNC, que foi adquirida agora, mas era uma empresa de Curitiba com vários projetos, tanto HSBC, Boticário, empresas nos Estados Unidos as well, também. Um dos grandes projetos que eu gostei de ter participado, e eu acho que talvez o pessoal aí vai conhecer, foi com a Cita Aéreo. Então, um dos clientes dessa empresa era a Cita, elas fazem todos, se você vai no aeroporto lá e você vai no quiosque e passa o cartãozinho lá para fazer o teu check-in, tem o símbolo da cita ali, aquela solução de quiosque lá foi criada pela nossa equipe. Aquela solução lá foi desenhada pela nossa equipe. E eu tive o prazer de contribuir para a arquitetura daquilo lá. Então, foi muito legal o deployment, o primeiro large deployment, vamos dizer assim, de projeto que eu tive. Fazer todo o offline com todos os servidores no aeroporto, para atender todas as demandas, com backup para online, fazer conexão com hardware. Foi a primeira interação que eu tive com backup para online, fazer conexão com hardware. Foi a primeira interação que eu tive com hardware. Então, foi muito legal. Isso foi em 2007. Na Volvo, eu era o responsável pela América do Sul na prática de agilidade de Scrum. Então, eu era o representante de Scrum. Não atuava como arquiteto, mas atuava em arquitetura dos projetos. Então, é interessante como isso vai evoluindo, vai ser volta às vezes, pelo menos na minha carreira eu tive chances de experimentar várias posições ali. O que me trouxe para o Brasil, para os Estados Unidos, foi uma consultoria. para o Brasil e para os Estados Unidos foi uma consultoria. Eu vim atender um cliente nos Estados Unidos, em Miami, arquitetei toda a solução deles de broker-dealer, então eles fazem todas as transações da bolsa de valores para clientes, e a gente tinha uma equipe pequena, 4, 5 pessoas, arquitetando toda a solução de gestão de ordens deles, ordem management system, fui convidado para me juntar a eles. Quando eu juntei a Tradewire, essa empresa, acabei indo depois para a Fucrum, uma empresa de consultoria indiana, que me deu exposição a healthcare, que é a parte de saúde, e lá eu era o arquiteto de várias soluções. Então, eu desenvolvi software para a área de saúde lá, integrado com hospital, integrado com hardware, arquitetando e liderando a arquitetura para uma equipe de, a gente tinha 500, 600 pessoas no desenvolvimento. Agora, Eduardo, deixa eu te fazer uma pergunta agora. Você passou em diversas empresas, em diversos projetos, consultoria, você pula de projeto para lá e para cá. Isso, de forma geral, é muito bom, porque te gera um repertório gigante de domínios que você começa a aprender a resolver. Você consegue começar a conversar sobre tudo quanto é tipo de assunto e isso aí você consegue aplicar coisas que você aprendeu em projetos passados para os projetos que você está pegando. Agora, seguinte, quando você chegou a começar a trabalhar com arquitetura de solução, primeira pergunta que pode parecer muito inocente, mas ela dá um monte de discussão, que é o seguinte, você acha que você conseguiria atuar como arquiteto de solução sem ter sido um desenvolvedor antes? É difícil. É difícil. É difícil. Porque você precisa ter a experiência do código saber. Tem muita gente que faz um curso de arquitetura, ou estuda análise de sistemas, que vai fazer arquitetura, mas tem detalhes de código que influenciam direto a sua arquitetura. Ainda mais hoje, com a integração das coisas, dos diferentes aspectos. Então, a arquitetura no passado era só software. Você passava para alguém rodar o software para você. Hoje não. Hoje, quando você desenvolve soluções nativas de nuvem, você está pensando em operação, você está pensando em operação, você está pensando em provisionamento, você está pensando como que o teu software integra com, vamos dizer assim, com o kernel do container que está rodando no Kubernetes. Então, é muito difícil você não ter experiência, não ter aquela exposição. E você chegou em algum momento e falou, poxa, nesse momento foi a hora que eu precisei vender e expandiu. Qual que é a relação que você vê de um arquiteto de solução com a área de vendas? Porque esses caras, a área comercial e a área de arquitetura de solução são melhores amigos ali, né? Para conseguir vender uma solução, para trazer um projeto novo para a empresa. Consultorias adoram botar o arquiteto junto nas reuniões comerciais por conta disso. Como que funciona essa dinâmica, Carlos? Ela é um desafio para muita gente, principalmente quando a gente é introvertido. Quando eu saí da FUG com essa empresa em Nova York e fui para a Califórnia e juntei uma startup, nós desenvolvemos um produto para a área de fintech, uma plataforma de empréstimos. E com essa plataforma de empréstimos, além de arquitetar todo o produto, toda a plataforma que sustentava o produto, eu vendia o produto. Porque eu trazia todos os detalhes que muitos dos consumidores ou partes técnicas precisavam. Ela anda em conexão com vendas. E para a sua pergunta, foi fundamental para mim ser um arquiteto e desenvolvedor que pudesse fazer vendas. Porque um amigo meu, que é de longa data, a gente trabalhou em outras empresas, ele falava, a gente nunca perdeu uma venda quando a gente estava junto. Agora, Eduardo, o negócio é o seguinte. Na sua opinião, o que é um arquiteto de solução? Qual é a diferença de um arquiteto de solução para um arquiteto de software? Porque agora você vai ver que é arquiteto de software. Porque agora você vai ver que é arquiteto de tudo. Tem arquiteto de cloud, você tem arquiteto de solução, arquiteto de software. Aí você vai ver que a maior parte das cloud providers, você vai ver os cargos de vários caras é solution architecture para AWS, por exemplo. Na sua opinião, como que você vê? Porque cada hora está surgindo novos cargos e você vê pessoas que trabalham com nuvem virando arquitetos de solução, mas o cara nunca desenvolveu. Como que está, na sua opinião, esse tipo de mercado? Eu acho que é assim. Os cargos que estão sendo criados criam uma divisão meio complicada, porque não está mais tão simples como era antigamente. Antigamente você tinha arquiteto de aplicação, de solução empresarial. Hoje tem detalhes, um arquiteto de solução da IWS, ele vai trabalhar com arquitetura de solução, mas com foco muito grande. Então, o que eu diria que hoje, um arquiteto de solução é aquele que consegue arquitetar soluções não só na cloud. É aquele que consegue saber os conceitos e aplicar isso de formas diferentes em clouds diferentes, por exemplo. Por isso, para ser generalista antes, Wesley, é importantíssimo para você ter um arquiteto de solução eficaz que você possa aplicar esses conceitos em ambientes diferentes. E se você fizer nativo, como que você faz? Então, eu acho que é aí que você está chegando. Mas, claro, que com essas soluções muito... Eduardo, você está dizendo que um arquiteto de solução é AWS? Um arquiteto de solução? Ele é. Mas é focado naquele mundo, naquela cloud. Então, isso é efetivo. Tem conhecimento que se passa pelas Azure, mas tem detalhes do Azure que você não vai conhecer. É que, hoje em dia, como a maioria das aplicações, elas já estão nascendo ali, são cloud native de forma geral, acaba fazendo com que a maioria da galera que trabalha com arquitetura de solução já são caras especialistas em cloud, porque sabem que as soluções vão precisar de cloud. E tem muito, o mercado é muito grande. Então, faz todo sentido você se especializar, principalmente nas duas maiores, que é a Azure e o AWS. Então, faz todo sentido. Acho que profissionalmente falando, a especialização é bastante atrativa. Uma coisa que eu falo da generalização é que ela te permite você ter uma exposição maior e até uma fragência maior. Então, uma coisa que eu falaria, por exemplo, eu não colocaria, uma expressão americana, don't put all the eggs in a single basket, então não coloca todos os ovos em uma cesta só, eu trabalharia com duas clouds, por exemplo. Show de bola. Agora, o seguinte, Eduardo, chegou no momento que você começou a arquitetar essas soluções, você começou a mudar de vários projetos, acabou vindo para os Estados Unidos e chegou o momento de trabalhar em startup. E aí é uma grande pergunta que sempre cai. Startup tem tempo para criar cargo e falar, esse é o meu principal architect engineer, esse é o meu solution architect, etc. A startup normalmente está com aquele foco de botar o negócio para funcionar o meu solution, solution architect, etc. A startup, normalmente, ela está com aquele foco de botar o negócio para funcionar o quanto antes, testar produto, validar e conseguir escalar rapidamente. Por outro lado, você está trabalhando numa startup que era uma fintech, o negócio mexe com grana. Você tem que ter pelo menos um mínimo de governança de uma forma geral para conseguir escalar esses tipos de produto. Como que a partir daí você fala, poxa, até aqui que eu fazia, eu sei que a arquitetura de solução, depois disso as coisas já estavam todas misturadas. Hoje em dia acontece muito disso. Acontece e você vê muitas falhas ou muitos problemas atritos em startups exatamente por causa dessa transição de crescimento para otimização. Então, para o seu ponto, Wesley, eu trabalhava 80 horas por semana no começo. Até no final depois também. Eu fiz cicatrinhos aqui por causa da vida de startup. Mas era mão no código, trabalhando, arquitetando, desenvolvendo, mostrando e falando com o negócio. Você tem... Está falhando as expressões agora, mas você está com a mão na massa. Não tem eu sou arquiteto, faço um diagrama para você, está aqui, vai lá e desenvolva isso. Não. Começamos com uma equipe de cinco pessoas. E sabíamos que íamos crescer. Porque um outro desafio que acontece é o sucesso. Quando você não tem sucesso na startup, você fica lá patinando, fica melhorando, aí você fica escovando o bit, né, limpando, lustrando a solução, porque não, que é assim, vai ficar melhor, vai conseguir os primeiros três clientes. No nosso caso, nós tivemos sorte que... ou... eu acho que foi sorte, eu não vou reclamar disso. Nós tínhamos muitos clientes. Muitos clientes. Então, nós crescemos tanto como produto, como equipe, de 5 para 80 pessoas em 6 meses. Se a gente não tivesse definido um pouquinho, sabe, de fundação para suportar essas equipes, teria sido muito pior. Não estou dizendo que a gente era perfeito, mas longe disso. A gente tinha uma estrutura, tinha práticas, não era tão documentada, mas estava ali. Então, a gente conseguiu criar um processo para suportar esse crescimento. Agora, em relação aos clientes, o sucesso traz uma outra coisa que é complicada, a pressão. Porque você corre aquele risco. Ah, faz rapidinho aí pra gente vender pro cara. Aí você como arquiteto, você fala. Não, não tá certo. Não faça isso. Aí você fica naquele dilema de como que você cria algo que balancear isso. E esse é um outro aspecto importante do arquiteto de solução. Que é achar o meio termo que é bom para o negócio, mas também que é bom para o produto, que é bom para a arquitetura, que é bom para o software, que vai ser long term, longo prazo, com médio prazo. Então, isso é muito importante. E como você descobre isso, cara? Porque, assim, a gente tem situações que eu preciso vender ou eu vou fechar as portas. Aí você está aceitando qualquer coisa. Mas é aquela história, se eu crescer muito rápido também, eu fecho a porta. Também tem isso, tem empresas que elas implodem na realidade. Como que você, na sua opinião, consegue balancear isso? É somente feeling? eu acho que a experiência que a gente tem na vida ajuda bastante a gente acaba carregando a gente fala de test driven development TDD eu tenho uma versão disso que eu chamo de TDD é trauma driven development desenvolvimento baseado em trauma porque você sabe que se você desenvolver alguma coisa muito ruim, depois vai implodir porque os seus clientes vão comprar, não vão custar, vão sair e não vão voltar. O feedback negativo deles vai ser muito pior. Principalmente com a fintech, por exemplo, é um mercado, é uma coisa que o sistema é razoavelmente pequeno. Grandes valores, nosso software lá gerenciava mais de 2 bilhões de dólares em assets, em ativos, porém, para uma startup era fenomenal, porém, é uma realidade pequena. Então, se o cara falar mal de você, ele não vai falar mais. O que a gente fez, a gente criou um balanço de coisas que não escalavam, então fazia na mão, para entregar, para fazer rápido, mas com coisas que a gente, a longo prazo. Uma, por exemplo, nós criávamos, nós tínhamos uma cota para débito técnico. Então, technical debt, a gente tinha cota. Então, technical debt, a gente tinha cota. Então, se a gente está trabalhando em um sprint com oito features para fazer, para entregar, duas lá, ou uma, depende, no começo era 10%, tinha que ser alguma coisa que estava errada que a gente tinha que resolver. No começo, teve atrito, porém, depois criou aquela máquina que ajudou a gente a manter manter o técnico o débito técnico sustentável show, agora você já, em algum momento já chegou a trabalhar formalmente em consultorias como arquiteto de solução ao ponto de o meu trabalho final é esse documento. A gente fala de Solution Architecture Document, SAD. Como é que é no dia a dia? Porque o que acontece? Documentação é aquela história. Se é muito, ninguém lê. Se é pouco, faz falta. Quanto maior o risco, eu sei que eu preciso de mais documentação. Invariavelmente eu preciso. Mas no dia a dia, numa empresa, uma pessoa que está agora assistindo a gente, falando, pô, eu quero trabalhar com isso e etc. Como é que é? Eu vou sentar, fazer um monte de diagrama, documentar, preencher umas planilhas, fazer um zip e falar, meu trabalho está feito. Como é que funciona a construção disso? É um ponto muito interessante. Na Amazon, diria que quanto mais documento, melhor. É famosa por tudo ser baseado em documento. A gente pode falar sobre isso. Mas eu trabalhei como arquiteto de arquiteto Web Services SOA. Então, arquiteto no Brasil, onde eu atendia Web Services SOA. Então, no Brasil, onde eu atendia a NET. A NET teve a cabo em São Paulo. Nós fizemos toda a parte de Web Services dele para a integração de todos os canais. Tanto o telefone, quanto no receiver, como na web dos portais. Então, eles usavam produtos da Oracle, WebLogic. E eu trabalhei como arquiteto nessa oportunidade formalmente, vamos dizer assim, consultoria. E os meus artefatos eram especificações. Então, diagramas, documentação, integração, especificações para os desenvolvedores, muito esquema. Então, diagramas, documentação, integração Especificações para os desenvolvedores Muito esquema Então, é uma mistura de trabalho de analista De sistemas, aquele mais antigo Que trazia os esquemas De como vai ser Mas eu definia como que eram os esquemas Como que vai ser toda a Enterprise Bus Como que vai estar fazendo conexão Qual que são as transformações, até desenvolver alguns, lembram-se assim, uns X-Quiz para fazer essas transformações, os mapeamentos, que eram parte do processo. Foi entregada aí com essa documentação para a equipe de desenvolvimento fazer o desenvolvimento. Então, esse é um aspecto que aconteceu ali, onde o meu artefato era documentação. Na sua opinião, o que mais funciona dessas documentações? Você é um cara da Amazon, e isso todo mundo sabe, escancarado. A Amazon é documento mesmo, a galera fica com muita documentação. Como que para você, você já deve estar doutrinado com essa parada de documentação agora, mas aonde que hoje você vê que esses tipos de coisas acabam realmente ajustando o processo? A documentação, ela faz você usar documentos como mecanismo, como meio de conversação, vamos dizer assim. Ele te força a pensar mais. Então, quando você faz um documento de design de uma solução, onde você escreve, onde você detalha a sua solução, tá? Não vamos confundir isso com um processo de waterfall versus scrum. Não é isso. É sobre... Pensar no problema mesmo. Pensar no problema. Se você está pensando no problema que você está descrevendo, depois você vai rever esse documento. Essa é uma prática. A gente escreve o documento, depois revê com a equipe inteira, a equipe destrói você, aí você tem que refazer o documento do zero, e aí vai e vem. A gente coleta feedback aí no começo e tal, então é muito importante, porque isso garante que o que? Uma, todo mundo está alinhado, você compartilha esse documento e a solução é bem pensada, né? Eu dou um exemplo, um exemplo que eu posso compartilhar. Eu tenho um pessoal fazendo um estágio com a gente e aí eles estavam trabalhando sobre a questão de usar para fazer o mock da base de dados, entre usar em memória, na Lambda, ou usar um DynamoDB como storage, persistence, e sabendo que era um throwaway code, que é o código que vai ser jogado fora. Qual é a prática nossa? Escreva um Troll, um A-code, que é código que vai ser jogado fora. Qual é a prática nossa? Escreva um documento, por que um é bom, por que o outro, o Proencode de cada um. Escreva um documento de três páginas. E detalhando, opção 1 é boa por causa que é mais fácil, mais rápido, mais isso, pior por causa disso ou daquilo. Opção 2 é melhor e tal. Tanto fat que é mais fácil, mais rápido, mais isso, pior por causa disso ou daquilo, opção 12 é melhor e tal, tanto fatores tangíveis e intangíveis, como por exemplo, a experiência para o usuário usando um banco de dados é muito melhor porque é próxima da realidade mesmo que seja mais tempo de desenvolvimento então, quando você aplica uma cultura de documentação de elaborar o seu pensamento num documento, como desenvolvedor, como arquiteto, como analista, isso ajuda muito a você ter uma coisa muito mais clara e detalhada. Agora, uma coisa a gente sabe, criar documentos dessa forma, com esse nível de detalhamento, toma tempo. E como que você consegue organizar o seu tempo, fazer essas coisas e ao mesmo tempo tocar outras coisas no dia a dia. Porque você não vai ficar, pessoal, ninguém fala comigo agora, estou aqui essa semana só escrevendo uma PR aqui que eu vou mandar para todo mundo analisar e daí vocês discutem raramente a gente consegue fazer isso, você não acha que como que isso pode afetar o ritmo de trabalho, ou se a empresa tem uma cultura forte como essa por exemplo, uma Amazon da vida, provavelmente funciona bem, senão ela já teria mudado a forma. Como que é o ritmo? As coisas andam num ritmo mais acelerado ou você acha que é devagar, mas é mais assertivo? Como a parte do débito técnico, que no começo é mais devagar, que ela causa mais fricção, depois ela alinha e começa a criar uma cadência mais sustentável. Então, essa prática, se ela é aplicada constantemente, você vai ter atrito no começo, mas se ela é persistida, você vai ver isso transformar num ritmo, e esse ritmo vai ser o seu novo ritmo. Talvez seja mais devagar do que se eu pegasse e fizesse as coisas, mas talvez você veja outros benefícios. Por exemplo, o número de bugs que você vai ter na sua solução. Você pode ter uma métrica para a qualidade do seu software. Quando a gente está falando de arquitetura, que você fala dos atributos de qualidade de arquitetura, você fala é das atributos de qualidade de arquitetura né o número de regressos né de erros que estão retornando pode ser menor porque você gastou mais tempo pensando no problema então devagar né tem uma expressão em inglês né é slow is smooth is fast quer, devagar é tranquilo e tranquilo é rápido, né? Isso traduz nesse sentido. Wesley, não posso falar aqui, faça devagar, documenta tudo, não, porque não é assim, não. Na minha experiência, antes da Amazon, onde eu estava liderando uma equipe também, uma empresa muito maior, com uma equipe muito maior, a gente criou toda uma plataforma, a gente tinha um ambiente muito mais balanceado. Eu não estava como arquiteto, eu estava mais como liderança, porém eu arquitetei a plataforma com uma equipe inteira de novo. E lá nós tínhamos um balanço de documentação e ação. Então essa é uma coisa que você vai ter que balancear e ver qual é o cenário da sua empresa. Cada empresa tem a sua cultura, a sua forma de agir. E, cara, como que você acha que essas coisas acabam impactando no custo total da solução? Por exemplo, você estava dando um exemplo aí de ah, eu vou pegar um Dynamo, ou vou pegar um banco de dados em memória e a gente sabe que são opções que provavelmente vão funcionar ambos a curto prazo, mas ao longo prazo, daqui a cinco anos, qual dessas soluções será que iria sair mais custosa? Esses tipos de cálculo, muitos deles a gente consegue fazer antes. E muitos desenvolvedores não sabem nem por onde começar a calcular custo, a calcular, sei lá, conseguir fazer os cálculos básicos de eu tenho tantos usuários diários, usuários trafegam 200k por requisição, eu tenho 100 milhões de requisições, então em 5 anos eu vou gastar tanto de taxa de transferência. Algumas dessas contas, assim, dá para você fazer no papel de pão. Mas se você não faz nem no papel de pão, você está assumindo um passivo gigante que pode, no final das contas, tirar a sustentação do negócio. Um risco muito grande, porque você pode... E já tem casos, né? De startup que fez muito sucesso, de repente a conta da AWS virou 16 mil dólares no mês. Ei! Eu não tenho como pagar isso, porque eu estava só no freemium ainda. Não tinha nem plano de aquisição e não conseguia ter cliente. Então isso acontece e aconteceu. Tem casos nossos lá que a AWS absorveu contas específicas por causa de situações assim. Eu conheço um caso de uma empresa que estava querendo sair da AWS mas ela tinha tanto arquivos na S3 que se ela tirasse aqueles arquivos da AWS e jogasse para o GCP, por exemplo, a empresa não ia ter dinheiro para pagar essa taxa de transferência. Entendeu a situação que ela estava? E aí eles negociando com o Google para tentar fazer com que o Google pagasse essa taxa de transferência, porque eles não conseguiriam migrar a solução, porque ia ser muito caro só de taxa de transferência de dados. Eu espero que eles pelo menos bloquearam o acesso aos pastos do S3, né? Mas assim, eu acho que cada dia mais E aí essa evolução Se você pega 2000, 2010 2020 Vamos pôr em 10 ou até 5 anos 2010 com 2015 Arquiteto de solução Tinha uma área de responsabilidade Muito diferente do que tem hoje Hoje, que nem você estava falando, Wesley, desenvolvendo aplicativos nativos de nuvem na AWS, você tem que levar em consideração o custo que a tua ferramenta que você está escolhendo vai ter. Você tem que levar em consideração qual é o fault tolerance dela, qual é a tolerância à falha que ela tem? Qual é a disponibilidade que ela tem? Qual vai ser a resiliência que ela tem com essas dependências que você está colocando na sua solução? E tudo isso faz parte. Então, se não está como... Eu acho que hoje que não existe uma oportunidade muito grande. Eu acho que aí o teu curso ajuda muito. Trazer esse ensinamento sobre como eu faço esse cálculo, como que eu penso de uma forma holística em isso, não tanto mais na operação, porque hoje a arquitetura de solução tem boa parte de operação também. Ela está em conjunto. E é complicado dizer que, no final das contas, é aquela história. Se a gente pega lá em 2000, eu comecei com o PHP 3, não era o 2. Mas trabalhei muito com Perl e etc. também. E o negócio era o seguinte, naquela época a gente era o webmaster. Depois, comecei a trabalhar, eu só fazia uma coisa. O resto, a área de deployment, fazia tudo, não mexia com nada. Depois, agora volta todo mundo de novo, faz cada um responsável pelo seu microserviço. Tem que arquitetar, desenvolver, testar, deployar, botar as métricas de monitoramento para você garantir que o seu microserviço está funcionando. E no meio dessa história, a gente começa a ver aos poucos cargos de arquiteto de software não existindo mais, porque o desenvolvedor toma decisões de arquitetura, mas muitas vezes arquitetos de solução que você vai, por exemplo, tentar entrar numa Amazon da vida, ou mesmo uma AWS, o desenvolvedor tem que fazer ali provas de system design, que muitas dessas coisas são coisas referentes à arquitetura de solução. Ou seja, o desenvolvedor, ele está absorvendo muito dessa parte hoje em dia. Hoje, os desenvolvedores que eu tenho, por exemplo, na minha equipe, que são no entry level, que a gente fala que saem da faculdade, eles são muito entry level, que a gente fala que saem da faculdade, eles são obrigados, mas a gente precisa que eles façam propostas de soluções em design. Então, hoje a demanda é muito grande que todo desenvolvedor tenha arquitetura de solução como parte do skill set que eles têm. Falando agora em Amazon, com certeza muita gente gostaria de saber como é trabalhar numa empresa dessa e entendendo esses aspectos. Cara, o que se espera? Acabei de prestar, saí da faculdade, estou entrando entry level mesmo, sou o Juninho da Amazon. Cara, o que uma empresa dessa espera de mim, tanto em relação a entendimento de arquitetura, design de software, esses tipos de coisas. Eu sei que para entrar numa Amazon, a barra é alta já, né? Você, assim, não é uma entrevista para trabalhar na locadora que você vai conseguir entrar. A barra é alta. Mas, o que que se espera, cara? E até que ponto, o que se espera em relação à arquitetura de solução para essa galera que está entrando? Você vê, né? Eu gastei quase 10 anos na área de fintech. E em maio do ano passado, eu fui para e-commerce. Fui para retail, que a gente chama. Dei um pivot total. E-commerce. People Retail, que a gente chama. De um pivot total. Então, se não fosse aquela experiência com outras indústrias, se não fosse a exposição, por isso que eu falei de ser generalista, se não fosse essa experiência, seria muito difícil eu ter conseguido entrar na Amazon. Então, a Amazon não está procurando uma pessoa com um skill set especializado. Tem muita gente que é arquiteto, certificado da AWS, que não passa na prova da Amazon. Mas tem muita gente que tem fundamento, que tem raciocínio, que tem possibilidade de que consegue fazer uma solução de design. Está falhando os termos agora, mas aqui... Ficar falando inglês o dia inteiro na hora de soltar o português. Gente, perdoa mesmo, mas é falha genuína. Mas assim, tem muitas dessas... A entrevista, você tem behavior questions, perguntas de comportamento, de princípios de liderança e técnicas. Técnicas você tem system design, que aplica design de sistemas, e você tem código de codificação também. Então, eles não estão preocupados com um específico conhecimento, questão de arquitetura ou de cloud geral e computação porque eles sabem que se você tem aquele conhecimento, se você consegue aplicar aquilo, eles conseguem te ensinar a questão do domínio é isso que eu estava falando da parte generalista tem como aspectos comuns, cada toda aplicação roda num servidor. Se ela está na nuvem, se está na sua casa, naquele Pentium 3, eu sou bem velho, se está em casa, não tem problema, vai rodar num computador. Como que você roda, como que você configura a rede, como que você expõe para a internet, como que você bloqueia o acesso, como que você faz o roteamento, como que eu bloqueia o acesso, como que você faz o roteamento, ou como que eu distribuo as suas... Tudo isso é genérico, vamos dizer assim, é comum, e isso é o que é importante para a Amazon. Eu acho que dessas grandes empresas, você pega o Google, você pega a Microsoft, a Amazon, elas procuram por esse aspecto. Não está preocupado, ah, ele programa em Python, então em Python eu não quero, só se fosse Java. Esse tipo de coisa é relevante hoje em dia, a linguagem que o cara quer. É, não, exato. Tem muita gente que veio, eu tenho desenvolvedores na equipe que vieram de Data Science, programando em Python, mas eles conseguiram aplicar conceitos de programação, conceitos fundamentais que permitiram eles entrarem, conseguiram entrar na Amazon e estão sendo bem-sucedidos hoje. E assim, até uma pergunta que o Kaique pôs ali, o que se espera de um pleno? Se espera muito. Porque se um cara, um júnior, já está fazendo design, ou um pleno, eu diria, ele tem que estar fazendo coaching, ele tem que estar guiando os outros desenvolvedores. No mínimo. Então, é muito interessante. Tentando ir para as proporções, normalmente quem faz esse coaching aqui em empresas médias no Brasil são os sêniors e os tech leads o que um sênior faz na Amazon então? faz coaching também só que você começa da mesma forma que a arquitetura você tem arquitetura de system architect, application architect, solution architect, enterprise architect, você está falando de que você tem, vamos dizer assim, escopos que vai aumentando, né? Na aplicação, eu trabalho com componente. Em system architect, eu queria dizer software architect, né? Que é um componente. Aplicação, você trabalha com uma aplicação. O solution, você trabalha com uma solução. O enterprise, você trabalha com a governança e com várias integrações e tal. O Senior Dev, ele também tem isso. Ele vai estar a ser responsável por fazer a liderança, por guiar, fazer o mentoring, mas também para ser um exemplo, para trazer, ser uma referência. E dentro da Amazon, por exemplo, você tem o senior e depois você tem o principal. E depois você tem o senior principal. Então, a pirâmide vai fazendo assim, vai bem fininho assim. Mas é o que se espera. Então, se espera a maior abrangência de influência. Então, por exemplo, de um senior, ele tem que se sentir confortável conversando com outros peers de outros times, de elaborar uma solução clara para várias pessoas. O que é muito parecido com a arquitetura de solução, né Wesley? Exatamente. Eu acho que também pode ter muita coisa que muda o grau de risco. Uma pessoa que está entrando agora, uma pessoa que é plena mesmo, estando em uma empresa grande, provavelmente o tipo de projeto, o tipo de solução que essa pessoa está desenhando, o nível de impacto dessa solução provavelmente não deve ser tão crítico como uma solução que um principal engineer está trabalhando. Normalmente, acaba tendo mais... É aquilo que você falou, são layers, são abrangências de influência que é aquilo que a pessoa está arquitetando naquele momento. Exatamente. E você também tem a questão do aspecto que, como é importante você arquitetar o ambiente que você está criando. Então, desde a criação de um serviço, onde você vai pedir para o cara aprender a usar as ferramentas, calcular, como que você abstrai isso do desenvolvedor, né? Como para ele criar um novo serviço, ele precisa saber de Kubernetes, ele precisa saber do Cloud, como que você abstrai isso? Ah, como que ele pode calcular ou como que ele pode criar? Quais são as ferramentas que você está criando para criar uma cultura onde que eles possam fazer isso? Então, automação, ferramentaria, processos, tudo isso faz parte, não da arquitetura de solução, mas mais daquela empresarial, que é importantíssima para habilitar, um enabler, para que equipes possam ser arquitetos no dia a dia. Exatamente. Basicamente, o que você está falando é, hoje em dia, a gente tem muito esses times de plataforma que ajudam o dev a não perder tempo com coisas que tem que entregar mastigado para ele. Preciso fazer um deploy, está pronta a minha pipeline. Preciso monitorar, está aqui o meu APM. Eu tenho esses tipos de coisas. Mas pilotar o avião é o próprio dev que faz, né? Exatamente. Isso que é o negócio. Na empresa anterior na Neonet, onde a gente criou toda a plataforma, onde a gente pôde fazer toda a topologia dos times, tinha um time de plataforma, tinha os diferentes times para cada área de produto e microserviço, A gente teve que criar, e isso é uma coisa que a gente criou, desde command line para abstrair template para projeto, para fazer provisionamento por código, tudo isso a gente criou. Então, você chegava lá, criar serviço. O serviço vai usar banco de dados? Vai. O serviço vai ter segurança? Vai. Vai precisar de permissão, a gente tinha ABAC e RBAC, que é acesso por role, por perfil, ou por atributo também, é uma mistura. Então, diga quais são as suas configurações, ia respondendo questionariozinho ali no command line, ali no terminal, gerava o template do projeto, você publicar e faz. Essa ferramentaria, ela é extremamente importante e tem que ser pensada desde o início. Então, mesmo que você esteja num time pequeno, trabalha com aquilo, com aquela cota que a gente falou, porque quando você crescer, aquilo vai salvar a sua tua vida mais do que uma documentação mas junto com tudo isso aí, partindo do princípio que, poxa, olha, eu entendi o que é arquitetura de solução, eu tenho que desenhar dependendo se eu tiver um cargo muito claro que eu sou um arquiteto de solução, provavelmente eu vou ter que gerar aqueles documentos, vou ter que colocar. Mas quando eu estou em empresas que não necessariamente tem essa role, esse papel de arquiteto de solução, provavelmente, se não tem, não é porque alguém não está fazendo esse papel, pode ser não ter o cargo a necessidade está lá e o papel está lá também, se você está em um ambiente mais formal existem práticas e frameworks que ajudam, então por exemplo uma deles é o TOGA que é um framework para arquitetura então esse é um framework muito conhecido na mão empresarial para arquitetura de forma geral. Como o ITU é para gestão de serviços, o Togaf é para arquitetura. Agora, quando você está em um ambiente onde você não vê isso explícito, como você falou, Wesley, a necessidade ainda existe e provavelmente está sendo feita por desenvolvedores. Então, a responsabilidade está sendo distribuída. Agora, na sua opinião, qual é a diferença de você fazer isso on the fly ou de forma intencional? Eu acho que a grande sacada, porque falar até, eu sou desenvolvedor, eu trabalho no arquiteto de solução, eu vou programando, vou fazendo. Agora, quando você para para fazer isso de forma intencional, a coisa muda. Com certeza. Mas isso é um interessante aspecto que a gente fala. A gente vai construir o avião enquanto a gente pilota ele. Só que vocês... Nem começou pelas asas, né? Então é complicado. Tem que... Quando você faz o on the fly, ou ad hoc, assim, ela se torna... Você consegue ter talvez mais... Traction, né? Você consegue avançar mais rápido. Só que tem que tomar cuidado para não chegar a um ponto onde você bate numa parede e não consegue continuar evoluindo porque agora ficou, talvez, muito acoplada. Então, você sempre tem que estar validando o seu processo, a sua solução, o seu design. Então, por isso que esse check constante é importante quando você faz on the fly. Para você usar aquela do construir, verificar, o que em inglês a gente fala PDCA, plan, do, act and adjust, check and adjust. E se você planejou, fez, verificou, ajustou, isso direto é importante. Quando você faz de uma forma mais intencional, como você está fazendo, você pode cair numa armadilha. Você vê que os dois têm coisas boas e ruins. Primeiro, você pode sair rápido, mas você pode ter problema depois, no longo prazo. Segundo, você pode cair na armadilha de não conseguir evoluir, ou você ficar preso, otimizando aquela fundação por muito tempo e não trazer resultado. Então, toma cuidado. Você pode ficar poluindo pedra lá, e dizer, não, ainda não está lá, está lá, agora temos o ambiente, agora a arquitetura está perfeita, vamos começar a desenvolver o produto. Aí acabou o dinheiro da startup e todo mundo vai embora. Mas, o seguinte, quando você trabalha como arquiteto de solução, você fez a solução, mostrou junto lá na reunião com o cara comercial, mostrou para o cliente, o cliente falou vamos fazer e tudo mais, e começa a ser feito o projeto. Chega uma parte do projeto e você fala, putz, estava bonito para caramba isso no papel, mas não funciona. E daí a coisa começa a sair um pouco dos trilhos do que aquilo estava planejado. Como que você faz com que esse monte de documentação não vire somente papel rasgado? Como que você consegue... Como que esse check, cara? Qual que é o nível de verificação e de ajuste e de redocumentação desses tipos de coisas? Eu tenho que admitir para você. Eu já participei de alguns projetos que deu vontade de chorar. Eu vi um cara lá trabalhando por semanas em um documento, mostrava, tudo no toquinho, beleza. Uma semana de projeto já estava tudo diferente daquilo. O cara falou, não, está certo mesmo, eu errei. Mas aquele documento ficou lá, cara. Nunca mais. Morreu. Eu acho que documentos desatualizados é uma das maiores pragas do desenvolvimento, do desenvolvimento na história. Então, não tem resposta fácil e direta. É cultura. É cultura. É criar um ambiente em que você, primeiro, você está experimentando. Então, se você tem uma solução, como que você consegue desenvolver, validar essa ideia de forma gradual e voltar e atualizar a documentação? Então, por pedaços, não tenta desenvolver tudo de uma vez, certo? E outra é a cultura de vir atualizar, de usar aquele documento como uma coisa viva, como referência. Então, tem muitas ferramentas que ajudam isso. Hoje a gente até acabou, essa é uma das coisas que acontece, que eu acho que uma das consequências que eu não sou muito fã, por exemplo, com todo mundo fazendo, todo mundo sendo arquiteto, tendo essa responsabilidade, acabamos, perdemos um pouco do uso de algumas ferramentas, de algumas práticas que seriam úteis. Então, naquela época que eu falei da NET, a gente usava o SPARKS, o Enterprise Architect. Então, estava permitindo você criar todos os diagramas em UML, todas as arquiteturas, e salvar em um repositório, e está lá, vivo. Você pode atualizar no sistema, publicar, colaborar em cima. Essa colaboração mudou ao longo do tempo. E hoje a gente não tem esse mesmo nível de colaboração. Então, eu acho que essa é uma coisa que poderíamos resgatar um pouco mais de uma forma geral de prática. Por isso que é importante a cultura da sua equipe. Não tem resposta fácil. E tem uma coisa também. Eu acho que, eu não digo malefício mas eu acho que o maior problema de quando um time é responsável pela própria arquitetura e etc, é aquela história, cachorro com dois donos morre de fome quem daquele time vai ser já que todo mundo está fazendo arquitetura, então quem vai documentar, já que é todo mundo todo mundo vai, não vai então esses então quem vai documentar? Já que é todo mundo. Todo mundo? Não vai. Então, esses tipos de coisas é algo que realmente dá muito trabalho e tem algum momento eu falar, você vai ser o arquiteto, mas não em relação, você tem um cargo mais importante que alguém aqui do time. Não, mas você é isso, então você fica responsável por manter a documentação, por verificar se está todo mundo seguindo aquilo que todo mundo combinou junto e esses tipos de coisa. Então, o maior problema é que quando todo mundo tem que fazer tudo, ninguém faz nada em alguns aspectos como essas definições, esses documentos de arquitetura que são importantes realmente. E esse foi o único ditado que eu consegui traduzir para o inglês, que é a dog of two owners dies hungry. Porque eu tentei e não consegui, não saiu legal. Mas eu concordo com você Wesley, é importante ter Uma pessoa que é responsável Por aquilo, não? Porque uma coisa que se você Trabalha, tem a tabela RACI Responsible, Accountable Contributed and Involved Que quer dizer Se você é responsável Você é Accountable Essa eu não sei Quer dizer, se você é responsável, você é accountable, essa eu não sei, mas é uma coisa você ser... Você segura a bucha se você é accountable, praticamente é isso, né? Se tiver coisa errada, você vai ser o cara que vai estar respondendo por aqui. Então tem essa pessoa, tem que ter uma pessoa responsável por aqui mesmo que não seja necessariamente ela que ele execute e talvez a execução seja dependente do time funcionar compartilhado mas vai ter uma pessoa auditando e garantindo que vai ser executado essa é importante então você tem que ter uma pessoa responsável pela bucha aí se você vai ser aquela pessoa que vai desenvolver é outra coisa agora é aí que você pode ver a dinâmica do time que deve funcionar melhor tem uma pergunta bem interessante se você entrar num projeto agora que tivesse zero documentação nada, nada, nada, por onde você começaria, cara? Eu rodaria a aplicação na minha máquina. Eu debugaria a aplicação. Claro que talvez não dê para rodar na máquina, mas eu acho que o código diz muita coisa. Então, quando você tem um ambiente legado, procurar toda a documentação possível, não tem nada de documentação, como funciona? Então, começa a fazer uma inspeção dela rodando, no servidor, quais são as configurações, e também olhando no código. as configurações e também olhando no código. Aí, é rodando. Fazer que nem o Elon Musk, né? Mandar imprimir o código no sulfite para os outros engenheiros analisar como é que ficou, né? Olha só, 50 mil páginas impressas. Agora, olha só o follow-up daqui. Se você não fosse documentar, por onde você começaria a documentar? Componentes, banco de dados e classes. Essa é a parte interessante. Tem muita ferramenta que te ajuda com isso. Principalmente código de barra, código Java ou se chaco coisas, linguagens mais tradicionais, linguagens mais bem estabilizadas, tem muita ferramentaria que permite você gerar diagramas automaticamente das suas classes, dos seus pacotes dali. Então, você pode usar isso. Então, essa é uma ferramenta que eu usaria para acelerar essa documentação. Para banco de dados, da mesma forma, qualquer editor de banco de dados te gera um diagrama em RD da tua base existente. Aí formatar, imprime, que nem o Elon Musk pediu, fazendo 50 mil páginas para você analisar ou tentar colar tudo junto. Eu trabalhei em um dos projetos que nós tínhamos, o que era? 1350 tabelas no banco de dados. Podia ser reduzido para muito menos, mas o pessoal gostava. Cara, eu trabalhei num projeto em 2006, 2007, para desenvolver uma ferramenta de BI. E o cara queria que pegasse essa ferramenta e conseguisse fazer isso para gerar dados contábeis. Então era uma ferramenta de BI mais focada em geração e simulação de planos de contas, etc. E o cara falou, esse é uma RP o DBA vai dar acesso para vocês de leitura. Cara, era um banco de dados com 1.200 tabelas e o nome das tabelas era tipo assim, 1, 2, 3, 4, a outra era 4, 5, 6, sabe? Não tinha nome as tabelas, era tipo, sei lá o que era. A gente ficou ali três meses só para tentar entender o que se tratava cada tabela e a gente criou um banco de dados para mapear as tabelas, para dar apelido nas tabelas para a gente saber o que a gente estava fazendo e os caras tinham zero documentação zero documentação sabe, e outra coisa que eu falo que é, não é assim todo mundo adora, banco de dados zero documentação sabe, e outra coisa que eu falo que é todo mundo adora, banco de dados sem esquema MongoDB põe tudo lá, põe no Cassandra muito legal mas cuidado cada problema tem uma solução é parte da arquitetura de solução analisar isso. Aquela cultura de documentação. Data model, como que vai ser? E o que eu quero? Qual é a vantagem de usar? Por exemplo, se eu vou usar o Progress, eu vou usar o MongoDB, qual é a vantagem? Ah, mas eu não tenho flexibilidade, eu preciso ficar manantendo em cima. Tudo bem, eu sou imigração Como que você faz a migração disso? Você já viu Como que é nojento Desculpa a palavra Como que é complicado O script Como é chato O script de uma tabela De uma entidade De um zombie Do Mongo para uma outra, que você tem bilhões de registros lá, também em tudo, é a coisa mais bonita. Então, tudo isso tem que ser considerado também. Você está falando de banco de dados, lembrou aí, banco de dados, cuidado, escolha o cenário. E isso aí é papel de arquitetura de solução, né cara? você conseguir olhar modelo de dados tem coisas plano de capacidade data model, design de API todos esses tipos de pensamento vem do arquiteto de solução obviamente que nunca existe um, vamos dizer assim aqui é arquitetura de solução, Obviamente que nunca existe um, vamos dizer assim, aqui é arquitetura de solução, aqui é de software. Sempre tem aquela zona cinzenta ali no meio. Mas de uma forma ou de outra, como que eu vou arquitetar uma solução se eu não consigo falar nem qual é o tipo de banco de dados que ele vai usar e quanto que vai custar esse banco de dados ao longo do tempo. Nós não tínhamos o banco de dados ao longo do tempo. Nós tínhamos o banco de ODS, aquele grupo separado, que te dizia como funcionavam os dados, te garantia acesso de leitura, que nem você falou, desenvolvedores. Aquilo começou a criar e agora se uniu. Se uniu aquelas funções. E agora a gente está unindo aquela função aqui do lado, que é a parte de arquitetura e de infraestrutura também. Então, para o seu ponto, Wesley, é importante você saber qual é a base de dados, o que você vai usar, qual vai ser o custo, qual o impacto. Por exemplo, se você está usando um banco de memória para cache, por exemplo, um Redis ou um Elastic Cache da AWS, você vai colocar quanto dado lá? Você vai usar, que nem você colocou no seu short do outro dia, do sidecar? Você vai colocar um sidecar ali do lado para fazer um banco de cache, para fazer um cache local? Qual o impacto disso? Vai crescer demais? É caro? O Elastic Cash da AWS é um dos serviços de storage mais caro que tem. Se você colocar muitos dados lá com muito tráfego, vai custar caro. Então, você planejou isso? É isso que é o negócio fazendo no botão arrastando o botão ali, etc é tudo baratinho e lindo as soluções se enquadram perfeitamente só não dá pra pagar depois tipo isso aí fecha a porta, troca de e-mail vamos e cara pra gente ir caminhando aí pro fim, o Eduardo, queria fazer uma pergunta pra você, cara. Até que ponto você acha que as pessoas devem, principalmente em quem vai criar soluções novas, a gente tem aqueles perfis, galera mais arrojada, gosta de pegar mais coisa, mais experimental. Tem um pessoal muito mais conservador, principalmente que está em projetos que já estão muito estabelecidos por muito tempo nas empresas. E o que é importante daquele negócio não é firula, é estabilidade. Cara, como que você vê isso? Até que ponto eu posso experimentar? Até que ponto eu posso colocar coisas novas? E como que é gerada uma política para esses tipos de coisa dentro de uma empresa? Ah, eu quero usar essa biblioteca nova. Ah, eu quero usar, quero experimentar esse Elastic Cache. Ah, não, nunca trabalhei com Dynamo. Quero usar o Dynamo aqui no projeto. Como que, porque experimentar coisas novas geram soluções diferentes e às vezes soluções melhores mas também só fazer coisas novas às vezes sai mais caro e as coisas vão errar como é que você vê isso? eu vejo isso como um bom desafio hoje com alguns cabelos brancos na cara mais do que eu gostaria de novo né gente trauma driven development cara, né? Mais do que eu gostaria. E, de novo, né, gente? Trauma-driven development faz com que a gente pense duas vezes em algumas coisas. Já fui daquele tipo de cara que viu aquele framework novo, tem, tá no SourceForge, eu sou do SourceForge, by the way. SourceForge, você lembra? Isso não é pra todo mundo. Só os fortes, em geral. Os velhos, né? Mas assim, lançou um framework novo, ah, legal, vamos usar. Tinha dois desenvolvedores. Dois meses depois o cara parou, ah, não gostei mais, vou fazer outro projeto. E eu fiquei lá, refém. Um projeto não gerenciado por lá. Da mesma forma, ah, mas eu vou ficar usando essa coisa que está errada aqui. Quando eu trabalhei na Volvo, a gente estava fazendo a atualização de um software feito em VB1, VB5, daí a gente estava migrando para a .NET, então que componentes a gente usa? Usa componentes somente nativos ou tem ferramentas que permitiam, a gente acabou comprando componentes, The Telerik uma empresa que desenvolveu componentes customizados, então o que eu quero dizer lá para o seu ponto para a sua pergunta Wesley é vai ser um balanço, tem hora para você inovar, você tem que tomar cuidado para não pegar uma coisa que é bleeding edge. Bleeding edge é muito... Normalmente, dependendo da sua empresa, por exemplo, se você está começando um produto e tal, bleeding edge talvez não seja o melhor perfil. Porque você tem que ter, vamos dizer assim, você tem que ter capacidade de experimentar e falhar. Você tem aquela pergunta, né? Posso falhar? Vou poder voltar atrás e mudar? Não. Então, ok. O que eu posso usar no lugar? Então, são perguntas que você vai fazer como arquiteto para definir o quão novo, o quão inovador você vai querer ser em uso dessas bibliotecas ou não. Ou, estou falando de ficar com o legado, ficar com aquela solução antiga, mas também balancear. Quando é hora de sair de uma coisa? Quando é hora de estar chegando no limite? Então, tem um balanço ali. Já tive situações que eu usei muito avançado, situações que eu fiquei preso porque eu não avancei. Então, não tem uma resposta perfeita para isso. Eu acho que isso talvez demande muito, inclusive, de quantos tiros você pode dar. Você está em uma startup, você tem uma chance, você tem três meses da startup, dinheiro para ela rodar. Você não vai fazer um negócio que você vai ter que refazer depois em seguida dessa forma. Então, isso aí tem que tomar muito cuidado. Por outro lado, eu já vi muitas startups que conseguiram fazer coisas mais rápidas exatamente por terem tido coragem de pegar soluções exatamente desse tipo. Eu lembro dos moleques, falo dos moleques porque eles são muito foda mesmo. A galera lá que fez o Pagar.me, fundaram a Brexite, né? A Brexite. Agora, na época quando eles criaram a Pagar.me, que depois foi vendida pra Stone, etc. O Node tava ali começando de forma geral, entendeu? Era uma parada mega experimental. E os caras fizeram uma gateway de pagamento movimentando milhões usando uma tecnologia que, cara, eu não tinha coragem de usar pra produção pro meu projeto pessoal, entendeu? Então, tem algumas coisas que você tem que ter culhão, né? É. Na Neonet, a empresa que a gente... pessoal, entendeu? Então, tem algumas coisas que você tem que ter cuidado, né? É, na Neonet, a empresa que a gente, que eu comentei que eu trabalhei antes da Amazon, a plataforma inteira é Node.js com text-free. Então, para áreas de cálculo que a precisão do Node não ajudava, porque tem falha matemática, a gente teve que fazer algumas mágicas ali, umas extensões, mas não demais. Conseguiu, funcionou. E foi rápido, e foi leve. A gente brincava que o nosso container... Olha só, arquitetura de solução. Para onde você tem que pensar? O nosso container, a imagem base do nosso container, a gente criou from scratch. Então, do zero. Ela tinha 17 megas. Uma imagem base do .NET para um Docker container, hoje está otimizada para 150, mas antigamente era 700 megas. Quando a gente criou o nosso node com 17, não tinha mais nada ali. Era só o sistema operacional, basicamente. Caraca, e as node modules, cara? Agora euaca, e as Node Modules, cara? Agora eu fiquei com essa dúvida aí. A gente fazia o trim de tudo, zerava o mínimo, mínimo, mínimo, fazia o tree shaking total, que é para fazer a eliminação de desnecessários, fazer o flattening, porque o Node tem... cria aquela árvore que duplica... Dependência, dependência da dependência. É. Aí a gente comprimou, ficou perfeito, rapidinho, melhorou o storage do nosso repositório, que era o JFrog, a conta ficou baixa, que agora é menos espaço, então tudo isso ajuda. Muito bacana, cara. Então, olha aí, a galera do Node aí que gosta pra caramba, aí, ó, fatura, quanto que ela tava gerindo de assets lá, cara? Ah, então, essa não é da startup, né? Ah, não, essa não é dessa startup, essa é de outro. É um monte de projeto que é fogo. É, a Neonet em si, dados públicos, né, ela gerencia em torno de meio trilhão de dólares em assets. Ela é ela gerencia em torno de meio trilhão de dólares em assets ela é a maior servidora de empréstimos de estudantes dos Estados Unidos caraca, cara e aí, dá orgulho você olhar uma empresa desse tamanho hoje e saber que um monte de linha de código lá foi você que meteu a mão um monte de decisão crítica foi você que tomou dá, não, com certeza isso é uma das coisas mais satisfatórias da vida de arquiteto ou de desenvolvedor, é olhar para trás e falar, fui eu. Então, isso dá bastante orgulho. Eu acho que, assim, às vezes até mais que dinheiro, que é aquela questão de prazer de você falar, principalmente quando você tem a paixão por aquilo. Tem muita gente hoje na tecnologia que tem a tecnologia como emprego, não como paixão. Aqueles que têm paixão vão olhar para isso e vão ter prazer, vão ter orgulho. E esses vão bem mais longe. Show de bola! Galera, falamos aqui com o Eduardo Dias. O cara trabalha na área de gestão, você virou gestor no final da história, depois de tudo isso, virou gestor trabalha na área na Amazon, né o cara só fica com a prancheta na mão mandando os devs fazer as coisas, é isso? aí, ó a prancheta moderna, né é o meu caderninho aqui. Eu, com o tempo, fui indo para a gestão, mas sempre envolvido, tanto que na Neonet eu falava que um PR por semana era a minha dose de saúde mental. Na Amazon, eu trabalho com a experiência em espanhol, SpanishOn.com. Então, tudo que você vai na Amazon.com e você pesquisa em espanhol, ele começa a falar, você quer falar espanhol? E começa, Amazon, agora vai ser áudio, Amazon Music, tudo isso, é a minha equipe que está trabalhando com essas equipes para melhorar a experiência. Então, a minha equipe está em todas essas partes. E a gestão. Só que a Amazon gestão, Wesley, é muito engraçado. Eu posso não codificar hoje, posso tacar pranchetinha aqui, mas, por causa dessa cultura de documento, de design, eu estou envolvido em cada decisão técnica da equipe. Então, eu sei de tudo. A gente tem métricas pra tudo então eu sei de cada detalhe que tá acontecendo posso não estar desenvolvendo, eu contribuí com código mas essa é a minha meta até o final do ano eu poder estar desenvolvendo também mas eu me sinto também participando no dia a dia show de bola um dia eu quero marcar um bate-papo com você só de Amazon só de empresa grande porque eu não tenho dúvidas tem um monte de gente que quer saber o que é trabalhar numa empresa dessa mas como será que é então fica aí pra gente uma hora marcar um papo só pra falar de Amazon experiência em grandes empresas eu tenho uma galera que está no Google Microsoft Amazon, tem galera Netflix pega as Fangs aí e fazer uma live só para falar como que é trabalhar em Fang eu tenho até alguns amigos aí no LinkedIn que podem participar também que vão trazer uma perspectiva aí bem boa. Show de bola. Eduardo, cara, muito obrigado mesmo pelo bate-papo. Cara, valeu mesmo. Eu não tenho dúvida disso aí, que vai ser mega enriquecedor. É aquela história, conceito e coisas a gente acha em livro. A gente faz curso, você assiste as aulas que eu gravei, tem todos os conceitos bonitinhos mas o dia a dia como que as coisas vão acontecendo é o que faz a diferença então cara, muito obrigado por contribuir aí com a sua experiência e com a sua história de vida aí achei massa demais e valeu pra galera eu ia falar só obrigado Wesley pela oportunidade massa demais e valeu. Para a galera... Eu ia falar só obrigado Wesley pela oportunidade e espero que tenha contribuído com o pessoal e qualquer coisa é só entrar em contato com a gente no LinkedIn, eu tive a pergunta e posso responder sem problema nenhum. Show de bola, vou deixar o seu LinkedIn para a galera te bombardear lá então. Manda ver.