Jornada para Microsserviços

Proxy HTTP: um ótimo “primeiro passo” na transformação de sistemas monolíticos em microsserviços

Um dos grandes desafios para migração de sistemas monolíticos para arquiteturas baseadas em microsserviços é o uso ampliado dos recursos de rede. Por isso, em uma migração gradual, um ótimo primeiro passo é assegurar que a infraestrutura utilizada pela organização não será um empecilho.

Nesse contexto, quando um sistema monolítico expõe funcionalidades através de APIs HTTP (ou qualquer outro protocolo formal de comunicação), é recomendável que implementemos um proxy.  Caberá a ele interceptar todas as requisições para esse serviço, transmitindo-as para ele na sequência, aguardando seus retornos, para, então, retornar para as aplicações clientes.

 

Essa recomendação, formalizada recentemente por Sam Newman – uma das maiores autoridades mundiais em microsserviços – permite identificar muito cedo eventuais problemas de infraestrutura além de possuir custo mínimo, tanto técnico quanto para o negócio. Além disso, tem complexidade minimizada por sua alta reversibilidade.

Eventualmente, o proxy poderá redirecionar requisições para que sejam atendidas por um microsserviço que implementará uma funcionalidade extraída do monólito. Tudo isso de maneira transparente tanto para as aplicações clientes quanto para a própria aplicação monolítica que mantém (por algum tempo) a implementação original.

Finalmente, com o tempo, o proxy também poderá evoluir e se adaptar melhor as necessidades das aplicações clientes, operando como uma API externa.

Em Resumo
  • O problema

    Um dos grandes desafios para migração de sistemas monolíticos para arquiteturas baseadas em microsserviços é o uso ampliado dos recursos de rede. É importante poder determinar o mais cedo possível se a infraestrutura está preparada ou não para suportar o overhead de tráfego.
  • O insight

    Quando um sistema monolítico expõe funcionalidades através de APIs HTTP (ou qualquer outro protocolo formal de comunicação), é recomendável que implementemos um "proxy".  Caberá a ele interceptar todas as requisições para esse serviço, transmitindo-as para ele na sequência, aguardando seus retornos, para, então, retornar para as aplicações clientes.
  • Os benefícios

    O "proxy" permitirá identificar problemas na infraestrutura além de facilitar a separação de "deploy" e "release", mais tarde, quando os primeiros microsserviços entrarem em produção.

Elemar Júnior

Microsoft Regional Director e Microsoft MVP. Atua, há mais de duas décadas, desenvolvendo software e negócios digitais de classe mundial. Teve o privilégio de ajudar a mudar a forma como o Brasil vende, projeta e produz móveis através de software. Hoje, seus interesses técnicos são arquiteturas escaláveis. bancos de dados e ferramentas de integração. Além disso, é fascinado por estratégia e organizações exponenciais.

Talvez você goste também

Carregando posts…

Mais posts da série Jornada para Microsserviços

2 Comentários
  1. Anderson

    Ótimo artigo, teria algum exemplo de como fazer isso? Tipo uma aplicação monolítico framework 4.6.1 ou algo assim com core para microservicos?

  2. Marcus Alexandre

    Muito bom este artigo e uma ótima dica. Talvez eu o escreveria esclarecendo o que é ACL, expondo que o proxy é uma destas ACLs e deixando em aberto outros padrões que também podem ajudar, como os Adapters. Abraço!

Deixe uma resposta

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