Todos os dias usamos os grupos técnicos para perguntar: Como fazer X, como fazer Y.

Mas você já se perguntou se fazer X ou Y está certo?

Por que um curso de arquitetura?

Por que falar de arquitetura?

Arquitetura de Software ou Arquitetura de Solução?

Será que isso faz sentido para a minha carreira?

Identidade

Vamos supor que você queira autenticar seus usuários, naturalmente surge a pergunta: “Como criar uma senha segura?”

Mas será que lidar com senhas, na mão, é ideal? Será que essa abordagem não esconde questões de segurança sérias?

Mas aí você pensou: – Nossa: Muito trabalho adotar um Identity Server ou Keycloak para isso, deixa eu fazer um codigozinho aqui para…

Performance

Memory Cache em Web Farm/Web Garden

Você percebe a oportunidade de adotar o MemoryCache para melhorar sua performance. Em seus testes tudo funciona perfeitamente. Mas ao colocar em produção, em um cenário de cluster, começa o caos! Sim, você não previu o dilema de trabalhar com múltiplas instâncias da sua aplicação.

Latência de Cache Distribuído

Você resolveu usar um cache distribuído, como redis, ou state server e agora começou a sofrer com latência de rede, porque faz dezenas de operações de rede a todo request. Bad Idea!

Falta de Lock no Cache

Ou então percebeu que nos momentos de limpeza ou invalidação em massa no cache, operações simultâneas geram uma enxurrada de acessos a banco.

Como você está usando cache, que melhora substancialmente sua capacidade de atender grandes cargas de trabalho, durante esses momentos, sua aplicação ou seu banco chegam a cair, porque o dimensionamento do que está atrás do cache, só suporta a carga de trabalho por causa do cache.

Workflow de Lock errado

O cache é esvaziado e de repente 2 instâncias acabam executando a mesma obtenção de dados do banco para popular o cache. Você adota o lock, mas ignora que quando você é barrado pelo lock, precisa revalidar o estado antes de prosseguir.

Pronto, sua aplicação começa se comportar como um vírus para sua infraestrutura.

Proxy Reverso e Performance

Você ouviu falar de proxy reverso, mas fica com medo de um proxy reverso gerar perda de performance.

Proxy Reverso e Docker

Você não entende porque docker está tão alinhado com o conceito de proxy reverso.

Cache

Você ouve falar de serviços como Akamai, Azure CDN, mas não faz ideia de como esses serviços podem salvar sua pele no final do dia. E não sabe como eles podem te fazer economizar milhares de dólares dependendo do tipo de aplicação e conteúdo.

API Gateway

Você pode ter ouvido falar, mas acredita que ter um API Gateway pode ser um problema para sua performance, ou acredita que ele não tem função na sua arquitetura.

Mensageria

Você ouve o Gago falando de mensageria em algum lugar, acha legal. E tenta fazer.

Será que você está sendo resiliente?

RabbitMQ não traz resiliência só por instalá-lo e usá-lo. Há técnica e configuração para isso. Configuração na criação de objetos, na publicação de mensagens e no consumo. Não é default!

Mas aí você descobriu aqui no blog que existe a possibilidade de trabalhar com RPC. Achou uma boa ideia. Então seu backend caiu e pronto. Cadê a resiliência? Seu cliente ficou esperando uma mensagem de resposta que nunca virá!

Ou você tem uma demanda por uma sequencia de processamento e um pipeline resolveria, mas como lidar com esse tipo de complexidade?

Log

Talvez você esteja se perguntando sobre como usar o Enterprise Application Log, como implementá-lo em sua aplicação. Ótimo, mas também talvez você tenha feito da mesma forma como fazia. Enviando algumas mensagens para o Elastic que não servem para nada.

Docker

Você até hoje não entendeu nada de containers. Ou apenas usa para subir alguns servicinhos, como SQL Server, MySQL, talvez um redis, um RabbitMQ. Só.

Diz: Minhas aplicações não precisam de container.

Talvez não precisem mesmo!

Mas boas são as chances de você de fato sequer ter entendido o que é docker e porque docker é default ao ponto de ter seu setup presente no Visual Studio.

IIS

Talvez você ainda use o IIS e ache o máximo.

Talvez você diga: Ele resolve meus problemas!

---

A real

