Em outubro de 2021, começamos a notar um aumento significativo no tempo de resposta desse serviço. Ligamos o farol amarelo em nossos monitoramentos e acompanhamos de perto para entender o motivo desse aumento (para ver se não era algo pontual). No entanto continuou com uma certa constância, até que em fevereiro de 2022 isso começou a onerar nosso SLI de disponibilidade.

Nesse meio tempo iniciamos uma Design Doc com o objetivo de propor uma solução que reduzisse significativamente o tempo de resposta. Isso porque quanto mais rápido esse serviço fosse, mais percepção de valor nosso cliente teria do produto — afinal, essa lentidão gerava muito contact rate (indicador de negócio e termômetro da experiência do cliente).

Após o levantamento e análise do contexto geral, elencamos alguns ofensores:

1. Arquitetura não escalável;
2. Ausência de uma estratégia eficiente de cache;
3. Não tolerante a falhas;
4. Linguagem de programação.

1. Arquitetura não escalável

A falta de planejamento e tempo hábil para criar uma arquitetura evolutiva, que suportasse o crescimento do negócio ao longo do tempo, foi o primeiro sintoma que emergiu. Notamos também que era necessário entender mais a fundo aquele domínio de negócio mediante a tantas integrações de sistemas que ali existiam, para que ao final, fosse possível alcançar uma solução tolerante a falhas e resiliente.

Nesse momento tínhamos o seguinte cenário:

Uma API Core chamava outra API (Contexto A) para validar a informação da conta do cliente. No entanto, por trás do Contexto A existiam ainda mais 4 API’s nesse fluxo, resultando assim em 5 requisições HTTP — o que estava mais do que claro que iria falhar em diversos momentos, principalmente ao integrar com sistemas externos.

A primeira coisa que fizemos foi conversar com os especialistas de domínio para entender se existia realmente a necessidade de tantas integrações, pois olhando para o código implementado parecia existir uma certa repetição. Após alguns estudos, chegamos à conclusão que seria suficiente utilizar apenas o Contexto B para validar a informação que a API Core necessitava, então demos o primeiro passo removendo o que não era necessário.

Nesse momento foi possível reduzir boa parte do tempo de resposta. Contudo, não ter uma estratégia de resiliência nos incomodava muito, pois se a API Contexto A caísse teríamos novamente aumento de contact rate.

2. Estratégia de cache

Quando pensamos em desenvolvimento moderno de software, na maior parte do tempo estamos falando sobre caching.

Aqui não foi diferente: ao identificarmos que o estado da informação que a API Core consultava não sofria tanta alteração, a primeira ideia foi…

“Vamos colocar uma camada de cache e ser felizes!”

A ideia era muito boa e traria um ganho significativo no fluxo, mas esbarramos em problema de capacidade de time: a implementação dessa camada de cache não caberia no planejamento, pois tínhamos uma equipe pequena com um backlog já gigante.

Foi assim que decidimos adicionar um API Gateway com a estratégia de response cache, sendo necessário apenas alguns arquivos yaml para configurar tudo, chegando na seguinte arquitetura:

Basicamente configuramos:

- API Gateway Kong em modo DB-Less;
- Plugin para cache de response com Redis (TTL de 4 horas);
- Exposição de endpoints para a API Contexto A.

3. Tolerância a falhas

Reduzir conexões e adicionar a camada de cache já traria um resultado significativo, mas ainda havia a necessidade de evitar falhas em cascata, já que temos chamada HTTP para fora do contexto Core e sabemos que isso é problema (as falácias da computação distribuída estão aí para provar).

Sendo assim, decidimos utilizar o padrão Circuit Breaker que permite um fluxo mais tolerante a falhas e resiliente, que “sobrevive” quando os principais serviços que a API Core consome estiverem passando por instabilidade. Assim, o blueprint final da arquitetura ficou dessa forma:

4. Linguagem de programação

