Les univers du développeur d’applications et de l’architecte réseau ne pourraient être plus différents, si ce n’est peut-être dans la façon dont chacun perçoit le domaine de l’autre.
Du point de vue du réseau, le déploiement d’une application se présente souvent comme suit :
De l’autre côté du « mur », le déploiement de cette même application est souvent perçu ainsi par le développeur :
Les deux sont sans aucun doute fidèles à leurs domaines respectifs, mais font largement abstraction de l’architecture réelle de l’autre. Cela illustre bien pourquoi tant de problèmes surviennent lors de la mise en production des applications. Et ils sont bel et bien nombreux. Une étude indique qu’en 2013, « 90 % des développeurs déclaraient consacrer leurs week-ends, jours fériés et vacances à résoudre des urgences liées aux applications en production[1] ». Si bon nombre de ces problèmes sont certainement liés à des défauts et à des erreurs logicielles, beaucoup d’autres sont sans aucun doute dus aux nombreuses différences entre les environnements. La production n’est pas le développement, et inversement.
Les applications actuelles tirent parti de divers services présents dans les environnements de production, mais rarement dans les environnements de développement ou de test : des répartiteurs de charge pour assurer l’évolutivité, des caches pour améliorer les performances et des pare-feu d’applications web pour garantir la sécurité. Ces services interviennent sur chaque requête et chaque réponse lors de leur transit sur le réseau entre l’utilisateur et l’application (ou entre l’application et l’API, si vous préférez) et, dans certains cas, ils modifient les requêtes et/ou les réponses. L’adresse IP de l’utilisateur en est un bon exemple. Cette valeur figure dans les en-têtes HTTP de chaque requête, mais lorsqu’elle transite par un proxy de répartition de charge, elle devient l’adresse IP du proxy, et non celle du client.
Pour le développeur qui ne s’y attend pas, cela peut entraîner un « dysfonctionnement » des applications et nécessiter des heures de dépannage, en plus du temps requis pour modifier l’application. Ces types de problèmes liés aux différences entre les environnements expliquent sans doute pourquoi, à la mi-2015, 28 % des développeurs ayant répondu à une enquête[2] ont déclaré que « plus de 50 % des problèmes en production auraient pu être détectés et corrigés avec un environnement de test approprié ». Et plus de la moitié (52 %) ont indiqué qu’« entre 25 % et 50 % des problèmes en production auraient pu être corrigés ».
Bon nombre des problèmes qui surviennent en production sont directement imputables aux différences au sein de l’application, en particulier pour les applications développées selon des méthodologies agiles. Les méthodes agiles peuvent accroître le risque que ce type de conflit survienne en production en raison de la fréquence des modifications apportées au code.
Un nombre croissant de ces difficultés, mais loin de les résoudre toutes, peuvent être surmontées à l’aide d’un proxy programmable, ce qui évite de devoir modifier du code déjà en production et de retarder davantage la mise sur le marché de l’application. Le problème d’« adresse IP » mentionné précédemment est généralement résolu en demandant au proxy d’insérer un nouvel en-tête HTTP contenant l’adresse IP réelle, afin que les développeurs aient toujours accès à cette information. Par ailleurs, les proxys d’équilibrage de charge de couche 7 sont particulièrement efficaces pour acheminer les requêtes d’applications et d’API en fonction de diverses données, notamment les versions et les signatures d’API.
Il est intéressant de noter que le répartiteur de charge est le seul composant souvent représenté à la fois dans les schémas d’architecture logicielle et dans ceux d’ingénierie réseau. Bien que ce proxy soit traditionnellement déployé et géré par l’équipe réseau, il joue un rôle suffisamment essentiel dans les architectures applicatives pour être presque toujours intégré à la représentation de l’application. De même, les développeurs reconnaissent aujourd’hui l’importance de la répartition de charge pour faire évoluer les applications et l’incluent généralement dans leurs schémas.
Cela reflète également le nombre croissant de cas où les développeurs et les équipes d’exploitation ont pris en charge la scalabilité et, par conséquent, le contrôle de la répartition de charge de leurs applications. C’est une bonne chose, car cela signifie que les équipes de développement et d’exploitation peuvent intégrer — et, espérons-le, intègrent déjà — la répartition de charge (avec tous les avantages de la couche 7) au pipeline CI/CD, notamment lors des tests, afin de détecter rapidement les éventuels problèmes et de les résoudre avant la mise en production. Le fait d’intégrer la répartition de charge plus en amont dans le pipeline CI/CD permet également d’adopter une approche plus globale de la livraison continue, dans laquelle l’ensemble du package applicatif (l’architecture) est géré sous forme de code et peut être mis à jour simultanément. L’infrastructure réseau — puisque c’est traditionnellement dans cette catégorie que l’on classe la répartition de charge — peut ainsi prendre en charge une architecture immuable, dans laquelle les applications (ou les microservices, si vous avez choisi cette voie) sont entièrement redéployées avec de nouvelles configurations plutôt que simplement mises à jour, ce qui évite l’entropie logicielle naturelle susceptible d’engendrer des difficultés et une dette technique.
À bien des égards, le proxy est le pont qui relie le « réseau » à l’« application » en franchissant le fossé métaphorique — qui ressemble davantage à un mur, à vrai dire — séparant les ingénieurs et architectes logiciels de leurs homologues réseau. C’est l’un des fossés que le DevOps doit combler pour permettre aux organisations de monter en charge et de relever les défis posés par les architectures modernes.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.