Afinal é para dev? É para DevOps? É para Ops? O que é essa bagaça? Vamos falar sobre isso hoje.

Não é nem um pouco novidade que eu cuido do Docker Definitivo e hoje estou 100% dedicado a esse projeto.

Mas o que é o Docker Definitivo?

Bom, vamos começar pelo nome: Docker Definitivo.

Docker é o novo sistema operacional onde nossas aplicações rodam. Já é o caminho natural da maioria dos deployments .NET dos projetos que eu tenho contato. E isso se dá pela natureza de estar próximo da galera que quer esse tipo de tranquilidade e está disposta a abraçar o desafio e desafiar o status quo imposto pela ideia: Se é .NET é no Windows.

Tenho visto cada vez mais aplicações chegando a esse ambiente. Isso quer dizer, saindo do deployment no Windows e vindo para o Linux, principalmente com containers.

Mas isso é bom?

Sim. É muito mais barato, muito mais estável, e por incrível que pareça, embora traga muito mais recursos, é mais simples e previsível.

A questão é que não é porque é mais simples que não deixa de ser disruptivo. E se já é disruptivo para quem é nativo no Linux, para nós que somos do Mundo Microsoft, há um abismo a ser superado.

O ponto é que não só quem depende de escala se beneficia. Nada disso, todo mundo brinca, todo mundo se diverte! Basta precisar instalar uma aplicação no IIS para conseguir te mostrar um mundo muito mais tranquilo, sereno e de paz no Linux.

Se você tem uma aplicação que precisa de diversos componentes para fazer uma demonstração on premise, ou tem o desafio de rodar uma aplicação on premise ou na núvem: Todos esses são bons cases para aplicações .NET em que você se beneficia de docker. Até para usar 2 setups diferentes, aproveitando o mesmo servidor, você se beneficia. Mas, vamos lembrar que docker é apenas um facilitador.

Docker Definitivo, porque desse nome?

Simples: Docker não é objetivo, é meio. Se docker é o novo sistema operacional para nosso deployment. Podemos compará-lo ao Windows para nosso dia-a-dia.

De que adianta vc aprender windows? Qualquer um que nasceu em frente a um computador não precisa! Mas um eremita que nunca tenha visto um computador, precisa aprender Windows.

E aqui no universo ao redor do .NET, nós somos eremitas em relação ao Linux e ao Docker. São quilos de conceitos, que nos foi ensinado de forma complicada porque o windows é complicado em sua arquitetura.

Então é preciso revisitar um conjunto de conceitos antigos, que no Linux são mais simples. E para assegurar que não seria necessário esse conhecimento prévio, eu embarquei um módulo de Linux com o básico, para conseguirmos prosseguir.

Mas nem por ser simples, nem por não ser muito extenso, Linux não deixa de ser disruptivo para nós.

O termo Definitivo do nome foi pensado com a conotação de: O seu último curso de Docker. Porque? Porque meu foco não é ensinar Docker. É usar Docker para ensinar arquitetura de solução. Definitivo tem a intenção de ser O DEFINITIVO, O CONCLUSIVO, O FINAL. Pois a ideia aqui é quebrar as barreiras entre o dev .NET e todo o universo dos containers, orquestração, escala, resiliência.

E isso só é possível, passando por toda a jornada de um arquiteto de solução. Mostrando soluções, decisões, os arquétipos de projeto que demandam questões que até então boa parte dos alunos sequer compreendia.

De uma forma que a partir do momento em que você enxerga com seus próprios olhos o que e eu faço e como consigo fazer, você tem a oportunidade de copiar. E para uma fração do grupo, será um dos últimos cursos de tecnologia. Simplesmente pela autonomia que você ganha no decorrer dessa jornada.

Para esses poucos, eles vão ver como as documentações em 2021 são ricas, e completas, e vão ver que com a documentação debaixo do braço, assim como eu faço, o mundo é infinitamente mais fácil.

Vão entender que na maioria das vezes o básico, o feijão com arroz é o que é bom.

Se você aprende docker, você consegue rodar suas aplicações .NET no Linux. Mas pra quê? Existem aspectos financeiros e operacionais que justificam, mas e daí? Na minha opinião uma grande vantagem está no isolamento e no que isso nos permite fazer com ambientes locais e ambientes de produção.

Se fosse fácil e não consumisse recursos, usaríamos 10 vm’s nos nossos desktops. Mas a realidade é que 10 VM’s demandam 11 kernels, 11 sistemas operacionais inteiros rodando. Assim nos habituamos com a ideia de não ter hardware para simular um ambiente produtivo.

Quem usava Redis, sem docker, fazia setup em um servidor dedicado, ou local. O mesmo acontecia com RabbitMQ, Elastic, Kong e diversas outras tecnologias. Então para usar uma tecnologia era aquele inferno de pedir servidor, estudar formas de setup, lidar dependências e requisitos, e isso podia levar meses.