Optamos em testar uma nova linguagem. Sabíamos que escrevendo essa solução em Go teríamos um enorme ganho em economia de infraestrutura e startup do projeto, pois nossa solução trabalhava em média com 150MB de memória e seu startup chegava a 5 minutos (o que dificultava muito a subida/escala de novos pods no K8S).

Havia ainda outros contextos dentro do time que precisavam realizar processos concorrentes ou paralelos, tornando-se aprazível o uso de Go Routines.

De forma geral achamos Go uma linguagem com baixa curva de aprendizagem, o que nos possibilitou uma entrega muito rápida do projeto e, ao colocar em produção, atingimos números admiráveis (que compartilho na sequência).

Resultados obtidos

• Consumo de memória reduzido em 80% - 150MB para 30MB.
• Redução no tempo de inicialização do serviço em 99,3% - 5 minutos para 2 segundos.
• Consumo de CPU reduzido em 97,5% - 4% para 0,1%.
• Tamanho da imagem docker reduzido em 91,6% - 168MB para 14MB.
• Tempo de resposta reduzido em 90,83% - 120ms para 11ms.
• A camada de cache reutiliza 90% das requisições, evitando ir até o destino e removendo uma grande carga da API Contexto A.
• Caso a API Contexto A fique fora do ar, o sistema Core consegue operar durante 4 horas retornando erro apenas para 10% das requisições.

Esses foram os resultados que obtivemos dessa experiência aqui dentro do will. E você, já testou algo parecido? Fique à vontade para comentar e contar pra gente!

Referências

• Design Docs at Google
• DB-less and Declarative Configuration - v2.8.x | Kong Docs
• Fallacies of distributed systems
• bliki: Circuit Breaker

Quer fazer parte de um time incrível, construir um banco do zero e democratizar o crédito para milhões de brasileiros? Veja nossas vagas e vem ser will!

Como reduzimos em ~90% o tempo de resposta de um serviço core do Will was originally published in will bank on Medium, where people are continuing the conversation by highlighting and responding to this story.

Neste projeto em questão estou utilizando o JFrog como gerenciador de artefatos, porém essa configuração vai funcionar para qualquer outro.

Adicionei 3 variáveis em meu .npmrc (JFROG_API_KEY, JFROG_USERNAME, JFROG_EMAIL) resultando nisso:

Em seguida criei o arquivo yml da actions (̶̶a̶̶̶ ̶̶̶p̶̶̶r̶̶̶i̶̶̶n̶̶̶c̶̶̶í̶̶̶p̶̶̶i̶̶̶o̶̶̶ ̶̶̶e̶̶̶s̶̶̶t̶̶̶o̶̶̶u̶̶̶ ̶̶̶c̶̶̶o̶̶̶n̶̶̶f̶̶̶i̶̶̶g̶̶̶u̶̶̶r̶̶̶a̶̶̶n̶̶̶d̶̶̶o̶̶̶ ̶̶̶C̶̶̶y̶̶̶p̶̶̶r̶̶̶e̶̶̶s̶̶̶s̶̶̶ ̶̶̶p̶̶̶a̶̶̶r̶̶̶a̶̶̶ ̶̶̶r̶̶̶o̶̶̶d̶̶̶a̶̶̶r̶̶̶ ̶̶̶t̶̶̶e̶̶̶s̶̶̶t̶̶̶e̶̶̶s̶̶̶,̶ ̶p̶o̶r̶é̶m̶ ̶a̶ ̶p̶a̶r̶t̶e̶ ̶ú̶t̶i̶l̶ ̶n̶o̶ ̶c̶o̶n̶t̶e̶x̶t̶o̶ ̶d̶o̶ ̶p̶o̶s̶t̶ ̶s̶ã̶o̶ ̶a̶s̶ ̶l̶i̶n̶h̶a̶s̶ ̶1̶6̶ ̶à̶ ̶2̶1̶ ̶o̶n̶d̶e̶ ̶e̶s̶t̶á̶ ̶o̶c̶o̶r̶r̶e̶n̶d̶o̶ ̶a̶ ̶i̶n̶s̶t̶a̶l̶a̶ç̶ã̶o̶ ̶d̶o̶s̶ ̶p̶a̶c̶o̶t̶e̶s̶), veja que estou passando como parâmetro as secrets do Github afim de evitar o vazamento de informações sensíveis.

