Monolítico vs. Arquitetura de microsserviços: Os microsserviços estão fora, os monólitos estão de volta

Para aqueles que sentem que estão sofrendo um caso grave de déjà vu técnico, vocês não estão errados. Esta é 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 postagem de Manes porque o original parece ter sido engolido pela Internet.

Agora, Manes estava sendo hiperbólico e um tanto sarcástico porque, como bem sabemos, a arquitetura orientada a serviços não morreu. Ele foi ressuscitado rapidamente como microsserviços e, pela lamentação da Internet, os designers ainda não aprenderam o quão grande é o papel que “a rede” desempenha no desempenho.

SOA ‘morreu’ por dois motivos:

1. Padrões XML concorrentes e inchados que tornavam as arquiteturas excessivamente complexas. Ninguém se lembra com carinho de WSDL, SOAP e UDDI. Ninguém.
2. As leis da física e os padrões de interoperabilidade restringem a troca de pacotes de rede à velocidade da luz e a 1500 bytes.

Podemos ter superado o primeiro desafio, mas e o segundo? A única resposta para a segunda questão foi e continua sendo um equilíbrio delicado entre a granularidade do design do serviço e uma boa compreensão do tempo que leva para transferir dados entre os serviços.

A transferência de dados não é gratuita. Leva tempo. Não existe “custo zero” quando se trata de comunicações entre serviços. Há o tempo que leva para colocar um pacote na rede, depois transferi-lo, retirá-lo do pacote e, finalmente, 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 não é gratuito, assim como o tempo que leva para serializar e desserializar cargas úteis 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 para processar uma solicitação depende do número de serviços pelos quais a solicitação deve passar.

Maior granularidade? Maior tempo de processamento. Mais serviços? Maior congestionamento na rede, o que aumenta o tempo de processamento, pois as placas de rede e os dispositivos tentam colocar os pacotes em ordem e exigem retransmissão.

Então, assim como SOA, os microsserviços podem e irão sofrer com padrões de design que dependem de muita granularidade.

A Amazon escolheu um monólito para substituir seus microsserviços. Isso significa que, para seu caso de uso, uma arquitetura monolítica era a melhor opção. Isso significa que os microsserviços estão mortos?

Não. Em vez disso, deveríamos retirar dois pontos-chave:

• Primeiro, devemos seguir o exemplo da Amazon e ser mais deliberados e cuidadosos sobre como projetamos sistemas que dependem de serviços e garantir que entendemos as implicações no desempenho da divisão de tarefas entre muitos serviços pequenos.
• Em segundo lugar, devemos lembrar que os monólitos são uma escolha viável de arquitetura de aplicação. Há uma razão pela qual 60% de um portfólio de aplicativos corporativos é composto por aplicativos baseados em arquitetura “tradicional” e 16% das organizações não têm planos de desativá-los.

Arquiteturas de aplicativos não são boas nem ruins, nem são apropriadas para todos os casos de uso. As organizações precisam dar um passo para trás e considerar 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" porque, bem, está na moda.

Quando dizemos que o futuro é a TI híbrida, queremos dizer mais do que apenas uma mistura de implantações multinuvem e locais. Também queremos dizer que o portfólio de aplicativos empresariais permanecerá híbrido — uma mistura de tradicional e moderno — no futuro próximo. É por isso que o portfólio F5 continua a oferecer suporte a todos os aplicativos, sejam eles locais ou na nuvem pública, ou ambos.