NGINX Sprint 2.0: Visão clara, código novo, novos compromissos com o código aberto

Todos os anos, no NGINX Sprint , compartilhamos nossas melhores e mais recentes tecnologias. É a melhor parte do ano! Revelamos o novo código e as versões do produto que criamos enquanto nos esforçamos para melhorar a vida cotidiana da nossa comunidade e dos nossos clientes. Mas este ano é um pouco diferente. Claro, revelaremos novos projetos e produtos. Mais sobre isso abaixo. Mas eu seria negligente se não parasse um momento para dar um passo para trás e ser explícito sobre a visão que orienta nossos esforços. E o mais importante, como essa visão resulta em um conjunto de compromissos que queremos assumir com nossa comunidade.

Aqui na F5, nossa visão para o futuro são applications que se adaptam. O que queremos dizer com “ applications adaptativas ”? Pense em aplicativos que agem como organismos. Eles crescem, encolhem, curam e se defendem de forma autônoma, ajudando a reduzir a necessidade de intervenção manual constante.

Enfatizo a palavra “autonomamente” por um motivo. À medida que criamos a próxima geração de serviços digitais, os applications subjacentes não conseguem mais executar na velocidade humana e são limitados pela presença de humanos no circuito. Eles devem ser inteligentes o suficiente para se adaptar ao ambiente, com base no contexto e nas condições. Eles devem fazer mudanças por conta própria, como organismos vivos.

Já estamos explorando como o aprendizado de máquina pode impulsionar a inteligência adaptativa. No entanto, há alguns passos intermediários necessários para chegarmos lá. Veja como estamos pensando sobre o caminho para aplicativos adaptáveis e como nossos lançamentos de tecnologia e roteiro de produtos contribuem para atingir essa visão.

Acreditamos que há três ondas de entrega de application modernos. O foco da primeira onda foi permitir simultaneidade e escala massivas. Essa foi a onda que deu origem ao NGINX, em resposta ao surgimento de applications em escala web.

A segunda onda, que estamos surfando agora, é quando os applications se desvinculam em microsserviços e se conectam por meio de APIs para se tornarem mais distribuídos e resilientes. O Kubernetes e a conteinerização estão impulsionando essa onda, que realmente começou com o crescimento da computação em nuvem. A segunda onda também permitiu um tremendo progresso na automação, entregando a primeira geração de aplicativos adaptáveis. O comportamento adaptativo pode ser tão simples quanto o dimensionamento automático e tão complexo quanto mecanismos de políticas que se autocorrigem observando o desempenho de APIs e applications .

A segunda onda estabelece as bases para a terceira onda, que consistirá em dotar os applications de inteligência mais sofisticada e aprendizado de máquina, tornando-os ambientalmente conscientes e verdadeiramente capazes de se adaptar sem intervenção humana.

Vimos um padrão comum surgindo entre usuários e clientes do NGINX que implantaram com sucesso aplicativos modernos em clusters Kubernetes à medida que a segunda onda continua. Nós o chamamos de padrão “Cluster Out” e ele inclui três estágios, representados no diagrama e descritos abaixo.

Etapa 1: Construa uma base sólida para o Kubernetes

Muitas empresas ainda estão se atualizando com o Kubernetes e os contêineres. E, francamente, o Kubernetes requer considerável personalização e ajustes para torná-lo pronto para produção. Embora seja uma plataforma poderosa de uso geral para vários casos de uso, o Kubernetes pronto para uso ainda não possui os recursos de entrega e segurança de application que você realmente precisa para implantar, gerenciar e proteger aplicativos de produção.

Resumindo, se um ambiente de produção do Kubernetes não for estável, os desenvolvedores ficarão relutantes em implantar seu código nele. Para dar aos desenvolvedores a confiança necessária, você deve adicionar rede de Camada 7, observabilidade e segurança ao seu ambiente de produção do Kubernetes. Você resolve esse desafio com controladores Ingress , WAFs e malhas de serviço , juntamente com outros projetos nativos da nuvem, como o Prometheus .

Etapa #2: Gerencie APIs com segurança dentro e fora do cluster