Como cadastro secrets?

Acesse Settings na barra de ferramentas do seu repositório.

Clique em Secrets no menu ao lado esquerdo e New secret.

Basicamente é isso, bem simples! :)

Github actions e pacotes privados do npm was originally published in allbarbos on Medium, where people are continuing the conversation by highlighting and responding to this story.

No dia a dia é um saco trabalhar com imagens docker de tamanhos exagerados e na maioria dos casos falta apenas um pouco de carinho pra criar um Dockerfile otimizado.

Sendo assim decidi compartilhar esse caso que atuei recentemente, onde o problema não era especificamente o tamanho da imagem, mas corroborava pra piorar o cenário e não dava pra deixar como estava.

Contexto

API Rest com alto throughput de request, rodava no k8s e pasmem, sua imagem final era de 1.04GB.

Daria pra listar vários problemas, mas nesse contexto pode prejudicar bastante o tempo para escalar novos pods e também no dia a dia o desenvolvimento para baixar imagens.

Como executamos o binário da aplicação podemos descartar todo o resto do projeto, deixando a imagem infinitamente menor ao manter todos arquivos, com isso podemos utilizar algumas soluções:

Alpine

Por ser uma distribuição leve, de cara temos uma redução significativa para 600MB sem quebrar muito a cabeça com o Dockerfile

Flags

Se fizer sentido para seu contexto, podemos remover as informações de flags ao compilar o binário, o que nos poupa alguns MBs, neste caso 4

Multi-stage builds

Podemos ir além com multi-stage builds e criar uma imagem com apenas o necessário para rodar a aplicação, assim teremos uma redução absurda de 594MB para míseros 21.8MB

UPX

E a cereja do bolo é o UPX que nos permite compactar binário e reduzir ainda mais o tamanho

Caso queira ver os dockerfiles que gerei as imagens basta acessar este gist.

Basicamente é isso que gostaria de compartilhar e espero conseguir ajudá-lo a criar imagens pequenas :)

Golang — Criando imagens docker like a boss was originally published in allbarbos on Medium, where people are continuing the conversation by highlighting and responding to this story.

Para iniciar basta executar os comandos abaixo via CLI.

$ serverless create --template aws-nodejs --path consulta-cep
$ cd consulta-cep
$ npm init -y
$ npm i -E serverless serverless-offline

A lib serverless-offline nos permite debugar localmente o código e para que tudo funcione corretamente adicionei algumas informações no serverless.yml

service: consulta-cep

provider:
  name: aws
  runtime: nodejs10.x
  stage: dev
  region: us-east-1

functions:
  ceps:
    handler: src/handler.ceps
    events:
      - http:
          path: ceps/{cep}
          method: get
          request:
          parameters:
            paths:
              cep: true
plugins:
  - serverless-offline

No Visual Studio Code adicionei o seguinte código para debug:

{
  "type": "node",
  "request": "launch",
  "name": "Serverless",
  "program": "${workspaceFolder}/node_modules/.bin/sls",
  "cwd": "${workspaceFolder}",
  "args": ["offline"]
}

Ao executar o projeto (F5) será impresso no console a rota de acesso, basta realizar uma requisição e tudo estará funcionando, inclusive o debug.

A partir de agora podemos focar apenas no código que realmente importa! :)

Sendo assim implementei uma função simplória que consulta o WS dos correios e retorna os dados do CEP em questão, todo o código você pode acessar no Github e abaixo um snapshot de como ficou a estrutura de pastas e etc.

