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

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

Table des matières

0:00 Présentation

Floyd Smith : Bonjour et bienvenue à notre présentation. Nous sommes ici chez NGINX, et nous parlerons aujourd'hui de mon ebook 5 raisons de passer à un logiciel d'équilibrage de charge .

Nous sommes deux à présenter ici aujourd’hui. Je m’appelle Floyd Smith et je suis rédacteur technique et marketing pour NGINX. J’étais auparavant rédacteur technique senior chez Apple et j’ai écrit plusieurs ouvrages sur différents aspects de la technologie.

Fayçal Memon : Bonjour, je m’appelle Faisal Memon et je suis responsable du marketing produit chez NGINX. Je suis ici depuis environ un an. Avant de venir ici chez NGINX, j'ai travaillé comme ingénieur marketing technique chez Riverbed, ainsi que chez Cisco. J'ai commencé ma carrière en faisant du développement en C. Ingénieur logiciel chez Cisco – j'ai occupé ce poste pendant environ huit ans.

1:38 Qui es-tu ?

Floyd : Nous recevons des inscriptions pour nos webinaires avant de les organiser, et nous pouvons voir les titres de poste, les organisations et les raisons de participation que chacun d'entre vous a soumis.

C’était vraiment intéressant de regarder les titres des personnes présentes. Nous avons des architectes de solutions – plusieurs types d’architectes différents. Administrateurs Linux, responsables de l'ingénierie, PDG, responsable senior de la livraison Agile, plusieurs personnes avec des titres DevOps, développeur de logiciels Full Stack, ingénieur, scientifique, développeur, responsable des opérations marketing.

Nous disposons d’un très bon éventail de personnes ayant des compétences techniques. J’ai l’impression que les personnes qui participent à ce webinaire maîtrisent très bien la technologie et seront directement confrontées aux problèmes dont nous parlons aujourd’hui.

Nous avons également un très bel éventail d’organisations représentées. Certains d’entre vous s’intéressent peut-être à cela pour pouvoir guider vos clients dans la prise de décisions intelligentes, mais la majorité d’entre vous semblent gérer cela directement, en interne.

3:53 Du matériel au logiciel

Le marché des ADC matériels est en déclin, selon les rapports financiers, donc les personnes qui vendent des ADC matériels tentent d'augmenter les revenus qu'ils obtiennent par client même si leur base de clientèle diminue. De nombreux clients de matériel ADC commencent à se rendre compte qu’ils ne veulent pas faire partie de ce groupe toujours plus restreint de personnes qui paient toujours plus cher pour ces services fournis par le matériel ADC. Ils commencent à voir qu’ils peuvent réellement faire la même chose en mieux au niveau logiciel et gagner en flexibilité. Ceux d’entre vous dont le titre inclut DevOps savent probablement ce que je veux dire.

Ce que nous voyons souvent ici chez NGINX, c'est que les gens atteignent la date de renouvellement du contrat sur leur ADC matériel, ou qu'ils subissent une augmentation soudaine du trafic et une hausse soudaine des frais, et qu'ils se démènent alors vraiment pour sortir du contrat. Ensuite, il faut essayer de faire les choses très vite. Ils réussissent généralement, mais c’est stressant, ce n’est pas planifié et ce n’est pas budgété. Avec l’aide de cette présentation, vous pouvez démarrer un processus plus planifié.

La question budgétaire n’est pas aussi critique, car vous économisez beaucoup d’argent en passant au logiciel, mais les tracas opérationnels sont énormes. Vous pouvez réduire considérablement ces risques simplement en commençant tôt.

NGINX est une alternative vraiment solide à un ADC matériel. Il a été créé à l'origine pour résoudre le problème C10K . Il s’agit d’un serveur Web exécuté sur un ordinateur et servant 10 000 connexions simultanées ou plus. Avant NGINX c'était impossible. Les gens créeraient un site Web, il deviendrait populaire, puis il s’effondrerait. Empêcher que cela se produise était très, très, très difficile, mais avec NGINX, c'est devenu beaucoup plus facile.

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

La société NGINX est basée dans la Silicon Valley (San Francisco) et nos bureaux de développement sont à Moscou. Nous avons également des bureaux au Royaume-Uni. L’entreprise est soutenue par des capitaux de capital-risque provenant de leaders du secteur. Nous avons plus de 800 clients et nous venons d’atteindre les 100 employés l’autre jour.

6:33 Le serveur Web leader pour les sites les plus fréquentés au monde

Il y a 160 millions de sites au total fonctionnant sur NGINX.

