A Arquitetura Orientada a Serviços (SOA) foi declarada morta há quase dez anos. Um fator que contribuiu para seu fim — embora raramente discutido — foi a rede. A latência entre os serviços impediu que os arquitetos decompusessem totalmente as aplicações em serviços com a granularidade necessária para incentivar a reutilização e, em última análise, viabilizar aplicações combináveis.
É aí que entra a Arquitetura de Microsserviços (MSA). Seus princípios exigem uma decomposição ainda maior, priorizando funções (verbos) em vez de objetos (substantivos) como principal critério para dividir uma aplicação. Essa mudança de foco aparentemente sutil resulta em serviços mais granulares, pois há muito mais funções do que objetos em qualquer sistema.
A rede está pronta. A velocidade e a capacidade da rede física aumentaram drasticamente. O poder computacional também avançou de acordo com a Lei de Moore, tornando a latência da rede praticamente irrelevante.
Infelizmente, a latência na comunicação tomará o seu lugar.
Reproduzimos, dentro dos ambientes de contêineres usados 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 sustenta a Internet. As tags das aplicações — os metadados — precisam ser traduzidas em um endereço IP. Os registros de serviços e as entradas complexas de tabelas de IP funcionam como DNS em miniatura, traduzindo tags em endereços e permitindo a comunicação entre os serviços.
A natureza efêmera dos microsserviços e de seus respectivos contêineres agrava a latência associada a esse processo. Como seus ciclos de vida são medidos em segundos ou minutos, em vez de horas ou meses, a resolução de nomes precisa ocorrer a cada chamada. O tempo de vida (TTL) no mundo dos contêineres é, na prática, zero.
Mesmo que ignoremos essa reprodução de uma das maiores fontes de latência na comunicação, ainda resta a latência associada ao TCP. Iniciar ou encerrar uma conexão TCP não é — e nunca foi — uma operação sem custo. Essa fonte de latência é certamente pequena, mas seu efeito é cumulativo. Cada conexão — cada microsserviço — necessária para executar uma única transação acrescenta latência, que acaba ultrapassando o limite de tolerância a atrasos.
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 de conteúdos compostos por vários objetos, como páginas e aplicações web. Idealmente, os microsserviços são projetados para que cada serviço retorne uma única resposta. Embora várias solicitações por uma conexão já estabelecida certamente reduzam a sobrecarga de comunicação, isso não é possível em um sistema no qual várias solicitações são distribuídas entre vários serviços independentes .
O problema, portanto, não é a latência da rede, mas a latência da comunicação. As conexões ainda são relevantes, e as melhorias em protocolos projetados para aumentar o desempenho de comunicações baseadas na web e com múltiplas transações não ajudarão nas transações que envolvem vários serviços.
O resultado é a SOMA: Arquiteturas Orientadas a Serviços e Microsserviços. Um híbrido peculiar das arquiteturas orientada a serviços e de microsserviços, que nos faz questionar onde uma termina e a outra começa. A decomposição de aplicações em seus serviços componentes 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 nas redes certamente tenham aumentado a granularidade com que a decomposição pode ser realizada de forma razoável, eles não eliminaram essa limitação. Outro fator é que há várias ordens de grandeza mais funções em uma aplicação do que objetos. Isso torna a tarefa de gerenciar uma aplicação com arquitetura de microsserviços puros uma espécie de pesadelo logístico para as equipes de operações de rede, sem falar nos desenvolvedores de aplicações. Somado ao problema inerente causado pela latência de comunicação, isso faz com que as organizações desenvolvam cada vez mais microsserviços orientados a objetos, em vez de microsserviços verdadeiramente orientados a funções.
Em última análise, é por isso que vemos as aplicações serem decompostas para além da arquitetura tradicional de três camadas, mas não a ponto de representar fielmente uma decomposição baseada em funções.
Até que resolvamos a latência inerente às comunicações baseadas em conexão (TCP) — seja com algo novo, seja concentrando esforços nas implementações em nível de sistema —, continuaremos limitados a arquiteturas de microsserviços que têm menos de “micro” e mais de “serviços”.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
O estado da maturidade digital empresarial: a transformação digital ainda não terminou
Explore como a IA impacta as empresas, as aplicações da IA generativa, as estratégias para modernizar as operações de TI e os benefícios da maturidade digital com a F5.
Como a IA generativa acelera a transformação digital
Veja como a IA generativa impulsiona a transformação digital nas empresas, acelerando tendências como a integração de APIs, os desafios dos modelos operacionais de TI híbrida e a adoção de AIOps.
Seis capacidades técnicas para acelerar a transformação digital
As arquiteturas empresariais atuais carecem dos fatores necessários de agilidade, escalabilidade, segurança e observabilidade, essenciais para impulsionar a mudança tecnológica. No entanto, estas seis capacidades fundamentais ajudarão as empresas a gerenciar riscos e desafios ao longo de sua transformação digital.
Inverter a API é a transformação digital de que as empresas precisam para participar e competir em uma economia de APIs
As organizações detêm um valor latente — na forma de APIs internas — que precisam explorar para competir em uma economia de APIs. Embora os desafios técnicos e de segurança possam desestimular algumas delas, as empresas precisam reconhecer que inverter suas APIs permitirá liberar o valor da organização como plataforma.
A modernização da TI começa pela infraestrutura
O hardware e o software evoluíram rapidamente desde os primórdios da internet, mas, para aproveitar ao máximo os benefícios resultantes dessa evolução, as organizações precisam avaliar e modernizar sua infraestrutura e a entrega de aplicativos. Acelere os esforços de modernização com a nova F5 rSeries.