Depois que você tem uma base Kubernetes de nível de produção, os desenvolvedores estão dispostos a implantar mais código nela. Este é o fenômeno “se você construir, eles virão”. Você verá que o número de microsserviços e aplicativos cresce rapidamente, junto com o número de APIs que eles usam para se comunicar, tanto com outros serviços no cluster quanto com clientes e applications externos. Chamadas de API internas ( de serviço para serviço ) geralmente superam as externas ( de aplicativo para cliente ) por um fator de 10 ou mais.

À medida que seu ambiente de aplicativo cresce, surgem novos desafios que sua base Kubernetes não consegue resolver, incluindo requisitos para autenticação de API mais sofisticada, autorização, roteamento/modelagem e gerenciamento de ciclo de vida. É essencial ter ferramentas que ajudem você a proteger, gerenciar, versionar e descontinuar APIs, que podem chegar a centenas ou milhares em ambientes complicados. Nesta fase de movimento para fora do cluster, você precisa de tecnologias como gateways de API, gerenciamento de API e ferramentas de segurança de API – elas permitem o dimensionamento contínuo dos serviços à medida que os desenvolvedores fazem alterações e tornam os applications mais robustos.

Etapa #3: Torne o Cluster Resiliente

O terceiro estágio na implementação do padrão Cluster Out é pensar em como conectar um ambiente Kubernetes com outros ambientes, sejam eles outros clusters ou implantações de aplicativos em VMs ou bare metal. Afinal, estamos projetando applications nativos da nuvem que são distribuídos, fracamente acoplados e resilientes.

No mínimo, os applications modernos devem ser capazes de se comunicar entre vários clusters do Kubernetes para criar níveis mais altos de resiliência e executar políticas mais inteligentes (para controle de custos, por exemplo). De forma mais ampla, porém, as applications modernas raramente são ilhas. É muito mais provável que eles estejam entrelaçados em uma rede de serviços externos, buckets de armazenamento e APIs de parceiros que provavelmente estão localizados em outros ambientes. Mesmo internamente, applications complexos podem precisar se comunicar com outros applications internos que não estejam alocados em um cluster, zona de disponibilidade ou data center.

Esta é a próxima etapa da migração do cluster para o ambiente externo, e aqui novamente o Kubernetes pronto para uso não resolve seus desafios. Você precisa conectar seu perímetro do Kubernetes – o controlador Ingress – automaticamente a tecnologias externas, como balanceadores de carga de camada 4 , controladores de entrega de application e serviços DNS para rotear o tráfego e lidar com failovers.

Na realidade, o padrão Cluster Out é apenas uma receita para o sucesso do Kubernetes que vimos os primeiros usuários usarem. Como uma estrutura de priorização, é um caminho lógico e metódico para operar contêineres em escala em um ambiente empresarial que ajuda você a adotar o Kubernetes e aplicativos modernos de forma mais eficiente.

O poder dessa abordagem é que ela oferece às equipes de plataforma uma maneira sistemática de reforçar o Kubernetes na produção. Mas não é aí que as implantações do Kubernetes começam. Eles começam com desenvolvedores criando pilhas de application compostas de ferramentas de código aberto. Nós entendemos isso. Por mais de 15 anos, o código aberto esteve no coração do NGINX e continuará sendo o que nos impulsiona em direção ao futuro. No próximo ano, tomaremos medidas significativas para aumentar nosso apoio ao código aberto, investindo no engajamento da comunidade, promovendo a inovação do código aberto e aderindo às melhores práticas do código aberto.

Aqui estão nossos compromissos de código aberto para o próximo ano.

Compromisso nº 1: Mais código aberto, mais interação com a comunidade

Somos a prova viva do que o código aberto pode alcançar. O NGINX alimenta mais de 400 milhões de sites e mais da Internet do que qualquer outro servidor – e levamos nosso trabalho a sério. Queremos avançar mais rápido e aumentar o número de projetos que desenvolvemos para criar uma nova geração de soluções de código aberto para redes de Camada 7, segurança e observabilidade.