Il est utilisé dans deux modes différents. Certains sites utilisent NGINX comme serveur Web , ce qui était son objectif initial. Mais de nombreux sites utilisent NGINX comme serveur proxy inverse . C'est là que vous placez NGINX devant votre architecture actuelle, en utilisant NGINX pour gérer le trafic et acheminer le trafic vers vos serveurs d'applications. Dès que vous faites cela, vous êtes sur la bonne voie pour réaliser un équilibrage de charge , ce dont nous parlerons aujourd'hui.

51 % des 10 000 sites Web les plus fréquentés sont passés à NGINX. Pourquoi ? Pourquoi avons-nous une utilisation encore plus grande parmi les sites Web les plus fréquentés que parmi les sites Web dans leur ensemble ?

La raison est que NGINX est la meilleure solution pour les sites Web très fréquentés. Un moyen rapide de sauver un site Web très fréquenté qui rencontre des problèmes consiste à utiliser NGINX comme serveur proxy inverse, puis à exécuter l'équilibrage de charge par-dessus .

Au fil du temps, vous pouvez soit transférer vos applications existantes vers NGINX, soit, si vous en développez de nouvelles, exécuter NGINX comme serveur Web également pour celles-ci. Et c’est ainsi que nous avons réussi à obtenir cette utilisation parmi ces personnes très occupées, qui ne changent pas de serveur Web sur un coup de tête. Ils ont de l’expérience avec d’autres serveurs Web et savent comment les utiliser, mais ils font ce changement à cause de tout ce que NGINX fait pour eux.

36 % de tous les sites sur Amazon Web Services utilisent NGINX. C'est en quelque sorte devenu un outil standard. Désormais, les gens commencent souvent avec NGINX et s’y tiennent tout au long de leur projet.

Voici quelques sites qui nous utilisent. Bien sûr, avec 160 millions de sites Web utilisant NGINX, nous ne pouvons pas tous les avoir sur une seule diapositive, mais certains de nos partenaires et amis sont Netflix, Airbnb, Uber et Amazon Web Services, comme je l'ai mentionné, Box, Pinterest, WordPress.

Toutes ces entreprises qui font de la diffusion Web pour gagner leur vie, là où cela doit fonctionner, sont passées à NGINX.

8:48 La place de NGINX

Voyons où se situe NGINX.

Sur la droite, vous voyez NGINX exécuté en tant que serveur Web. Et en tant que serveur Web, il utilise une passerelle d’application pour permettre à différents types de serveurs d’applications de fonctionner avec lui. En tant que serveur Web, NGINX peut gérer 10 000 connexions simultanées, plus ou moins, selon ce que vous faites.

Mais NGINX est également utile en tant que serveur proxy inverse, et c’est là que vous obtenez la mise en cache, l’équilibrage de charge et un certain nombre d’autres fonctionnalités.

9:32 Architecture Web moderne

NGINX vous aide également à migrer vers une architecture Web moderne. Il pourrait s’agir d’architectures de type J2EE à trois niveaux migrant vers des microservices. Il peut s'agir de protocoles complexes HTML et SOAP passant à des protocoles plus légers comme REST et la messagerie, qui constituent une grande partie des microservices. Ou passer de déploiements persistants à des déploiements mutables 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 possédez vous-même. Nous avons des choses comme SDN et NFV et le cloud, en particulier le cloud. Au lieu de sorties massives tous les quelques mois, vous bénéficiez d'une livraison continue toutes les quelques heures. Et au lieu d’équipes cloisonnées, où vous avez un groupe de développement, un groupe de test et un groupe d’exploitation travaillant par l’intermédiaire de leurs propres responsables, vous avez une culture DevOps de responsabilité partagée où chacun retrousse ses manches et gère certains aspects de chaque problème.

10:42 DevOps fonctionne parfaitement avec NGINX

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

L’histoire de DevOps est étroitement liée à NGINX. De nombreux acteurs de DevOps ont NGINX dans leurs poches et lorsqu’ils rencontrent un déploiement qui rencontre des problèmes, ils font appel à NGINX.

Dans certains déploiements, vous pouvez même ne pas prendre la peine de modifier la configuration de l'application. Vous placez NGINX devant lui, vous obtenez le trafic vers les serveurs d'applications d'une manière qu'ils peuvent gérer. Vous n’avez pas modifié ce code et vous n’avez pas mis en péril vos fonctionnalités principales lorsque vous êtes pressé de résoudre un problème de performances.

