Microsservices is life 🚀

Thiago D.
Let’s code Brasil
5 min readJul 7, 2020

Microsserviços, nesse artigo vou falar um pouco deles, conforme minhas experiências e os capítulos do livro “Microsserviços prontos para a produção: Construindo Sistemas padronizados em uma organização de engenharia de software”.

Susan J. Fowler dá uma verdadeira aula sobre o mundo dos microsserviços nessas 224 páginas. Ela divide todo o seu estudo em sete capítulos super didáticos e com uma fluidez incrível de aprendizado. Por eu viver nesse ecossistemas de microsserviços desde 2017, me identifico muito com suas teorias e especificidades, ler esse livro foi e é uma leitura incrível, recomendo à todos engenheiros e entusiastas de #microservices .

Microsserviços, disponibilidade de produção, estabilidade e confiabilidade, escalabilidade e desempenho, tolerância a falhas e prontidão para catástrofes, monitoramento e por fim e não menos importante documentação. São esses os sete capítulos que Fowler nos apresenta e que permeiam todo o ecossistema para um microsserviço estar pronto para produção e ser produtivo.

Quando falamos de microsserviços prontos para produção, temos que garantir algumas coisas, para que de fato o sistema esteja preparado para o tráfego de dados e funcione de maneira estável para o usuário final ou cliente/dependente daquele microsserviço específico.

Sempre pensando em padrões, garanta que seu micro serviço esteja estável, confiável, escalável, tolerante a falhas, seja de alto desempenho, bem monitorado, com uma documentação sucinta e preparado para qualquer catástrofe, se serviço estiver com todos esses pontos; ele estará pronto para tráfego em produção, mas não esqueça que mesmo com todos esses níveis garantidos, um micro serviço pode e vai gerar erros em produção, a intenção é mitigá-los e tratá-los da melhor maneira possível para que não afete todo o ecossistema de microsserviços do qual ele faz e/ou fará parte.

Mas trabalhar com microsserviços também gera algumas contrapartidas importantes, que caso as pessoas não tomarem cuidado pode afetar toda a produtividade deles, algumas dessas contrapartidas são as seguintes:

  • Isolamento e Comunicação deficiente entre equipes
  • Dispersão técnica
  • Maior capacidade de falhas do sistema
  • Competição por recursos de engenharia e infraestrutura

Em todos projetos que trabalhei ocorreram esses tais problemas, e no livro diversos exemplos trazem essas mesmas questões; equipes que não se conversam e os microsserviços vão trabalhar em conjunto no mesmo ecossistema, equipes que se acham mais capazes tecnicamente que outras, mas não fazem nada para passar seus conhecimentos, por esse motivo geram muitos erros e falhas no sistema como um todo, pois um microsserviço não consegue se comunicar direito com os outros e isso prejudica todo o ecossistema, e uma das coisas que mais me irrita no mundo do desenvolvimento; a competição por recursos de infra, já cheguei a ouvir que eu devia ir lá falar com os cara de infra e levar uns chocolates para eles me ajudarem com falta de recursos, parece absurdo né? mas não é, olha é bem comum esse tipo de coisa, me lembra muito aquela cena de tropa de elite 2: você quer rir aspira? tem que me fazer rir primeiro.

Enquanto essa cultura de “suborno” é mantida e alimentada dentro de corporações, sempre veremos sistemas distribuídos falharem e operarem de mal forma. como podem ver, quase todos os problemas e falhas que citei, são humanos, e não é a toa.

Para que um microsserviço desempenhe no padrão de mais alta performance, temos algumas camadas onde em cada uma delas temos equipes e pessoas diferentes que tomam conta, e se não existir uma cultura de tecnologia na mente de todos esses indivíduos que fazem parte de um todo, as coisas não vão funcionar bem, vamos destrinchar cada camada abaixo.

Camada 1: Hardware

Contem os servidores físicos, sistemas operacionais, tecnologias de isolamento e abstração de recursos, gerenciamento de configuração, monitoramento e logging em nível de servidor.

Equipe responsável: TechOps.

