Ainda não estruturei como uma jornada, portanto o começo dessa jornada é um brainstorm. Como toda jornada onde sabemos o destino, mas temos um caminho desconhecido, vamos buscando do horizonte curto para o distante e do horizonte distante para o curto, aproximando e reduzindo a área de incompreensão.

Eu já havia dedicado algum tempo a tentar mostrar meu ponto de vista: Com o nível das discussões ao redor de Microsserviços, e com o que eu tenho acompanhado do mercado e da comunidade, pude concluir com os meus olhos que microsserviços virou hype, e dizer-se fazendo microsserviços virou insígnia para se colocar no currículo, no blazer, na farda.

Eu vi clientes falando e planejando fazer coisas horríveis, eu vi usuários da comunidade codificando coisas horrendas dizendo que eram microsserviços. Eu entrevistei muitos candidatos que diziam: “- Eu faço microsserviço!”, mas bastava 1 pergunta e 55 segundos de resposta para perceber que na verdade não tem nada de microsserviço naquela experiência.

A intenção não é nem de longe cagar regra, mas esclarecer que se você quer ter benefícios, você precisa, de outro lado, viabilizar isso. E é aí que mora a pegadinha. Os esforços de engenharia de software para viabilizar microsserviços são notáveis e inúmeros. E precisamos ficar atentos a isso, pois a ausência de elementos fundamentais fazem com que sua implantação de microsserviços continue com problemas de monolitos.

O que quero dizer, é que não basta fazer um serviço pequeno, é preciso encarar cada serviço como um sistema autônomo. Isso tem implicações práticas, e complexas de se lidar, como a necessidades de mais integrações, por exemplo. Para um microsserviço, a dependência de outro microsserviços é um ofensor para sua própria disponibilidade.

Assim não importa se estamos falando de um serviço externo (google, azure, etc) ou interno (da própria empresa ou do próprio sistema), tudo que extrapola as fronteiras do próprio microsserviço, é visto como acoplamento, e potencial ofensor para disponibilidade. Aí endereçamos patterns de resiliência para lidar com disponibilidade.

Autonomia demanda Governança

Quando lidamos com a evolução dos microsserviços, em um modelo de baixo acoplamento, entendemos que devemos poder ter diversas versões do mesmo microsserviço, rodando lado-a-lado. Versões antigas atendendo clientes antigos, como estratégia para retrocompatibilidade. Pois, se estamos falando em serviços autônomos, quebrar contratos¹ faz parte do seu ciclo de vida, e você lida com essas quebras de diversas formas. Desde de adapters, middlewares de transformação, mas em última instância, grandes refatorações demandam fazer com que você efetivamente tenha 2 versões de um mesmo serviço rodando lado-a-lado. Possivelmente usando bancos diferentes, hosts, data centers e talvez até protocolos diferentes. Essa gestão é o preço pago pela autonomia.

[1] Você de fato não quebra contratos, você muda os contratos e trata com ferramentas e padrões para que os clientes não sejam impactados. Em última instância, duplica-se os serviços, mantendo retrocompatibilidade e cria-se um plano de comunicação e transição para lidar com a necessidade de migração.

Claro, isso não é um problema, é uma característica. Essa necessidade de maior gestão e melhor comunicação se dá exatamente para que seja possível de fato exercer essa autonomia. Se você quer autonomia, é necessário ser independente, senão sua estratégia é limitada à capacidade dos seus consumidores de reagir aos anseios de seu roadmap.

Ainda, se chegamos ao ponto de termos versões tão diferentes de microsserviços rodando lado-a-lado, temos também o desafio de manter 2 versões. E se os repositórios de dados ou as características desses serviços mudarem substancialmente, temos o problema de precisar de repositórios de dados diferentes.

Isso foi o que aconteceu com o DialogFlow (antigo API.AI), serviço de Natural Language Processing, comprado pelo google em 2016. No final de 2018 sinalizaram que em outubro de 2019 (1 ano depois) migrariam todas as API’s de REST para gRPC.

Isso é um plano de transição. Nesse caso temos 2 API’s, lado-a-lado.

São casos extremos, e devem ser avaliados como exceção? Sim e não.