L’une des choses pour lesquelles DevOps et NGINX ont tendance à bien fonctionner ensemble est l’équilibrage de la charge logicielle, comme nous le verrons. Cela fonctionne très bien avec les déploiements cloud, mais aussi avec vos propres serveurs. Il propose une variété de méthodes d’équilibrage de charge. Il y a ici une différence entre NGINX et NGINX Plus, sur laquelle je reviendrai dans une minute.

La capacité de reconfiguration à la volée de NGINX prend en charge la découverte et la disponibilité des services. La découverte de services est essentielle pour les microservices et l’automatisation, et avec la reconfiguration à la volée, vous n’avez pas besoin de faire sortir les gens d’un serveur pour le configurer, ce qui constitue un énorme avantage pour garder vos clients en ligne.

Les contrôles de santé des applications donnent un avertissement précoce des problèmes de distribution des applications afin que vous puissiez arrêter en douceur un serveur problématique, plutôt que de le laisser se bloquer et perturber les utilisateurs. Et puis il y a une surveillance robuste et personnalisable. Encore une fois, cela vous permet d'être informé des problèmes dès qu'ils surviennent, afin que vous puissiez les résoudre avant qu'ils n'affectent les clients.

12h30 Fonctionnalités de NGINX Plus

Que contient NGINX Plus ?

Ainsi, NGINX open source est le produit original, et NGINX Plus est le produit commercial qui se trouve au-dessus. Chez NGINX, nous passons au moins 70 % de notre temps sur le côté open source, mais c'est également la base des fonctionnalités avancées de NGINX Plus.

Le produit open source inclut le routage des requêtes, qui est le cœur de ce que fait un serveur Web ; la compression car cela minimisera la charge sur un serveur Web et minimisera également le trafic sur le réseau, ce qui peut être très précieux. Il prend en charge SSL pour la sécurité. Nous disposons également d’un langage de script intégré, deux en fait. L'un est le nôtre, le module JavaScript NGINX [anciennement appelé nginScript], et l'autre est Lua.

Il existe quelques fonctionnalités qui sont en partie open source NGINX mais qui sont améliorées dans NGINX Plus. Vous pouvez réaliser un équilibrage de charge assez efficace avec NGINX open source, mais avec NGINX Plus, vous obtenez quelques fonctionnalités plus avancées. De même, vous pouvez utiliser NGINX open source comme cache de périphérie et pour le streaming multimédia, et cela fonctionne encore mieux dans NGINX Plus.

NGINX Plus possède également plusieurs fonctionnalités qui lui sont propres. Il existe la surveillance de l’état des applications, la visualisation de l’interface utilisateur graphique pour votre surveillance, la surveillance et l’analyse, l’API de configuration RESTful et quelques-unes des techniques d’équilibrage de charge les plus avancées.

Avec NGINX Plus, vous avez accès aux ingénieurs NGINX pour vous aider dans votre travail. Si vous utilisez actuellement F5, Citrix ou un système similaire, vous êtes probablement habitué à ce type de support. Pour les sites Web plus grands et plus fréquentés, où même un petit temps d'arrêt vous coûte beaucoup d'argent, cela peut être crucial - et peut facilement s'autofinancer si vous évitez même 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 fait le changement.

WordPress.com utilisait BIG-IP de F5 et ils l’ont abandonné pour NGINX car ils avaient besoin d’équilibrer la charge avec plus de 10 000 requêtes par seconde et par serveur – c’est le problème C10k dont nous parlions et que NGINX résout depuis plus de dix ans. À l’époque, ils étaient limités à 1 000 requêtes par seconde et par serveur. Vous pouvez imaginer à quel point cela représentait un fardeau par rapport à 10 000 ou plus.

Wordpress.com possédait plusieurs systèmes F5 BIG-IP et allait évoluer vers dix centres de données. Pour assurer une haute disponibilité, c'est-à-dire pour disposer d'une sauvegarde en direct pour chaque centre de données, ils envisageaient dix paires de serveurs BIG-IP. Très cher. Ils avaient également besoin d’une reconfiguration à la volée pour ne pas expulser les utilisateurs lorsqu’ils modifiaient la configuration.

Ils ont commencé à passer à NGINX en le testant sur Gravatar, une application qui propose un avatar aux utilisateurs. Cela leur a permis de se familiariser avec NGINX. Ils ont ensuite migré de leurs serveurs F5 vers NGINX, ce qui leur a permis d'obtenir une empreinte mémoire réduite et prévisible, ainsi qu'une empreinte CPU réduite et prévisible.