A facilidade do setup produz um efeito de sadio de popularização de ferramentas que antes só estavam disponíveis para quem conseguia aquela grande infra, com um servidor de banco, um servidor da ferramenta etc. Isso é megalomaníaco demais, e impedia que fizéssemos provas de conceito, que avaliássemos soluções. Era moroso, caro, envolvia muita gente e recursos que estão além da nossa competência.

Errar custava tempo e infra e muita gente, não era só o tempo de quem suspeitava que ferramenta A ou B traria benefícios. O nível de certeza precisava ser elevado, antes mesmo de colocar a mão na ferramenta.

Com docker, isso tudo acabou.

Se você quer testar sua aplicação com um API Gateway como Kong, basta um docker compose e menos de 2 GB de RAM para o docker.

E se você já torceu o nariz pensando no ambiente produtivo: Calma! Dê a Cezar o que é de Cezar! O que estou propondo aqui é experimentação. Validar ideias antes de firmar o compromisso de pedir infraestrutura. E só pedir se sua análise primária confirmar positivamente a solução. Nada muda quanto à necessidade de um ambiente produtivo. Docker pode entrar como facilitador, mas eu sequer abordo essa parte de Ops.

Agora você pode explorar mais, você pode, na sua máquina testar praticamente qualquer coisa. E se seus testes demonstrarem sucesso, ótimo, o próximo passo é de fato planejar isso corporativamente. Mas você conseguiu provar uma ideia, um conceito, antes de envolver outras áreas e antes de correr o risco de estar redondamente errado. Se a solução que você escolheu não te atende, ótimo, você não alocou infra para descobrir isso. Não gastou tempo convencendo meio mundo de usar a solução errada. Você se manteve sensato, avaliando uma possibilidade.

Mas e aí? Com esse poder a mais, o que dá para fazer?

Como se essa oportunidade já não fosse boa até aqui, ganhamos outra: a oportunidade de trabalhar com escala de forma mais fácil, demandando menos recursos. E não estou dizendo que você vai chegar na sua empresa, com 10 funcionários e vai criar um projeto de escala global! Você até poderia, mas a importância disso é que agora as soluções que ajudam Azure, Netflix, Google e Amazon estão mais acessíveis, não só nos seus respectivos datacenters, mas na sua máquina, no seu desktop, local.

Da mesma forma como no post Sobre Formula 1 e Microsserviços eu expliquei como as soluções se tornam cada vez mais populares, as arquiteturas que usam essas soluções acompanham esse movimento e se tornam ainda mais populares.

Docker traz facilidade, mas consigo também tem sua complexidade. Fácil e simples para quem já estava no mundo Linux, mas para nós, do universo .NET, a forma de enxergar algumas coisas é beeeeem diferente.

Desde os primeiros dias com docker em produção, você já vai precisar de conceitos que permeiam infraestrutura. E aqui no universo .NET nós negligenciamos isso de uma forma tão, mas tão absurda!

Proxy Reverso, tema que abordo em detalhes aqui no gago.io, é um assunto que desde o segundo deployment com docker no mesmo servidor, você há vai precisar saber. Bastou ter 2 aplicações para colocar na mesma porta 80 ou 443 que o proxy reverso se faz necessário em um ambiente docker. Da mesma forma como se faz necessário um Ingress Controller no Kubernetes.

Mas isso não é coisa de Ops/DevOps? Não! Na verdade sim e não.

Do ponto de vista de produção, do ambiente produtivo, até acredito que seja assunto de Ops. Mas o papel da galera de Infra é subir o serviço, e garantir uptime. Do nosso lado, precisamos compreender como estruturar as decisões sobre o uso em cada solução.

Um arquiteto, líder técnico ou desenvolvedor senior que desenvolva uma simples API de Soma, precisa saber lidar com as configurações pertinentes ao proxy reverso no startup.cs, precisa saber o que acontece quando há um proxy reverso layer 7 entre sua aplicação e o mundo. E o que é possível fazer quando você só tem um proxy reverso layer 3. Ao colocar a mão no docker, tudo de infraestrutura que você negligenciou por anos, se vira contra você. Proxy Reverso, DNS, conceitos sobre Sistemas Operacionais.

Afinal, Proxy Reverso vs Api Gateway ou os 2?

Vamos deixar essa pergunta para depois. Mas é pertinente.

O ponto é que você não precisa sair correndo para se matricular na primeira faculdade que aparecer nos google ou facebook ads. Calma. Mas sim, são conceitos importantes que farão falta no dia-a-dia.