A real é que aqui no universo .NET, a gente sempre se manteve distante do que o resto das plataformas faziam. Nosso IIS, o AD, e o universo que a Microsoft criou ao redor do Windows nos possibilitou chegar à senioridade sem ter contato com muitos assuntos, muitos desses assuntos.

Isso é incrível, pois temos contato com um universo que se interconecta de forma fácil, de forma simples, e principalmente: De forma Intuitiva.

O poder de ser intuitivo

Com base em uma boa User Experience, e qualquer um que descordar que a experiência de uso do Windows (com mouse) é incrível para qualquer Sysadmin ou Usuário Avançado, como nós, desenvolvedores, qualquer um que descordar que essa experiência é boa, vive em outro planeta.

Isso faz com que sem estudar muito você consiga, tateando ir descobrindo comportamentos e funcionalidades sem necessariamente passar pelo estudo prévio dos fundamentos daquilo.

É uma faca de 2 gumes, sim, é. Mas isso é dar poder! Inquestionavelmente isso dá poder.

Mas a vida é uma caixinha de surpresas

O ponto é que cada vez mais lidamos com outras tecnologias, outras plataformas que inevitavelmente estão distantes do universo Microsoft. Python, Java, Javascript, Go, Rust. E do lado de lá, o mundo é muito diferente.

Do lado de fora o mundo é mais cru.

Você fala do que precisa ser feito e não da abstração que seu vendor criou. Se você precisa de 2 aplicações NodeJS no mesmo server trabalhando na mesma porta, precisa criar um proxy reverso pra isso. Em qualquer lugar, exceto aqui no universo Microsoft. O IIS abstraiu esse conceito e por diversas vezes encontramos o termo “port sharing” e “share port” na documentação Microsoft.

Compartilhamento de portas no windows é uma expressão que usam para simplificar a ideia de que há um proxy reverso genérico feito pela Microsoft. Só que para nós, dá a impressão que compartilhamento de portas entre processos e serviços diferentes é algo possível. Não é! Nunca foi. E tem a possibilidade de de fato nunca acontecer.

Esse é um detalhe. Um elemento que faz com que não enxerguemos coisas importantes quando chegamos ao mundo dos containers.

O show de Truman

No filme Truman vivia uma realidade construída ao seu redor desde o seu nascimento. Aqui não foi diferente. E quando nos deparamos com a realidade dos projetos lá fora, percebemos o quão diferente nós somos em relação “a eles”. E sim, por algum tempo nós pensamos que eles estão errados e que nós é que estamos certos.

Mas alguns loucos, como eu, resolveram atravessar o muro, ao mesmo tempo que a galera do lado de fora, veio pra cá. O mercado foi mesclando profissionais de diversas stacks e profissionais passaram a possuir diversas stacks.

Ficou mais fácil perceber que estávamos vivendo uma ilusão. Sem maldade, mas estávamos diante de um ecossistema provido pela Microsoft e aquilo era o que nos bastava.

Ao mesmo tempo isso não viabilizava a adoção de .NET em escala em projetos realmente significativos. Afinal, dos aplicativos que você usa hoje, quantos tem alguma parte do backend feito com .NET?

Lá fora o mundo Open Source fala de Identity Providers, caching, proxy reverso e diversos assuntos que estão ligados ao poder da plataforma. Subindo milhares de servidores, 100% automatizáveis via linha de comando.

E nós?

A virada

Essa mudança começa em 2006 com o PowerShell, depois em 2008 com o Windows Server 2008. O Windows Server Core é uma das primeiras iniciativas da Microsoft na simplificação do sistema operacional para um ambiente possivelmente gerenciado pela linha de comando.

Mais tarde mudamos do webforms para o MVC.

Depois veio o anúncio e lançamento do .NET Core.

Hoje culminamos no lançamento do .NET 6.

O backend aqui no universo Microsoft nunca mais será o mesmo. Estamos em franca expansão na direção da simplificação, na direção da redução da quantidade de código.

Mas sempre vamos usar mais componentes de terceiros, mais serviços como Redis, Elastic, Mongo, Kong, RabbitMQ, Kafka, Prometheus, OpenTelemetry, OpenFaaS, Dapr, Kubernetes, Keycloak, Docker e tantos outros, cada um para um problema.

Porque ficou tão complexo?

Porque precisamos

Microsserviços

