Jornada para Microsserviços

O primeiro microsserviço, em um processo de transformação de um monólito, não precisa (nem deve) ser perfeito!

A transformação de um sistema monolítico, potencialmente legado, para microsserviços não é atividade simples. Buscar uma “primeira implementação perfeita” poderá atrapalhar mais do que ajudar. Além disso, é grande o risco de paralisia por análise.

Paralisia por análise

Analysis paralysis (or paralysis by analysis) describes an individual or group process when overanalyzing or overthinking a situation can cause forward motion or decision-making to become “paralyzed”, meaning that no solution or course of action is decided upon. A situation may be deemed as too complicated and a decision is never made, due to the fear that a potentially larger problem may arise. A person may desire a perfect solution, but may fear making a decision that could result in error, while on the way to a better solution. 

— Wikipedia

Uma vez que se constate que a adoção de microsserviços se justifica, quanto antes houver algo que se assemelhe a um microsserviço em produção, melhor. Afinal, antes serão discutidos aspectos relacionados com a operação, fazendo com que práticas de DevOps aconteçam por necessidade e não por imposição.

Sam Newman indica que a primeira implementação de um microsserviço, em um processo de migração, pode ser uma extração simples de lógica da aplicação monolítica, ainda compartilhando a mesma base de dados.  Essa “preservação” do esquema original, aliás, facilita a separação dos processos de deploy release permitindo que o microsserviço seja “desligado” com prejuízos mínimos quando se algo der errado.

Em um cenário ideal, o acionamento do microsserviço será responsabilidade de um proxy http que esteja interceptando todas as requisições para o sistema. Esse proxy, por sua vez, deverá condicionar a utilização do microsserviço a uma ou mais feature toogles. 

Por algum tempo, atividades de consulta sem modificação de estado podem, inclusive, ocorrer simultaneamente no microsserviço e no monólito. Dessa forma, será possível verificar no proxy se a nova implementação está em conformidade com a antiga.

You won’t appreciate the true horror, pain and suffering of microservices until you are running them in production (Sam Newman)

O esforço para colocar um microsserviço em produção antecipa e explicita as debilidades do sistema monolítico que se está evoluindo, sobretudo os pontos de acoplamento.

Em Resumo
  • O problema

    A transformação de um sistema monolítico, potencialmente legado, para microsserviços não é atividade simples. Buscar uma "primeira implementação perfeita" poderá atrapalhar mais do que ajudar. Além disso, é grande o risco de paralisia por análise.
  • O insight

    Uma vez que se constate que a adoção de microsserviços se justifica, quanto antes houver algo que se assemelhe a um microsserviço em produção, melhor. A primeira implementação de um microsserviço, em um processo de migração, pode ser uma extração simples de lógica da aplicação monolítica, ainda compartilhando a mesma base de dados.
  • Os benefícios

    Quanto antes ocorrer o deploy, menores são os riscos de que a imaturidade da operação comprometa resultados. Além disso, mais cedo serão sentidas as "dores" relacionadas a esse modelo de arquitetura.

Mais posts da série Jornada para Microsserviços

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *