É com muita felicidade e um frio na barriga que anuncio as mudanças para 2022 aqui no gaGO.io. A principal mudança por hora é o rebranding do Docker Definitivo que passa a se chamar Cloud Native .NET é só uma mudança no nome, mas significa muito no que ele transmite.

Desde 2019 até agora construímos muita coisa do lado de cá, e encaro como a profissionalização de uma paixão: ajudar desenvolvedores! Ver a transformação no dia-a-dia dos alunos é surreal. É empolgante, é intenso, é inesquecível.

Tem arquiteto que concebeu e reestruturou software que ajudou com a vacina, em plena pandemia, teve gente nova que queria se realocar, gente já não tão nova assim mas que precisava entender esse ecossistema de containers, aplicações distribuídas, mensageria, caching, proxy e uma infinidade de assuntos que estão ao redor do universo Cloud Native simplesmente para se reposicionar no mercado novamente, após décadas empreendendo.

Sabe, há muito tempo eu me queria dar um significado ao trabalho. Algo em que eu pudesse sentir prazer em fazer e ao mesmo tempo sentir que faz sentido. Eu queria conseguir ver, com meus olhos, o resultado. O impacto. E está sendo incrível.

E hoje eu posso dizer: Estou muito, mas muito feliz com o trabalho realizado.

Aqui dentro eu vi alguns Devs que conseguiram seus primeiros Jobs como arquitetos. Vi Devs virando Líderes técnicos. Vi Arquitetos que usou o curso para evoluir seus skills. Cada um ao seu modo, cada um no seu tempo.

Mas independente do título ou cargo:

São pessoas, são ao menos ~310 profissionais que entraram e a maioria esmagadora, deu certo!

Maioria? Sim, há os engavetadores de curso, são compradores compulsivos de cursos. Para uma fração não precisa nem assistir as aulas, só o ato de passar o cartão já faz com que eu brote magicamente na mesa deles e como eum passe de mágica eu sussurro no ouvido o passo-a-passo. Óbvio que isso não acontece, mas é um estereótipo engraçado. Há quem comprou e não lembra, há quem comprou e vai assistir ainda, só falta tempo.

Fato que o universo Cloud Native é quase ostentação para muita empresa pequena, mas é a realidade de muitas outras. Veja o landscape da CNCF por exemplo:

Cada iconezinho desses é um projeto, com uma finalidade, com uma equipe, com uma história, com um viés.

Mas calma, a gente não conhece isso tudo e não precisa conhecer essa lista toda.

Nosso subset é bem menor, apenas com os mais relevantes.

Mas afinal, o que é Cloud Native?

Segundo a CNCF (Cloud Native Compute Fundation):

As tecnologias Cloud Native capacitam as organizações a criar e executar aplicações escaláveis ​​em ambientes modernos e dinâmicos, como nuvens públicas, privadas e híbridas. Containers, service meshes, microservices, infraestrutura imutável e APIs declarativas exemplificam essa abordagem.

Essas técnicas permitem sistemas fracamente acoplados que são resilientes, gerenciáveis ​​e observáveis. Combinados com robustas automações, eles permitem que os engenheiros façam alterações de alto impacto com frequência e previsibilidade com o mínimo de trabalho.

github.com/cncf/foundation/blob/main/charter.md

A Microsoft também fala de Cloud Native no docs.microsoft.com.

docs.microsoft.com/pt-br/dotnet/architecture/cloud-native/introduction

Há dezenas de implicações quando a gente fala de aplicações fracamente acopladas, resilientes, gerenciáveis e observáveis. Mas entendo que esse é o mínimo que monolitos e microsserviços precisam ser.

Embora exista um apego ao termo microsserviço, não acho conteúdo exclusivo para esse tipo de aplicação. Tanto monolitos quanto microsserviços podem ser resilientes, gerenciáveis e observáveis, e também podem estar em containers rodando em alguma cloud ou em um simples e modesto VPS.

Tudo depende de quem é o cliente, quem é o time, quais são seus dilemas.

