Créer la prochaine expérience NGINX, conçue pour la réalité des applications modernes

En tant que vice-président produit chez NGINX, je parle fréquemment avec les clients et les utilisateurs. Que vous soyez une équipe Platform Ops, un architecte Kubernetes, un développeur d’applications, un RSSI, un DSI ou un CTO, j’ai parlé à quelqu’un comme vous. Au cours de nos conversations, vous m'avez donné vos impressions honnêtes sur NGINX, y compris nos produits, nos prix et nos modèles de licence, soulignant à la fois nos forces et nos faiblesses.

La principale leçon que nous avons apprise est que notre approche « NGINX est le centre de l’univers » ne sert pas bien nos utilisateurs. Nous avons créé des produits visant à faire de NGINX la « plateforme » – le plan de gestion unifié pour tout ce qui concerne le déploiement d’applications. Nous savions que certains de nos produits précédents destinés à cet objectif avaient été peu utilisés et adoptés. Vous nous avez dit que NGINX est un composant essentiel de votre plateforme existante, développée en interne ou non, mais que NGINX n'était pas la plateforme. Nous devions donc mieux nous intégrer au reste de vos composants pour faciliter le déploiement, la gestion et la sécurisation de nos produits avec (et c'est important) des modèles de tarification et de consommation transparents. Et de rendre tout cela possible via API, bien sûr.

Le message sous-jacent était simple : facilitez l’intégration de NGINX dans vos flux de travail, vos chaînes d’outils existantes et vos processus, sans opinion. Nous vous avons entendu. En 2024, nous adopterons une approche beaucoup plus flexible, simple, reproductible et évolutive en matière de configuration et de gestion des cas d’utilisation pour le plan de données et la sécurité.

Votre désir prend tout son sens. Votre monde a changé et continue de changer ! Vous avez traversé différentes étapes, passant du cloud à l’hybride, au multicloud et au multicloud-hybride. Il y a également eu des changements des machines virtuelles vers Kubernetes et des API vers les microservices et le sans serveur. Beaucoup d’entre vous se sont déplacés vers la gauche et cela a conduit à la complexité. De plus en plus d’équipes disposent de plus d’outils qui nécessitent davantage de gestion, d’observabilité et de sécurité renforcée, le tout alimentant des applications qui doivent pouvoir évoluer en quelques minutes, et non en heures, en jours ou en semaines. Et le dernier accélérateur, l’intelligence artificielle (IA), exerce une pression considérable sur les architectures d’applications et d’infrastructures existantes.

Ce que nous prévoyons d'aborder dans les prochaines versions de produits NGINX

Bien que les bases des produits NGINX aient toujours été solides, testées au combat et performantes, la façon dont nos utilisateurs pouvaient consommer, gérer et observer tous les aspects de NGINX n'a pas suivi le rythme du temps. Nous agissons rapidement pour remédier à ce problème en lançant un nouveau produit et une multitude de nouvelles fonctionnalités. Nous en annoncerons davantage à ce sujet lors de la conférence AppWorld 2024 de F5, qui se déroulera du 6 au 8 février. Voici les problèmes spécifiques que nous prévoyons de résoudre dans les prochaines versions de produits.

Point douloureux n°1 : Les applications modernes sont difficiles à gérer en raison de la diversité des environnements de déploiement

Aujourd’hui, les DSI et les CTO peuvent choisir parmi une grande variété de modalités de déploiement d’applications. C’est une bénédiction car cela permet beaucoup plus de choix en termes de performances, de capacités et de résilience. C’est aussi une malédiction car la diversité mène à la complexité et à l’étalement urbain. Par exemple, la gestion des applications exécutées dans AWS nécessite des configurations, des outils et des connaissances tribales différents de la gestion des applications dans Azure Cloud.

Bien que les conteneurs aient standardisé de larges pans du déploiement d'applications, tout ce qui se trouve en dessous des conteneurs (ou qui entre et sort des conteneurs) reste différencié. En tant que plate-forme d’orchestration de conteneurs de facto, Kubernetes était censé nettoyer ce processus. Mais quiconque a déployé sur Amazon EKS, Azure Kubernetes Service (AKS) et Google Kubernetes Engine (GKE) peut vous le dire : ils ne sont pas du tout identiques.

Vous nous avez dit que la gestion des produits NGINX dans cette grande diversité d’environnements nécessite des ressources opérationnelles importantes et entraîne du gaspillage. Et, franchement, les modèles de tarification basés sur des licences annuelles s’effondrent dans les environnements dynamiques où vous pouvez lancer une application dans un environnement sans serveur, la faire évoluer dans un environnement Kubernetes et maintenir un petit déploiement interne exécuté sur le cloud à des fins de développement.

