5 raisons de passer à l’équilibrage de charge logiciel

Floyd SmithDirecteur du marketing de contenu

Cet article est adapté d’un webinaire présenté par Floyd Smith et Faisal Memon de NGINX, Inc. Notre nouvel ebook sur le sujet est disponible au téléchargement.

Table des matières

0:00 Introduction

Floyd Smith : Bonjour et bienvenue à notre présentation. Nous sommes ici chez NGINX et nous allons parler aujourd’hui de mon e-book 5 raisons de passer à une solution logicielle pour l’équilibrage de charge.

Nous sommes deux à assurer cette présentation aujourd’hui. Je m’appelle Floyd Smith et je suis rédacteur marketing technique chez NGINX. J’ai auparavant occupé le poste de rédacteur technique senior chez Apple et j’ai écrit plusieurs ouvrages consacrés à différents aspects de la technologie.

Faisal Memon : Bonjour, je m’appelle Faisal Memon et je travaille dans le marketing produit chez NGINX. Je suis ici depuis environ un an. Avant de rejoindre NGINX, j’ai travaillé comme ingénieur en marketing technique chez Riverbed, ainsi que chez Cisco. J’ai commencé ma carrière dans le développement en C. J’ai ensuite occupé un poste d’ingénieur logiciel chez Cisco pendant environ huit ans.

1:38 Qui êtes-vous ?

Floyd : Nous recevons les inscriptions à nos webinaires avant leur tenue, et nous pouvons consulter les intitulés de poste, les organisations et les raisons de participer que chacun d’entre vous a indiqués.

C’était vraiment intéressant de regarder les intitulés de poste des participants. Nous avons des architectes de solutions – plusieurs types d’architectes différents. Des administrateurs Linux, des directeurs de l’ingénierie, des PDG, des responsables seniors de la livraison Agile, plusieurs personnes occupant des postes liés au DevOps, des développeurs full stack, des ingénieurs, des scientifiques, des développeurs et des responsables des opérations marketing.

Nous avons un très bon éventail de profils à dominante technique. J’ai le sentiment que les participants à ce webinaire sont vraiment très proches de la technologie sur le terrain et qu’ils seront directement confrontés aux problématiques dont nous parlons aujourd’hui.

Nous avons également le plaisir d’accueillir des représentants d’un large éventail d’organisations. Certains d’entre vous s’intéressent peut-être à ce sujet afin d’aider leurs clients à prendre des décisions éclairées, mais la plupart semblent y être directement confrontés en interne.

3:53 Du matériel au logiciel

Selon les rapports financiers, le marché des ADC matériels est en déclin. Les fournisseurs d’ADC matériels cherchent donc à augmenter le chiffre d’affaires généré par chaque client, alors même que leur clientèle diminue. De nombreux clients commencent à se rendre compte qu’ils ne veulent plus faire partie de ce groupe toujours plus restreint d’utilisateurs qui paient toujours plus cher pour les services fournis par ces ADC matériels. Ils constatent qu’ils peuvent en réalité obtenir de meilleurs résultats avec une solution logicielle, tout en gagnant en flexibilité. Ceux d’entre vous dont l’intitulé de poste comporte le terme DevOps voient probablement ce que je veux dire.

Chez NGINX, nous constatons souvent que les entreprises attendent la date de renouvellement du contrat de leur ADC matériel, ou qu’elles subissent une hausse soudaine du trafic accompagnée d’une forte augmentation des coûts, avant de chercher dans l’urgence à se dégager du contrat. Elles doivent alors agir très rapidement. Elles y parviennent généralement, mais la situation est stressante, imprévue et non budgétée. Grâce à cette présentation, vous pourrez mettre en place une démarche plus planifiée.

La question budgétaire n’est pas aussi critique, car le passage à une solution logicielle permet de réaliser des économies considérables. En revanche, les contraintes opérationnelles sont importantes. Vous pouvez les réduire sensiblement en vous y prenant suffisamment tôt.

NGINX est une excellente alternative à un contrôleur de mise à disposition d’applications (ADC) matériel. Il a été créé à l’origine pour résoudre le problème des 10 000 connexions simultanées (C10K). Il s’agit de permettre à un serveur web exécuté sur un seul ordinateur de gérer au moins 10 000 connexions simultanées. Avant NGINX, c’était impossible. Dès qu’un site web gagnait en popularité, il finissait par s’effondrer. Empêcher cela était extrêmement difficile, mais NGINX a grandement simplifié les choses.

Notre première version open source a été publiée en 2004 en Russie, où NGINX [le logiciel] a été créé à l’origine [Note de l’éditeur – Floyd dit ici « fondé » ; NGINX, Inc. a été fondée en 2011]. NGINX Plus, la version commerciale avec support, a été lancée en 2013.