À medida que avançamos, queremos aumentar a participação da comunidade. É por isso que nos comprometemos a usar o GitHub como repositório para todos os nossos novos projetos. Então, prometemos não apenas fazer mais trabalho de código aberto, mas fazê-lo da maneira mais transparente possível, com documentação de alta qualidade, rastreamento de problemas e notas de versão. Também queremos incentivar nossa comunidade a contribuir com nossos projetos e ajudar a moldar o futuro conosco.

Compromisso nº 2: Continue a inovar no plano de dados… e além

Ouvi muitos usuários dizerem que “o proxy é uma mercadoria”, o que significa que você pode trocar qualquer proxy – NGINX, Envoy, HAProxy, et al. – por qualquer outro. Não acreditamos que isso seja verdade. Ainda há muita inovação acontecendo no plano de dados. Vimos novos recursos de descoberta de serviços, criptografia, autenticação, segurança e rastreamento introduzidos somente no ano passado.

Aqui na NGINX, acreditamos que um proxy inteligente é a base para entregar aplicativos modernos. Estamos comprometidos com mais recursos de código aberto na camada do plano de dados. Nosso objetivo é superar o estado da arte atual. E não para nos proxies e no plano de dados. Estamos comprometidos em inovar em todas as camadas da pilha de tecnologia de application modernos, incluindo o plano de controle e o plano de gerenciamento. Para isso, planejamos abrir o código-fonte de mais tecnologias de plano de controle e fornecer novas tecnologias de plano de gerenciamento para fornecer recursos de fluxo de trabalho extraídos mais complexos.

Compromisso nº 3: Seja claro sobre o que é código aberto e o que é comercial

À medida que buscamos aumentar o número de soluções de código aberto que fornecemos, precisamos de um modelo claramente definido para criar versões comerciais. É por isso que nos comprometemos com um modelo transparente e consistente para que cada equipe possa entender facilmente os diferentes tipos de produtos NGINX e obter valor dos produtos mais adequados às suas necessidades.

Em mais detalhes:

• O software de código aberto NGINX sempre será de nível de produção, uma base confiável para criar seus aplicativos modernos. Ele continuará leve, rápido e fácil de usar, projetado especificamente para desenvolvedores e equipes de application individuais. Tenha certeza de que – assim como o NGINX Open Source – cada ferramenta de código aberto que criarmos será útil por si só. Não reteremos recursos que impeçam as equipes de desenvolvedores e application de criar ótimos aplicativos.
• Nossos produtos comerciais NGINX serão desenvolvidos com base em nossas ferramentas de código aberto, fornecendo os recursos adicionais que as equipes de plataforma e grandes empresas precisam para operar e entregar aplicativos modernos em escala na produção. Especificamente, as ferramentas comerciais incluirão recursos adicionais de segurança, governança, observabilidade e escalabilidade. Este modelo será consistente em todos os projetos NGINX. Embora os recursos exatos variem de acordo com a finalidade da ferramenta, as equipes de operações de plataforma podem ter certeza de que as ofertas comerciais do NGINX foram projetadas com suas necessidades específicas em mente.

Sabemos que os compromissos não valem muito até que os cumpramos. Precisamos mostrar, não apenas contar – por favor, cobrem-nos disso durante o próximo ano. E já estamos nos movendo para tornar esses compromissos uma realidade. Temos três anúncios nessa frente.

Anúncio nº 1: Recursos adicionais para a comunidade Kubernetes

Por muitos anos, a comunidade Kubernetes confiou no NGINX para alimentar seu recurso e controlador Ingress . Junto com esta versão da comunidade, o próprio NGINX oferece o NGINX Ingress Controller baseado em código aberto NGINX e o NGINX Ingress Controller comercial baseado no NGINX Plus . Aprendemos muito com a comunidade ao longo dos anos e queremos aprofundar nosso envolvimento no avanço do projeto Kubernetes Ingress . Hoje estamos anunciando duas coisas:

1. Estamos dedicando um funcionário em tempo integral para ajudar a gerenciar o projeto Ingress da comunidade.
2. Estamos designando vários funcionários para o Kubernetes Gateway API SIG para ajudar a avançar a funcionalidade de entrada e saída do Kubernetes. Estamos animados para investir muito mais recursos no Ingress e em outros projetos relacionados ao Kubernetes. Esta grande comunidade tem feito um trabalho incrível ao longo dos anos e estamos orgulhosos de fortalecer nossa parceria com eles.

