Sobre monólitos versus microsserviços

Os microsserviços (e seus melhores amigos, os contêineres, frequentemente mencionados) estão começando a dominar os corações e mentes dos desenvolvedores em geral. Não são apenas as startups que estão adotando os princípios de design granular, somente API e frouxamente acoplados dos microsserviços; grandes empresas também estão entrando no jogo.

Com a adoção crescente ( Datadog , um provedor de monitoramento de infraestrutura em nuvem, viu um crescimento de quase 5x nos 12 meses desde setembro de 2014), vêm os gritos mais altos declarando a morte dos aplicativos monolíticos e sua arquitetura totalmente inadequada, não apenas por serem ultrapassados, mas simplesmente ruins.

Mas, como observou um artigo recente no Gigaom , há compensações que precisam ser consideradas antes de sacar a britadeira e dividir cada monolítico em cem microsserviços diferentes. Aliás, esse não é um conceito novo. O pai dos microsserviços, Martin Fowler, escreveu sobre essas compensações há muito tempo e alertou sobre o que só pode ser considerado “adoção cega” de microsserviços.  Na verdade, o artigo do Gigaom geralmente aborda os mesmos pontos que Fowler, embora em um formato mais conciso.

Se você está procurando o TL;DR em ambos, basicamente tudo se resume a isto: microsserviços adicionam complexidade operacional e podem impactar negativamente a experiência do aplicativo em termos de desempenho. Ambas são consequências indesejáveis — e muitas vezes não intencionais — que precisam ser entendidas desde o início, antes que aquele sujeito ali no seu data center comece com a britadeira alegórica.

Dito isso, por que diabos Lori se importa? Afinal, nem ela nem a F5 estão no ramo de criar ou projetar aplicativos. A F5 vai entregar esses aplicativos, sejam eles monólitos ou microsserviços ou a próxima arquitetura de aplicativo aqui>.

Tudo verdade. Mas nosso negócio é criar e implantar os serviços de aplicativos que entregam esses aplicativos, e movimentos recentes como DevOps e microsserviços (e a febre dos contêineres) trazem as mesmas questões para o nosso domínio. Ou seja, você deve decompor os serviços de aplicativo normalmente implantados em uma plataforma ADC em serviços mais granulares e afins ao aplicativo em um modelo que se alinhe mais de perto com a arquitetura de microsserviços?

Ainda sobre compensações

Independentemente de estarmos falando sobre arquitetura de aplicativo ou arquiteturas de serviço de aplicativo, a resposta continua sendo entender as compensações envolvidas antes de tomar tal decisão.

A abordagem da plataforma (monolítica)

Essa é a abordagem tradicional para fornecer os serviços de aplicativos necessários para proteger, dimensionar e otimizar aplicativos de todos os tipos. Os serviços são implantados em uma plataforma única e compartilhada. Devido à arquitetura do proxy subjacente, essa abordagem tem a vantagem de melhorar o desempenho. Isso ocorre porque todas as solicitações (e respostas) podem percorrer os serviços necessários sem sair do mesmo ambiente. Isso significa que não são necessários saltos de rede adicionais (e a latência associada) ou conexões (recursos, latência). Cada serviço ainda pode ser dimensionado e gerenciado individualmente, mas todos dependem de um único hardware compartilhado (COTS ou personalizado). Isso significa que o hardware compartilhado é um ponto único de falha que afetará não um, mas muitos serviços

A abordagem de proxy por aplicativo (microsserviços)

Este modelo se alinha mais de perto com o DevOps e as práticas de arquitetura de aplicativos emergentes. Cada serviço é implantado, gerenciado e dimensionado individualmente. Embora isso implique custos administrativos adicionais (afinal, há mais instâncias para gerenciar), alguns desses custos são atenuados se cada serviço for implantado na mesma plataforma, mas oferece a capacidade de “misturar e combinar” serviços de diferentes provedores. As vantagens dessa abordagem são que os serviços podem ser mais intimamente associados – e, portanto, incluídos como parte – da arquitetura do aplicativo, incluindo a integração com estruturas de automação populares.

As mesmas desvantagens – nomeadamente as de desempenho e complexidade crescente – estão associadas à decomposição da entrega de aplicações nos seus serviços de aplicações compostos. Por outro lado, os mesmos motivos pelos quais os desenvolvedores estão adotando microsserviços e evitando monólitos – ou seja, o desejo por agilidade, diversidade e modularidade – também são verdadeiros para a entrega de aplicativos.

Vou simplesmente citar Martin Fowler: “ Muitas equipes de desenvolvimento descobriram que o estilo arquitetônico de microsserviços é uma abordagem superior a uma arquitetura monolítica. Mas outras equipes descobriram que eles eram um fardo que minava a produtividade. Como qualquer estilo arquitetônico, os microsserviços trazem custos e benefícios. Para fazer uma escolha sensata, você precisa entendê-las e aplicá-las ao seu contexto específico.”

Esta afirmação se aplica igualmente bem aos serviços de aplicativos. Tanto a abordagem tradicional (monolítica) quanto a moderna (microsserviços) têm custos e benefícios que precisam ser considerados dentro do contexto do aplicativo que serão entregues, protegidos e otimizados.