La société NGINX est basée dans la Silicon Valley (à San Francisco), et nos bureaux de développement se trouvent à Moscou. Nous avons également des bureaux au Royaume-Uni. L’entreprise bénéficie du soutien financier de sociétés de capital-risque de premier plan dans le secteur. Nous comptons plus de 800 clients et venons tout juste de franchir le cap des 100 employés.

6:33 Le serveur web de référence pour les sites les plus fréquentés au monde

Au total, 160 millions de sites fonctionnent sous NGINX.

Il est utilisé selon deux modes différents. Certains sites utilisent NGINX comme serveur web, ce qui était sa fonction initiale. Mais de nombreux sites utilisent NGINX comme serveur proxy inverse. Il s’agit alors de placer NGINX devant votre architecture actuelle afin qu’il gère le trafic et l’achemine vers vos serveurs d’applications. Dès lors, vous êtes en passe de mettre en œuvre la répartition de charge, qui est le sujet que nous allons aborder aujourd’hui.

51 % des 10 000 sites web les plus fréquentés sont passés à NGINX. Mais pourquoi ? Pourquoi NGINX est-il encore plus utilisé parmi les sites web les plus fréquentés que parmi l’ensemble des sites web ?

La raison en est que NGINX constitue la meilleure solution pour les sites web à très fort trafic. Pour remédier rapidement aux problèmes d’un site web très fréquenté, il suffit de déployer NGINX comme serveur proxy inverse, puis de mettre en place un équilibrage de charge par-dessus.

Au fil du temps, vous pouvez soit migrer vos applications existantes vers NGINX, soit, si vous en développez de nouvelles, utiliser également NGINX comme serveur web pour celles-ci. C’est ainsi que nous avons réussi à faire adopter NGINX par ces professionnels très sollicités, qui ne changent pas de serveur web sur un coup de tête. Ils ont l’expérience d’autres serveurs web et savent les utiliser, mais ils franchissent le pas en raison de tout ce que NGINX leur apporte.

36 % de tous les sites hébergés sur Amazon Web Services utilisent NGINX. Cet outil est en passe de devenir une référence. Aujourd’hui, les utilisateurs commencent souvent avec NGINX et continuent à l’utiliser tout au long de leur projet.

Voici quelques-uns des sites qui utilisent NGINX. Bien sûr, avec 160 millions de sites web utilisant NGINX, nous ne pouvons pas tous les faire tenir sur une seule diapositive, mais parmi nos partenaires et amis figurent Netflix, Airbnb, Uber, Amazon Web Services, comme je l’ai mentionné, Box, Pinterest et WordPress.

Toutes ces entreprises, dont l’activité repose sur la diffusion de contenu web et pour lesquelles tout doit fonctionner parfaitement, sont passées à NGINX.

8:48 La place de NGINX

Voyons où se situe NGINX.

À droite, vous voyez NGINX fonctionner comme serveur web. À ce titre, il utilise une passerelle applicative qui lui permet de fonctionner avec différents types de serveurs d’applications. En tant que serveur web, NGINX peut gérer environ 10 000 connexions simultanées, selon l’utilisation que vous en faites.

Mais NGINX peut également servir de serveur proxy inverse, offrant ainsi des fonctionnalités de mise en cache, d’équilibrage de charge et bien d’autres possibilités.

9:32 Architecture web moderne

NGINX vous aide également à adopter une architecture web moderne. Il peut s’agir de faire évoluer des architectures à trois niveaux de type J2EE vers des microservices, de remplacer des protocoles complexes reposant sur HTML et SOAP par des protocoles plus légers comme REST et la messagerie, qui jouent un rôle majeur dans les microservices, ou encore de passer de déploiements persistants à des déploiements modifiables exécutant des conteneurs ou des machines virtuelles.

Au lieu d’une infrastructure fixe et statique, vous disposez généralement d’un service que vous gérez vous-même. Il existe des technologies comme le SDN, le NFV et le cloud, surtout le cloud. Au lieu de déploiements massifs tous les quelques mois, vous pratiquez la livraison continue toutes les quelques heures. Et au lieu d’équipes cloisonnées, avec un groupe de développement, un groupe de test et un groupe d’exploitation relevant chacun de sa propre hiérarchie, vous adoptez une culture DevOps fondée sur le partage des responsabilités, où chacun retrousse ses manches et prend en charge certains aspects de chaque problème.

10:42 DevOps fonctionne parfaitement avec NGINX

Méthodologie DevOps, déploiements dans le cloud et découverte automatisée des services” size-full wp-image-46723″ style=”border:2px solid #666666; padding:2px; margin:2px;” />

L’histoire du DevOps est étroitement liée à celle de NGINX. De nombreux professionnels du DevOps ont NGINX dans leur boîte à outils et, lorsqu’ils rencontrent des problèmes lors d’un déploiement, ils font appel à NGINX.

