Microsserviços: Menos Micro e Mais Serviços
A Arquitetura Orientada a Serviços (SOA) foi declarada morta há quase dez anos. Um fator que contribuiu — mas raramente discutido — para seu fim foi a rede. A latência entre os serviços impedia que os arquitetos decompusessem completamente os aplicativos em serviços com a granularidade necessária para incentivar a reutilização e, por fim, aplicativos componíveis.
Entre na Arquitetura de Microsserviços (MSA). Seus princípios exigem uma decomposição ainda maior, com foco na função (verbos) em vez do objeto (substantivos) como o principal critério para dividir uma aplicação. Dessa mudança aparentemente sutil de foco surge uma maior granularidade de serviços; há muito mais funções do que objetos em qualquer sistema.
A rede está pronta. As velocidades e os feeds da rede física aumentaram drasticamente. A computação também avançou de acordo com a Lei de Moore e tornou a latência de rede quase um problema inexistente.
Infelizmente, a latência de comunicação tomará seu lugar.
Replicamos no interior dos ambientes de contêineres utilizados para implantar microsserviços a complexidade da Internet. Embora um microsserviço possa não precisar de DNS, ele ainda depende do mesmo tipo de resolução baseada em nomes que executa a Internet. As tags do aplicativo - metadados - devem ser traduzidas para um endereço IP. Registros de serviços e entradas complexas de tabelas de IP atuam como DNS em miniatura, traduzindo tags em endereços e permitindo a comunicação entre serviços.
A natureza efêmera dos microsserviços e seus contêineres associados agrava a latência associada a esse processo. Com vidas úteis medidas em segundos ou minutos em vez de horas ou meses, a resolução de nomes deve ocorrer a cada chamada. O tempo de vida (TTL) dentro do mundo dos contêineres é, efetivamente, zero.
Mesmo se ignorarmos essa reprodução de uma das maiores fontes de latência de comunicação, ficamos com aquela associada ao TCP. Não é - e nunca foi - livre iniciar ou interromper uma conexão TCP. Essa fonte de latência é certamente pequena, mas absolutamente aditiva. Cada conexão — cada microsserviço — necessária para executar uma única transação adiciona latência que eventualmente viola a tolerância ao atraso.
O HTTP/2, apesar de suas mudanças drásticas de comportamento, não resolve esse problema. O HTTP/2 foi projetado para facilitar a transferência de vários objetos pela mesma conexão, reduzindo assim a latência para conteúdo de vários objetos, como páginas da web e aplicativos baseados na web. Os microsserviços são idealmente projetados de forma que cada serviço retorne uma única resposta. Embora múltiplas solicitações em uma conexão estabelecida certamente reduzam a sobrecarga de comunicação, isso não pode ser feito em um sistema onde múltiplas solicitações são distribuídas entre vários serviços discretos .
O problema, então, não é a latência da rede, mas a latência da comunicação. As conexões ainda contam, e melhorias em protocolos projetados para melhorar o desempenho de comunicações multitransacionais baseadas na web não ajudarão nas transações multisserviços.
O resultado é SOMA. Microarquiteturas orientadas a serviços. Um estranho híbrido de arquiteturas orientadas a serviços e microsserviços que nos deixa imaginando onde uma termina e a outra começa. A decomposição de aplicativos em serviços compostos baseados em funções é limitada pela latência de comunicação e, em última análise, pela sustentabilidade da base de código. Embora os avanços da rede certamente tenham aumentado a granularidade com a qual a decomposição pode ser razoavelmente realizada, eles não eliminaram a restrição. Outro fator é que há ordens de magnitude a mais de funções do que objetos em um aplicativo. Isso torna a tarefa de gerenciar um aplicativo arquitetado puramente por microsserviços um pesadelo logístico para as operações de rede, e muito menos para os desenvolvedores de aplicativos. Combinado com o problema inerente levantado pela latência das comunicações, as organizações estão cada vez mais desenvolvendo microsserviços orientados a objetos em vez de microsserviços verdadeiramente orientados a funções.
É por isso que vemos a decomposição de aplicativos além da arquitetura tradicional de três camadas, mas não a ponto de ser uma representação fiel da decomposição baseada em funções.
Até que abordemos a latência inerente às comunicações baseadas em conexão (TCP) - seja com algo novo ou focando nas implementações em nível de sistema - continuaremos limitados a arquiteturas de microsserviços que são menos micro e mais serviços.