Uma grande montanha de dinheiro está em empresas que pensam quase que exclusivamente em microsserviços, por seu tamanho. No entanto outra montanha de dinheiro está pulverizada em empresas pequenas, que também precisam de software, que também não são capazes de lidar com a complexidade de microsserviços, não me parece justo?

Hoje os desenvolvedores estão inseridos em bolhas, fazendo mais ou menos os mesmos tipos de projetos, tendo contato com os mesmos tipos de gambiarras e boas soluções. O que podemos fazer para melhorar isso?

Eu convoco qualquer um a tentar fazer melhor e mais profissional do que está sendo feito hoje.

Independendo do cargo, profissão ou status.

Sempre haverá formas de evoluir.

Nosso mercado de tecnologia se profissionalizou. Soluções comuns e demandas que no passado se resolviam com simples tabelinhas, hoje são encaradas como anti-patterns e gambiarras.

Hoje temos a obrigação de primeiro buscar soluções de mercado para nossos problemas, avaliando os benefícios e perdas de cada uma das soluções que adotamos. Ao preço de sermos julgados por jogar dinheiro fora reinventando rodas.

Rodas Quadradas!

Rodas quadradas são aquelas que não rodam bem. Elas são idealizadas com base em uma roda redonda, mas no final das contas era melhor não ter. Elas rodam mal. Uma roda quadrada é uma versão amadora de uma roda redonda. É uma versão que precisará de uso extremo para amadurecer e perder seus cantos pontudos, dando lugar a de fato uma roda redonda, lapidada pela jornada de maturidade.

É sobre essa busca incessante e incansável de tentar produzir um mercado melhor, onde a única chance do dev ficar estagnado seja por desejo pessoal, não por um punhado de infelizes coincidências.

Eu encaro Cloud Native como uma visão de mundo, uma visão onde você pode produzir projetos profissionais, que são mais previsíveis e eficientes.

Mas afinal o que é o Cloud Native .NET?

É um curso, para levar Desenvolvedores, Lider Técnicos e Arquitetos ao universo Cloud Native, é uma comunidade, com acompanhamento.

Cloud Native é o termo que batiza esse desenho de solução pautado em microsserviços rodando sob containers, em um desenho de infraestrutura imutável, projetados para serem escaláveis, resilientes, gerenciáveis e observáveis e rodar em nuvens públicas , nuvens privadas e nuvens híbridas.

Se você é daqueles que leu apenas “Microsserviços e Containers” e já pulou fora… lamento te informar, não é para você.

Há implicações absurdas nessa singela sentença de mais ou menos 200 caracteres.

Se estamos falando de rodar em nuvens públicas (leia-se cloud), nuvens privadas (leia-se cloud e IaaS on premise) e nuvens híbridas, estamos falando de um desenho que opera independente da cloud mas trabalha em qualquer cloud.

Se estamos pensando nesse tipo de solução, rpecisa

E note, nenhuma das 3 possibilidades é facultativa aqui.

Estamos falando de algo que rode em qualquer lugar.

---

Uma nuvem híbrida é um tipo de computação em nuvem que combina infraestrutura local — ou uma nuvem privada — com uma nuvem pública. Nuvens híbridas permitem que dados e aplicativos se movam entre os dois ambientes.

–

Muitas organizações escolhem uma abordagem de nuvem híbrida devido a imperativos de negócios, como atender aos requisitos regulatórios e de soberania de dados, aproveitar ao máximo o investimento em tecnologia local ou resolver problemas de baixa latência.

–

A nuvem híbrida está evoluindo para incluir também cargas de trabalho de borda. A computação de borda traz o poder de computação da nuvem para dispositivos IoT – mais perto de onde os dados residem. Ao mover as cargas de trabalho para a borda, os dispositivos gastam menos tempo se comunicando com a nuvem, reduzindo a latência e podem até operar de forma confiável em longos períodos offline.

azure.microsoft.com/en-us/overview/what-are-private-public-hybrid-clouds/

---

A nuvem híbrida é uma arquitetura de TI que incorpora algum nível de portabilidade, orquestração e gerenciamento de cargas de trabalho entre dois ou mais ambientes. Dependendo de quem fala, esses ambientes precisam incluir:

🔹No mínimo, uma nuvem privada e uma nuvem pública