Ils gèrent désormais plus de 70 000 requêtes par seconde et 15 gigabits par seconde [Gbps] sur 36 serveurs NGINX. Ils peuvent atteindre un pic de 20 000 requêtes par seconde et par serveur. Et ils peuvent reconfigurer et mettre à jour à la volée.

Si vous voyez la citation, ils parlent simplement de la différence de dépenses entre une petite implémentation, où NGINX vous fera économiser une somme d’argent importante. Mais lorsque vous passez à dix paires de serveurs, c’est une énorme différence entre le jour et la nuit.

16:42 Étude de cas client – Montana Interactive

Montana Interactive choisit NGINX Plus pour l'équilibrage de charge à haute disponibilité. En réalité, il est plus facile, moins cher et plus efficace de fournir de nombreux services gouvernementaux en ligne. Si vous avez pris rendez-vous auprès de votre service automobile ou autre, vous saurez de quoi je parle. Ces sites Web peuvent vous aider à voter, à payer vos impôts, etc.

Il existe un nombre considérable de ces services gouvernementaux essentiels, et le Montana est un très grand État avec un nombre relativement faible de personnes dispersées partout. Il est donc très important d’avoir accès à des services en ligne, plutôt que de voir les résidents conduire six ou huit heures pour se rendre dans un bureau gouvernemental.

Au début, Montana s'est tourné vers les services en ligne de manière assez dynamique, mais à mesure de sa croissance, il a commencé à souffrir de pertes de sessions. Ils ont connu de gros pics trimestriels de trafic de transactions en raison d'une importante application de paiement des impôts. Au milieu du remplissage d'un long formulaire, quelqu'un pouvait soudainement être abandonné et tout son travail était perdu. Si vous faites vos impôts ou tout autre type de processus complexe, c’est assez stressant.

La solution pour eux était de passer des serveurs exécutant Pound à NGINX Plus, de placer NGINX Plus sur différents hyperviseurs, centres de données et de fonctionner comme un proxy inverse dynamique, acheminant les requêtes en temps réel, leur offrant ainsi une meilleure gestion du trafic. Grâce au passage à NGINX Plus, ils ont constaté des améliorations considérables en termes de vitesse, de flexibilité et de facilité d’utilisation. Ils ont bénéficié d’une reconfiguration à la volée, ils ont déchargé leur traitement SSL sur les serveurs NGINX et ont utilisé la 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 tests de performance l’ont époustouflé et il n’arrivait presque pas à croire la différence dans ce qu’il pouvait gérer sur les mêmes serveurs avec NGINX.

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

Il s’agit d’une autre étude de cas présentant d’énormes avantages pour le client – BuyDig.com, un site de commerce électronique qui a obtenu l’évolutivité et la sécurité avec NGINX.

BuyDig.com avait une ancienne application .NET. Ils ne voulaient pas la modifier et n'étaient pas obligés de le faire. Après avoir subi une attaque DDoS à grande échelle, ils ont réalisé qu'ils avaient besoin d'une interface rapide, tolérante aux pannes et facile à configurer, offrant de meilleures performances, une meilleure sécurité et une meilleure évolutivité.

Ils ont placé NGINX Plus dans la couche d'application frontale, hébergée sur Amazon Web Services. Ils n’ont apporté aucune modification à leurs services back-end exécutés sur .NET. Et c’est tellement énorme – aucun changement – pas de petits changements, pas de tracas mineurs, pas de risques mineurs, mais aucun.

Ils bénéficient désormais de performances et d’une sécurité fantastiques. Ils ont utilisé des langages de configuration pour NGINX pour le personnaliser. Ils utilisent TLS SNI et des journaux personnalisables afin de les aider à rester en sécurité. Ils n’ont pas eu un seul ralentissement ni une seule interruption du site, et ils sont vraiment satisfaits des performances.

Ce ne sont là que quelques exemples de ce que NGINX Plus peut faire.

20:10 Ebook – 5 raisons de passer à un logiciel d'équilibrage de charge

Laissez-moi maintenant plonger dans l’ebook. Je vais vous donner un bref résumé de ce qui se trouve dans l’ebook, puis Faisal vous expliquera les deux premières raisons de changer, qui sont plus techniques, et je reprendrai après cela. Il y a des liens. Vous recevrez cette présentation et l’enregistrement du webinaire à votre disposition une fois que nous aurons terminé. Il faut environ un jour, je pense, pour que cet e-mail soit envoyé.

