Juntamente com o ecossistema mais amplo de contêineres, as malhas de serviço continuam avançando rumo à maturidade. No entanto, ainda estamos nos estágios iniciais, e diversas abordagens estão sendo aplicadas para resolver o problema do gerenciamento do tráfego entre contêineres com malhas de serviço.
Nós (isto é, o “nós” corporativo) recebemos muitas perguntas no período que antecedeu a aquisição oficial da NGINX por nós nesta primavera. Várias delas se concentravam em áreas de “sobreposição” de tecnologias e soluções. Afinal, tanto a NGINX quanto a F5 oferecem soluções de entrega de aplicações baseadas em proxy. Tanto a NGINX quanto a F5 estão desenvolvendo uma malha de serviços. A pergunta era: qual delas venceria?
Porque é assim que as coisas geralmente funcionam em aquisições.
Como eu e meu colega da NGINX reiteramos diversas vezes, em nossa avaliação, as tecnologias apontadas como sobrepostas eram mais complementares do que concorrentes. Isso também se aplica às nossas soluções de malha de serviços.
Nossa lógica parte de uma visão compartilhada sobre a entrega de aplicações. Ambos reconhecemos o impacto que os contêineres e a nuvem, os microsserviços e a predominância de violações de segurança estão causando nas arquiteturas e nos modelos de entrega de aplicações. Assim como já não existe "um único caminho de dados para entregar todas as aplicações", também não existe mais "um único modelo de entrega de aplicações para fornecer todos os serviços de aplicação". A nuvem introduz vários caminhos de dados. Os contêineres introduzem um novo caminho de dados. Ambos ampliam as possibilidades de posicionamento dos serviços de aplicação, que deixam de se limitar a um proxy baseado em rede (um ADC) e passam a abranger uma extensa lista de locais, desde o cliente até a rede, o servidor, o contêiner e a nuvem.
Como observamos em uma publicação sobre arquiteturas da nossa série Bridging the Divide, a escolha de onde e como fornecer serviços de aplicações depende de muitos fatores. Não se trata apenas de escolher entre implementações de fornecedores ou entre "soluções empresariais e software livre e de código aberto (FOSS)"; é uma escolha que deve levar em conta a localização (na nuvem ou no ambiente local), o modelo operacional e até mesmo a facilidade de implementação em relação à funcionalidade necessária. Considerando a amplitude do caminho de entrega, há várias opções para inserir serviços de aplicações.

É por isso que consideramos nosso portfólio combinado da F5 e da NGINX complementar, e não concorrente. Isso porque, no mercado geral de entrega de aplicações, a disputa não é mais por presença em um único local, mas sim em vários locais.
As malhas de serviço são projetadas para oferecer escalabilidade, segurança e visibilidade em ambientes de contêineres. Como essa é uma tecnologia emergente e em rápida evolução, vários modelos estão surgindo. Um deles se baseia no uso de um proxy sidecar (Envoy se consolidou como um dos principais projetos da CNCF e como o proxy sidecar padrão do setor), enquanto o outro utiliza proxies por aplicativo, como o NGINX Plus.
Atualmente, planejamos oferecer suporte a ambos, pois os clientes têm opiniões muito fortes sobre suas escolhas de infraestrutura quando se trata de contêineres. Alguns preferem Istio e Envoy, enquanto outros padronizaram tudo com NGINX.
A quantidade de componentes que precisam ser operados e gerenciados em um ambiente de contêineres faz com que a experiência prévia com a tecnologia seja um fator importante na escolha de uma malha de serviços. As organizações que padronizaram sua infraestrutura com o NGINX tendem naturalmente a optar por uma solução de malha de serviços do NGINX, pois ela é composta inteiramente por software NGINX, desde o proxy NGINX ou o NGINX Unit até o NGINX Controller. A experiência operacional prévia com o NGINX e seu ecossistema de código aberto pode reduzir os atritos e atrasos na implantação.
Outras organizações têm a mesma visão sobre soluções alternativas de código aberto, como Istio e Envoy. Aspen Mesh usa o Envoy e é implementado sobre o Istio, sendo uma opção mais natural para organizações que já investiram na tecnologia subjacente. Trata-se de uma distribuição do Istio testada, robusta, empacotada e validada. O Aspen Mesh adiciona vários recursos ao Istio, incluindo uma experiência de usuário mais simples por meio do painel do Aspen Mesh, uma estrutura de políticas que permite aos usuários especificar, mensurar e aplicar metas de negócios, além de ferramentas como Istio Vet e Traffic Claim Enforcer. Assim como o NGINX, o Aspen Mesh também se integra bem ao F5 BIG-IP.
Tanto o NGINX quanto o Aspen Mesh oferecem gerenciamento e visualização de clusters do Kubernetes. O Aspen Mesh e o NGINX disponibilizam suas soluções como opções locais. Ambos fornecem rastreamento e métricas essenciais para solucionar o problema de visibilidade, um dos principais desafios em ambientes de produção, apontado por 37% das organizações no Relatório sobre o estado do Kubernetes da Replex.
As organizações que preferem uma abordagem de service mesh baseada em proxies sidecar optarão pelo Aspen Mesh. Já as organizações que acreditam que service meshes baseados em proxies por aplicativo atendem melhor às suas necessidades optarão pelo NGINX.
Sua escolha depende de diversos fatores, e acreditamos que esse espaço emergente seja importante o suficiente para continuarmos apoiando opções que atendam a diferentes combinações de necessidades e requisitos.
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...