Dans certains déploiements, il n’est même pas nécessaire de modifier la configuration de l’application. Il suffit de placer NGINX devant celle-ci pour acheminer le trafic vers les serveurs d’applications de manière à ce qu’ils puissent le gérer. Vous n’avez pas modifié le code ni mis en péril vos fonctionnalités essentielles alors que vous devez résoudre rapidement un problème de performances.

Comme nous le verrons, DevOps et NGINX fonctionnent particulièrement bien ensemble pour assurer la répartition de charge logicielle. Cette solution est très efficace pour les déploiements dans le cloud, mais aussi sur vos propres serveurs. Elle propose diverses méthodes de répartition de charge. Il existe à ce niveau une différence entre NGINX et NGINX Plus, sur laquelle je reviendrai dans un instant.

La capacité de reconfiguration à la volée de NGINX favorise la découverte de services et la disponibilité. La découverte de services est essentielle pour les microservices et l’automatisation. Grâce à la reconfiguration à la volée, vous n’avez pas besoin de déconnecter les utilisateurs d’un serveur pour le configurer, ce qui constitue un avantage considérable pour assurer la disponibilité de vos services auprès de vos clients.

Les contrôles d’intégrité des applications permettent de détecter rapidement les problèmes de mise à disposition des applications afin de pouvoir arrêter progressivement un serveur défaillant, plutôt que de le laisser se bloquer brutalement et déconnecter les utilisateurs. À cela s’ajoute une supervision robuste et personnalisable. Là encore, vous êtes informé des problèmes dès leur apparition, ce qui vous permet de les résoudre avant qu’ils n’affectent vos clients.

12:30 Fonctionnalités de NGINX Plus

Que contient NGINX Plus ?

Ainsi, NGINX Open Source est le produit d’origine, tandis que NGINX Plus est le produit commercial qui s’appuie sur celui-ci. Chez NGINX, nous consacrons au moins 70 % de notre temps à la version open source, mais celle-ci sert également de base aux fonctionnalités avancées de NGINX Plus.

Le produit open source inclut le routage des requêtes, qui constitue la fonction principale d’un serveur web, ainsi que la compression, qui réduit la charge du serveur web et le trafic réseau, ce qui peut s’avérer très utile. Il prend également en charge SSL pour assurer la sécurité. Nous proposons aussi deux langages de script intégrés. Le premier est notre propre module JavaScript NGINX [anciennement appelé nginScript], et le second est Lua.

Certaines fonctionnalités sont disponibles en partie dans la version open source de NGINX, mais sont améliorées dans NGINX Plus. La version open source de NGINX permet d’effectuer efficacement la répartition de charge, mais NGINX Plus offre quelques fonctionnalités avancées supplémentaires. De même, vous pouvez utiliser la version open source de NGINX comme cache en périphérie et pour la diffusion de contenus multimédias, avec des performances encore meilleures dans NGINX Plus.

NGINX Plus possède également plusieurs fonctionnalités qui lui sont propres. Il propose notamment la surveillance de l’état des applications, une interface graphique pour visualiser les données de surveillance, des fonctions de surveillance et d’analyse, une API de configuration RESTful, ainsi que certaines techniques avancées d’équilibrage de charge.

Avec NGINX Plus, vous avez accès aux ingénieurs NGINX, qui peuvent vous accompagner dans votre travail. Si vous utilisez actuellement F5, Citrix ou un système similaire, vous êtes probablement habitué à ce type d’assistance. Pour les sites web de grande envergure et à fort trafic, où la moindre interruption peut coûter très cher, cet accompagnement peut s’avérer crucial et être facilement rentabilisé s’il permet d’éviter ne serait-ce qu’une brève panne une fois par an.

14:41 Étude de cas client – WordPress.com

Examinons quelques études de cas de clients qui ont franchi le pas.

WordPress.com utilisait BIG‑IP de F5, mais a abandonné cette solution au profit de NGINX, car l’entreprise devait assurer la répartition de charge de plus de 10 000 requêtes par seconde et par serveur. C’est le problème C10k dont nous parlions, que NGINX résout depuis plus de dix ans. À l’époque, WordPress.com était limité à 1 000 requêtes par seconde et par serveur. Vous imaginez à quel point cette contrainte était lourde par rapport à une capacité de 10 000 requêtes ou plus.

WordPress.com disposait de plusieurs systèmes F5 BIG‑IP et prévoyait de passer à dix centres de données. Pour assurer une haute disponibilité, c’est-à-dire disposer d’un système de secours opérationnel pour chaque centre de données, l’entreprise envisageait d’utiliser dix paires de serveurs BIG‑IP. Une solution très coûteuse. Elle avait également besoin de pouvoir modifier la configuration à la volée afin de ne pas déconnecter les utilisateurs lors de ces changements.

Ils ont commencé leur migration vers NGINX en le testant sur Gravatar, une application qui affiche un avatar pour les utilisateurs. Cela leur a permis de se familiariser avec NGINX. Ils ont ensuite remplacé leurs serveurs F5 par NGINX, ce qui leur a permis de bénéficier d’une empreinte mémoire faible et prévisible, ainsi que d’une utilisation du processeur faible et prévisible.