Et ce lien ici vous amènera à un endroit de téléchargement pour cet ebook gratuit . Alors, juste pour mentionner à l'avance quelles sont les raisons : elles sont de réduire les coûts ; d'améliorer l'adéquation DevOps ; de déployer partout (vos propres serveurs sur site, dans le cloud, dans un cloud privé, tout ce que vous voulez faire) ; la capacité de s'adapter rapidement et aucune contrainte contractuelle étrange, que j'expliquerai en détail. Mais maintenant, laissez-moi céder la parole à Faisal pour qu’il parle de réduction des coûts.

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

Fayçal : Merci, Floyd. La première des cinq raisons est que vous pouvez réduire considérablement les coûts en passant à NGINX Plus pour la livraison d’applications logicielles.

Au milieu des années 90, la seule façon de faire évoluer un site Web était d’acheter un serveur plus grand, ce qui était incroyablement cher et peu fiable, car ce serveur unique était également un point de défaillance unique.

C'est à cette époque que F5 a lancé pour la première fois BIG-IP, qui a fourni une architecture différente aux propriétaires de sites Web ; au lieu d'acheter un serveur plus gros, vous pouviez utiliser BIG-IP pour équilibrer la charge d'un ensemble de serveurs peu coûteux. Cela réduit donc les coûts, car il est moins cher d’acheter le BIG-IP et les serveurs bon marché que d’acheter un seul serveur gigantesque, et vous bénéficiez également d’une certaine redondance car vous avez éliminé le point de défaillance unique.

C’était une architecture formidable – révolutionnaire et vraiment la seule à l’époque – mais beaucoup de choses ont changé au cours des 20 dernières années. L’un des changements majeurs est que le coût des serveurs a considérablement diminué. De nos jours, vous pouvez acheter un serveur assez lourd pour moins que le prix d’un mois de loyer ici dans la région de la baie de San Francisco.

Le deuxième changement majeur est l’existence désormais de logiciels open source comme NGINX qui fournissent les mêmes fonctionnalités que celles de F5 BIG‑IP ou de Citrix NetScaler. Dans le cas de l'open source, vous pouvez obtenir gratuitement des fonctionnalités similaires à celles de ces gros appareils coûteux. Floyd a souligné plus tôt qu’il y a plus de 160 millions de sites Web qui utilisent NGINX. Et si vous regardez les 10 000 meilleurs sites, plus de la moitié d’entre eux fonctionnent sur NGINX.

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

23:19 NGINX Plus contre. F5 BIG-IP

J’ai réalisé une analyse comparative et une analyse des coûts plus tôt cette année et voici un extrait de celle-ci. Il s’agit de comparer le logiciel NGINX Plus exécuté sur du matériel standard. Dans ce cas, il est fourni par Dell, et nous le comparons à différents modèles du F5 BIG‑IP.

Cet exemple particulier est le 2000S, qui est le F5 BIG‑IP d'entrée de gamme. Je l'ai comparé à deux tailles différentes de NGINX Plus sur les serveurs Dell. Un modèle dont les performances sont légèrement inférieures à celles du F5 BIG‑IP (vous pouvez voir les mesures de performances en bas) et un modèle dont les performances sont presque doublées.

En regardant simplement la colonne de droite, où NGINX Plus double les performances du 2000S, vous obtenez 78 % d’économies la première année, y compris le coût du matériel et le support de maintenance pendant un an. Et ces économies de coûts 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 est 58 % moins cher que le F5.

24:37 NGINX Plus contre. Citrix NetScaler

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

Citrix dispose d'un système de licences selon lequel, si vous souhaitez des fonctionnalités de base telles que la mise en cache et la compression de contenu, vous devez mettre à niveau votre licence vers la licence Enterprise Edition. Avec NGINX, la mise en cache et la compression de contenu sont incluses sans frais supplémentaires dans les versions open source et NGINX Plus. Nous comparons ici l'édition Enterprise de Citrix NetScaler, car elle offre une meilleure parité des fonctionnalités avec ce qui est fourni dans NGINX Plus, et nous constatons ici les mêmes économies de coûts qu'avec le F5 lorsque vous remplacez Citrix NetScaler par NGINX Plus.

Vous obtenez toutes les mêmes fonctionnalités et performances que vous attendez, mais vous payez 89 % de moins la première année. Même jusqu’à la cinquième année, vous économisez toujours 75 % sur le coût du matériel (dans ce cas, des serveurs Dell grand public) et sur le coût d’un abonnement au logiciel NGINX Plus.

Une mesure critique, dont les fournisseurs de matériel parlent beaucoup, est le nombre de transactions SSL par seconde, ou le nombre de nouvelles connexions SSL qui peuvent être établies par seconde. Au sein de ces plateformes, ce nombre est généralement accéléré par le matériel. 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.

