Eu sou Diego Tondim.

Dicas de windows terminal para devs

E ai meus queridos, tudo bem?

Recentemente venho utilizando mais o windows terminal com ubuntu no meu dia a dia, basicamente todas as minhas ferramentas comuns de desenvolvimento estão no Windows Subsystem for Linux (WSL), entre elas posso citar aws cli, eksctl, kubectl, docker e git. Dito isto, posso afirmar que você vai percebendo a necessidade de customizar ou pelo menos deixar o terminal um pouco mais amigável e confortável para você trabalhar o dia inteiro, com isso venho compartilhar algumas dicas de mudanças que fiz para ajudar na produtividade.

Tema

É muito importante você encontrar o tema ideal para trabalhar o dia inteiro na linha de comando, os temas das ferramentas que utilizo normalmente são com fundos escuros e cores de letras em tom pastel, isso ajuda a cansar menos os olhos para a leitura, pelo menos no meu caso, para procurar o tema que se adapte melhor ao seu perfil procure nesse site as opções:

https://windowsterminalthemes.dev

Você pode escolher entre os temas existentes, verificar diferentes situações e como o tema se comporta:

Apos escolher o tema, basta clicar em “Get theme” e o site copia o tema para você colar nas configurações do terminal. Para isso, abra o windows terminal e use o atalho “ctrl+,” para editar o arquivo settings.json, encontre a seção “schemes” e cole o tema copiado anteriormente como abaixo:

Para aplicar o tema, encontre a seção “profiles” e altere o tema padrão para o tema que você escolheu:

Salve o arquivo e pronto, seu terminal já esta com o tema aplicado:

Você deve estar se perguntando porque o caminho das pastas no meu terminal estão diferentes, vou mostrar isso no próximo tópico.

Powerline + Git

Uma das ferramentas mais importantes durante o dia com certeza e o git, e normalmente você pode estar trabalhando em um projeto, alterou alguns arquivos, trocou de contexto e abriu outro projeto, e se torna útil no terminal ter uma ideia de onde você esta, qual branch, se alterou algo naquele projeto, para isso tem uma extensao usando powerline que pode trazer essas informações para você, para isso, basta executar os comandos abaixo:

sudo apt-get update

sudo apt-get install golang-go

go get -u github.com/justjanne/powerline

Logo ap ó s instalar o go e o powerline, precisamos adicionar o trecho de código que vai adicionar as informações ao terminal, para isso, digite os comandos abaixo:

cd ~

vim .bashrc

Logo que abrir o arquivo para edição, copie e cole o código abaixo em qualquer lugar:

function _update_ps1() {
    PS1="$($GOPATH/bin/powerline-go -error $? -jobs $(jobs -p | wc -l))"

    # Uncomment the following line to automatically clear errors after showing
    # them once. This not only clears the error for powerline-go, but also for
    # everything else you run in that shell. Don't enable this if you're not
    # sure this is what you want.
    
    #set "?"
}

if [ "$TERM" != "linux" ] && [ -f "$GOPATH/bin/powerline-go" ]; then
    PROMPT_COMMAND="_update_ps1; $PROMPT_COMMAND"
fi

Para salvar o arquivo basta pressionar ESC e digitar :wq + ENTER, feche e abra o terminal novamente e você deve ter algo similar:

Caso o terminal não exiba corretamente os símbolos do Powerline, recomendo baixar alguma fonte compatível, pode seguir as instruções aqui:

https://github.com/powerline/fonts

Para definir a nova fonte no terminal, basta editar o arquivo de settings.json novamente:

Defina a fontFace para o nome da fonte desejado e pronto, você poderá ver os ícones e símbolos utilizados pela extensão.

Outro detalhe na minha configuração, e a pasta padrão para abrir o terminal, definindo a propriedade “startingDirectory” você pode escolher por exemplo a pasta com os seus projetos do github para facilitar a navegação cada vez que abrir o terminal.

Por hoje era isso, acredito que essas dicas podem ser úteis para quem está começando a utilizar o windows terminal no dia a dia, abraço e até a próxima!

Porque eu preciso de um API Gateway?

E ai pessoal, tudo bem?

hoje vou falar um pouco sobre API Gateway pattern e a minha experiência recente com diferentes ferramentas e os benefícios a curto e longo prazo principalmente migrando de monolito para microservices.