Ils traitent désormais plus de 70 000 requêtes par seconde et 15 gigabits par seconde [Gbit/s] sur 36 serveurs NGINX. Ils peuvent atteindre des pics de 20 000 requêtes par seconde et par serveur. Ils peuvent également effectuer des reconfigurations et des mises à jour à la volée.

Si vous regardez le devis, ils parlent simplement de la différence de coût pour un déploiement de petite envergure, où NGINX vous permettra d’économiser une somme importante. Mais lorsque vous passez à dix paires de serveurs, la différence est véritablement considérable.

16:42 Étude de cas client – Montana Interactive

Montana Interactive choisit NGINX Plus pour assurer une répartition de charge à haute disponibilité. Il est en réalité plus simple, moins coûteux et plus efficace de proposer de nombreux services publics en ligne. Si vous avez déjà pris rendez-vous auprès du service des véhicules automobiles ou d’un organisme similaire, vous voyez ce que je veux dire. Ces sites web peuvent permettre de voter, de payer ses impôts, etc.

Il existe un très grand nombre de services publics essentiels de ce type, et le Montana est un État très vaste, dont la population relativement peu nombreuse est dispersée sur l’ensemble du territoire. Il est donc très important que ces services soient accessibles en ligne, afin d’éviter aux habitants de devoir faire six ou huit heures de route pour se rendre dans un service administratif.

Au départ, le Montana a développé ses services en ligne à un rythme soutenu, mais à mesure que leur utilisation augmentait, des interruptions de session ont commencé à se produire. Le trafic transactionnel connaissait d’importants pics trimestriels en raison d’une application de paiement des impôts très utilisée. En plein milieu d’un long formulaire, un utilisateur pouvait soudainement être déconnecté et perdre tout son travail. Quand on remplit sa déclaration de revenus ou que l’on effectue toute autre démarche complexe, c’est particulièrement stressant.

La solution a consisté à remplacer les serveurs exécutant Pound par NGINX Plus, à déployer NGINX Plus sur différents hyperviseurs et dans plusieurs centres de données, et à l’utiliser comme proxy inverse dynamique afin d’acheminer les requêtes en temps réel et de mieux gérer le trafic. Grâce à cette migration vers NGINX Plus, ils ont constaté des améliorations considérables en matière de rapidité, de flexibilité et de facilité d’utilisation. Ils ont bénéficié de la reconfiguration à la volée, ont déchargé le traitement SSL sur les serveurs NGINX et ont utilisé une gestion basée sur les rôles pour améliorer les opérations et la sécurité.

James Ridle, de Montana Interactive, a été impressionné par la puissance de NGINX. Les résultats des tests de performance l’ont stupéfié, et il avait peine à croire à quel point NGINX lui permettait de traiter une charge plus importante avec les mêmes serveurs.

18:43 Étude de cas client – BuyDig.com

Voici une autre étude de cas qui illustre les avantages considérables obtenus par le client, BuyDig.com, un site d’e-commerce qui a gagné en évolutivité et en sécurité grâce à NGINX.

BuyDig.com disposait d’une ancienne application .NET. L’entreprise ne souhaitait pas la modifier, et cela n’a pas été nécessaire. Après avoir subi une attaque DDoS à grande échelle, elle a compris qu’elle avait besoin d’un frontend rapide, tolérant aux pannes et facile à configurer, offrant de meilleures performances, une sécurité renforcée et une plus grande évolutivité.

Ils ont déployé NGINX Plus dans la couche applicative front-end, hébergée sur Amazon Web Services. Ils n’ont apporté aucune modification à leurs services back-end fonctionnant sous .NET. Et c’est un avantage considérable : aucun changement, pas même de petites modifications, de légers désagréments ou des risques mineurs. Absolument aucun.

Ils bénéficient désormais de performances et d’une sécurité exceptionnelles. Ils ont utilisé les langages de configuration de NGINX pour le personnaliser. Ils utilisent le SNI TLS et des journaux personnalisables afin de renforcer leur sécurité. Ils n’ont connu aucun ralentissement ni aucune indisponibilité du site, et sont vraiment très satisfaits des performances.

Voilà donc quelques exemples de ce que NGINX Plus peut faire.

20:10 Ebook – 5 raisons de passer à une solution logicielle pour l’équilibrage de charge

Passons maintenant à l’ebook. Je vais vous résumer rapidement son contenu, puis Faisal vous présentera les deux premières raisons de changer de solution, qui sont plus techniques. Je reprendrai ensuite. Des liens sont disponibles. À l’issue de cette session, vous recevrez cette présentation ainsi que l’enregistrement du webinaire. Il faut compter environ une journée, je crois, pour que cet e-mail vous soit envoyé.