Anúncio nº 2: Novos projetos de código aberto em todas as camadas da pilha de entrega

Sempre participamos de tecnologias de plano de dados de código aberto, como NGINX Open Source , NGINX JavaScript e NGINX Unit . Mas, como mencionei acima, estamos estendendo nossas tecnologias de código aberto para incluir tecnologias de plano de controle e gerenciamento.

Para ser mais específico, lançaremos dois novos projetos de código aberto nos próximos meses: um focado em redes de microsserviços e outro que permite que as equipes de operações de plataforma operem e gerenciem facilmente instâncias NGINX em suas organizações. Também lançaremos uma ferramenta de desenvolvimento de código aberto independente de plataforma (não relacionada à tecnologia principal do NGINX) para desenvolver applications modernos. Eu adoraria entrar em detalhes agora, mas não queremos revelar os novos projetos até que possamos fornecer uma ótima experiência ao desenvolvedor – incluindo os repositórios do GitHub, documentação e grupos de discussão necessários para dar suporte a você.

Essas novas ferramentas ajudarão os desenvolvedores a gerenciar grandes frotas de instâncias do NGINX e a se conectar perfeitamente a ambientes Kubernetes. Todos eles serão gratuitos e de código aberto, com versões comerciais adicionais projetadas especificamente para equipes de operações de plataforma.

Anúncio nº 3: Uma nova arquitetura de referência de aplicativos modernos de código aberto

Os aplicativos modernos são criados em um ecossistema de ferramentas, mas unir várias ferramentas ou projetos geralmente é trabalhoso e requer muita configuração manual. Hoje estamos anunciando a Arquitetura de Referência de Aplicativos Modernos (MARA) do NGINX, disponível agora no GitHub.

A arquitetura de referência aborda os principais pilares de uma arquitetura de application moderna: portabilidade, escalabilidade, resiliência e agilidade. A NGINX fez parceria com vários outros fornecedores e organizações para criar um application completo e totalmente operacional baseado em microsserviços que você pode colocar em funcionamento em minutos, hospedado em um único repositório do GitHub. MARA é um código facilmente implantável, pronto para produção e "roubável" que desenvolvedores, equipes de DevOps e Platform Ops podem usar para criar e implantar aplicativos modernos em ambientes Kubernetes.

A arquitetura adota uma abordagem modular, fornecendo componentes modulares gratuitos e de código aberto que vêm pré-conectados e pré-integrados para tornar o processo de criação de aplicativos modernos mais simples, confiável e menos manual. Continuaremos a desenvolver esta arquitetura de referência e pedimos que a comunidade se junte a nós. Você tem um repositório de código específico que usa? Ou uma ferramenta CI ou CD diferente? Crie um módulo que integre essa tecnologia à arquitetura de referência e contribua com o código de volta. Nosso objetivo é diminuir as barreiras para qualquer empresa que queira colocar o Kubernetes em produção, de forma rápida e confiável.

Para todos os detalhes sobre a arquitetura de referência, consulte Uma nova arquitetura de referência para aplicativos modernos de código aberto em nosso blog.

Para saber mais sobre nossa visão e a inovação de código aberto que estamos promovendo, junte-se a nós no NGINX Sprint 2.0 , que começa hoje. É um evento virtual de três dias que inclui palestras, demonstrações interativas, workshops e treinamento aprofundado. Terminamos ao meio-dia de cada dia, porque sabemos que seu tempo é valioso. E é totalmente gratuito!

Não deixe de reservar seu assento virtual e fique ligado para ouvir as últimas notícias do NGINX, mergulhar fundo nas tecnologias e soluções do NGINX e, como sempre, conectar-se com o restante da incrível comunidade do NGINX. Esperamos ver você lá! E não se preocupe se você não puder comparecer em nenhum dos três dias. Publicaremos todo o conteúdo após o evento para visualização sob demanda.