A ideia agora é adicionar novas funções neste projeto para que possamos ver como é o funcionamento do projeto e depois realizarmos o deploy disso tudo.

Porém ficará para o próximo post :)

Criando FaaS e configurando ambiente was originally published in allbarbos on Medium, where people are continuing the conversation by highlighting and responding to this story.

Antes de adentrar nas entranhas do código, é importante ressaltar que FaaS é apenas uma das opções da arquitetura Serverless, se não sabe ainda o que significa o conceito segue abaixo um brevíssimo resumo das palavras de Mike Roberts no artigo Serverless Architectures.

Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform.

Dado o contexto podemos falar brevemente sobre os AWS Lambdas, que são funções que nos permite focar diretamente no desenvolvimento do negócio, descartando toda complexidade para provisionar e gerenciar servidores, ficando por conta da vendor cloud — AWS.

Os lambdas são cobrados pelo tempo de execução e quantidade de chamadas, podendo ser acionados automaticamente por serviços da AWS ou através de aplicações via HTTP — o período em que o serviço não é requisitado não é cobrado.

Como gerenciar seu código

Sistema baseado em funções é bem granular, com isso torna-se um tanto quanto doloroso gerenciar inúmeros deploys, reutilização de código e etc.

Talvez seja mais fácil utilizar alguma plataforma ou framework para obter uma melhor produtividade:

• Serverless Framework
• AWS SAM
• IronFunctions
• Fn Project
• OpenFaaS
• Apache OpenWhisk

Ambiente local para desenvolvimento

Um item importantíssimo é como o desenvolvedor poderá simular localmente o mesmo cenário que será deployado, possibilitando realizar debug e testes do código — para demonstrar isso criaremos algumas funções mais a frente através do Serverless Framework, porém caso não esteja utilizando nenhum framework que facilite este processo é possível utilizar a ferramenta localstack.

Overengineering

Lambdas possui inúmeros pontos positivos, porém tome muito cuidado antes de inseri-los em sua stack de serviços, pois como tudo na vida existem trade-off.

Fragmentação

Existem várias formas de arquitetar uma aplicação FaaS, lembre-se sempre de como será entregue a esteira de CI/CD e o versionamento de código, pois dependendo do quão fragmentado fique a solução você ganhará milhares de repositórios, pipelines e configurações para gerenciar — e não receberá insalubridade no final do mês para lidar com YAML :)

Reutilização de código

Reutilizar módulos não é nada trivial, apesar de existir os Lambdas Layers, então dependendo da linguagem que irá escolher de runtime, realize uma análise de como será reutilizado os módulos e se existe a necessidade.

Limite de recursos

Alocação de memória: 128 MB a 3,008 MB, em incrementos de 64 MB.
Tempo-limite de processamento: 900 segundos (15 minutos)
Variáveis de ambiente: 4 KB
Lambda Layers: 5
Solicitações por segundo: 10x o limite de execuções simultâneas (forma síncrona, todas as origens) — 10x o limite de execuções simultâneas (forma assíncrona — origens que não são da AWS) — Ilimitado (forma assíncrona — origens de serviços da AWS)

Veja mais detalhes dos limites na docs.

Com esse breve contexto e sem mais delongas, podemos partir para a epopéia de desenvolvimento em lambdas, sendo assim irei dividir em vários posts para que o conteúdo fique melhor organizado.

Vamos falar de lambda functions? was originally published in allbarbos on Medium, where people are continuing the conversation by highlighting and responding to this story.

Evolução das APIs

O fato não ter uma interface padrão definida facilita a evolução, pois não haveria breaking changes caso necessite agregar mais informações em determinado recurso, pois quem controla o que quer receber é o cliente e não mais o servidor conforme estamos acostumado com o REST.