Ce que nous constatons, c’est que même avec une solution logicielle (sans accélération matérielle, en utilisant simplement la puissance de traitement du processeur), nous pouvons suivre le rythme du matériel personnalisé. Nous offrons des économies de coûts considérables, avec les performances que vous obtiendriez avec des solutions accélérées par le matériel.

Voilà donc la raison n°1 : vous pouvez économiser beaucoup d’argent en passant à NGINX Plus. Mais ce n’est pas seulement une question d’argent.

26:52 Raison n°2 – DevOps nécessite la livraison d'applications logicielles

Avec une solution logicielle, vous bénéficiez également d’une grande flexibilité, et la deuxième raison de passer à un équilibreur de charge logiciel est que si vous passez à DevOps, vous avez vraiment besoin d’un logiciel pour la distribution d’applications.

Avec F5 et NetScaler, ces appareils sont généralement déployés au sein des grandes entreprises sous forme de point d'agrégation. Donc, beaucoup de trafic sans rapport passe par là. Ce même F5 BIG-IP peut équilibrer la charge des pare-feu réseau, des serveurs de messagerie d'entreprise, de plusieurs applications d'entreprise principales différentes et peut également équilibrer la charge de l'application d'entreprise frontale. Il pourrait s’agir d’équilibrer la charge des API dans une architecture de microservices. Il peut donc s’agir d’équilibrer la charge de beaucoup de choses.

À première vue, cela semble être une bonne architecture car elle est assez simple : il suffit de tout exécuter via la touche F5. Pendant longtemps, cela a fonctionné, en particulier au début des années 2000, lorsque tout était question de centre de données privé et que nous exécutions toutes nos applications, tout ce sur quoi l’entreprise s’appuyait, à partir d’un centre de données sur site. Mais les choses ont changé ces dernières années et la plupart des choses sont désormais transférées vers le cloud.

Lorsque je parle de cloud, je ne parle pas seulement d’héberger une application Web frontale au sein d’Amazon, mais également d’utiliser des outils tels que Salesforce et Office 365, par opposition aux systèmes CRM et aux serveurs de messagerie sur site. Avoir un appareil capable de faire toutes ces choses peut donc s’avérer excessif par rapport à ce que les gens utilisent réellement de nos jours.

Un deuxième problème que pose cette agrégation est qu’elle conduit à ce que ces appareils soient très bien verrouillés. Vous devenez très hésitant à y apporter des modifications, car si vous gâchez la configuration F5, vous risquez de détruire l'ensemble du réseau de l'entreprise. Il peut s'agir d'équilibrer la charge des serveurs de messagerie ou des pare-feu réseau. Ainsi, la configuration devient une affaire risquée et les modifications doivent être très restreintes et très verrouillées.

Quiconque souhaite y apporter des modifications doit généralement déposer un ticket informatique, ce qui peut prendre des heures, des jours ou des semaines selon l’organisation et la priorité que l’organisation accorde à la modification demandée.

Le fait d’avoir ce matériel extrêmement verrouillé rend le passage à DevOps très difficile. Lorsque vous faites du DevOps et que vous évoluez vers l’automatisation, vous évoluez vers une intégration continue, vous évoluez vers une publication de code beaucoup plus fréquente. Et si vous devez déposer un ticket informatique à chaque fois que vous souhaitez apporter une modification, cela inhibe et tue cette initiative.

Ce que nous constatons dans de nombreuses organisations, c’est que les personnes responsables de l’application qui souhaitent évoluer vers DevOps et vers le développement Agile ne peuvent pas se permettre de devoir déposer un ticket à chaque fois, car cela entrave les initiatives DevOps et Agile. Ils déploieront donc parfois NGINX open source et feront pointer le F5 BIG-IP vers celui-ci, et cette instance NGINX sera gérée par l'équipe DevOps ou l'équipe d'application, ce qui leur permettra d'automatiser et d'apporter des modifications sans tracas. C’est donc une façon de contourner la politique informatique de l’entreprise. Ensuite, nous voyons beaucoup de clients, bien sûr, une fois qu'ils essaient cela, commencer à se tourner vers NGINX Plus pour obtenir les fonctionnalités plus avancées ainsi que le support.

NGINX prend en charge une gamme de modèles de déploiement flexibles et différents, y compris ceux dans lesquels vous pouvez conserver votre F5 actuel en place. Vous pouvez utiliser NGINX Plus pour compléter et décharger l'équilibrage de charge et la livraison des applications Web frontales, des API et des microservices, en gardant F5 en place pour équilibrer la charge réseau des serveurs de messagerie d'entreprise. Si vous n’avez pas besoin de services réseau ni d’équilibrage de la charge réseau, vous pouvez évidemment également remplacer le F5 par NGINX Plus et disposer d’une solution unique.