Falhas comuns:

  • No servidor;
  • No rack;
  • No datacenter;
  • No provedor de serviços de nuvem;
  • No provisionamento do servidor;
  • Na tecnologia de isolamento e/ou na abstração de recursos;
  • Gerenciamento separado de configuração;
  • Mudanças de configuração;
  • Lacunas do monitoramento no âmbito do servidor;
  • Lacunas do logging no âmbito do servidor;
  • Falha de rede;
  • Downtimes operacionais;
  • Falta de redundância de infraestrutura;

Camada 2: Comunicação

Contem a rede, o dns, o frameworks rpc, os endpoints, troca de mensagens, descoberta de serviços, registro de serviços e balanceamento de carga.

Equipe responsável: Infraestrutura.

Falhas comuns:

  • De rede;
  • De dns;
  • De rpc;
  • Tratamento inadequado de solicitações e/ou respostas;
  • Falha no sistema de troca de mensagens;
  • Na descoberta de serviços e registro de serviços;
  • Balanceamento de carga incorreto;

Camada 3: Plataforma de aplicação

Contem ferramentas internas do tipo autosserviço, o ambiente de desenvolvimento, ferramentas de teste, empacotamento, versão e liberação, o pepiline de deployment, monitoramento e logging em nível de microsserviços.

Equipe responsável: DevSecOps.

Falhas comuns:

  • Nas ferramentas e/ou ambiente de desenvolvimento;
  • Nos pipelines de teste, empacotamento, versão e liberação;
  • Lacunas no logging no âmbito de microsserviço;
  • Lacunas no monitoramento no âmbito de microsserviços;
  • Pipeline de deployment;

Camada 4: Microsserviços

Contem os microsserviços e todas configurações especificas do microsserviço.

Equipe responsável: Engenheira de Software.

Falhas comuns:

  • Insuficiente revisão do projeto de arquitetura de sistema e serviços;
  • Revisões incompletas de código;
  • Processos precários de desenvolvimento;
  • Ele não tem um ponto único de falha.
  • Descontinuação do endpoint de API;
  • Desativação do endpoint de API;
  • Descontinuação do microsserviço;
  • Desativação de microsserviço;
  • Interrupções de um microsserviço downstream ( dependência);
  • Descontinuação da interface ou do endpoint;
  • Timouts para um serviço downstream;
  • Timouts para uma dependência externa;
  • Interrupções de serviços internos;
  • interrupções de serviços externos ( terceiros );
  • uma dependência não consegue cumprir seu SLA;

Todos esses pontos acima, podemos mitigar, usando à seguinte lógica:

Não permitimos o microsserviço ter um ponto único de falha, todos cenários de falha e as possíveis catástrofes foram identificados e mapeados, nosso microsserviço é testado para resiliência por meio de testes de código, testes de carga e testes de caos, toda detecção e mitigação de falhas foram automatizadas e existem procedimentos padronizados de incidentes e interrupções dentro da equipe de desenvolvimento de microsserviços e em toda a organização.

Quando esse mantra é utilizado a risca, garantimos toda estabilidade possível e começamos performar como empresa, organização e equipes de alta performance na engenharia de software.

Deixando aqui meu pitaco, eu passei por diversos projetos, por diversas equipes, empresas e startups, mas nunca havia visto alguma delas chegar perto desse tipo de metodologia, nesses meus 5 anos de desenvolvimento de forma profissional.

Encontrar pessoas engajadas para performar no mais alto nível, é muito difícil, e encontrar lideres que impulsionem todos da organização nessa cultura tech é ainda mais raro.

Mas desde outubro de 2019, encontrei um projeto que está a todo vapor e sendo construído com essas premissas, e lá conheci muitíssimas pessoas engajadas para fazer que tudo isso aconteça.

Posso dizer que é uma das melhores fazes da minha carreira no quesito aprendizagem, evolução técnica e engajamento desde novas tecnologias até formas de comunicação e passagem de conhecimento.

“Projeto marte”, esse é o nome dele, e temos à missão de evoluir à plataforma digital do iti Itaú para um novo patamar de excelência tecnologica, com à mais alta performance no que se diz respeito a desenvolvimento de software, e queremos chegar no estado puro da arte de desenvolvimento e engenharia de software.

Baita desafio né? Mas tenho certeza que vamos alcançar nosso objetivo, pois estamos performando muito bem nesse sentido; microsservices is life 🚀

--

--