Mania de malha de serviço: Escolhendo Aspen Mesh ou NGINX
Junto com o ecossistema de contêineres maior, as malhas de serviço continuam avançando em direção à maturidade. Ainda estamos no começo, porém, e há uma variedade de abordagens sendo aplicadas para resolver o problema do gerenciamento de tráfego intracontêiner com malhas de serviço.
Nós (o Nós corporativo) respondemos a muitas perguntas antes da aquisição oficial da NGINX nesta primavera. Vários deles se concentraram em áreas de "sobreposição" em tecnologia e soluções. Afinal, tanto o NGINX quanto o F5 oferecem soluções de entrega de aplicativos baseadas em proxy. Tanto o NGINX quanto o F5 estão construindo uma malha de serviços. A questão era: qual deles venceria?
Porque é assim que geralmente funciona com aquisições.
Como meu colega da NGINX e eu frequentemente reiteramos, as tecnologias apontadas como sobrepostas eram, em nossa opinião, mais complementares do que competitivas. Isso também se aplica às nossas soluções de malha de serviço.
Nossa lógica decorre de uma visão compartilhada de entrega de aplicativos. Ambos vemos o impacto que contêineres e nuvem, microsserviços e uma preponderância de violações de segurança estão tendo nas arquiteturas e modelos de entrega de aplicativos. Da mesma forma que não existe mais "um caminho de dados para entregar todos os aplicativos", não existe mais "um modelo de entrega de aplicativos para entregar todos os serviços de aplicativos". A nuvem introduz vários caminhos de dados. Os contêineres introduzem um novo caminho de dados. Ambos ampliam o possível posicionamento de serviços de aplicativos de um proxy baseado em rede (um ADC) para uma longa lista de locais que vão do cliente à rede, do servidor ao contêiner e à nuvem.
Como observamos em uma postagem focada em arquiteturas em nossa série Bridging the Divide , a escolha de onde e como os serviços de aplicativos são entregues depende de muitos fatores. Não é apenas uma escolha entre implementações de fornecedores ou "empresa versus FOSS"; é uma escolha que deve levar em consideração a localização (nuvem ou local), o modelo operacional e até mesmo a facilidade de implementação versus a funcionalidade necessária. Considerando a amplitude do caminho de entrega, isso fornece diversas opções para inserir serviços de aplicativos.
É por isso que vemos nosso portfólio combinado F5 e NGINX como complementar e não competitivo. Porque o mercado geral de entrega de aplicativos não está mais competindo pela colocação em um único local, mas sim pela colocação em vários locais.
As malhas de serviço são projetadas para dimensionar, proteger e fornecer visibilidade em ambientes de contêiner. Sendo uma tecnologia emergente e em rápida evolução, há diversos modelos surgindo. Um é baseado no uso de um proxy sidecar ( o Envoy surgiu como um projeto CNCF líder e o proxy sidecar padrão da indústria) e o outro aproveita os proxies por aplicativo, à la NGINX Plus .
Atualmente, planejamos oferecer suporte a ambos porque os clientes têm opiniões muito fortes sobre suas escolhas de infraestrutura quando se trata de contêineres. Alguns preferem Istio e Envoy e outros são padronizados em tudo que é NGINX.
O número de componentes que devem ser operados e gerenciados em um ambiente de contêiner é tal que a experiência existente em tecnologia é um fator importante na escolha de uma malha de serviço. As organizações que padronizaram o NGINX para sua infraestrutura provavelmente gravitarão em direção a uma solução de malha de serviço NGINX porque ela abrange todo o software NGINX, do proxy NGINX ou da unidade NGINX ao controlador NGINX. A experiência operacional existente no NGINX e seu ecossistema de código aberto pode significar menos atrito e atrasos na implantação.
Outras organizações têm as mesmas opiniões sobre soluções alternativas de código aberto, como Istio e Envoy. O Aspen Mesh usa o Envoy e é implementado no Istio, por isso é uma opção mais natural para organizações com investimentos existentes na tecnologia subjacente. É uma distribuição testada, reforçada, empacotada e verificada do Istio. 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, medir e aplicar metas de negócios, além de ferramentas como o Istio Vet e o Traffic Claim Enforcer . O Aspen Mesh, assim como o NGINX, 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 oferecem sua solução como uma opção local. Ambos fornecem rastreamento e métricas essenciais para abordar a questão da visibilidade, um dos principais desafios de produção observados por 37% das organizações no Relatório do Estado do Kubernetes da Replex .
Organizações que preferem uma abordagem baseada em proxy sidecar para service mesh preferirão o Aspen Mesh. As organizações que acreditam que as malhas de serviços baseadas em proxy por aplicativo atendem melhor às suas necessidades preferirão o NGINX.
Sua escolha depende de uma variedade de fatores e acreditamos que esse espaço emergente é importante o suficiente para continuar a dar suporte a escolhas que abordem diferentes combinações de necessidades e requisitos.