🔹Duas ou mais nuvens privadas

🔹Duas ou mais nuvens públicas

🔹Um ambiente virtual ou bare-metal conectado a, no mínimo, uma nuvem pública ou privada

www.redhat.com/pt-br/topics/cloud-computing/what-is-hybrid-cloud

---

Se estamos falando em microsserviços em containers com escalabilidade, resiliência, gerenciabilidade e observabilidade, estamos indo muito além de alguns logs aqui ou acolá, muito além de algumas API’s. Estamos falando de um outro patamar na forma de gerenciar aplicações e seu ciclo de vida. Estamos falando de monitoramento, tracing, telemetria e total compreensão de como cada instância de cada serviço está rodando, onde está rodando e o que está fazendo… momento a momento.

Se estamos falando de baixo acoplamento, resiliência, e alta disponibilidade, estamos falando desacoplamento físico, protocolos resilientes, assincronismo.

Mas também estamos falando de standards, protocolos e serviços de mercado para promover o reaproveitamento de serviços e principalmente, o reaproveitamento de esforço, tempo e dinheiro. Estamos falando de construir menos e reaproveitar mais.

É aqui que você encontra uma proposta completamente diferente de forma de desenhar soluções.

E é aqui que entra o Cloud Native .NET.

Só que não basta fazer um desenho…

No power point ou whiteboard é fácil!

Você precisa lidar com cada minúsculo elemento desse desenho, desde como as mensagens são trafegadas serviço-a-serviço, quais tecnologias usar para resolver quais problemas, quais produtos e ferramentas usar, quais patterns e estratégias técnicas adotar.

Como resolvemos isso aqui do lado de dentro?

Linux e Containers

A primeira questão é sanar o básico: Linux e Containers. Nós precisamos não só usar Docker para subir aplicações de terceiros, precisamos aprender a criar nossas próprias imagens, empacotar e rodar nossas aplicações em containers, as vezes até empacotar aplicações de terceiros. É nosso papel fazer troubleshooting em containers, afinal nossas aplicações estão rodando neles.

Uma vez que você sabe empacotar sua aplicação como uma imagem e rodá-la com um container, podendo até debugar esse container, estamos prontos para começar a trabalhar e ver arquiteturas, problemas, soluções.

Cache e Lock distribuídos

Nesse momento você está pronto para começar a adicionar alguma complexidade aos seus projetos. E começamos com caching e lock distribuído.

São assuntos comuns, que começam a ficar evidentes quando se pensa em aplicações que precisam escalar, concorrer e processar assincronamente.

O caching de um lado e lock, são fundamentais para enriquecer enriquecer o repertório do desenvolvedor. Principalmente quando falamos em aplicações escaláveis e/ou aplicações distribuídas no geral.

Os medos que permeiam aplicações distribuídas começam a ser sanados antes mesmos de começar a falar delas. Cache e lock, são ferramentas poderosas para evitar aberrações no uso de mensageria e processamento assíncrono.

Message Broker

Quando começamos a falar de aplicações distribuídas conversando entre si usando mensageria, e alguns dos medos comuns deixam de existir. Isso ocorre porque conhecemos padrões e implementações, e comportamentos e entendemos como sanar as mais variadas necessidades desse tipo de solução.

Quando entramos no principal e mais usado Message Broker do mercado, o RabbitMQ, vemos como construir o pilar de uma arquitetura que entrega disponibilidade, eficiência, resiliência, confiabilidade e escalabilidade. Então conseguimos endereçar, com uma só solução, e diversos padrões, muitos aspectos que fazem parte da complexidade de trabalhar com aplicações distribuídas. Sejam elas microsserviços ou qualquer outra coisa.

Entendemos a necessidade de coordenar não só o RabbitMQ, mas o Redis, e entendemos como dividir responsabilidades entre os dois. De um lado a distribuição da carga de trabalho, do outro Lock e Cache distribuídos.

Como resultado temos os assuntos mais disruptivos sanados, e é hora de ver esse ecossistema colaborando.

Mas ela traz consigo outras questões que vão se beneficiar do resto do ecossistema, como Redis para cache e lock distribuídos.