Et ce lien vous permettra d’accéder à la page de téléchargement de cet ebook gratuit. Pour vous donner dès maintenant un aperçu des raisons : réduire les coûts ; mieux s’intégrer aux pratiques DevOps ; pouvoir déployer partout (sur vos propres serveurs sur site, dans le cloud, dans un cloud privé, ou selon toute autre configuration de votre choix) ; s’adapter rapidement et éviter les contraintes contractuelles inhabituelles, que je vous expliquerai plus en détail. Mais pour l’instant, je laisse la parole à Faisal, qui va vous parler de la réduction des coûts.

21:22 Raison n° 1 – Réduire considérablement les coûts

Faisal : Merci, Floyd. La première des cinq raisons est que vous pouvez réduire considérablement vos coûts en passant à NGINX Plus pour la mise à disposition d’applications logicielles.

Au milieu des années 1990, la seule façon de faire évoluer un site Web consistait à acheter un serveur plus puissant, ce qui était extrêmement coûteux et peu fiable, car ce serveur unique constituait également un point de défaillance unique.

C’est à cette époque que F5 a lancé pour la première fois BIG‑IP, offrant ainsi aux propriétaires de sites web une architecture différente : au lieu d’acheter un serveur plus puissant, ils pouvaient utiliser BIG‑IP pour répartir la charge entre plusieurs serveurs peu coûteux. Cela permettait de réduire les coûts, car l’achat de BIG‑IP et de serveurs peu coûteux revenait moins cher que celui d’un unique serveur gigantesque, tout en apportant une certaine redondance grâce à l’élimination du point de défaillance unique.

C’était une excellente architecture – révolutionnaire et vraiment la seule solution disponible à l’époque –, mais beaucoup de choses ont changé au cours des 20 dernières années. L’un des principaux changements est la baisse spectaculaire du coût des serveurs. Aujourd’hui, on peut acheter un serveur assez puissant pour moins que le prix d’un mois de loyer ici, dans la baie de San Francisco.

Le deuxième changement majeur est l’existence désormais de logiciels open source comme NGINX, qui offrent les mêmes fonctionnalités que F5 BIG‑IP ou Citrix NetScaler. Avec l’open source, vous pouvez bénéficier gratuitement de fonctionnalités similaires à celles de ces équipements coûteux. Floyd a indiqué précédemment que plus de 160 millions de sites web utilisent NGINX. Et parmi les 10 000 sites les plus importants, plus de la moitié fonctionnent avec NGINX.

Nous disposons donc désormais de ce logiciel open source qui, non seulement, offre toutes les fonctionnalités dont vous avez besoin par rapport à F5, mais est également aussi évolutif et fiable que n’importe quel autre produit commercial.

23:19 NGINX Plus face à F5 BIG‑IP

J’ai réalisé des tests de performance et une analyse des coûts plus tôt cette année, et en voici un extrait. Il s’agit de comparer le logiciel NGINX Plus exécuté sur du matériel standard disponible dans le commerce — fourni ici par Dell — à différents modèles de F5 BIG‑IP.

Dans cet exemple précis, il s’agit du modèle 2000S, l’entrée de gamme de F5 BIG‑IP. Je l’ai comparé à deux configurations différentes de NGINX Plus sur des serveurs Dell : l’une offre des performances légèrement inférieures à celles de F5 BIG‑IP (vous pouvez voir les indicateurs de performance en bas), tandis que l’autre affiche des performances presque deux fois supérieures.

Si l’on considère uniquement la colonne de droite, où NGINX Plus offre des performances deux fois supérieures à celles du 2000S, vous réalisez 78 % d’économies dès la première année, y compris sur le coût du matériel et du contrat de maintenance d’un an. Ces économies se poursuivent jusqu’à la cinquième année. Même après cinq ans, le coût total de possession de NGINX Plus avec le serveur Dell reste inférieur de 58 % à celui de F5.

24:37 NGINX Plus face à Citrix NetScaler

J’ai effectué la même comparaison des coûts avec Citrix NetScaler. Ici, nous comparons le modèle d’entrée de gamme de NetScaler, le MPX‑5550 Enterprise Edition.

Avec le modèle de licence de Citrix, si vous souhaitez bénéficier de fonctionnalités de base telles que la mise en cache et la compression de contenu, vous devez passer à la licence Enterprise Edition. Avec NGINX, la mise en cache et la compression de contenu sont incluses sans frais supplémentaires, aussi bien dans la version open source que dans NGINX Plus. Nous comparons donc ici l’édition Enterprise de Citrix NetScaler, car ses fonctionnalités correspondent davantage à celles proposées par NGINX Plus. Nous constatons les mêmes économies qu’avec F5 lorsque Citrix NetScaler est remplacé par NGINX Plus.