Para esse business, a modelagem é muito flexível e permite evoluções sem quebra de compatibilidade, no entanto essa mudança que vimos leva em conta uma mudança no protocolo. Isso muda tudo.

Embora apenas uma pequena quantidade de demandas, exijam tal gestão, o problema é que sua arquitetura precisa prever isso. Se você não lidar com isso, todos os argumentos e benefícios de autonomia e flexibilidade simplesmente deixam de existir. Se você não prever a possibilidade de lidar com isso, bem vindo ao microsserviço com problemas de monolito!

Mensageria e Stream de Eventos

Sob outro aspecto, ao trabalharmos com microsserviços, vamos entender que os fluxos de negócio ganham vida via integrações. Enquanto com o acoplamento momnolítico temos serviços à disposição para chamá-los, pois simplesmente ignoramos indisponibilidade quando chamamos métodos em um mesmo processo. Em uma arquitetura distribuída, evitamos chamadas diretas a serviços sempre que possível. Assim o gerenciamento dos fluxos ganham vida com plataformas e ferramentas de mensageria, onde publicamos eventos.

Eventos são impulsos que enviamos para um gerenciador de eventos, de forma a sensibilizar todo mundo que está esperando esse impulso para executar sua parte de uma coreografia. Ao invés de deliberadamente realizar uma orquestração de chamadas, a forma mais resiliente é usando mensageria. E com essa lambança de diversos serviços, com possivelmente diversos bancos, possivelmente geodistribuídos. The source of truth, é sua infraestrutura de mensageria, na verdade com os desafios desse tipo de arquitetura, a tendência é que pensemos em event streams e stream platforms como Kafka.

RabbitMQ atende essas demandas pela perspectiva de controle de execução em escala, mas Kafka entrega um modelo de time machine. E poder reprocessar mensagens é algo que em uma arquitetura dessas, você definitivamente torcerá para não precisar, mas se precisar, ficará imensamente grato por ter à sua disposição.

Você pode se questionar, e achar que estamos falando em BIG DESIGN UP FRONT eu já falei disso em Oragon – Princípios de Design – Complexidade Reside na Arquitetura. Como encaro arquitetura como uma estratégia de guerra contra Murphy e contra as adversidades do dia-a-dia de um projeto, como citei diversas vezes, que a única certeza é que seu projeto sofrerá mudanças, e em contrapartida devemos oferecer meios de tornar essas mudanças digeríveis. Essas questões são questões cotidianas, elas estão presentes para assegurar que você terá os benefícios que essa arquitetura se pré-dispõe a entregar.

Gerenciamento de Workloads, Monitoramento, Configuração

Outro ponto que chama a atenção é o gerenciamento de grandes cargas de trabalho. Vamos supor 50 microsserviços, com 20 workers cada. Esse é um cenário com 1000 instâncias rodando lado-a-lado. E claro que, por questões óbvias, você precisará lidar com silos de baixa latência produzindo em algum nível segmentos que atendem demandas de acordo com alguma prioridade. Note, que estou falando de demandas que extrapolam o básico de Docker e Kubernetes estou falando das necessidades de service mesh. Que alias operacionalmente se integram com outra demandas extremas: Monitoramento, configuração dinâmica e hot.

Você não começa tendo todas essas demandas de uma vez só, faz parte do dia-a-dia de cada projeto, cada serviço, mas as coisas crescem, e microsserviço é feito para crescer! Essa complexidade é necessária e inerente a grandes projetos, para te entregar os benefícios que microsserviços são capazes de prover. E ainda não falamos estratégias de rollout de novas versões, como Canary e Blue/Green Deployment, também não falamos em DevOps e automação.

Tolerância a falhas, Rollback e Reprocessamento

Também não falamos sobre como lidar com comportamentos errados. Necessidade de rollback de serviços. E note, não é o aspecto de subir uma versão antiga que me preocupa. É como lidar com as ações “defeituosas” que foram realizadas com sucesso e geraram eventos, que foram processados por outros microsserviços, durante os 30 minutos ou 2 horas de execução daquela versão (supondo que esse seja o tempo necessário para descobrir que uma nova versão falhou por algum aspecto de negócio, ou ainda, reduziu sua capacidade de venda, por exemplo).