Atualmente trabalho com um grande monolito, com alguns milhões de requisições por dia, toda a infraestrutura na AWS, monitoramento a nível de aplicação e a nível de infraestrutura, mas nem sempre o monitoramento de infraestrutura ou aplicação ajuda quando precisamos entender alguns cenários do dia a dia, como por exemplo comunicação entre aplicações.

As vezes a gente pode ter algum problema em um um serviço que é uma dependência da nossa aplicação, talvez vamos ver que as chamadas estão lentas no lado do app, mas a resposta está normal a nível de aplicação na dependência, ai você vai ao nível de infraestrutura e você vê nos Load Balancers que o trafego estava normal, ai você se pergunta, onde está o problema?

Pra começar, você precisou olhar em pelo menos dois lugares para entender o que poderia estar acontecendo, monitoramento da aplicação e monitoramento da infraestrutura. Com um API Gateway em frente das suas aplicações, você pode ter um único ponto de entrada para elas, sendo assim, consegue ter logs sobre todo o trafego dos clientes/consumidores para elas em um único lugar.

Utilizando um API Gateway você consegue ver detalhadamente as transações entre o seu cliente e as aplicação e também entre aplicações.

O API Gateway ainda tem muitas funções que podem ajudar em alguns desafios, como por exemplo certificado distribuído, controlar acesso aos endpoints por API Keys, Circuit Breakers, Timeouts, Retries, você consegue definir N configurações em um único lugar.

Agora vem a pergunta de ouro: Qual o melhor API Gateway? Bom, depende! sim, tudo depende do que você precisa e o quanto pretende investir em infraestrutura e também da curva de aprendizado além do objetivo que pretende atingir, mas aqui vão algumas das ferramentas que tive contato:

