Como vice-presidente de produto da NGINX, falo frequentemente com clientes e usuários. Seja você uma equipe de operações de plataforma, arquiteto de Kubernetes, desenvolvedor de aplicativos, CISO, CIO ou CTO – conversei com alguém como você. Em nossas conversas, você me deu suas opiniões honestas sobre o NGINX, incluindo nossos produtos, preços e modelos de licenciamento, destacando nossos pontos fortes e fracos.
O principal que aprendemos é que nossa abordagem “NGINX é o centro do universo” não atende bem aos nossos usuários. Estávamos construindo produtos que visavam fazer do NGINX a “plataforma” – o plano de gerenciamento unificado para tudo relacionado à implantação de aplicativos. Sabíamos que alguns dos nossos produtos anteriores voltados para esse objetivo tinham sido pouco utilizados e adotados. Você nos disse que o NGINX é um componente crítico da sua plataforma existente, desenvolvida internamente ou não, mas que o NGINX não era a plataforma. Portanto, precisávamos nos integrar melhor com o restante dos seus componentes para facilitar a implantação, o gerenciamento e a proteção de nossos produtos com (e isso é importante) modelos de preços e consumo transparentes. E tornar tudo isso possível via API, é claro.
A mensagem subjacente era direta: facilite a integração do NGINX aos seus fluxos de trabalho, cadeias de ferramentas existentes e processos de maneira imparcial. Nós ouvimos você. Em 2024, adotaremos uma abordagem muito mais flexível, simples, repetível e escalável em relação à configuração e ao gerenciamento de casos de uso para plano de dados e segurança.
Seu desejo faz todo o sentido. Seu mundo mudou e continua mudando! Você passou por vários estágios, migrando da nuvem para configurações híbridas, multi-nuvem e multi-nuvem-híbridas. Também houve mudanças de VMs para Kubernetes e de APIs para microsserviços e sistemas sem servidor. Muitos de vocês mudaram para a esquerda e isso levou à complexidade. Mais equipes têm mais ferramentas que exigem mais gerenciamento, capacidade de observação e segurança robusta, tudo isso alimentando aplicativos que devem ser capazes de escalar em minutos; não em horas, dias ou semanas. E o mais recente acelerador, a inteligência artificial (IA), coloca uma pressão significativa sobre as arquiteturas de infraestrutura e aplicativos legados.
Embora a estrutura dos produtos NGINX sempre tenha sido sólida, testada em batalha e de alto desempenho, a maneira como nossos usuários podiam consumir, gerenciar e observar todos os aspectos do NGINX não acompanhou o tempo. Estamos agindo rapidamente para remediar isso com o lançamento de um novo produto e uma série de novos recursos. Anunciaremos mais sobre isso na conferência AppWorld 2024 da F5, que acontecerá de 6 a 8 de fevereiro. Aqui estão alguns pontos problemáticos específicos que planejamos abordar nos próximos lançamentos de produtos.
Hoje, CIOs e CTOs podem escolher entre uma ampla variedade de modalidades de implantação de aplicativos. Isso é uma bênção porque permite muito mais opções em termos de desempenho, capacidades e resiliência. Também é uma maldição porque a diversidade leva à complexidade e à expansão. Por exemplo, gerenciar aplicativos em execução na AWS exige configurações, ferramentas e conhecimento tribal diferentes do que gerenciar aplicativos no Azure Cloud.
Embora os contêineres tenham padronizado grandes áreas de implantação de aplicativos, tudo abaixo dos contêineres (ou entrando e saindo dos contêineres) permanece diferenciado. Como plataforma de orquestração de contêineres de fato, o Kubernetes deveria limpar esse processo. Mas qualquer pessoa que tenha implantado no Amazon EKS, Azure Kubernetes Service (AKS) e Google Kubernetes Engine (GKE) pode dizer que eles não são nada parecidos.
Você nos disse que gerenciar produtos NGINX nessa enorme diversidade de ambientes exige recursos operacionais significativos e gera desperdício. E, francamente, modelos de preços baseados em licenças anuais entram em colapso em ambientes dinâmicos, onde 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.
A complexidade de ambientes diversos pode dificultar a descoberta e o monitoramento de onde os aplicativos modernos são implantados e a aplicação das medidas de segurança corretas. Talvez você tenha implantado o NGINX Plus como seu balanceador de carga global e o NGINX Open Source para vários microsserviços, com cada um sendo executado em nuvens diferentes ou sobre diferentes tipos de aplicativos. Além disso, eles podem exigir coisas diferentes para privacidade, proteção de dados e gerenciamento de tráfego.
Cada permutação acrescenta um novo toque de segurança. Não existe uma solução padrão e abrangente, o que gera complexidade operacional e potencial para erros de configuração. É verdade que aumentamos essa complexidade ao tornar confuso quais tipos de segurança podem ser aplicados a quais soluções NGINX.
Nós entendemos. Os clientes precisam de uma única maneira de proteger todos os aplicativos que aproveitam o NGINX. Esta solução de segurança unificada deve cobrir a grande maioria dos casos de uso e implementar as mesmas ferramentas, painéis e processos operacionais em todos os ambientes de nuvem, no local, sem servidor e outros. Também reconhecemos a importância de avançar para 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 ter.
Em um mundo de mudança para a esquerda, todas as organizações querem capacitar desenvolvedores e profissionais para que façam seu trabalho melhor, sem precisar abrir um tíquete ou enviar um Slack. A realidade tem sido diferente. Alguma abstração marginal de complexidade foi alcançada com Kubernetes, mecanismos sem servidor e outros para gerenciar aplicativos distribuídos e aplicativos que abrangem ambientes locais, na nuvem e em várias nuvens. Mas esse progresso ficou em grande parte confinado ao contêiner e à aplicação. Ele não foi bem traduzido para as camadas em torno de aplicativos como rede, segurança e observabilidade, nem para CI/CD.
Já mencionei esses problemas nos pontos problemáticos anteriores, mas o ponto principal é este: a complexidade tem grandes custos em termos de horas e trabalho, segurança comprometida e resiliência. Manter sistemas cada vez mais complexos é fundamentalmente desafiador e exige muitos recursos. A complexidade dos preços e das licenças acrescenta outra camada desagradável. A NGINX nunca foi uma empresa "correta" que critica os usuários quando eles consomem demais por engano.
Mas em um mundo de SaaS, APIs e microsserviços, você quer pagar conforme o uso e não pagar por ano, nem por assento ou licença de site. Você quer um modelo de preços fácil de entender com base no consumo, para todos os produtos e serviços NGINX, em toda a sua infraestrutura de tecnologia e portfólio de aplicativos. Você também quer uma maneira de incorporar suporte e segurança para quaisquer módulos de código aberto que suas equipes executem, pagando apenas pelas partes que você deseja.
Isso exigirá algumas mudanças na forma como o NGINX embala e precifica os produtos. A solução definitiva deve ser simplicidade, transparência e pagamento por consumo, assim como qualquer outro SaaS. Nós ouvimos você. E temos algo ótimo guardado que resolverá todos os três pontos problemáticos acima.
Falaremos sobre essas atualizações interessantes na AppWorld 2024 e lançaremos partes da solução como parte do nosso plano e roteiro de longo prazo nos próximos doze meses.
Junte-se a mim nessa jornada e sintonize no AppWorld para uma análise completa do que está por vir. Os preços para inscrição antecipada estão disponíveis até 21 de janeiro. Confira a página de inscrição do AppWorld 2024 para mais detalhes. Você também está convidado a se juntar aos líderes do NGINX e outros membros da comunidade na noite de 6 de fevereiro no escritório F5 de San Jose para uma noite de reflexão sobre o futuro do NGINX, conexões com a comunidade e deliciar-se com os clássicos: pizza e brindes! Veja a página do evento para inscrição e detalhes.
Esperamos ver você no mês que vem em San Jose!
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."