Integrando monólitos a microsserviços

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Existe uma crença fantasiosa de que basta pegar um monólito, colocá-lo em um contêiner e voilà! Você passa a ter os benefícios de escala e velocidade de uma arquitetura moderna.

Na verdade, uma pesquisa da KubeCon de 2018 indicou que é exatamente isso que está acontecendo com cerca de 55% dos entrevistados, que afirmaram usar contêineres "como substitutos de máquinas virtuais para aplicações existentes". Outras pesquisas mostram uma quantidade significativa de aplicações Java de nível empresarial sendo executadas em contêineres. Uma pesquisa da Diamanti de 2018 mostrou que, embora a maioria (54%) usasse contêineres para aplicações nativas da nuvem, quase um terço (31%) os utilizava para modernizar aplicações legadas.

Os motivos citados geralmente são de natureza operacional; os contêineres são considerados mais fáceis de gerenciar, apesar da enorme quantidade de componentes dinâmicos que precisam ser administrados. O desempenho e os custos de licenciamento também costumam influenciar a decisão de adotar contêineres.

Mas essa migração não é tão simples quanto empacotar um aplicativo legado e colocá-lo em um contêiner.

A realidade é que os monólitos — aplicações cliente-servidor e web tradicionais — têm certas características que dificultam sua migração direta para um contêiner e o aproveitamento dos benefícios operacionais. Contêineres e microsserviços não são necessariamente usados em conjunto, mas ambos seguem os princípios de “projetado para falhar”, nos quais se baseia a disponibilidade das aplicações modernas. Caso você não conheça esse princípio, ele estabelece que, se um contêiner falhar, basta iniciar outro para substituí-lo. Todos os contêineres são como gado, e qualquer um serve tão bem quanto o outro.

Em arquiteturas de aplicações sem estado deliberadamente modernas, isso é verdade. Já em arquiteturas tradicionais de aplicações com estado, nem tanto.

Veja bem, as aplicações cliente-servidor e suas sucessoras, as aplicações web de três camadas, geralmente mantêm estado. Elas armazenam em uma sessão determinadas informações sobre a interação entre o cliente e a aplicação. Essa sessão pode ser mantida na memória do servidor de aplicações ou do servidor web, ou em um banco de dados separado. Independentemente de onde esses dados sejam armazenados, são eles que fazem com que a aplicação mantenha estado. Esses dados são relevantes e importantes para o funcionamento da aplicação. Eles incluem seu carrinho de compras, a última página que você visitou e outras informações específicas da aplicação.

Você pode imaginar que, se o servidor web/de aplicativo no qual essas informações estão armazenadas desaparecer de repente, isso prejudicará a experiência do cliente. Meu carrinho sumiu. Preciso voltar para onde estava. Basicamente, preciso começar tudo de novo.

Esse comportamento é diametralmente oposto aos princípios arquiteturais modernos, que eliminam a operação com estado de uma aplicação. É a natureza sem estado dos aplicativos e serviços modernos que permite substituir uma instância por outra de forma transparente quando algo dá errado. Essa é a base sobre a qual funciona o conceito de "projetado para falhar". Se você reintroduzir o estado nessa equação, de repente tudo desmorona.

Embora o aplicativo continue funcionando, o usuário fica sem saber o que fazer. Seu fluxo é interrompido, e suas transações são lançadas no limbo, para nunca mais serem vistas.

Esse problema deu origem à necessidade de os serviços de aplicação preservarem o estado. Depois que um cliente se conectava a um determinado servidor de aplicação/web, ele precisava continuar se conectando ao mesmo servidor durante toda a sessão. A persistência por cookies e outros mecanismos foram desenvolvidos para garantir que as solicitações fossem sempre encaminhadas ao mesmo servidor, preservando assim o estado.

A realidade é que, a menos que você seja uma startup criada do zero, sua empresa tem aplicações tradicionais e modernas em execução neste momento. Embora os estudos sobre o tema apresentem variações, a proporção de "63% de aplicações legadas / 37% de aplicações novas" permanece praticamente constante ao longo do tempo. Isso significa que você precisa oferecer suporte simultâneo a arquiteturas legadas e modernas.

Simplesmente mover o monólito para um contêiner não vai ajudar se você ainda não tiver resolvido a divisão entre aplicações com estado e sem estado.

DIVISÃO EM CAMADAS ARQUITETURAIS

A melhor — ou pelo menos a mais fácil — maneira de gerenciar a migração de monólitos para um ambiente conteinerizado é garantir que ainda seja possível respeitar o estado, mesmo na anarquia sem estado de um cluster de contêineres. Isso exige certa inteligência na borda do cluster, no ponto de entrada onde o tráfego N-S encontra o E-W.

Uma abordagem em duas camadas oferece suporte tanto a modelos operacionais tradicionais quanto modernos, bem como à migração de aplicações tradicionais com estado para um ambiente conteinerizado. Ao aproveitar o F5 Container Ingress Services (CIS), a equipe de NetOps pode continuar atendendo às necessidades das aplicações com estado durante sua migração para ambientes conteinerizados. A conectividade garante que os métodos tradicionais de balanceamento de carga que utilizam persistência continuem funcionando e direcionando as solicitações para o contêiner correto ou diretamente para um ambiente tradicional.

Enquanto isso, o BIG-IP pode direcionar simultaneamente solicitações de aplicações e APIs modernas para um controlador de entrada dentro do cluster de contêineres, para distribuição entre quantos contêineres sem estado forem necessários.

Transições levam tempo

A realidade é que a maioria das organizações oferece suporte a até cinco arquiteturas de aplicações bastante distintas — de monólitos a aplicações móveis e microsserviços. Oferecer simultaneamente suporte a uma quantidade equivalente, porém distinta, de modelos de rede e operação certamente sobrecarregará as equipes de operações e anulará os benefícios da migração para arquiteturas e ambientes modernos. Uma abordagem estratégica em duas camadas permite que as organizações aproveitem os benefícios operacionais e comerciais de ambos os modelos durante a transição para um ambiente predominantemente conteinerizado.

OPÇÃO DE REFATORAÇÃO

Uma das medidas que você pode adotar para facilitar essa transição é refatorar aplicações legadas para aproveitar sessões compartilhadas. Essas sessões são armazenadas em um local separado do servidor web/de aplicações — geralmente algum tipo de banco de dados — e podem ser acessadas por qualquer servidor web/de aplicações que tenha o ID de sessão correto. Ainda será necessário controlar o ID de sessão, mas isso geralmente pode ser feito por meio de um cookie que persiste independentemente do estado do servidor web/de aplicações. Se as aplicações legadas ainda não utilizarem um modelo de sessão compartilhada, refatorá-las para adotá-lo é um processo relativamente simples em comparação com a migração de toda a aplicação para uma nova plataforma.

Como essas transições levam tempo — afinal, ainda hoje quase todos operamos em um modelo multinuvem —, é importante identificar e aproveitar opções arquitetônicas que maximizem os benefícios sem comprometer necessidades essenciais dos clientes, como disponibilidade e segurança. Uma abordagem arquitetônica de duas camadas oferece ambos os benefícios sem limitar os esforços de conteinerização.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

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 Vittie