Os microsserviços (e seus grandes aliados, os contêineres, frequentemente mencionados) estão começando a conquistar desenvolvedores de todos os setores. Não são apenas as startups que estão adotando os princípios de design granular, fracamente acoplado e baseado exclusivamente em APIs dos microsserviços; as grandes empresas também estão entrando nesse jogo.
Com a crescente adoção (Datadog, uma provedora de monitoramento de infraestrutura em nuvem, registrou um crescimento de quase cinco vezes nos 12 meses desde setembro de 2014), surgem manifestações contundentes que decretam a morte das aplicações monolíticas e classificam sua arquitetura totalmente inadequada não apenas como ultrapassada, mas simplesmente ruim.
Mas, como observou um artigo recente no Gigaom, há prós e contras que precisam ser considerados antes de pegar a marreta e transformar cada aplicação monolítica em uma centena de microsserviços diferentes. Aliás, esse conceito não é novo. Martin Fowler, o pai dos microsserviços, escreveu sobre esses prós e contras há muito tempo e alertou contra o que só pode ser chamado de “adoção cega” dos microsserviços. Na verdade, o artigo do Gigaom apresenta, em linhas gerais, os mesmos argumentos de Fowler, embora de forma mais concisa.
Se você quer um resumo dos dois, basicamente é o seguinte: os microsserviços aumentam a complexidade operacional e podem afetar negativamente a experiência de uso da aplicação em termos de desempenho. Ambas são consequências indesejáveis — e muitas vezes não intencionais — que precisam ser compreendidas de antemão, antes que aquele sujeito ali no seu data center comece a usar a britadeira metafórica.
Dito tudo isso, por que diabos a Lori se importa? Afinal, nem ela nem a F5 trabalham com o desenvolvimento ou o design de aplicações. A F5 vai entregar essas aplicações, sejam elas monolíticas, baseadas em microsserviços ou em <insira aqui a próxima arquitetura de aplicações>.
Tudo isso é verdade. Mas nosso negócio é criar e implantar os serviços de aplicação que disponibilizam essas aplicações, e movimentos recentes como DevOps e microsserviços (e a febre dos contêineres) trazem as mesmas questões para o nosso domínio. Mais especificamente, você deveria decompor os serviços de aplicação normalmente implantados em uma plataforma ADC em serviços mais granulares e específicos para cada aplicação, seguindo um modelo mais alinhado à arquitetura de microsserviços?
Ainda é uma questão de escolhas
Independentemente de estarmos falando sobre a arquitetura do aplicativo ou sobre arquiteturas de serviços de aplicativos, a resposta continua sendo compreender as concessões envolvidas antes de tomar tal decisão.
A abordagem de plataforma (monolítica)
Essa é a abordagem tradicional para fornecer os serviços de aplicativos necessários para proteger, dimensionar e otimizar aplicações de todos os tipos. Os serviços são implantados em uma única plataforma compartilhada. Devido à arquitetura do proxy subjacente, essa abordagem oferece a vantagem de melhorar o desempenho. Isso ocorre porque todas as solicitações (e respostas) podem passar pelos serviços necessários sem sair do mesmo ambiente. Isso significa que não são necessários saltos adicionais de rede (nem a latência associada) ou conexões adicionais (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 apenas um, mas vários serviços.
A abordagem de proxy por aplicativo (microsserviços)
Esse modelo está mais alinhado ao DevOps e às práticas emergentes de arquitetura de aplicações. Cada serviço é implantado, gerenciado e dimensionado individualmente. Embora isso gere custos administrativos adicionais (afinal, há mais instâncias para gerenciar), parte desses custos é reduzida se cada serviço for implantado na mesma plataforma. Por outro lado, o modelo permite combinar serviços de diferentes provedores. A vantagem dessa abordagem é que os serviços podem estar mais estreitamente associados à arquitetura da aplicação — e, portanto, ser incluídos como parte dela —, inclusive com integração a frameworks de automação populares.
As mesmas desvantagens — especificamente, as relacionadas ao desempenho e ao aumento da complexidade — estão associadas à decomposição da entrega de aplicações nos serviços que a compõem. Por outro lado, os mesmos motivos pelos quais os desenvolvedores estão adotando microsserviços e evitando arquiteturas monolíticas — especificamente, o desejo por agilidade, diversidade e modularidade — também se aplicam à entrega de aplicações.
Vou simplesmente citar Martin Fowler: “Muitas equipes de desenvolvimento consideram o estilo arquitetural de microsserviços uma abordagem superior à arquitetura monolítica. No entanto, outras equipes constataram que ele pode ser um fardo que compromete a produtividade. Como qualquer estilo arquitetural, os microsserviços trazem custos e benefícios. Para fazer uma escolha sensata, é preciso compreendê-los e aplicá-los ao seu contexto específico.”
Essa afirmação se aplica igualmente aos serviços de aplicação. Tanto a abordagem tradicional (monolítica) quanto a moderna (microsserviços) apresentam custos e benefícios que precisam ser considerados no contexto da aplicação que irão disponibilizar, proteger e otimizar.
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
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...