Como estamos falando de um ser vivo, como um corpo humano. Cada novo deploy é como uma pequena cirurgia, um transplante, em que trocamos um órgão por outro. E sempre estamos suscetíveis à impactos e precisamos lidar com isso. Precisamos estar prontos para lidar com os reflexos de uma implantação mal sucedida. E as vezes essa implantação sequer foi mal sucedida porque falhou, quebrou. Ela pode simplesmente ter resultado em maior consumo de infra, ou lentidão para o usuário final. É o tipo de erro que impacta em venda, mas não necessariamente é considerado showstopper. Atrapalha a operação, reduz a experiência do usuário, mas não impede a realização de tarefas. É o tipo de erro que não se descobre segundos após a implantação ou durante a implantação.

Todos esses desafios fazem de microsserviços uma arquitetura única e incrível! Entretanto, mais complexa e verdade seja dita, muito mais cara. De outro prisma autonomia e responsabilidades de um time de desenvolvimento em uma arquitetura dessa natureza é outro. Agora o time é responsável por todos os aspectos do produto. E isso demanda senioridade e skills técnicos escassos.

Se de um lado microsserviços entrega:

• Complexity localization
• Cross-cutting business functionality
• Increased Resiliency
• Better scaling
• Output Flexibility
• Real-time processing support
• Support for best technology use
• Efficient system optimization and organization
• Rapid growth facilitation
• Cross-functional teams
• Outsourcing flexibility
• Team optimization
• Technology experimentation flexibility
• Cross-team coordination support
• High-quality

Fonte: https://www.qat.com/15-benefits-microservices/

Por outro, para que essa arquitetura faça seu trabalho, temos muito dever de casa. Algumas tarefas a serem realizadas antes de começarmos, outras durante o processo e outras quando as coisas realmente se tornam grandes. Mas todas essas questões se costuram e se fundem umas às outras.

Sem essa devida atenção, o que terá são “microsserviços” que:

• Não escalam
• Não podem evoluir pois quebram outros microsserviços ou clientes externos
• Não são resilientes
• Não são escaláveis
• Geram downtime em outros serviços.
• Impactam a operação
• Sofrem downtime durante implantações
• São irrecuperáveis (em caso de falha)
• São impossíveis de se realizar qualquer tipo de análise e troubleshooting

Se algum desses problemas afeta hoje seus microsserviços, há boas chances de você não estar fazendo um microsserviço.

Conclusões

Agora será que pelo amor de Deus vocês entendem o motivo d’eu ficar descabelado quando vejo tanta negligência ao falarem de microsserviços?

O ponto é que olho para cada afirmação a respeito desse tipo de arquitetura e de fato dedico um tempo ao entendimento de:

Como?

Qual a mágica que torna isso possível?

Quais as implicações disso ser assim como está proposto?

Como lidar com as consequências de Y, fundamental para X?

Arquitetura é um grande Xadrez, onde o tabuleiro são as possibilidades. Cada peça tem um movimento, mas os reflexos e desdobramentos são previsíveis.

Eu tento elucidar alguns pontos nos meus posts, isso porque o tema não era algo que eu gostaria de abordar agora em 2019. Eu tinha outros assuntos para falar antes de falar de microsserviços, e sinceramente, conheço gente muito mais preparada que já está falando do assunto.

No próximo post, que será continuação desse post aqui eu começo a explicar a minha jornada, mostrando coisas que publiquei, experiências que vivi. Vocês vão entender muito de como eu construo essa história! Enquanto isso, peço, por favor que comente.

Se eu fui muito simplista nas construções dos porquês, talvez sua dúvida me ajude a escolher uma forma mais fácil de esclarecer esses pontos.

Outra coisa importante, eu separei essa série em temporadas. Pois teremos alguns posts, mas não posso dedicar muito tempo ao assunto, preciso falar de outros projetos meus, como o Oragon, preciso falar de Spring, preciso falar de outros aspectos do uso de Docker como Service Mesh, Open Tracing, fazer um apanhado de projetos da CNCF, também preciso falar de Configurações Dinâmicas, etc. Assuntos que mais tarde serão costurados em na segunda temporada de posts a respeito de microsserviços e arquitetura em geral.