Todo mundo, calma. Respirem fundo e, em seguida, vamos entrar devagar no meio da guerra entre microsserviços e monólitos que está acontecendo na internet.
O resumo:
Recentemente, a Amazon publicou um estudo de caso documentando sua decisão de abandonar os microsserviços e adotar os monólitos, citando uma redução de 90% nos custos. Esse estudo de caso provocou uma enxurrada de comentários e tuítes sarcásticos na Internet, colocando microsserviços e monólitos frente a frente no ringue técnico.
A realidade:
Para aqueles que sentem estar sofrendo de um grave caso de déjà vu técnico, essa impressão não está errada. Essa é a mesma situação em que a arquitetura orientada a serviços (SOA) se encontrava por volta de 2009, quando Anne Thomas Manes declarou sua morte. O link leva a um comentário de David Linthicum sobre a publicação de Manes, pois o original parece ter sido engolido pela Internet.
Manes estava sendo hiperbólica e um tanto sarcástica porque, como bem sabemos, a arquitetura orientada a serviços não morreu. Ela ressurgiu rapidamente na forma de microsserviços e, para a consternação da Internet, os projetistas ainda não aprenderam o quanto “a rede” influencia o desempenho.
A SOA “morreu” por dois motivos:
- Padrões concorrentes e inchados baseados em XML, que tornavam as arquiteturas excessivamente complexas. Ninguém se lembra de WSDL, SOAP e UDDI com carinho. Ninguém.
- As leis da física e os padrões de interoperabilidade limitam a troca de pacotes de rede à velocidade da luz e a 1.500 bytes.
Talvez tenhamos superado o primeiro desafio, mas e o segundo? A única resposta para o segundo tem sido, e continua sendo, encontrar um equilíbrio delicado entre a granularidade do design dos serviços e uma boa compreensão do tempo necessário para transferir dados entre eles.
A transferência de dados não é gratuita. Ela leva tempo. Não existe “custo zero” quando se trata da comunicação entre serviços. Há o tempo necessário para colocar um pacote na rede, transferi-lo, retirá-lo do pacote e, por fim, processá-lo. E não se esqueça de que as comunicações de transporte também levam tempo. Abrir sockets e aceitar solicitações também tem um custo, assim como o tempo necessário para serializar e desserializar payloads em algo que o serviço possa processar.
Agora, multiplique esse custo total pelo número de serviços que você está tentando usar.
Quanto mais granular for o design do seu sistema, mais tempo levará para processar uma solicitação. Em outras palavras, o tempo total de processamento de uma solicitação depende do número de serviços pelos quais ela precisa passar.
Maior granularidade? Maior tempo de processamento. Mais serviços? Maior congestionamento na rede, o que acaba aumentando o tempo de processamento à medida que placas de rede e dispositivos tentam colocar os pacotes em ordem e solicitam a retransmissão.
Portanto, assim como a SOA, os microsserviços podem sofrer — e sofrerão — com padrões de projeto que dependem de granularidade excessiva.
A Amazon optou por um monólito para substituir seus microsserviços. Isso significa que, para o caso de uso da empresa, uma arquitetura monolítica era a melhor opção. Isso quer dizer que os microsserviços estão mortos?
Não. Em vez disso, devemos tirar duas conclusões principais:
- Primeiro, devemos seguir o exemplo da Amazon e ser mais criteriosos e cuidadosos ao projetar sistemas que dependem de serviços, garantindo que compreendamos as implicações para o desempenho de distribuir responsabilidades entre um número excessivo de pequenos serviços.
- Em segundo lugar, devemos lembrar que os monólitos são uma opção viável de arquitetura de aplicações. Há uma razão para que 60% do portfólio de aplicações de uma empresa seja composto por aplicações baseadas em uma arquitetura “tradicional”, e 16% das organizações não tenham planos de descontinuá-las.
As arquiteturas de aplicações não são boas nem ruins, tampouco são adequadas para todos os casos de uso. As organizações precisam dar um passo atrás e avaliar cuidadosamente o que estão tentando alcançar e qual arquitetura pode atender melhor a essa necessidade, em vez de escolher a arquitetura mais “moderna” simplesmente porque, bem, está na moda.
Quando dizemos que o futuro é a TI híbrida, estamos falando de mais do que apenas uma combinação de implantações multicloud e locais. Também queremos dizer que o portfólio de aplicações empresariais continuará híbrido — uma combinação de arquiteturas tradicionais e modernas — no futuro próximo. É por isso que o portfólio da F5 continua oferecendo suporte a todas as aplicações, sejam elas executadas localmente, na nuvem pública ou em ambos os ambientes.
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.