Point douloureux n° 2 : Les applications exécutées dans de nombreux environnements et couvrant plusieurs types de licences sont difficiles à sécuriser

La complexité d’environnements divers peut rendre difficile la découverte et la surveillance de l’endroit où les applications modernes sont déployées, puis l’application des mesures de sécurité appropriées. Peut-être avez-vous déployé NGINX Plus comme équilibreur de charge global et NGINX Open Source pour divers microservices, chacun s'exécutant dans différents clouds ou sur différents types d'applications. De plus, ils pourraient avoir des exigences différentes en matière de confidentialité, de protection des données et de gestion du trafic.
Chaque permutation ajoute une nouvelle dimension de sécurité. Il n’existe pas de solution standard et complète, ce qui entraîne une complexité opérationnelle et un risque d’erreurs de configuration. Certes, nous avons ajouté à cette complexité en rendant difficile la définition des types de sécurité pouvant être appliqués à quelles solutions NGINX.

Nous comprenons. Les clients ont besoin d'une solution unique pour sécuriser toutes les applications qui exploitent NGINX. Cette solution de sécurité unifiée doit couvrir la grande majorité des cas d'utilisation et déployer les mêmes outils, tableaux de bord et processus opérationnels dans tous les environnements cloud, sur site, sans serveur et autres. Nous reconnaissons également l’importance d’évoluer vers une approche de sécurité plus intelligente, en tirant parti de l’intelligence collective de la communauté NGINX et de la vue sans précédent du trafic mondial que nous avons la chance d’avoir.

Point douloureux n° 3 : La gestion des coûts des applications modernes est complexe et génère du gaspillage

Dans un monde en transition vers la gauche, chaque organisation souhaite permettre aux développeurs et aux praticiens de mieux faire leur travail, sans déposer de ticket ni envoyer de Slack. La réalité a été différente. Une certaine abstraction marginale de la complexité a été obtenue avec Kubernetes, les systèmes sans serveur et d’autres mécanismes de gestion d’applications distribuées et d’applications couvrant des environnements sur site, dans le cloud et multicloud. Mais ces progrès sont restés en grande partie confinés au niveau du conteneur et de l’application. Cela ne s’est pas bien traduit dans les couches entourant les applications telles que la mise en réseau, la sécurité et l’observabilité, ni dans le CI/CD.

J’ai déjà évoqué ces problèmes dans les points critiques précédents, mais l’essentiel est le suivant : la complexité a un coût élevé en termes d’heures et de travail, de sécurité compromise et de résilience. Maintenir des systèmes de plus en plus complexes est un véritable défi et nécessite beaucoup de ressources. La complexité des prix et des licences ajoute une autre couche désagréable. NGINX n’a jamais été une entreprise de « régularisation » qui s’en prend aux utilisateurs lorsqu’ils consomment trop par erreur.

Mais dans un monde de SaaS, d’API et de microservices, vous souhaitez payer au fur et à mesure et non pas à l’année, ni à la licence de siège ou de site. Vous souhaitez un modèle de tarification facile à comprendre basé sur la consommation, pour tous les produits et services NGINX, sur l’ensemble de votre infrastructure technologique et de votre portefeuille d’applications. Vous souhaitez également un moyen d’intégrer le support et la sécurité pour tous les modules open source exécutés par vos équipes, en payant uniquement pour les éléments que vous souhaitez.

Cela nécessitera quelques changements dans la manière dont NGINX conditionne et tarifie les produits. La solution ultime doit être la simplicité, la transparence et le paiement à la consommation, comme pour tout autre SaaS. Nous vous entendons. Et nous avons quelque chose de formidable en réserve qui répondra à ces trois problèmes.

Rejoignez-nous à App World 2024

Nous parlerons de ces mises à jour passionnantes lors de l'AppWorld 2024 et déploierons des éléments de la solution dans le cadre de notre plan et de notre feuille de route à plus long terme au cours des douze prochains mois.

Rejoignez-moi dans ce voyage et connectez-vous à AppWorld pour une description complète de ce qui vous attend. Le tarif préférentiel est disponible jusqu'au 21 janvier. Veuillez consulter la page d'inscription AppWorld 2024 pour plus de détails. Vous êtes également invité à rejoindre les dirigeants de NGINX et d'autres membres de la communauté le soir du 6 février au bureau de San Jose F5 pour une soirée consacrée à l'avenir de NGINX, aux connexions communautaires et à la dégustation des classiques : pizza et swag ! Consultez la page de l'événement pour l'inscription et les détails.

Nous espérons vous voir le mois prochain à San José !