Nous prenons en charge une gamme de modèles de déploiement différents pour aider les organisations à évoluer vers DevOps, vers la livraison continue et vers l'automatisation.

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

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

Floyd : Merci, Faisal.

Avec NGINX, vous pouvez déployer partout avec une seule solution ADC. Que signifie « partout » ? Cela signifie que vos serveurs sur site, votre cloud public, votre cloud privé ou votre cloud hybride fonctionnent tous sur une seule solution. Et il y a un aspect pratique et aussi architectural là-dedans.

Tout d’abord, si vous utilisez des serveurs internes et que vous n’utilisez pas le cloud, tout ce que nous avons dit s’applique fortement. De nombreuses personnes qui migrent vers NGINX et NGINX Plus pour obtenir une meilleure flexibilité, davantage de fonctionnalités et économiser de l’argent se trouvent exactement dans cette situation : elles déploient sur des serveurs internes.

Si vous utilisez ou envisagez d’utiliser le cloud à l’avenir, il n’y a tout simplement aucune comparaison entre NGINX et l’ADC matériel. Vous ne pouvez pas déplacer votre ADC matériel vers les centres de données d’Amazon. L'ADC matériel ne vous aidera pas dans ce cas.

Désormais, les développeurs d’ADC matériels disposent de certaines solutions logicielles, mais dans certains cas, ils recommandent uniquement de les utiliser pour le développement. Il ne s'agit pas d'un remplacement du convertisseur analogique-numérique matériel. Les avantages que vous pourriez percevoir en termes de simplicité, ou du principe « si ce n'est pas cassé, ne le réparez pas », s'effondrent lorsque vous souhaitez migrer vers le cloud .

Avec NGINX et NGINX Plus, l’architecture de l’application est indépendante de la plateforme de diffusion. Certains fournisseurs de cloud commencent à ajouter de plus en plus de services auxquels vous pouvez vous connecter via des API. Pendant le développement, c’est vraiment une excellente chose à avoir, car vous n’avez pas à vous soucier de la manière de faire quelque chose ; vous utilisez simplement leurs API pour gérer l’équilibrage de charge, la mise en cache ou d’autres fonctionnalités. Mais lorsque vous évoluez, vous payez un petit montant pour chaque transaction.

Eh bien, tout d’un coup, lorsque vous effectuez des milliers, des dizaines de milliers, voire des centaines de milliers de transactions, ces chiffres commencent à s’additionner. La facturation est très confuse et difficile à prévoir, d’autant plus qu’elle est basée sur le trafic, qui varie toujours.

Si vous utilisez une approche basée sur NGINX ou NGINX Plus, vous faites fondamentalement la même chose sur n’importe quelle plateforme, et il y a très peu de différence lorsque vous passez à un autre fournisseur de cloud ou que vous revenez en interne.

Nous avons en fait des clients qui effectuent un équilibrage de charge entre leurs serveurs internes et le cloud. Alors, à quoi ça ressemble ? Ils disposent de suffisamment de serveurs internes pour répondre à leurs besoins 80 ou 90 % du temps. Ensuite, lorsqu’ils ont besoin de passer à une version supérieure, ils n’ont pas besoin d’acheter ou même de connecter de nouveaux serveurs ; ils passent simplement à une version cloud.

Le cloud est généralement plus lent que vos serveurs sur site et comme tout est équilibré en charge, seules les sessions qui seraient abandonnées si vous utilisiez uniquement vos serveurs internes vont vers le cloud. Ils ont une latence légèrement plus longue, mais ils sont traités, ils ne sont pas mis en file d’attente ni abandonnés.

Financièrement, c’est une bonne chose, car vous ne payez pour le cloud qu’en cas d’urgence, comme un pic soudain de trafic. Cela peut se produire en raison de la couverture médiatique, si votre produit reçoit de bonnes critiques, ou bien vous pourriez simplement dépasser votre plan d’affaires de manière continue et vous n’avez pas encore évolué en interne pour y parvenir, ou bien il se trouve que ce sont les vacances et cela ne vaut tout simplement pas la peine d’avoir deux fois plus de serveurs dont vous n’aurez besoin que pendant quelques semaines par an, alors que vous pouvez le faire en évoluant vers le cloud. Avec NGINX, tout cela peut être fait de manière flexible et même automatiquement.

