É incrível ver que mesmo diante do dilema de uma mudança abrupta de rotina, o calendário de Releases do .NET 5 se manteve intacto. Temos uma mudança incrível na plataforma e enfim chegou o .NET 5!

O Release Candidate 2 do .NET 5 já é SUPORTADO EM PRODUÇÃO pela Microsoft.

Daniel Roth, Principal Program Manager, ASP.NET é categórico em sua publicação “ASP.NET Core updates in .NET 5 Release Candidate 2“:

São inúmeras novidades relevantes mas algumas eu gostaria de listar, principalmente por conta da sua importância.

Open API specification support on-by-default | Ter o schema de cada API por padrão é um benefício incrível para todos os projetos. E isso é fantástico! Ajuda no desenvolvimento. Já faz alguns anos que escrevi Contratos são garantias – JSON Schema e esse é um assunto muito relacionado. Um ponto importante é poder salvar os contratos e até poder gerar os clients. Isso é incrível e facilita a criação de um ecossistema API first.

O Suporte a HTTP2 no Kestrel. Embora HTTP3 já seja realidade, o suporte ao HTTP2 vem em boa hora, principalmente com a ideia de criar um proxy reverso .NET, como é o caso do YARP.

Outro ponto é que o kestrel ganha a habilidade de observar mudanças em suas configurações e ser capaz de refazer seus binginds sem necessitar de restart da aplicação.

Outros aspectos que me chamam a atenção sobre a nova versão está relacionado à logging.

Quem me conhece sabe que eu defendo que log em plain text é uma aberração. Logs precisam ser estruturados para poderem ser importados em alguma ferramenta que permita consolidação. Essa é a minha opinião, é radical, quase extremista.

Mas um aspecto que eu tratava até agora era que eu me permitia ferir um dos elementos do 12 factors, que previa que o log deveria ser obrigatoriamente produzido no stdout, ou seja via console. O que eu sempre achei um absurdo até os últimos 2 anos.

Já faz algum tempo que mudei minha config do NGINX para produzir logs em JSON, no output do console. Isso permitiu plugar serviços como o LogStash, para importar esse JSON para o elastic, que posteriormente é visualizado no Kibana.

Minha configuração fica mais ou menos assim:

http {
    include       mime.types;
    include       block_ips.conf;
    default_type  application/octet-stream;
    #client_body_in_file_only on; $request_body_file
    log_format  main  escape=json '{'
        ' "time": "$time_local",'
        ' "status": "$status",'                
        ' "http_x_real_ip": "$http_x_real_ip",'
        ' "realip_remote_addr": "$http_cf_connecting_ip",'
        ' "proxy_add_x_forwarded_for": "$proxy_add_x_forwarded_for",'
        ' "http_x_forwarded_for": "$http_x_forwarded_for",'        
        ' "remote_addr": "$remote_addr",'        
        ' "remote_user": "$remote_user",'
        ' "host": "$host",'
        ' "http_name":"$http_name",'
        ' "cookie_name":"$cookie_name",'
        ' "query_string":"$query_string",'
        ' "tcpinfo_rtt":"$tcpinfo_rtt",'

        ' "bytes_sent": $bytes_sent,'
        ' "body_bytes_sent": $body_bytes_sent,'
        ' "request_length": $request_length,'

        ' "http_x_assets_host": "$http_x_assets_host",'

        ' "http_cf-ipcountry": "$http_cf_ipcountry",'

        ' "request_body": "$request_body",'
        

        ' "request_time": $request_time,'
        ' "request": "$request", '        
        ' "http_header":"$http_header",'
        ' "http_referer": "$http_referer",'
        ' "http_user_agent": "$http_user_agent",'
        ' "remote_user": "$remote_user",'
        ' "server_name": "$server_name",'
        ' "http_range":"$http_range",'
        ' "connection":"$connection",'
        ' "connection_requests":"$connection_requests",'
        ' "upstream_addr":          "$upstream_addr",'
        ' "upstream_status":        "$upstream_status",'
        ' "upstream_header_time":   "$upstream_header_time",'
        ' "upstream_cache_status":  "$upstream_cache_status",'
        ' "upstream_connect_time":  "$upstream_connect_time",'
        ' "upstream_cookie_name":   "$upstream_cookie_name",'
        ' "upstream_response_time": "$upstream_response_time",'
        ' "msec": $msec'
        ' } ';

    
    access_log  /var/log/nginx/access.log  main;
    


    charset utf-8;
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	server_tokens off;
	log_not_found on;
	types_hash_max_size 2048;
	client_max_body_size 20M;

Já no LogStash, basta uma config besta como essa para que ele importe o output do NGINX direto para o Elastic. Como eu tratei o output para ser JSON, funciona perfeitamente.

  file {   
    path => "/docker/EntryPoint/logs/*.log"
    codec =>"json"
  }

Isso permite produzir um board assim:

Mas até então, para aplicações. Eu ainda tinha o pensamento de colocar alguma infraestrutura que publicasse as mensagens em uma fila. Em geral classes de suporte com algum tipo de inteligência para isso. E óbvio, isso fere um dos 12 fatores e acaba produzindo complexidade.

Mas eu sempre estive disposto a pagar por essa complexidade.

Com a chegada do Console Logger Formatter e JSON Console Logger, já começo a repensar que isso pode não estar mais preso à aplicação e sim ser algo genérico, como um container ou serviço que se vale desses formatters para publicar mensagens em filas ou até mesmo direto no backend.

Uma das coisas mais importantes é estruturar a mensagem de log com dados que sejam buscáveis e que, óbvio, façam sentido para o negócio e para um eventual troubleshooting. Em 2014 eu escrevi no texto Logs Estruturados exatamente essa decisão, e o porque dos logs serem mais complexos que uma simples string like a Response.Write/Response.End!

RBAC authorization with Kerberos authentication and LDAP on Linux

Essa foi uma das notícias que explodiu minha cabeça. Muita gente espera isso há pelo menos 10 anos. Esse tema endereça windows authentication no linux. E sinceramente eu não imaginava que sairia agora nessa versão.

Azure Active Directory authentication with Microsoft.Identity.Web

E para quem está pensando em sair do Identity Server 4, já que agora ele será pago, o Azure AD B2C é uma excelente alternativa. Mas eu vou falar muito mais de Keycloak!!!! Ok?!

Conclusão

Muitas novidades legais e aqui vão meus principais pontos que endereçam assuntos que eu já abordei e estou revisitando por conta das mudanças.

O Log em JSON é interessante mas pra mim a interface de log ILogger precisava evoluir para receber algo como um dicionário, enfim, algo que pudéssemos estruturar com os dados que queremos que estejam no log.

Sem isso, log em JSON no output é bonitinho mas pouco funcional. Só parece interessante, mas na real… não serve para muita coisa! Mas aí que entra o problema: Temos mais de 20 anos de aplicações e mais aplicações escrevendo log como texto simples. O que fazer?