Dessa forma conseguimos não só entregar os 5 big benefícios, mas também resolvemos e aparamos as arestas da complexidade e da resolução de casos de uso, e questões de negócio nesse novo desenho de solução.

Outras tecnologias

Além disso vemos outras tecnologias que casam com essa visão agnóstica de um lado, multicloud de outro. Vemos o caos em termos de quantidade de filas em um pipeline de 6 etapas, com Redis, Minio, MongoDB, RabbitMQ, .NET, que ajuda a demonstrar como isso ocorre de fato em produção.

Agora que vimos esse ecossistema funcionando, bora falar de observabilidade e mostrar como usar soluções como o Enterprise Application Log e outras alternativas para isso. Ele conta com:

• ElasticSearch
• LogStash
• Kibana
• MetricBeat
• HeartBeat
• RabbitMQ
• ElasticHQ
• Elastic APM

E aqui vemos como esses serviços headless que construímos são monitorados, no detalhe. Agora em fevereiro de 2022, estou trabalhando na visão de Open Telemetry para trazer para o curso, e já falei de Event Driven Architecture em uma live de quase 2 horas.

Com esse hard skill entregue no curso, começam as dúvidas de arquitetura, e é aqui que a coisa muda de figura. Começam a aparecer as dúvidas interessantes. Dúvidas sobre cardinalidade de filas, resiliência, decisões técnicas. Dúvidas sobre estratégias de deployment.

E completamos a jornada com CI/CD, projeto de demonstração e conclusão de curso, além de Kubernetes do zero para aprendermos a colocar esse ecossistema no ar de forma consistente.

Outras tecnologias

Nessa jornada eu não espero que você tenha nenhum conhecimento sobre Linux, Containers, Microsserviços e Aplicações distribuídas, você pode talvez sequer ter ouvido falar, embora seja quase absurdo não ter escutado.

A ideia é sob a senioridade de um desenvolvedor .NET, que possamos construir tijolo-a-tijolo todo o alicerce, toda a fundamentação para que você os primeiros passos dessa jornada.

Nossa “catedral do conhecimento” começa de fundações como Linux e Containers. Nós vamos configurar seu windows, subir um Linux, instalar o windows terminal, configurar putty logo nos primeiros 4 dias.

No dia 5 nós apagamos a VM que criamos no módulo anterior e passamos a trabalhar 100% no Windows com WSL2.

E se você acha que “não precisa” ou que “dev só precisa codificar”, olha o que o Lucas Leme disse:

No dia 5 abandonamos a VM e partimos para o Docker Desktop onde vamos aprender sobre containers. E do dia 5 ao dia 25 percorremos todos os fundamentos de Containers, Imagens, Volumes e Network. Tudo que você precisa saber sobre esse início de jornada para estar apto a trabalhar com containers.

O que você aprende aqui, nesses poucos dias já pode ter servir, como aconteceu com o Bruno Lima:

Aqui temos a fundação, o entendimento do que é necessário para que mais tarde seja mais fácil você compreender como Kubernetes, Swarm e qualquer orquestrador funciona.

De um lado busco o conhecimento que você já tem de .NETY, Windows, IIS e e todo o universo Microsoft, com o objetivo de comparar, contrastar, mostrar as diferenças. Por isso eu preciso de certa senioridade, eu preciso da memória sobre cases, problemas, situações.

O Lucas Sheid conta como essa estruturação ajuda no dia-a-dia:

Durante sua jornada de aprendizado aqui comigo você é acompanhado em um grupo do telegram exclusivo para alunos que conta com gente feita do mesmo DNA que você, uma galera motivada que quer aprender mais e que tem as mesmas dúvidas ou já passou por elas, e está no meio desse mesmo turbilhão de informação e conteúdo desconexo.

Aqui organizamos isso.

Eu criei um site novo, detalhando quais são as aulas os conteúdos a duração.

cloudnative.net.br

A primeira turma sob o novo nome já está rodando, a gente fez uma iniciativa em Janeiro/2022, até para avaliar e garantir que cada pedacinho que referenciava Docker Definitivo está devidamente com o nome alterado.