Ocelot (https://github.com/ThreeMammals/Ocelot): Open source, escrito em C#, você instala um pacote no seu app e basicamente adiciona as funções de um API Gateway, fácil de usar e para cenários onde por exemplo você quer começar a aplicar facades para quebrar a sua aplicação de microservices, pode ser um bom começo, ele ajuda a fazer um proxy simples entre apis, mas não seria a minha escolha como um API Gateway hoje.

Kong (https://konghq.com): Open source e também tem versão Enterprise, mas para começar com certeza a versão gratuita tem tudo que você precisa, logging, controle de acesso com api keys, rotas customizados, certificado centralizado, load balancer, retries, circuit breaker e muito mais, com certeza uma ferramenta completa, tem várias integrações e muitos plugins que adicionam ainda mais poder para essa ferramenta incrível.

AWS API Gateway (https://aws.amazon.com/pt/api-gateway/): Temos várias funções que vemos no Kong, porém você paga pelo recurso, é um pouco mais difícil, você fica preso a AWS, porém foi muito útil pra gente iniciar nesse mundo e fazer controle por API Keys e fazer um rate limiting de acessos de consumidores, um lado bom que você não precisa de recursos extras para monitoramento e integrações, pois está tudo disponível dentro da plataforma da AWS.

Por hoje era isso, em breve devo trazer mais detalhes sobre como aplicar o uso do Kong e também Ocelot com implementações reais, até a próxima!

O poder do HTTP/2

Fala meus queridos, belezinha?

Hoje vou falar um pouco sobre HTTP/2, sei que muita gente vem falando de gRPC e muitas vezes não explicam que o real poder do gRPC depende muito do HTTP/2 e vou demonstrar com alguns exemplos quantos benefícios você pode ter apenas migrando suas conexões HTTP/1.1 para HTTP/2 e vou começar contando uma história de um projeto que trabalhei recentemente.

Algumas semanas atrás estava trabalhando em um projeto onde temos dependências de outra aplicação e a comunicação é realizada através do protocolo HTTP utilizando o HttpClient em .net core e a aplicação roda em máquinas virtuais com linux. Após algum tempo rodando a aplicação em produção com uma boa carga, começamos a ter erros baixo nível do linux “Too many open files”, e com isso a aplicação caia. Tentamos várias soluções de configuração no HttpClient baseado neste artigo do Steve Gordon alterando o lifetime da conexão e também tentando limitar a quantidade de sockets por domínio, mas não parecia efetivo, e no fim para ter uma solução rápida acabamos limitando a quantidade de requisições por máquina nas políticas do auto scaling group. Com isso conseguimos evitar os problemas até achar uma solução melhor.

Após esse caso comecei a estudar a migração para gRPC, comecei a fazer vários testes para entender melhor como funcionava e os benefícios reais que teríamos migrando de protocolo e tendo que provavelmente implementar vários endpoints novos além dos clients, com isso cheguei na raíz do gRPC: O HTTP/2.

O HTTP/2 tem algumas diferenças importantes se comparado ao 1.1, abaixo as duas mais importantes pra mim:

1. Conexões simultâneas ou multiplexing: HTTP/1.1 apenas consegue realizar a conexão de um recurso por vez, enquanto HTTP/2 pode fazer várias requisições diferentes na mesma conexão, na imagem abaixo fica mais claro.

2. Formato binário: HTTP/1.1 trafega plain text o que facilita para entender e implementar, porém tem um payload normalmente maior, com o binário conseguimos um tempo menor e também menos dados sendo trafegados.

Após entender isso, verifiquei que talvez seria possível reduzir a quantidade de sockets consumidos apenas migrando para HTTP/2 ao invés de gRPC.

Como o projeto era em .net core, basta definir a versão na mensagem conforme o exemplo abaixo:

var client = new HttpClient();
var req = new HttpRequestMessage(HttpMethod.Get, "https://google.com"){
             Version = new Version(2, 0)
             };
var x = await client.SendAsync(req);
var version = x.Version;

Console.WriteLine(version);

Se na resposta o header for 2.0, sucesso, o servidor que você está chamando tem suporte, caso contrário, será necessário configurar o servidor para expor o endpoint como HTTP/2, no meu caso a aplicação estava na AWS e o ALB automaticamente expõe o endpoint com suporte para HTTP/2, então basicamente uma linha de código trouxe resultados incríveis, com redução para até 30% do consumo de sockets comparado ao 1.1, com isso fomos capaz de aumentar novamente a capacidade de processamento por máquina sem tomar erro do linux por falta de sockets. Abaixo seguem alguns testes feitos localmente com um código em .net onde disparo 200 conexões para o google com ambas versões do protocolo e verifico no windows 10 quantas conexões realmente foram abertas.

HTTP/1.1

Código:

var client = new HttpClient();
var actions = new List<Action>();

for (int i = 0; i < 200; i++)
{
	actions.Add(() =>
	{
		var req = new HttpRequestMessage(HttpMethod.Get, "https://google.com")
		{
			Version = new Version(1, 1)
		};
		var x = client.SendAsync(req).Result;
		var version = x.Version;

		Console.WriteLine(version);
	});
}

Parallel.Invoke(actions.ToArray());
Console.ReadKey();

Resultados:

HTTP/2

Código:

var client = new HttpClient();
var actions = new List<Action>();

for (int i = 0; i < 200; i++)
{
	actions.Add(() =>
	{
		var req = new HttpRequestMessage(HttpMethod.Get, "https://google.com")
		{
			Version = new Version(2, 0)
		};
		var x = client.SendAsync(req).Result;
		var version = x.Version;

		Console.WriteLine(version);
	});
}

Parallel.Invoke(actions.ToArray());
Console.ReadKey();

Resultados:

Script que utilizei para verificar as conexões por processo:

$netstat = netstat -aon | Select-String -pattern "(TCP|UDP)"
$processList = Get-Process

foreach ($result in $netstat) {
    $splitArray = $result -split " "
    $procID = $splitArray[$splitArray.length – 1]
    $processName = $processList | Where-Object {$_.id -eq $procID} |    
    select processname
    $splitArray[$splitArray.length – 1] = $procID + " " +      
    $processName.processname
    $splitArray -join " "
 }

Como podemos ver, com HTTP/2 foi possível utilizar apenas 2 conexões para executar 200 requisições, enquanto com HTTP/1.1 foram criadas 18 conexões, o gerenciamento das conexões o próprio HttpClient que faz, mas normalmente no caso do HTTP/2 é possível ver a diferença enorme na quantidade de conexões, isso provavelmente vai trazer muitos benefícios para a sua aplicação caso tenha dependências de recursos onde o meio de comunicação é HTTP.

Mais detalhes sobre HTTP/2 nesse artigo.

Por hoje era isso, até a próxima!