Supondo que necessitamos buscar em uma API REST apenas os campos Nome, Sobrenome e Idade do recurso Usuários, o servidor nos retornaria o resultado abaixo - afinal existe um contrato definido para esse retorno.

api/v1/usuarios/02723022285

{
  "nome": "Erick",
  "sobrenome": "Enrico Souza",
  "idade": 27,
  "sexo": "Masculino",
  "rg": "40.659.657-8",
  "cpf": "027.230.222-85",
  "nascimento": "26/11/1991"
}

Se amanhã houver a necessidade de remover/adicionar um campo precisaríamos criar um novo contrato com o cliente para que ele não seja pego de surpresa, pois quem controla os dados que serão fornecidos é a API.

Já no cenário do GraphQL esse problema de contrato seria invisível, pois se o cliente deseja consumir apenas os dados Nome, Sobrenome e RG o retorno seria:

{
  "nome": "Erick",
  "sobrenome": "Enrico Souza",
  "rg": "40.659.657-8"
}

Ou seja, o fato do cliente controlar os dados que deseja receber acaba se tornando-se mais escalável.

Performance

Conforme mostrado acima, ao utilizar o GraphQL as requisições se tornam mais rápidas pois o payload trafegado na rede é bem reduzido, afinal será enviado apenas as informações necessárias para a consulta em questão.

Vários recursos em request único

As consultas acessam as propriedades de um recurso e também seguem suas referências, ou seja, é possível obter todos os dados em um único request e isso traz um enorme ganho de performance, pois se fosse em um cenário REST seria exigido o carregamento de várias URLs para obter outros recursos, sendo assim o GraphQL traz um significativo ganho as aplicações e ainda maior para aquelas que utilizam redes móveis lentas.

E para finalizar é importante frisar que o GraphQL não tem nenhuma relação com banco de dados ou sistemas de armazenamentos, ele é apenas um ponto de entrada da nossa aplicação que irá nos auxiliar em realizar consultas de dados performáticas.

Porque utilizar GraphQL? was originally published in allbarbos on Medium, where people are continuing the conversation by highlighting and responding to this story.

O Redis é uma estrutura de dados armazenada em memória que pode ser utilizada como banco de dados, cache e message broker.

Ele suporta estruturas de dados como strings, hashes, listas, conjuntos, conjuntos classificados com consultas de intervalo, bitmaps, hyperloglogs, índices geoespaciais com consultas e fluxos radius.

Aqui vai alguns comandos básicos para brincar:

Setar uma chave com valor

SET birl "birl gates"

Obter o valor de uma chave

GET birl

Deletar uma chave

DEL birl

Incrementar o valor inteiro de uma chave

SET birl 1
INCR birl

Ao invés de utilizar a função INCR também poderíamos incrementar o valor da seguinte forma:

x = GET count
x = x + 1
SET count x

O problema é que ao fazer dessa maneira funcionará somente enquanto houver um único cliente utilizando a chave. Veja o que aconteceria se dois clientes estivessem acessando a chave ao mesmo tempo:

O cliente A lê a contagem como 10.
O cliente B lê a contagem como 10.
O cliente A incrementa 10 e configura a contagem para 11.
O cliente B incrementa 10 e define a contagem para 11.
Queríamos que o valor fosse 12, mas em vez disso é 11!

Isso ocorre porque incrementar o valor dessa maneira não é uma operação atômica e a função INCR impedirá que isso aconteça, porque é uma operação atômica.

Setar tempo de expiração para chave/valor

SET birl "birl gates"
EXPIRE birl 120

A função EXPIRE faz com que a chave exista por um determinado período de tempo em segundos e para obter quanto tempo falta para a expiração da chave basta utilizar TTL

TTL birl

A função TTL pode ter os seguintes retornos:
-2: Quer dizer que a chave foi expirada e deixou de existir
-1: A chave nunca expirará
>= 0: Segundos que faltam para que a chave expire

