Como vice-presidente de Produtos da NGINX, converso frequentemente com clientes e usuários. Seja você integrante de uma equipe de Operações de Plataforma, arquiteto de Kubernetes, desenvolvedor de aplicações, CISO, CIO ou CTO, já conversei com alguém como você. Em nossas conversas, vocês compartilharam comigo suas opiniões sinceras sobre a NGINX, incluindo nossos produtos e modelos de preços e licenciamento, destacando tanto nossos pontos fortes quanto nossas fraquezas.
O principal aprendizado foi que nossa abordagem de que “o NGINX é o centro do universo” não atende bem aos nossos usuários. Estávamos desenvolvendo produtos com o objetivo de transformar o NGINX na “plataforma” — o plano de gerenciamento unificado para tudo relacionado à implantação de aplicações. Sabíamos que alguns de nossos produtos anteriores voltados para esse objetivo tinham tido pouco uso e adesão. Vocês nos disseram que o NGINX é um componente essencial da plataforma que já utilizam, seja ela desenvolvida internamente ou não, mas que o NGINX não era a plataforma em si. Portanto, precisávamos nos integrar melhor aos demais componentes de vocês para facilitar a implantação, o gerenciamento e a proteção de nossos produtos, com modelos transparentes de preços e consumo — e isso é importante. E, é claro, tornar tudo isso possível por meio de API.
A mensagem subjacente era clara: facilitar a integração do NGINX aos seus fluxos de trabalho, conjuntos de ferramentas existentes e processos, sem impor uma abordagem específica. Ouvimos você. Em 2024, adotaremos uma abordagem muito mais flexível, simples, reproduzível e escalável para a configuração e o gerenciamento de casos de uso relacionados ao plano de dados e à segurança.
Seu desejo faz todo o sentido. Seu mundo mudou e continua mudando! Vocês passaram por vários estágios, migrando da nuvem para ambientes híbridos, multinuvem e híbridos multinuvem. Também houve mudanças de VMs para Kubernetes e de APIs para microsserviços e computação sem servidor. Muitos de vocês adotaram a abordagem shift left, o que aumentou a complexidade. Mais equipes contam com mais ferramentas, que exigem mais gerenciamento, observabilidade e segurança robusta — tudo isso para viabilizar aplicações que precisam ser capazes de escalar em minutos, não em horas, dias ou semanas. E o mais recente catalisador, a inteligência artificial (IA), exerce uma pressão significativa sobre as arquiteturas legadas de aplicações e infraestrutura.
O que planejamos abordar nas próximas versões dos produtos NGINX
Embora a base dos produtos NGINX sempre tenha sido extremamente sólida, testada em situações reais e de alto desempenho, a forma como nossos usuários podiam consumir, gerenciar e observar todos os aspectos do NGINX não acompanhou a evolução dos tempos. Estamos agindo rapidamente para corrigir isso com o lançamento de um novo produto e uma série de novos recursos. Anunciaremos mais detalhes sobre isso na conferência da F5, a AppWorld 2024, que acontecerá de 6 a 8 de fevereiro. Veja a seguir alguns problemas específicos que pretendemos solucionar nas próximas versões dos produtos.
Ponto problemático nº 1: a diversidade dos ambientes de implantação dificulta o gerenciamento de aplicações modernas
Hoje, CIOs e CTOs podem escolher entre uma ampla variedade de modalidades de implantação de aplicações. Isso é uma vantagem, pois oferece muito mais opções em termos de desempenho, recursos e resiliência. Mas também é uma desvantagem, porque essa diversidade gera complexidade e dispersão. Por exemplo, o gerenciamento de aplicações executadas na AWS exige configurações, ferramentas e conhecimentos práticos diferentes daqueles necessários para gerenciar aplicações na Azure Cloud.
Embora os contêineres tenham padronizado grande parte da implantação de aplicações, tudo o que está abaixo deles (ou que entra e sai deles) continua sendo diferente. Como plataforma de fato para a orquestração de contêineres, o Kubernetes deveria simplificar esse processo. Mas qualquer pessoa que já tenha feito implantações no Amazon EKS, no Azure Kubernetes Service (AKS) e no Google Kubernetes Engine (GKE) pode confirmar: eles não são nem um pouco parecidos.
Vocês nos disseram que gerenciar os produtos NGINX em meio a essa enorme diversidade de ambientes exige recursos operacionais significativos e gera desperdício. E, francamente, os modelos de preços baseados em licenças anuais não funcionam em ambientes dinâmicos, nos quais você pode lançar um aplicativo em um ambiente sem servidor, escalá-lo em um ambiente Kubernetes e manter uma pequena implantação interna em execução na nuvem para fins de desenvolvimento.
Ponto problemático nº 2: é difícil proteger aplicações executadas em vários ambientes e que abrangem diferentes tipos de licença
A complexidade de ambientes diversos pode dificultar a identificação e o monitoramento de onde os aplicativos modernos estão implantados e, em seguida, a aplicação das medidas de segurança adequadas. Talvez você tenha implantado o NGINX Plus como seu balanceador de carga global e o NGINX Open Source para vários microsserviços, cada um executado em diferentes nuvens ou sobre diferentes tipos de aplicativos. Além disso, cada um pode ter requisitos distintos de privacidade, proteção de dados e gerenciamento de tráfego.
Cada combinação acrescenta um novo desafio de segurança. Não existe uma solução padrão e abrangente, o que aumenta a complexidade operacional e a possibilidade de erros de configuração. Reconhecemos que também contribuímos para essa complexidade ao dificultar a compreensão de quais tipos de segurança podem ser aplicados a cada solução NGINX.
Nós entendemos. Os clientes precisam de uma única maneira de proteger todos os aplicativos que utilizam o NGINX. Essa solução de segurança unificada deve abranger a grande maioria dos casos de uso e implementar as mesmas ferramentas, painéis e processos operacionais em todos os ambientes de nuvem, locais, sem servidor e outros. Também reconhecemos a importância de avançar rumo a uma abordagem de segurança mais inteligente, aproveitando a inteligência coletiva da comunidade NGINX e a visão sem precedentes do tráfego global que temos a sorte de possuir.
Ponto problemático nº 3: gerenciar o custo de aplicativos modernos é complexo e gera desperdício
Em um mundo de shift-left, toda organização quer capacitar desenvolvedores e profissionais para que façam melhor seu trabalho, sem precisar abrir um chamado ou enviar uma mensagem no Slack. Mas a realidade tem sido diferente. Foi possível abstrair minimamente a complexidade com Kubernetes, arquiteturas serverless e outros mecanismos para gerenciar aplicações distribuídas e aplicações que abrangem ambientes locais, de nuvem e multinuvem. No entanto, esse progresso ficou, em grande parte, restrito ao contêiner e à aplicação. Ele não se estendeu de forma eficaz às camadas ao redor das aplicações, como rede, segurança e observabilidade, nem a CI/CD.
Já mencionei essas questões nos pontos problemáticos anteriores, mas a conclusão é a seguinte: a complexidade tem custos elevados em termos de horas de trabalho e esforço, comprometimento da segurança e resiliência. Manter sistemas cada vez mais complexos é um desafio por natureza e exige muitos recursos. A complexidade dos preços e das licenças acrescenta mais uma camada de insatisfação. A NGINX nunca foi uma empresa que faz cobranças de ajuste (“true-up”), penalizando os usuários quando eles excedem o consumo por engano.
Mas, em um mundo de SaaS, APIs e microsserviços, você quer pagar conforme o uso, e não por ano, usuário ou licença de site. Você quer um modelo de preços baseado no consumo e fácil de entender para todos os produtos e serviços da NGINX, abrangendo toda a sua infraestrutura tecnológica e seu portfólio de aplicações. Você também quer uma forma de incluir suporte e segurança para quaisquer módulos de código aberto usados por suas equipes, pagando apenas pelos recursos que deseja.
Isso exigirá algumas mudanças na forma como a NGINX empacota e precifica seus produtos. A solução definitiva deve oferecer simplicidade, transparência e cobrança de acordo com o consumo, como qualquer outro SaaS. Entendemos você. E estamos preparando algo excelente que solucionará os três pontos problemáticos mencionados acima.
Junte-se a nós no App World 2024
Falaremos sobre essas novidades empolgantes no AppWorld 2024 e lançaremos partes da solução ao longo dos próximos doze meses, como parte do nosso plano e roteiro de longo prazo.
Junte-se a mim nesta jornada e acompanhe o AppWorld para conhecer em detalhes o que está por vir. Os preços promocionais para inscrições antecipadas estão disponíveis até 21 de janeiro. Consulte a página de inscrição do AppWorld 2024 para obter mais informações. Você também está convidado a se juntar aos líderes da NGINX e a outros membros da comunidade na noite de 6 de fevereiro, no escritório da F5 em San Jose, para um encontro dedicado a vislumbrar o futuro da NGINX, fortalecer os laços com a comunidade e aproveitar os clássicos: pizza e brindes! Consulte a página do evento para se inscrever e obter mais informações.
Esperamos ver você no próximo mês em San Jose!
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.