Estamos no último dia do Microsoft Build e sem sombra de dúvidas o maior lançamento dessa edição é o .NET ASPIRE.
É hora de falar tudo que você precisa saber sobre a história recente que nos remete à criação do projeto e suas ambições.
A conta não fecha
Conforme havíamos sinalizado em 2022, com a análise dos reports tanto da CNCF quanto DataDog, o desenvolvimento Cloud Native precisava de novas abstrações que simplificassem a jornada Cloud Native.
Se de um lado empresas não conseguiam profissionais, de outro, profissionais não conseguiam adquirir as skills necessárias para colocar aplicações Cloud Native no ar com o mínimo necessário.
O problema?
A jornada é complexa e extensa demais!
O dilema da lucratividade da Docker Inc
Como se não bastassem esses problemas, a Docker Inc, com a necessidade de se provar para os investidores e gerar lucro, toma algumas decisões importantes:
Em 2017 a Docker Inc resolve separar seu container runtime, criando o Containerd. O projeto é doado à CNCF como um projeto Open Source. Isso tira a atenção de sua equipe e remove boa parte da demanda da empresa para cuidar de algo que não gerava receita. Saiba mais
Em 2019 a Docker Inc perde seu CEO Steve Singh e logo em seguida vende a divisão Docker Enterprise para a Mirantis, além de realizar uma demissão em massa, saindo de 400 funcionários para 60. Saiba mais
Em 2020 a Docker Inc notifica que não dará mais suporte ao DockerShim, componente que permitia usar o Docker como container runtime do Kubernetes. O mercado entra em desespero equivocadamente, já que esse movimento começou em 2017 com a criação do Containerd. Era mais que esperado esse corte do cordão umbilical com o Kubernetes, tornando imediatamente o Containerd (que era parte do código do docker), seu substituto Saiba mais. Há anos o Containerd já é apontado como container runtime mais usado no Kubernetes.
Caso esse link pare de funcionar ou aponte para a versão errada do report, comente.
Em 2021 a Docker Inc faz um post em seu blog informando que no ano seguinte o Docker Desktop exigirá uma assinatura, apontando que a gratuidade do docker desktop acabava para empresas que não atendessem certas condições. Essa mudança também impactaria o docker hub. Saiba mais
A mudança no licenciamento do Docker Desktop afeta diretamente a comunidade .NET onde empresas que possuem workloads .NET e usam containers são afetadas, já que a integração do Visual Studio com Docker acontece via Docker Desktop e não diretamente operando o dockerd.
Recebi muitos relatos, muitos mesmo, de empresas que aboliram o uso do Docker Desktop devido ao licenciamento. Embora não fosse caro, a burocracia para se conseguir esse aval afetou muita gente por aqui.
Em resposta, a comunidade lança a versão v1.0.0 PODMAN em JAN/2019, e hoje o projeto está na sua v5.0.3, segundo seu repositório no github.
As respostas da Microsoft
A Microsoft respondeu a esse cenário com várias iniciativas:
- Assumindo a hospedagem de imagens de seus produtos no Azure Container Registry, deixando no Docker Hub apenas apontamentos e links.
- Novas ofertas do Azure
- Criação de novas ofertas sob o Kubernetes:
- Criação dos Projetos
Assim chegamos até aqui.
O que é o .NET ASPIRE?
1 ) ORQUESTRADOR (apenas para desenvolvimento)
No ambiente local de desenvolvimento, ele assume o papel do Docker Compose. Ele orquestra a subida das nossas aplicações e dos containers auxiliares.
Esse é um componente que não tem função em produção, ele não é implantado. Você desenvolve com ASPIRE e implanta em diversos lugares.
Mas embora não seja implantado, ele fornece informações sobre como implantar, e isso ajuda na hora de criar modelos para implantar em diversos lugares possíveis.
O mais comum e esperado é o AKS ou qualquer instância Kubernetes.
Mas seria hipoteticamente possível também implantar parte no Azure App Services, parte no Azure Container Apps, parte no Azure Container Instances, ficando a gosto do freguês, escolhendo cada uma das ofertas, componente-a-componente da sua stack.
2 ) Componentes
Aqui temos o setup otimizado dos componentes de infraestrutura nas nossas aplicações. Aquilo que usamos Program.cs e injetamos no ServiceCollection, ele faz por nós de forma não só simplificada, mas principalmente com observabilidade.
Um dos problemas que encontramos nas aplicações .NET feitas por profissionais sem experiência com orquestração é a incapacidade da aplicação esperar os serviços estarem disponíveis para somente então começar a rodar.
Isso gera alarmes desnecessários e alertas de observabilidade que não refletem a realidade. No final do dia, logs inúteis que precisamos ignorar.
Isso é peculiarmente problemático quando somente as aplicações .NET possuem esse comportamento.
Os componentes do .NET ASPIRE interagem com a infraestrutura do .NET fazendo com que métricas dos recursos que consumimos sejam armazenadas.
Também ganhamos um recurso incrível, que são as configurações básicas de resiliência.
Extensões dedicadas à retry, por exemplo, encapsulam o uso de Polly simplificando a jornada de resiliência, além de propagar parâmetros de observabilidade para assegurar que tenhamos um rastro entre o fluxo entre serviços.
Além disso, temos a implementação do OpenTelemetry que permite que o próprio ASP.NET envie nossa telemetria para endpoints OTLP (OpenTelemetry Protocol).
Por fim, a cereja do bolo é a capacidade de escolhermos o Container Runtime, podendo trocar de Docker para Podman.
3 ) Dashboard
Anunciado originalmente como uma ferramenta apenas de desenvolvimento, assim como o orquestrador, nesse lançamento durante o Microsoft Build o anúncio sinalizou que o dashboard é um dashboard pronto para produção.
Se você acompanhou o desenvolvimento do eShop Cloud Native, deve ter visto que empacamos no problema da necessidade de hardware absurdo para exemplificar um cenário minimamente decente de microsserviços.
Isso porque precisávamos de 3 elefantes para rodar nossa aplicação:
- Elastic
- LogStash
- Kibana
Independente do seu cenário, e da sua implementação de stack de observabilidade, sempre foi um desafio ter essa stack nas máquinas de desenvolvimento.
Isso porque são componentes pesados que demandam muito recurso e não são projetados para ambiente de desenvolvimento.
Do ponto de vista de arquitetura, ignorar esses componentes na sua stack de desenvolvimento gera um canto cego para o desenvolvedor, que não enxerga com clareza suas métricas, portanto sequer poderia ser devidamente cobrado por números que ele mesmo desconhece.
Então é uma prática comum criar ambientes de desenvolvimento, servidores de métricas compartilhados, para viabilizar que cada um consiga ver suas próprias métricas, sem pesar a máquina de desenvolvimento.
O problema é que isso só é possível em determinados tipos de empresa em que possuem esses servidores não produtivos. E justificar a existência desses servidores sempre foi difícil.
O natural nos projetos mais robustos é eventualmente embarcar esses componentes nos nossos projetos, mas o preço é essa família de elefantes na sala. Seja com Elastic LogStash e Kibana, seja com o OpenSearch e LogStash e OpenSearch Dashboard ou com Grafana, Loki, Prometheus e afins.
O dashboard resolve esse problema, e já falamos dele no post de primeiras impressões e .NET ASPIRE Dashboard Standalone como Container.
Conclusão
O .NET ASPIRE é mais uma das respostas para a situação incômoda que o mercado se encontra.
Seja pela dificuldade de profissionais especializados, de um lado, somada à dificuldade de formar esses profissionais.
Ao mesmo tempo, tornar o jovem, Júnior e Pleno aptos a trabalharem em projetos Cloud Native reduz a distância entre esse perfil e esse tipo de projeto, reduzindo drasticamente a dificuldade de contratação.
Será que ainda precisamos aprender:
- Docker
- Docker Compose
- Kubernetes
- Stacks de observabilidade como:
- LGTM ( Loki – para logs, Grafana – para visualização, Tempo – para traces e Mimir – para métricas)
- ELK ( ElasticSearch para armazenamento, LogStash – para ingestão e Kibana – para visualização)
??????????
Embora essa seja uma pergunta que somente o tempo dirá, eu acredito que:
Um dev não precisará aprender nada disso para ser produtivo.
Mas acredito que, quem dominar essa complexidade estará muito na frente dos demais. Essas pessoas definirão as arquiteturas, definirão as regras, e a forma como o primeiro grupo trabalhará.
Com esse conhecimento e essa capacidade de tomada de decisão, ganharão bem mais que o primeiro grupo.
É nisso que acredito!
0 comentários