Mensageria: Eu comecei rodando RabbitMQ no meu desktop windows. Isso em 2013. O primeiro passo é achar a versão correta do Erlang para a versão do RabbitMQ que você quer instalar. E instalar os 2.

Na medida que mais empresas buscam trabalhar com aplicações distribuídas, sendo elas microsserviços ou não, começamos a pensar em escala horizontal, em distribuição das nossas aplicações. E aí vem outros desafios:

Escalabilidade, resiliência, observabilidade, manutenibilidade.

Para esses, Docker, Docker Swarm e Kubernetes serão assuntos a serem pensados. Mas além disso, você precisa lidar com a escala em si. Como lidar com logs em aplicações que escalam na grandeza de dezenas ou até centenas ou milhares de instancias? Como lidar com a rastro, a pilha de chamadas que agora não é síncrona e nem HTTP? Não? Não!

RabbitMQ e Kafka são assuntos latentes em aplicações distribuídas pois eles entregam resiliência e tiram a dependência síncrona entre quem publica mensagens e quem consome mensagens.

Ao mesmo tempo, você precisa lidar com acesso, controle de acesso, certificados digitais de serviços que escalam nessa natureza louca de dezenas de milhares. Como lidar com isso?

Kong é um API Gateway e já apresentamos cenários com o Kong via Docker Compose, como edge, e cenários em que ele é um Ingress Controller do Kubernetes. Aliás, kubernetes é uma jornada inteira por si só. Mas é todo a parte anterior dessa jornada é importante. Mas antes de falarmos de Kubernetes, temos de lidar com as outras coisas ao redor dos containers: Rede, Service Discovery, DNS, roteamento, segurança.

São todos aspectos que uma equipe de Ops precisa assegurar e entregar para que o dev defina como vai usar esses recursos. Não cabe o dev apenas fazer pedidos superficiais, cabe ao dev saber como se integrar a um identity server externo como Keycloak.

E estamos em meio a um blackout desses profissionais. Não é a toa que DevOps virou cargo. O que é chamado de DevOps hoje pelo mercado, na minha opinião é apenas um Dev. O skill de DevOps é o que um dev sempre deveria ter sido. DevOps entra muito mais como uma forma de enxergar a parte de Ops, com uma visão mais sistêmica, mais focada no reaproveitamento, da mesma forma como pensamos responsabilidades, coesão, e acoplamento como quando desenhamos classes e usamos SOLID.

E tudo que discutimos aqui afeta o trabalho do Arquiteto e qualquer tipo de liderança técnica. Essas decisões envolvem estratégia técnica. Não necessariamente budget (dinheiro), mas tempo, com certeza é necessário. Mas se você não faz ideia do que estamos falando, levará mais tempo para acertar, e muito mais tempo errando antes de acertar. Será que esse erro pode ser destrutivo? Será que esses erros produzirão entendimentos errados que custarão uma vaga em alguns anos? Será

A jornada de distribuição de aplicações é complexa, exige coisas como caching, por exemplo. Mas e aí, em memória? Claro que não só. Também temos cache distribuído e talvez até lock distribuído. Redis é um candidato ao posto.

Sobre o Service Discovery temos novos desafios nesse ambiente de escala.

RabbitMQ, por exemplo, tem uma dúzia de detalhes na implementação de quem publica e consome mensagens para que você garanta que as mensagens são persistidas, não são perdidas, só são deletadas depois de processadas com sucesso. E você já deve ter visto a série sobre RabbitMQ aqui e a Masterclass RabbitMQ para aplicações .NET. E quando digo uma dúzia, estou me referindo a mais de 10 e menos de 20 itens!!!!

Até o ciclo de vida do ASP.NET Core para Worker Services é peculiar e não é óbvio. E para isso temos repositório no github com explicação e exemplo. Mas no que afeta a sua aplicação? No graceful shutdown! São detalhes que sequer sabemos como lidar sem parar para estruturar.

Agora você precisa lidar com automação? Afinal, em uma ordem de grandeza tão grande de deployments, como lidar? CI/CD! E aqui abordamos os pipelines do Jenkins. Mas você pode aproveitar o mesmo conceito para usar em qualquer lugar.

O único requisito que eu quase imponho em você, é a de que o build aconteça em um container, sem gerar dependências no host. E uma vez que isso é verdade, qualquer ferramenta serve, porque lado-a-lado, ninguém atrapalha ninguém por conta do que tínhamos no windows que apelidávamos de DLL HELL.

Então porque docker definitivo?

Para ser um amparo para quem precisa lidar com essas decisões, todas elas.

Seja tomando ou influenciando a decisão ou seja operacionalmente usando cada tecnologia da melhor forma, sabendo aproveitar e escolher as responsabilidades adequadas para cada cenário.

