Se você já ficou sabendo sobre as novidades no Cloud Native .NET, quero que saiba que ainda tem muito mais chegando. Hoje vou contar 10 novidades sobre o que fazemos do lado de dentro, conteúdo e projeto gratuito do lado de fora e mais algumas curiosidades sobre esse projeto.
1) 3 anos de Cloud Native .NET
Ok, começou como Docker Definitivo. Sim, verdade. Mas com uma jornada desse porte, era óbvio que levaria algum tempo até concluir minhas ambições de criar uma formação completa ao redor do que hoje é conhecido como Cloud Native.
Naquela época, em 2019, Cloud Native já era um assunto, mas muito menos relevante e ressaltava pouco aos olhos.
Ao mesmo tempo eu precisava ter certeza de que era capaz de produzir, em escala, com um método, o tipo de profissional com o skill que eu queria entregar para o mercado.
2) Forjar arquitetos sempre foi a missão do Cloud Native .NET
Na verdade forjar arquiteto é até demais até mesmo porque eu não acredito que formação alguma forme arquitetos. Arquitetos são formados pela prática, mas o que eu trago aqui é uma forma de desmistificar muitos dos assuntos que tornarão a jornada desse arquiteto pavimentada, mais fácil, mais tranquila.
A ideia é expor a diversos conceitos, práticas, padrões, arquiteturas que vão desmistificar muitos dos assuntos que você verá no dia-a-dia criando e definindo soluções.
Isso se traduz em reduzir o tempo perdido no meio da jornada, em acelerar o processo de aprendizado, em quebrar as grandes pedras, para que seja mais fácil alcançar seu objetivo.
Então precisamos superar muitos dos conceitos errados que vemos nas empresas “antiquadas”, e apresentar soluções, padrões e práticas de mercado que nos leve para o próximo nível.
3) Eram 2 Fases, agora são 3 Fases
Desde a concepção, o Docker Definitivo e posteriormente já com nome de Cloud Native .NET,
Muitas vezes é difícil entender onde o aluno está nessa jornada, portanto dentro da formação, criei uma divisão em 3 fases.
Fase 1: Fundamentos
onde discutimos basicamente containers e aprendemos o básico de Containers e Linux. Essa primeira fase possui seu próprio projeto final.
Fase 2: Aplicações Distribuída
onde discutimos os elementos necessários para distribuir aplicações, bem como padrões que envolvem mensageria, caching, mas além disso abordamos Observabilidade, CI/CD e deployment. Nesse nível aqui ainda falamos de cenários para empresas pequenas.
Fase 3: Microsserviços e Arquitetura
aqui já assumimos que você está em uma empresa grande e vamos falar de soluções corporativas, e decisões estratégicas sobre repositório de fontes, gerência de configuração, processo de tomada de decisão, microsserviços, padrões de microsserviços, Event Driven Architecture, governança e muito mais.
4) Porque começou com foco em Dev Senior?
Na verdade o foco eram Desenvolvedores Seniors, Líderes Técnicos e Arquitetos de Software e Solução. O ponto é que qualquer um desses perfis, demandam muito menos convencimento. Claro que eu tenho um desafio muito maior de provar que eu sou expert nesses assuntos, no entanto durante a formação a necessidade de convencimento, no dia-a-dia, após a entrada desse profissional na formação é muito menor.
Isso acontece porque ele já viu problemas suficiente e o que eu estou mostrando se encaixa diversas vezes em diversos problemas que ele já passou na vida. O desenvolvedor jr ou pleno muitas vezes está há anos de chegar em um problema desses.
Por exemplo, docker em 2019 não era um assunto tão relevante para o JR ou PLENO, hoje é e o desenvolvedor já toma bomba no processo seletivo, dependendo da empresa e do cargo. Mas naquela época, para eu conseguir falar de Docker para um JR ou PL eu precisava mostrar o antes, mostrar problemas e dificuldades que ELE AINDA NÃO VIVEU.
E isso dilacera a experiência dentro da formação, porque vira crendice, vira uma crença de que o que eu estou dizendo está certo, sem que ele tenha vivido ou experimentado problemas, para poder debater ou discutir.
Para poder falar dos problemas do IIS é preciso que você conviva o IIS, diariamente. E isso leva algum tempo.
Outro ponto é que poucos desenvolvedores seniors consideram o Kerstrel um Web Server de testes ou de brinquedo ou experimental ou sei lá o que. Mas há muitos PLENOS e JR que ainda pensam isso. Os seniors que pensam isso, sinceramente, nem seniors são. Mas o PL ou até o JR, precisa passar por mais coisas ao ponto de conseguir produzir esse julgamento.
Assim para que eu possa falar da solução, é preciso que você tenha vivido o problema. Ou dado uma solução errada, ou ao menos não adequada. É assim que eu consigo ganhar tempo e produzir conteúdo tão extenso, em menos de 120 horas de formação.
5) Começar com somente Docker foi uma estratégia!
Quando eu comecei esse projeto em 2019 eu tinha a ambição de criar uma formação de arquitetura de soluções. Mas com toda certeza eu não sabia se eu teria a paciência, se eu teria a vontade, e o interesse de fazer uma formação que durasse tanto tempo. Eu tenho aluno desde a primeira turma que ainda frequenta as lives.
Será que eu teria saco para falar sobre as mesmas coisas?
Será que eu não atrasaria meu próprio progresso?
Será que eu não perderia o interesse?
Tudo isso eram questões válidas e pertinentes. Então se eu vender A, e já entregar A, mais B, mais C, mais D, eu desde já consigo trazer uma galera pilhada, que vai receber muito mais do que contratou. E se eu perder o interesse, é só fechar as portas porque o contratado já estaria entregue.
Mas se eu conseguir criar o que eu quero, o resultado será avassalador. Porque eu terei todo o ciclo de vida do dev senior até a arquitetura de soluções.
Passando pelos principais assuntos, com um nível de profundidade animal e com um nível de abrangência animal. Será incrível.
O resumo é que hoje, 3 anos depois de começarmos estamos crescendo em conteúdo!
6) Aqui a gente testa e valida tudo o que apresenta
A única vez que eu falei de algo que não usava, foi em 2007. Na real eu usei Oracle de 2003 à 2005. Mas por volta de 2007 ou 2008 me pediram para pegar uma turma de Oracle. Então nem era que eu não usava, eu não usava mais!!! Ao mesmo tempo eu não tinha mais tempo sobrando para estudar outro assunto, porque naquela época eu estava trabalhando muito e estudando outros assuntos mais importantes para minha carreira.
O resumo foi que foi um fracasso total. Pedi para sair no primeiro dia.
Antes ou depois desse fato isolado, nunca falei de nada que não conhecia, de que não havia colocado a mão na massa para experimentar.
Então para falar de Sonar, eu subi, hospedei e usei sonar por mais de 5 anos.
Docker eu uso diariamente desde 2016. Aliás, em 2016 eu peguei o site da hoje famosa ViihTube para cuidar e subi todo com containers na época. Depois comprei meus próprios servidores na hetzner, onde hospedo minha infra até hoje, mesmo depois do MVP e de uma gorda conta no Azure.
Kubernetes eu comecei a trazer para o Cloud Native depois de anos… Depois de ter um cluster no ar por quase 1 ano e meio (~500 dias para ser exato).
Porque? Preciosismo?
Na verdade uma parte significativa dos profissionais ruins com que já trabalhei tinham um defeito caricato e repetitivo: Não sabiam do que falavam.
Arquitetos de overview, em que só haviam lido a primeira página e não sabiam de fato sequer fazer o que projetavam.
Desenvolvedores com ideias mirabolantes e complexas, que investem tempo para fazer o que não precisava sequer ser feito.
Eu não quero ser esse cara, por isso eu tomo minhas decisões, compartilho meus insights e minhas conclusões e fundamento meu pensamento de forma clara, para que possa ser debatido e para que possa mostrar que muitas vezes a realidade se contrapõe ao blueprint.
É o caso do Kong no eShop Cloud Native, onde usaremos em produção, mas não usaremos em desenvolvimento, principalmente por causa das máquinas dos desenvolvedores da comunidade, que não conseguem abrir o projeto direito, por causa do consumo de memória.
Já lidei com o elastic, tornando possível não executá-lo. Agora é hora de substituir o Kong em desenvolvimento para tornar a experiência viável inclusive para quem não tem, em casa, um hardware tão legal.
7) Nossos alunos estão no Brasil e no Mundo
Aqui nós temos alunos da Acimel, ACT Digital & Raízen, AmbevTech, Aubay Portugal, Autonomo, Avanade, B3, Banco Modal, BTG Pactual, Build Solutions, CI&T, ClearSale, Dell, EPAM, Escritório de Advocacia Dannemann, Evo Serviços Financeiros, Farfetch, FM Transportes, Inetum, Ioasys, Itaú, Itaú Unibanco, Localiza, Metanoia Sistemas, MICROPLAN AUTOMAÇÃO COMERCIAL LTDA. AUTOCOM, Monitora, ONS, Pentacom, Planet, RDI, SellersFunding, Skypro, Softplan, XP Inc., mas também muitos autônomos e consultores independentes.
A maioria esmagadora está aqui no Brasil, trabalhando para empresas daqui do Brasil, alguns trabalham do Brasil para empresas lá de fora, e alguns trabalham lá fora para empresas lá fora.
8) Como anda a adesão do conteúdo à realidade dos alunos?
Eu rodei uma pesquisa no final de semana que gerou alguns indicadores incríveis.
Eu perguntei: De 0 à 10, quanto o Cloud Native .NET te ajudou no exercício das suas funções na <empresa_atual>?
O resultado deu como média 8.05 com mediana em 8!
O que é incrível! uma mega aproveitamento do conteúdo no dia-a-dia.
Eu aproveitei e na mesma pesquisa perguntei se os alunos haviam trocado de empresa após entrarem na formação. Isso quer dizer que eu seria capaz de avaliar quanto o Cloud Native .NET conseguiria ajudar nos processos seleticos.
Eu perguntei: De 0 à 10, como o Cloud Native .NET te ajudou conseguir a vaga em <empresa_atual>?
Aqui o resultado deu como média 7.76 com mediana também em 8!
Claro eu não me proponho a resolver todos os problemas da engenharia de software em uma só formação portanto esses números são absurdamente insanos!
9) Habemus Ansible
Uma das maiores dificuldades contemporâneas é subir um Kubernetes e não gastar rios de dinheiros para isso. Quanto mais profissional, mais componentes, que demandam mais processamento muito antes de colocarmos a primeira aplicação de verdade no cluster.
Se pensarmos em volumes e persistência, aí, meu amigo. Lascou a vida.
Mas trouxe para esse assunto, várias coisas interessantes como os Operators de Postgres, RabbitMQ e para block storage, o Longhorn, depois de apanhar muito do OpenEBS.
10) Overview / apanhado geral? É a mãe!!!!
.
.
Hoje tirando dúvidas dos interessados recebi a mensagem de que consideravam um apanhado, ou algo como um overview.
Ahhhh como isso me deixa puto da vida!!!!
Nãoooooooo! De forma alguma! Nunca!
Overview eu faço em live pública, e olhe lá. Nem recentemente tenho feito overviews simplificados. Tenho ido direto ao ponto com problemas e soluções reais, como tenho feito na comunidade.
Aqui está um exemplo
Ansible
Já o conteúdo bruto recente de Ansible tem 5 horas, que na edição caiu para menos de 3 graças à arte da edição.
O módulo de ansible que é um dos que está mais fresco na memória por ter sido produzido nos últimos 15 dias, narra desde a formatação ao Kubernetes no ar, em produção, funcional, pronto para colocar centenas de aplicações.
Centenas?….
Sim, centenas!
Ao mesmo tempo, houve uma falha, causada pelo setup trazer pela primeira vez o kubernetes 1.25, recém lançado, onde um dos componentes que usamos, o Longhorn, não é compatível ainda.
Ness conteúdo você acompanha desde o processo de identificação do problema à correção, ao sucesso da implantação.
E essa correção demandou percorrer todo um caminho longo, desde a identificação das versões do Kubernetes disponíveis para o Microk8s, depois identificar, em uma role que usamos, onde ele era referenciado. Depois tranfromar em variável, definir um valor default que mantenha a retrocompatibilidade, e por fim parametrizar a configuração para que do lado de fora da role, fosse possível sobrescrever um comportamento default.
Como disse, do zero ao Kubernetes pronto para produção. Com um cluster com mais de 3 nós em alta disponibilidade, com mais de 16TB de armazenamento em RAID, com 8 TB disponíveis e orquestrados dentro do Kubernetes pelo Longhorn, 96 CPU’s e mais de 400GB de RAM.
Ao mesmo tempo temos RabbitMQ com 2 operators, mais Postgres com seu operator Cloud Native PG, servindo um cluster com 3 nós de Postgres em cluster possibilitando rodar Postgres sob o Kubernetes de forma profissional, em núvens privadas, públicas, híbridas e multi-cloud.
E aqui me dá a oportunidade de falar sobre concorrência em hardware, me dá a oportunidade de falar sobre quais riscos, quais decisões eu faria diferente de tivesse mais servidores, quais decisões eu tomaria se tivesse em um cloud provider onde pudesse contratar um banco gerenciado, quando eu traria essa responsabilidade para o cluster quando não. Quais os benefícios, impactos e problemas dessa abordagem.
Permite mostrar que não há opção CERTA, mas mostrar cenários. Mostrar quando, pra quê, por quê e o que me motivou a adotar aquela estratégia. Agora, não só em uma reunião de mentoria ou não só em uma resposta a uma dúvida no grupo privado, agora formalmente, em um conteúdo programático entregue. Onde consigo mostrar que se houver um jeito certo de fazer isso dentro de um ambiente k8s, não é subindo deployment, volumes e replicasets aleatórios, é necessário pensar um pouco mais e ver quem oferece para você uma estratégia sólida de clustering. Pra você: é aprender e usar!
No caso do postgres, ou rabbitmq, tudo isso com suporte a failover, para eleição de um novo nó como master em caso de um nó defeituoso ou capotado.
E por isso há um jeito certo e um jeito relapso.
Redis, docker e RabbitMQ
Redis é um assunto pequeno. Não abordamos 100% do redis, mas usamos redis diversas vezes. Nossos 2 principais usos são Cache Distribuído e Lock Distribuído. Ele ajuda alguns casos de uso que levam mensageria como principal tecnologia abordada, e por isso em menos de 1h o conteúdo de Redis é entregue. Diferente do conteúdo de docker que precisa de quase 10 horas.
Já o conteúdo de RabbitMQ dura em torno de 6 horas, porque na prática eu só tenho 3 componentes para detalhar, em alguns minutos, e o resto é de fato mostrando como esses 3 componentes completam dezenas de casos de uso diferentes.
Mas ainda assim é diferente de uma formação para especialistas em RabbitMQ, que é o papel do RabbitMQ para Aplicações .NET.
Aqui no Cloud Native .NET, RabbitMQ é um assunto que você aprende a trabalhar com, de forma profissional. No RabbitMQ para Aplicações .NET você pode viver de implantar e ensinar mensageria e RabbitMQ.
Ainda assim você tem ~6 Horas de conteúdo só de RabbitMQ (5h46min) aqui.
São propostas diferentes.
Já quando o assunto é roteamento de tráfego, essencial quando pensamos em containers, temos NGINX e Kong. Um com um simples proxy reverso e outro como um API Gateway.
Em 55 minutos você aprende NGINX com nossas aulas. Visto que você não precisa ser um especialista, mas vai precisar lidar com NGINX, no docker, no kubernetes, e em qualquer cloud provider você vai precisar no mínimo dos conceitos que aprendemos aqui.
Já com Kong, que é mais próximo de nós, por se tratar de um API Gateway, temos 2:30 de conteúdo exclusivo de Kong, fora o conteúdo do eShop Cloud Native que narra o uso propriamente dito do Kong.
11 ) BONUS | Qual a diferença entre o conteúdo do Youtube ou do gaGO.io e o conteúdo da formação?
A maior parte dos desenvolvedores olham para uma solução e tentam encaixar essa solução em um problema que não existe, ou um problema do qual a solução em questão, não foi projetada, e não é recomendada.
Na maioria das vezes essa abordagem vai levar à problemas, que por sua vez demandarão outras soluções, abordagens, técnicas, patterns e por aí vai.
Do lado de dentro eu tenho a oportunidade de ser cuidar com mais atenção, dessas dúvidas, de falar sobre cada aspecto que leva à minha decisão, de fazer aquilo, daquela forma, naquele projeto, e posso falar sobre quando eu não faria.
Então na prática eu consigo, decisão-à-decisão dizer: eu fiz assim por isso, porque esse contexto é esse, e porque as variáveis que eu tenho na mão são essas. Se as variáveis forem essa, essa e essa, eu teria tomado outra decisão.
Esse é o tipo de conteúdo que aqui do lado de fora é traumático de produzir.
De um lado as pessoas estão tão certas daquilo que não conhecem, que se torna impossível um conteúdo que fala de duas abordagens antagônicas, dar bom.
As pessoas esperam que você tenha um partido e que esse partido seja o delas.
E olha que embora seja um período eleitoral, eu não estou falando de política.
Como por exemplo, quando eu decido subir minha infra de RabbitMQ e Postgres dentro do Kubernetes, eu tenho de fazer considerações claras.
Como falar sobre os impactos de rodar esse tipo de workload dentro de um cluster que está também ocupado com aplicações processando freneticamente.
De falar da concorrência sobre as camadas físicas e sobre o overhead da abstração do file system.
Mas também falar sobre a capacidade de alocar POD’s em diversos nós, mesmo que eles dependam de volumes com identidade própria.
Preciso detalhar qual o real interesse daquela demonstração, preciso mostrar qual minha projeção de atividade para justificar uma escolha e mostrar contrapontos.
Poucas coisas são absolutas!
Tudo DEPENDE… depende dessas coisas! Depende da clareza sobre os interesses, os impactos e os benefícios.
Banco em container que é um sacrilégio para um projeto, é uma perfeita solução para outra fase do mesmo projeto, ou é ideal para um projeto de outra magnitude. Em tecnologia poucas coisas são absolutamente boas ou absolutamente ruins. O contexto importa.
E no caso do eshop-CloudNative, com RabbitMQ e Postgres (em breve outros componentes também) em cluster, eu quero mostrar como, você vai lidar, no asp.net com conexões diferentes para escrita e leitura em seus repositórios, como com RabbitMQ você lida com workers e masters em um afila do tipo Quorum. Eu quero tombar uma instância inteira do Kubernetes e mostrar como a aplicação com RabbitMQ não perde mensagem, como o cluster se reorganiza para conseguir continuar reprocessando as mensagens e continuar as atividades do dia-a-dia do cluster, porque eu estou interessado na resiliência, e nas decisões de arquitetura que mudam seu código.
Do ponto de vista do deployment, dos componentes ou escolhas, eu já entreguei todas, ou ao menos todas que eu vejo, que impactam suas decisões.
Dessa forma, não tem bairrismo. A intenção é explorar o contraditório mesmo, é mostrar 2 formas de resolver o problema, quais os impactos de cada uma. Mostrar quando eu posso ser mais conservador, quando é possível ser menos conservador. Qual tipo de workload é um ofensor, qual não é e digerir prós e contras.
E ainda assim, nas lives de mentoria, surgem dúvidas.
Ainda no grupo privado, surgem dúvidas.
E isso é debatido, super de boa!
Porque você tende a achar que no seu caso, é especial, no seu caso, uma variável diferente, muda tudo. Talvez mude mesmo, mas na maioria das vezes não. Na maioria esmagadora das vezes você está dando atenção a um problema que só é problema na sua cabeça.
As vezes você quer resolver o que não precisa ser resolvido ou o que não faz sentido ser resolvido.
12 ) BONUS | Uma nova comunidade está nascendo
Na semana que vem eu falo sobre a comunidade que vai ajudar desenvolvedores de todos os níveis, com conteúdos mensais e dicas para resolver problemas comuns na formação de Juniors, Plenos e Seniors.
O objetivo primário dessa comunidade é servir de suporte para o desenvolvedor pleno que queira entrar no Cloud Native .NET mas se sente perdido com diversos assuntos dentro da formação.
O objetivo secundário é ajudar seniors que do Cloud Native .NET com boas práticas de codificação.
O terceiro e último objetivo é servir ao JR acelerando o processo de crescimento dele, independente do Cloud Native .NET.
Se é sua primeira vez por aqui, conheça o eShop Cloud Native, o projeto final da fase 3 do Cloud Native .NET
Te vejo do lado de dentro! Grande abraço!
0 comentários