Se você tem uma demanda por trabalhar microsserviços, há outros assuntos relevantes para você: Tracing, Logging, Monitoring… aqui podemos falar de umas 10 soluções diferentes. De Elastic a Prometheus, passando por OpenTelemetry entre outras.

Talvez você queira saber porque HTTP é desprivilegiado (não é a primeira opção) quando pensamos em Microsserviços. Porque gRPC e Amqp estão na frente quando se pensa em Microsserviços.

Bancos de dados compartilhados podem fazer parte do seu dia-a-dia, e você jura que existem microsserviços com bancos compartilhados.

Você sabe bem que está se enganando!

Você só não sabe responder perguntas que sua experiência com bancos compartilhados te dão automaticamente.

O que faz o arquiteto?

O arquiteto digere esses dilemas, experimenta, entende, para depois implementar, e posteriormente difundir. A forma profunda como ele vai entender esses dilemas e problemas, compreendendo a solução permitirá a ele criar restrições.

São as restrições, que dão a garantia de que os benefícios de uma arquitetura serão experimentados.

Não há uma boa arquitetura sem regras claras sobre o que NÃO PODE ser feito.

Conceber uma arquitetura sem regras claras do que não fazer, exige que você defina todo o resto sobre como deve ser feito, e em boa parte é isso que engessa o desenvolvimento.

Claro que existem concessões, e para essas concessões são necessários outros mecanismos, geralmente mais caros, para entregar o mesmo benefício. E no pior cenário, o cenário não tem os benefícios mesmo.

O mais importante é que um bom arquiteto é o motor de previsibilidade.

A consciência sobre os impactos de uma decisão técnica não precisa vir com a experiência. Nós não fomos à 1% dos planetas do nosso sistema solar, mas sabemos bastante sobre eles.

O que te espera do lado de dentro?

Cloud Native .NET

Fundamentos

Se você não é apaixonado por entender como as coisas funcionam, eu sinceramente não acredito que você será feliz aqui. Eu tenho muito cuidado e carinho ao fundamentar toda a jornada. Explicando muito mais do que uma tecnologia, eu vou no porque o fundamento por trás da tecnologia é relevante. E o que uma determinada tecnologia traz de a mais sobre o fundamento que é util em nossas arquiteturas.

Fill the gaps

Muitas vezes não é possível entender conceitos que estão ao nosso redor por falta de fundamentos. Falta de compreensão sobre DNS, sobre Proxy Reverso, sobre Rede vai te impedir ser um bom arquiteto.

Esses conceitos são tão infra certo? Errado! Não é possível ser um bom arquiteto sem saber esses 3 fundamentos, por exemplo. Você não vai saber tomar decisões simples de roteamento, de service discovery. Não vai entender como é possível conectar uma API em um banco de dados. No máximo vai aprender a receita de bolo, mas sem entender o que está disponível quando você entende a mecânica.

A jornada do arquiteto é uma jornada de descoberta sobre as coisas que estão ao nosso redor. Sobre o que diariamente somos usuários e nem nos damos conta. As aplicações que usamos interagem com o backend usando API Gateways, Identity Servers, Proxies reversos, Containers, Orquestradores, Cache Servers, foram implantadas usando CI/CD, possuem registry privados, kubernetes e muito mais.

As arquiteturas dos serviços que consumimos estão disponíveis para você criar seus próprios serviços. Claro que nem tudo faz sentido, mas no passado o custo era proibitivo, a necessidade de programar dentro de casa esses componentes era real, o que nos jogava para escanteio. Ou desenvolvíamos com a migalha de tempo que fazíamos sobrar, ou deixávamos para lá, ou fazíamos o que dava.

Hoje não, hoje o jogo virou e temos o poder profissionalizar cada área e cada recurso não funcional de nossas aplicações, e produzir serviços dezenas de vezes mais profissionais, mais escaláveis, mais resilientes e mais seguros e mais flexíveis.

É dessa jornada que tratamos aqui.

Live dia 11

Nos dias 11 e 12 as inscrições para o Docker Definitivo estarão abertas.

No dia 11, eu vou fazer uma live para falar do universo Cloud Native e as oportunidades de carreira para desenvolvedores e arquitetos .NET, culminando na apresentação do que é o Docker Definitivo com a oportunidade para participarem.

Inscreva-se abaixo para receber notificações sobre o Docker Definitivo.

Esse form te cadastra para as informações de oferta do Docker Definitivo.