Para mim é a fusão de aulas conceituais e teóricas, com aulas práticas e muita mão na massa.

É sobre saber pensar

É sobre saber decidir

É sobre ponderar

É sobre tomar decisões.

É sobre experimentar

É sobre aprender a aprender.

Eu concebi em um único curso o que eu considero o roadmap de do arquiteto de soluções.

• Containers
• Orquestração
• Gestão de Identidade e Segurança
• CI/CD
• Qualidade de Código
• Aplicações distribuídas
• Resiliência
• Escalabilidade
• Observabilidade
• Estratégia

Todas as principais áreas em que aplicações que escalam são completamente diferentes do crud do dia-a-dia. Os cenários que proporcionam atenção especial desde o primeiro commit. Cenários que são impossíveis de conceber sem experiência prévia.

E eu acredito que esse conhecimento que produzimos aqui é fundamental para um desenvolvedor vencer a bolha dos ERP’s locais/regionais, e alcançar projetos e empresas de âmbito nacional e global.

Na minha visão o gap não está no detalhe de uma linguagem. Não está em não conhecer um padrão ou outro. Está em, pela ótica de uma empresa grande, sequer saber desenvolver software. E essa percepção é causada pelo tanto de engenharia de software que essas grandes empresas aplicam para lidar:

• com grandes cargas de trabalho
• com times técnicos tão grandes
• com tantas demandas de compliance e certificações

Coisas como deploy por FTP, entrar em servidor para fazer implantação manual, olhar log em disco nos servidores são coisas inconcebíveis nas maiores. Código não versionado, nunca chegará em produção, isso é uma regra básica. E hoje em 2021 ainda vejo gente usando publish do visual studio para implantar projeto no azure.

A distância entre as práticas de empresas pequenas e empresas grandes é tão grande que produz bolhas. São 2 grandes bolhas: Os devs de empresas pequenas e os devs de empresas grandes.

Esses mundos não conversam. As demandas de cada um desses universos são bem diferentes, embora tudo seja, no final do dia, software. O que muda não é o produto, mas a forma, as regras e as ferramentas para se construir um produto.

Abrangência e Profundidade

A contragosto de quem diz que quem dá atenção a diversas tecnologias é pato, ou que fullstack é pato, essa é a função de qualquer um que exerça uma liderança técnica. Seja o arquiteto, o líder técnico, mas também o desenvolvedor senior que está ajudando os mais novos. Entender e compreender diversos assuntos é fundamental para conseguir projetar uma solução nessas empresas grandes.

Mas o problema está em que quem diz isso.

Eles estão desmotivando quem tinha potencial.

A jornada que proponho é a mesma desses vídeos, a mesma jornada de grandes empresas, grandes projetos.

Essa jornada está disponível também para você.

Esse abril de 2021 é um mês muito importante para mim. É o mês em que o grupo de arquitetura completa 10 anos. E eu resolvi presentear a comunidade.

Em vez de uma janela de inscrições de 5 dias, como acontece normalmente. O Docker Definitivo está durante todo o mês de abril aberto para que você entre.

E nessa primeira metade de mês, eu fiz algo que poucas vezes fiz: Descontos, um bonus super agressivo. Enfim, dependendo do que você escolher eu posso tirar do meu bolso de R$ 500 a R$ 1497 para que você entre nesses dias.

O Docker Definitivo, está saindo de R$ 2997 por R$ 2697, para todo mundo. Eu estou tirando R$ 300 do meu bolso.

Se você quer contar com a minha ajuda nessa jornada, você pode entrar no Docker Definitivo clicando no botão abaixo.

Masterclass RabbitMQ para Aplicações .NET

Se você perdeu, aqui está sua chance de assistir ao conteúdo da masterclass.

Aliás após um longo inverno a Masterclass que não estava à venda, está pronta: Se você quer entrar assistir às gravações dos 2 dias, e participar do grupo privado comigo, além de ter acesso ao código-fonte de referência: basta clicar no botão abaixo.

O CÓDIGO – Curso Gratuito

Independente de você vir ou não para o Docker Definitivo ou Masterclass RabbitMQ para Aplicações .NET, aqui tenho um convite para você. Na primeira semana de Maio vai rolar uma nova jornada.

Ela se chamará O Código e será completamente diferente de todas as outras.

Dessa vez será um curso completo de uma semana, comigo.

E meu presente para a comunidade é a chance de qualquer um assistir e participar comigo ao vivo, de graça. Mas somente ao vivo. As inscrições já podem ser feitas, gratuitamente aqui ocodigo.net. O conteúdo não ficará gravado, então se prepare para estar presente.

Na última quinta-feira eu fiz uma live contando a maior sacada que recebi na vida. E vou compartilhar com você por email hoje, 11 da manhã.

Mas está aqui o vídeo também.