En tant que vice-président des produits chez NGINX, j’échange régulièrement avec des clients et des utilisateurs. Que vous fassiez partie d’une équipe chargée des opérations de plateforme, que vous soyez architecte Kubernetes, développeur d’applications, RSSI, DSI ou CTO, j’ai déjà discuté avec quelqu’un comme vous. Au cours de nos échanges, vous m’avez fait part en toute franchise de votre avis sur NGINX, notamment sur nos produits, nos tarifs et nos modèles de licence, en soulignant aussi bien nos points forts que nos points faibles.
Le principal enseignement que nous en avons tiré est que notre approche selon laquelle « NGINX est le centre de l’univers » ne répond pas correctement aux besoins de nos utilisateurs. Nous avions conçu des produits visant à faire de NGINX la « plateforme », c’est-à-dire le plan de gestion unifié de tout ce qui concerne le déploiement d’applications. Nous savions que certains de nos produits précédents conçus dans cette optique avaient été peu utilisés et adoptés. Vous nous avez expliqué que NGINX était un composant essentiel de votre plateforme existante, qu’elle ait été développée en interne ou non, mais que NGINX n’était pas la plateforme elle-même. Nous devions donc mieux nous intégrer à vos autres composants afin de faciliter le déploiement, la gestion et la sécurisation de nos produits, tout en proposant — et c’est important — des modèles de tarification et de consommation transparents. Et, bien entendu, rendre tout cela possible via une API.
Le message sous-jacent était clair : vous permettre d’intégrer plus facilement NGINX à vos workflows, à vos chaînes d’outils existantes et à vos processus, sans vous imposer une approche particulière. Nous vous avons entendus. En 2024, nous adopterons une approche beaucoup plus flexible, simple, reproductible et évolutive pour la configuration et la gestion des cas d’usage liés au plan de données et à la sécurité.
Votre souhait est tout à fait compréhensible. Votre environnement a changé et continue d’évoluer ! Vous avez franchi différentes étapes, passant du cloud à l’hybride, puis au multicloud et aux configurations hybrides multicloud. Vous êtes également passés des machines virtuelles à Kubernetes, et des API aux microservices et au serverless. Beaucoup d’entre vous ont adopté une approche « shift left », ce qui a accru la complexité. Davantage d’équipes disposent de davantage d’outils, qui nécessitent plus de gestion, d’observabilité et une sécurité robuste, le tout au service d’applications qui doivent pouvoir monter en charge en quelques minutes, et non en quelques heures, jours ou semaines. Enfin, le tout 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 des produits NGINX
Si les fondations des produits NGINX ont toujours été extrêmement solides, éprouvées sur le terrain et performantes, la manière dont nos utilisateurs pouvaient utiliser, gérer et surveiller tous les aspects de NGINX n’a pas évolué avec son temps. Nous agissons rapidement pour y remédier en lançant un nouveau produit et toute une série de nouvelles fonctionnalités. Nous en dirons davantage à ce sujet lors de la conférence de F5, AppWorld 2024, qui se tiendra du 6 au 8 février. Voici les principaux problèmes auxquels nous prévoyons de nous attaquer dans les prochaines versions de nos produits.
Problème n° 1 : la diversité des environnements de déploiement complique la gestion des applications modernes
Aujourd’hui, les DSI et les directeurs techniques peuvent choisir parmi un large éventail de modes de déploiement des applications. C’est un avantage, car ils disposent ainsi d’un choix bien plus vaste en matière de performances, de fonctionnalités et de résilience. Mais c’est aussi un inconvénient, car cette diversité entraîne complexité et prolifération. Par exemple, la gestion des applications exécutées dans AWS nécessite des configurations, des outils et des connaissances empiriques différents de ceux requis pour gérer les applications dans Azure Cloud.
Si les conteneurs ont permis de standardiser de larges pans du déploiement d’applications, tout ce qui se trouve sous les conteneurs (ou qui y entre et en sort) reste hétérogène. En tant que plateforme d’orchestration de conteneurs de facto, Kubernetes était censé simplifier ce processus. Mais quiconque a effectué des déploiements sur Amazon EKS, Azure Kubernetes Service (AKS) et Google Kubernetes Engine (GKE) peut vous le confirmer : ces services sont loin d’être identiques.
Vous nous avez indiqué que la gestion des produits NGINX dans des environnements aussi divers nécessite d’importantes ressources opérationnelles et entraîne du gaspillage. Et, à vrai dire, les modèles tarifaires fondés sur des licences annuelles ne sont pas adaptés aux environnements dynamiques, dans lesquels vous pouvez lancer une application dans un environnement serverless, la faire monter en charge dans un environnement Kubernetes et maintenir un petit déploiement interne dans le cloud à des fins de développement.
Problème n° 2 : les applications exécutées dans de nombreux environnements et relevant de différents types de licences sont difficiles à sécuriser
La complexité des environnements hétérogènes peut compliquer l’identification et la surveillance des emplacements où sont déployées les applications modernes, puis l’application des mesures de sécurité appropriées. Vous avez peut-être déployé NGINX Plus comme équilibreur de charge global et NGINX Open Source pour différents microservices, chacun s’exécutant dans des clouds distincts ou sur différents types d’applications. En outre, leurs exigences peuvent varier en matière de confidentialité, de protection des données et de gestion du trafic.
Chaque combinaison introduit de nouveaux enjeux de sécurité. Il n’existe aucune solution standard et complète, ce qui accroît la complexité opérationnelle et le risque d’erreurs de configuration. Il faut reconnaître que nous avons contribué à cette complexité en ne précisant pas suffisamment quels types de sécurité peuvent être appliqués aux différentes solutions NGINX.
Nous comprenons. Les clients ont besoin d’une solution unique pour sécuriser toutes les applications qui s’appuient sur NGINX. Cette solution de sécurité unifiée doit couvrir la grande majorité des cas d’usage et permettre d’utiliser les mêmes outils, tableaux de bord et processus opérationnels dans tous les environnements : cloud, sur site, sans serveur et autres. Nous sommes également conscients de l’importance d’évoluer vers une approche plus intelligente de la sécurité, en tirant parti de l’intelligence collective de la communauté NGINX et de la visibilité sans précédent sur le trafic mondial dont nous avons la chance de disposer.
Problème n° 3 : la gestion des coûts des applications modernes est complexe et entraîne du gaspillage
Dans un monde où les pratiques sont décalées vers l’amont (« shift left »), chaque organisation souhaite donner aux développeurs et aux professionnels les moyens de mieux faire leur travail, sans avoir à ouvrir un ticket ni à envoyer un message sur Slack. Dans les faits, la réalité est tout autre. Kubernetes, le serverless et d’autres mécanismes de gestion des applications distribuées et des applications déployées dans des environnements sur site, cloud et multicloud ont permis de masquer une petite partie de la complexité. Mais ces progrès sont restés en grande partie cantonnés au conteneur et à l’application. Ils se sont peu étendus aux couches qui entourent les applications, telles que le réseau, la sécurité et l’observabilité, ni à la CI/CD.
J’ai déjà évoqué ces problèmes dans les points de friction précédents, mais l’essentiel est le suivant : la complexité a un coût considérable en matière de temps et de tâches fastidieuses, de sécurité compromise et de résilience. La maintenance de systèmes toujours plus complexes est fondamentalement difficile et exige beaucoup de ressources. La complexité de la tarification et des licences ajoute une difficulté supplémentaire. NGINX n’a jamais été une entreprise pratiquant la « régularisation » pour pénaliser les utilisateurs lorsqu’ils dépassent leur consommation par erreur.
Mais dans un monde dominé par le SaaS, les API et les microservices, vous souhaitez payer à l’usage, et non à l’année, par utilisateur ou par licence de site. Vous voulez un modèle tarifaire simple à comprendre et fondé sur la consommation pour l’ensemble des produits et services NGINX, couvrant toute votre infrastructure technologique et votre portefeuille d’applications. Vous souhaitez également pouvoir bénéficier d’un support et de services de sécurité pour tous les modules open source utilisés par vos équipes, en ne payant que pour ce dont vous avez besoin.
Cela nécessitera de faire évoluer la manière dont NGINX conditionne et tarifie ses produits. La solution idéale devra être simple, transparente et fondée sur le paiement à l’usage, comme tout autre SaaS. Nous vous avons entendus. Et nous vous réservons une excellente solution qui répondra aux trois problématiques évoquées ci-dessus.
Rejoignez-nous à App World 2024
Nous présenterons ces nouveautés passionnantes lors de l’AppWorld 2024 et déploierons progressivement certains éléments de la solution dans le cadre de notre plan et de notre feuille de route à long terme au cours des douze prochains mois.
Rejoignez-moi dans cette aventure et suivez AppWorld pour découvrir en détail ce qui vous attend. Le tarif préférentiel est disponible jusqu’au 21 janvier. Pour en savoir plus, consultez la page d’inscription à AppWorld 2024. Vous êtes également convié à rejoindre les dirigeants de NGINX et d’autres membres de la communauté le soir du 6 février dans les bureaux de F5 à San José, pour une soirée consacrée à l’avenir de NGINX, aux échanges entre membres de la communauté et aux grands classiques : pizzas et goodies ! Consultez la page de l’événement pour vous inscrire et obtenir plus d’informations.
Nous espérons vous voir le mois prochain à San José !
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.