Vous bénéficiez de toutes les fonctionnalités et performances attendues, tout en payant 89 % de moins la première année. Même au bout de cinq ans, vous économisez encore 75 % sur le coût du matériel (dans ce cas, des serveurs Dell standard) et sur celui d’un abonnement au logiciel NGINX Plus.

Une métrique essentielle, dont les fournisseurs de matériel parlent beaucoup, est le nombre de transactions SSL par seconde, autrement dit le nombre de nouvelles connexions SSL pouvant être établies chaque seconde. Sur ces plateformes, ce nombre est généralement augmenté grâce à une accélération matérielle. NetScaler et F5 BIG‑IP disposent donc de matériel spécialisé pour accélérer les transactions SSL, ce qui augmente le coût de ces plateformes.

Nous constatons que, même avec une solution logicielle — sans accélération matérielle, en utilisant uniquement la puissance de calcul du processeur —, nous pouvons rivaliser avec le matériel spécialisé. Nous permettons de réaliser des économies considérables tout en offrant les mêmes performances que les solutions à accélération matérielle.

Voilà donc la raison n° 1 : vous pouvez réaliser d’importantes économies en passant à NGINX Plus. Mais ce n’est pas qu’une question d’argent.

26:52 Raison n° 2 – Le DevOps nécessite une solution de mise à disposition des applications logicielles

Une solution logicielle vous offre également une grande flexibilité. La deuxième raison de passer à un répartiteur de charge logiciel est que, si vous adoptez le DevOps, vous avez réellement besoin d’un logiciel pour assurer la mise à disposition des applications.

Avec F5 et NetScaler, ces appliances sont généralement déployées au sein des grandes entreprises comme points d’agrégation. Elles acheminent donc de nombreux flux sans rapport entre eux. Un même F5 BIG‑IP peut répartir la charge entre des pare-feu réseau, des serveurs de messagerie d’entreprise, plusieurs applications d’entreprise back-end différentes, mais aussi pour l’application d’entreprise exposée au public. Il peut également répartir la charge entre des API dans une architecture de microservices. Il peut donc assurer la répartition de charge pour de nombreux éléments.

À première vue, cette architecture semble judicieuse, car elle est assez simple : il suffit de tout faire transiter par le F5. Cette approche a bien fonctionné pendant longtemps, notamment au début des années 2000, lorsque les centres de données privés étaient la norme et que toutes nos applications, c’est-à-dire tout ce dont l’entreprise dépendait, étaient exécutées depuis un centre de données sur site. Mais les choses ont changé ces dernières années, et désormais, la plupart des ressources sont transférées vers le cloud.

Quand je parle de cloud, je ne parle pas seulement de l’hébergement d’une application web destinée au public sur Amazon, mais aussi de l’utilisation de solutions comme Salesforce et Office 365, plutôt que de systèmes CRM et de serveurs de messagerie sur site. Disposer d’un appareil capable de remplir toutes ces fonctions peut donc être excessif au regard de ce que les entreprises utilisent réellement aujourd’hui.

Un deuxième problème posé par cette agrégation est qu’elle conduit à verrouiller très strictement ces appliances. On hésite alors beaucoup à y apporter des modifications, car une erreur dans la configuration de F5 pourrait entraîner l’indisponibilité de l’ensemble du réseau de l’entreprise. L’appliance peut notamment assurer la répartition de charge des serveurs de messagerie ou faire office de pare-feu réseau. La configuration devient donc une opération risquée, et les modifications doivent être très limitées et strictement encadrées.

Toute personne souhaitant y apporter des modifications doit généralement soumettre un ticket au service informatique, dont le traitement peut prendre des heures, des jours, voire des semaines, selon l’organisation et le niveau de priorité qu’elle accorde à la modification demandée.

Le fait de disposer d’un équipement matériel aussi verrouillé rend la transition vers le DevOps très difficile. Lorsque vous adoptez le DevOps, vous vous orientez vers l’automatisation, l’intégration continue et des mises en production de code beaucoup plus fréquentes. Or, si vous devez ouvrir un ticket auprès du service informatique chaque fois que vous souhaitez apporter une modification, cela freine cette initiative et finit par la faire échouer.

Ce que nous constatons dans de nombreuses organisations, c’est que les personnes responsables de l’application et désireuses d’adopter le DevOps et le développement Agile ne peuvent pas se permettre de devoir ouvrir un ticket à chaque fois, car cela entrave les initiatives DevOps et Agile. Elles déploient donc parfois la version open source de NGINX et configurent F5 BIG‑IP pour qu’il redirige le trafic vers celle-ci. Cette instance NGINX est alors gérée par l’équipe DevOps ou l’équipe applicative, ce qui lui permet d’automatiser les processus et d’apporter des modifications sans difficulté. C’est donc une façon de contourner, en quelque sorte, la politique informatique de l’entreprise. Bien entendu, nous constatons ensuite que de nombreux clients, après avoir essayé cette solution, commencent à migrer vers NGINX Plus afin de bénéficier de fonctionnalités plus avancées ainsi que d’une assistance.