Redis — Básico was originally published in allbarbos on Medium, where people are continuing the conversation by highlighting and responding to this story.

Criar as pastas: BackupFiles, DataBaseFiles, LogFiles, SqlServerFiles, TempDBFiles

Instalação SQL Server 2017 was originally published in allbarbos on Medium, where people are continuing the conversation by highlighting and responding to this story.

É comum encontrarmos por ai o seguinte código:

let a = 13;
let b = 149;
let temp;

temp = a;
a = b;
b = temp;

console.log(a);
console.log(b);

No entanto, o ES6 nos permite fazer a mesma coisa com a metade de código:

let a = 13;
let b = 149;

[a, b] = [b, a];

console.log(a);
console.log(b);

Trocando valores de variáveis was originally published in allbarbos on Medium, where people are continuing the conversation by highlighting and responding to this story.

StartsWith
Ao utilizar este método podemos verificar se uma string inicia com determinado valor. Devemos passar a string que será procurada e a posição que começará a busca:

"Métodos bacanudos para string".startsWith("Métodos") // true
"Métodos bacanudos para string".startsWith("bacanudos", 8) // true

Lembrando que nem todos os browsers dão suporte a este recurso, sendo assim, para manter a compatibilidade existe o polyfill abaixo:

if (!String.prototype.startsWith) {
  String.prototype.startsWith = function(searchString, position) {
    position = position || 0;
    return this.indexOf(searchString, position) === position;
  };
}

EndsWith
Contrário ao startsWith, compara se o final da string é igual ao informado. Caso queira comparar um pedaço, basta informar no segundo parâmetro o tamanho a ser considerado na string.

"Métodos bacanudos para string".endsWith("string") // true
"Métodos bacanudos para string".endsWith("bacanudos", 17) // true

O polyfill a ser usado caso o browser não possua suporte é:

if (!String.prototype.endsWith)
  String.prototype.endsWith = function(searchStr, Position) {      
    if (!(Position < this.length))
      Position = this.length;
    else
      Position |= 0;

    return this.substr(Position - searchStr.length,
                       searchStr.length) === searchStr;
  };

Includes
O includes é case-sensitivity e verifica se existe determinado valor dentro da string, podendo também passar o parâmetro informando onde iniciará a verificação:

"Métodos bacanudos para string".includes("para") // true
"Métodos bacanudos para string".includes("Para") // false
"Métodos bacanudos para string".includes("Métodos", 1) // false

Polyfill:

if (!String.prototype.includes) {
  String.prototype.includes = function(search, start) {
    'use strict';
    if (typeof start !== 'number') {
      start = 0;
    }
    
    if (start + search.length > this.length) {
      return false;
    } else {
      return this.indexOf(search, start) !== -1;
    }
  };
}

Repeat
Como o nome já diz, o repeat nos retorna uma nova string de acordo com o número de repetição informado que pode ser entre 0 e infinito:

"Bacanudos".repeat(3) // "BacanudosBacanudosBacanudos"

Seu polyfill é:

if (!String.prototype.repeat) {
  String.prototype.repeat = function(count) {
    'use strict';
    if (this == null) {
      throw new TypeError('can\'t convert ' + this + ' to object');
    }
    var str = '' + this;
    count = +count;
    if (count != count) {
      count = 0;
    }
    if (count < 0) {
      throw new RangeError('repeat count must be non-negative');
    }
    if (count == Infinity) {
      throw new RangeError('repeat count must be less than infinity');
    }
    count = Math.floor(count);
    if (str.length == 0 || count == 0) {
      return '';
    }    
    if (str.length * count >= 1 << 28) {
      throw new RangeError('repeat count must not overflow maximum string size');
    }
    var rpt = '';
    for (var i = 0; i < count; i++) {
      rpt += str;
    }
    return rpt;
  }
}

Métodos bacanudos para string was originally published in allbarbos on Medium, where people are continuing the conversation by highlighting and responding to this story.