35:42 Raison n°4 – S’adapter rapidement aux demandes changeantes

NGINX vous permet de vous adapter rapidement pour répondre aux exigences changeantes de vos applications. Lorsque vous devez ajouter rapidement des serveurs ou des paires de serveurs pour une haute disponibilité, vous ne pouvez pas attendre que le matériel soit commandé, livré, reçu, testé et que vos iRules ou toute autre configuration logicielle dont vous avez besoin pour eux soient exécutées. iRules est également propriétaire – le seul moment où vous avez besoin d'iRules est si vous avez un serveur F5. Ce n’est pas un ensemble de compétences que vous pouvez facilement acquérir à la sortie de l’université. Si votre représentant iRules part, vous aurez du mal à en trouver un autre.

Lorsqu’il s’agit de modifications de configuration, vous ne pouvez souvent pas attendre que les opérations réseau approuvent les modifications. Vous ne souhaitez pas vraiment que vos modifications soient placées dans la file d’attente avec des choses moins urgentes.

Avec NGINX, les frais d’approbation de nouveaux projets sont bien moindres. Avec NGINX et NGINX Plus, vous pouvez garder du matériel supplémentaire dans un placard lorsque vous parlez de serveurs qui coûtent 2 000 $ ou 3 000 $. Vous ne pouvez pas faire cela lorsque vous parlez de plusieurs dizaines de milliers de dollars pour des ADC matériels.

Ce type de flexibilité, de redondance, de capacité à faire ce que vous devez faire, quand vous devez le faire, est une caractéristique essentielle de NGINX, et une des raisons pour lesquelles les personnes qui nous utilisent nous aiment tant.

37:08 Raison n°5 – Aucune contrainte de performance artificielle

Enfin, avec NGINX, il n’y a aucune contrainte artificielle ou liée au contact sur les performances. Pour NetScaler Enterprise Edition, la limite contractuelle de débit pour ce serveur est de 0,5 Gbit/s. Eh bien, c’est ridicule dans une situation d’entreprise. La configuration NGINX comparable exécutée sur du matériel standard du secteur prendra en charge 20 Gbit/s. C'est 40 fois la limite Citrix.

L’autre chose est que le numéro Citrix est une contrainte contractuelle. Si vous le dépassez, vos délais de paiement augmentent soudainement et considérablement. Le 20 Gbps est une recommandation de notre part. Donc, cela signifie simplement que lorsque vous entrez dans cette zone, vous pourriez commencer à remarquer que vos performances diminuent un peu, et vous pourriez penser que c'est une bonne idée d'obtenir un autre serveur et d'équilibrer la charge dessus. Mais vous avez la flexibilité, c'est vous qui décidez. Vous ne subirez pas de baisse soudaine de votre budget.

Avec Citrix, c’est comme heurter un panneau d’arrêt. Dans ce scénario, une augmentation des affaires peut être une mauvaise nouvelle. Un client supplémentaire peut vous coûter très cher, quelques clients supplémentaires peuvent vous coûter très cher parce qu'ils vous font dépasser ces plafonds. Lorsque vous utilisez NGINX, augmenter votre activité est une bonne nouvelle et vos coûts augmentent régulièrement avec l’augmentation de vos revenus provenant de votre base de clients élargie.

Nous recevons souvent des appels urgents de personnes qui dépassent ces plafonds et qui, soudainement, dépassent leur budget. Et ils ne reviendront pas dans les limites du budget sans procéder à un changement majeur. Ils doivent alors se démener pour accéder à NGINX et revenir dans une bonne situation. Ensuite, ils finissent souvent par être en dessous du budget car ils ont économisé beaucoup d’argent sur NGINX.

Mais qui a besoin de ce mal de tête ? En plus de l’incertitude et du sentiment d’effroi lorsque vous vous retrouvez soudainement confronté à ce terrible conflit entre budget et performances ? Passer à NGINX dès le début signifie que vous pouvez vous en libérer complètement.

40:00 Ressources

• Étude de cas – NGINX sur WordPress.com/Automattic
• Étude de cas – Montana Interactive améliore les performances de ses applications et son service client avec NGINX Plus
• Étude de cas – Comment Buydig.com fait évoluer et sécurise son application Microsoft .NET sans modifier une seule ligne de code
• Ebook – 5 raisons de passer à un logiciel d'équilibrage de charge
• Blog – NGINX Plus vs. F5 BIG-IP : Comparaison prix-performance
• Blog – NGINX Plus vs. Citrix NetScaler : Comparaison prix-performance
• Essai gratuit de NGINX Plus