NGINX prend en charge différents modèles de déploiement flexibles, notamment des modèles qui vous permettent de conserver votre solution F5 actuelle. Vous pouvez utiliser NGINX Plus pour compléter et délester l’équilibrage de charge et la diffusion des applications web frontales, des API et des microservices, tout en conservant F5 pour assurer l’équilibrage de charge réseau des serveurs de messagerie de l’entreprise. Si vous n’avez pas besoin de services réseau ni d’équilibrage de charge réseau, vous pouvez bien entendu remplacer simplement F5 par NGINX Plus et disposer ainsi d’une solution unique.

Nous prenons en charge différents modèles de déploiement afin d’aider les organisations à adopter le DevOps, la livraison continue et l’automatisation.

Pour la raison n° 3, je redonne la parole à Floyd.

31:59 Raison n° 3 – Déployez partout avec un seul ADC

Floyd :Merci, Faisal.

Avec NGINX, vous pouvez déployer partout à l’aide d’une solution ADC unique. Que signifie « partout » ? Cela signifie que vos serveurs sur site, votre cloud public, votre cloud privé ou votre cloud hybride fonctionnent tous avec une seule et même solution. Cette approche présente à la fois un aspect pratique et un aspect architectural.

Tout d’abord, si vous utilisez des serveurs internes et n’avez pas recours au cloud, tout ce que nous avons dit s’applique pleinement. De nombreuses personnes qui passent à NGINX et NGINX Plus afin de gagner en flexibilité, de bénéficier de davantage de fonctionnalités et de réaliser des économies se trouvent précisément dans cette situation : elles déploient leur infrastructure sur des serveurs internes.

Si vous utilisez le cloud ou envisagez d’y recourir à l’avenir, NGINX et un ADC matériel ne sont tout simplement pas comparables. Vous ne pouvez pas transférer votre ADC matériel dans les centres de données d’Amazon. Un ADC matériel ne vous sera d’aucune utilité dans ce contexte.

Certes, les développeurs d’ADC matériels proposent des solutions logicielles, mais dans certains cas, ils recommandent de les utiliser uniquement pour le développement. Elles ne remplacent pas l’ADC matériel. Les avantages que vous pourriez y voir en matière de simplicité, ou selon le principe « si ce n’est pas cassé, inutile de le réparer », disparaissent dès lors que vous souhaitez migrer vers le cloud.

Avec NGINX et NGINX Plus, l’architecture de l’application est indépendante de la plateforme de déploiement. Certains fournisseurs de services cloud commencent à proposer de plus en plus de services auxquels vous pouvez vous connecter au moyen d’API. Pendant le développement, c’est vraiment très pratique, car vous n’avez pas à vous soucier de la manière de procéder : il vous suffit d’utiliser leurs API pour gérer l’équilibrage de charge, la mise en cache ou d’autres fonctionnalités. Mais lorsque vous passez à l’échelle, vous payez un petit montant pour chaque transaction.

Et soudain, lorsque vous effectuez des milliers, des dizaines de milliers, voire des centaines de milliers de transactions, ces montants commencent à s’accumuler. La facturation est très complexe et difficile à prévoir, d’autant plus qu’elle dépend du trafic, qui fluctue en permanence.

Si vous optez pour une approche basée sur NGINX ou NGINX Plus, vous procédez globalement de la même manière sur toutes les plateformes, et le passage à un autre fournisseur de cloud ou le retour à une infrastructure interne ne change pratiquement rien.

Nous avons d’ailleurs des clients qui répartissent la charge entre leurs serveurs internes et le cloud. Concrètement, comment cela fonctionne-t-il ? Ils disposent de suffisamment de serveurs internes pour répondre à leurs besoins 80 à 90 % du temps. Ensuite, lorsqu’ils doivent augmenter leur capacité, ils n’ont pas besoin d’acheter ni même de brancher de nouveaux serveurs : il leur suffit de recourir au cloud.

Le cloud est généralement plus lent que vos serveurs sur site. Comme la charge est répartie, seules les sessions qui seraient interrompues si vous utilisiez uniquement vos serveurs internes sont redirigées vers le cloud. Leur latence est légèrement plus élevée, mais elles sont prises en charge au lieu d’être mises en file d’attente ou interrompues.

Sur le plan financier, c’est très avantageux, car vous ne payez le cloud qu’en cas de besoin exceptionnel, par exemple lors d’un pic soudain de trafic. Cela peut arriver à la suite d’une couverture médiatique ou d’un avis favorable sur votre produit. Il se peut aussi que vous dépassiez régulièrement les prévisions de votre plan d’activité sans avoir encore augmenté vos capacités en interne, ou que ce soit simplement la période des fêtes et qu’il ne soit pas rentable de disposer de deux fois plus de serveurs alors que vous n’en aurez besoin que quelques semaines par an, puisqu’il suffit d’étendre vos capacités dans le cloud. Avec NGINX, tout cela peut être réalisé de manière flexible, voire automatique.

35:42 Raison n° 4 – S’adapter rapidement à l’évolution des besoins

NGINX vous permet de vous adapter rapidement à l’évolution des exigences de vos applications. Lorsque vous devez ajouter rapidement des serveurs ou des paires de serveurs pour assurer une haute disponibilité, vous ne pouvez pas attendre que le matériel soit commandé, livré, réceptionné et testé, puis que les iRules ou toute autre configuration logicielle nécessaire soient mises en place. De plus, iRules est une technologie propriétaire : vous n’en avez besoin que si vous disposez d’un serveur F5. Ce n’est pas une compétence que l’on trouve facilement chez les jeunes diplômés. Si votre spécialiste iRules quitte l’entreprise, vous aurez beaucoup de mal à le remplacer.

Lorsqu’il s’agit de modifier la configuration, vous ne pouvez souvent pas attendre que l’équipe chargée des opérations réseau approuve les changements. Vous ne voulez pas vraiment que vos demandes soient mises en attente derrière d’autres moins urgentes.

Avec NGINX, le processus d’approbation des nouveaux projets est beaucoup moins contraignant. Avec NGINX et NGINX Plus, vous pouvez conserver du matériel supplémentaire dans un placard lorsqu’il s’agit de serveurs coûtant 2 000 ou 3 000 $. Ce n’est pas envisageable lorsqu’il s’agit de dépenser plusieurs dizaines de milliers de dollars pour des contrôleurs ADC matériels.

Ce niveau de flexibilité et de redondance, ainsi que la possibilité de faire ce dont vous avez besoin au moment où vous en avez besoin, constituent une caractéristique essentielle de NGINX et expliquent en partie pourquoi nos utilisateurs nous apprécient autant.

37:08 Raison n° 5 – Aucune limitation artificielle des performances

Enfin, avec NGINX, les performances ne sont soumises à aucune contrainte artificielle ou imposée par contrat. Pour NetScaler Enterprise Edition, le débit de ce serveur est contractuellement limité à 0,5 Gbit/s. Une telle limite est tout simplement ridicule dans un environnement d’entreprise. Une configuration NGINX comparable, exécutée sur du matériel standard du marché, peut prendre en charge un débit de 20 Gbit/s, soit 40 fois la limite imposée par Citrix.

L’autre point, c’est que le chiffre de Citrix constitue une limite contractuelle. Si vous la dépassez, le montant de vos paiements augmente soudainement et considérablement. Les 20 Gbit/s correspondent, quant à eux, à une recommandation de notre part. Cela signifie simplement qu’à l’approche de ce seuil, vous pourriez commencer à constater une légère baisse des performances et juger opportun d’ajouter un serveur pour y répartir la charge. Mais vous restez libre de décider. Votre budget ne subit pas de hausse soudaine.

Avec Citrix, c’est comme se retrouver face à un panneau stop. Dans ce cas, une hausse de l’activité peut être une mauvaise nouvelle. Un seul client supplémentaire peut vous coûter très cher, et quelques clients de plus peuvent également vous coûter très cher, car ils vous font dépasser ces plafonds. Avec NGINX, en revanche, une hausse de l’activité est une bonne nouvelle, et vos coûts augmentent progressivement à mesure que vos revenus s’accroissent grâce à l’élargissement de votre clientèle.

Nous recevons souvent des appels urgents de personnes qui ont dépassé ces plafonds et se retrouvent soudainement hors budget. Et elles ne pourront pas revenir dans les limites de leur budget sans procéder à un changement majeur. Elles doivent alors passer en urgence à NGINX pour rétablir la situation. Souvent, elles finissent même par dépenser moins que prévu, tant les économies réalisées grâce à NGINX sont importantes.

Mais qui a besoin de tels tracas ? Sans parler de l’incertitude et du sentiment d’angoisse qui vous envahit lorsque vous vous retrouvez soudain confronté à ce terrible dilemme entre budget et performances. En passant à NGINX suffisamment tôt, vous pouvez éviter tout cela.

40:00 Ressources

• Étude de cas – NGINX chez WordPress.com/Automattic
• Étude de cas – Montana Interactive améliore les performances de ses applications et son service client grâce à NGINX Plus
• Étude de cas – Comment Buydig.com fait évoluer et sécurise son application Microsoft .NET sans modifier une seule ligne de code
• Livre blanc – 5 raisons de passer à une solution logicielle d’équilibrage de charge
• Blog – NGINX Plus vs F5 BIG‑IP : comparaison du rapport prix-performances
• Blog – NGINX Plus face à Citrix NetScaler : comparaison du rapport prix-performances
• Essai gratuit de NGINX Plus

À propos de l’auteur

Floyd SmithDirecteur du marketing de contenu

Autres articles de Floyd Smith