Aujourd’hui, l’une des questions les plus fréquemment entendues dans les couloirs d’un fournisseur d’infrastructure est de savoir comment expliquer la valeur de cette infrastructure à la communauté des développeurs. Le problème, c’est que la plupart des avantages de l’infrastructure ne se concrétisent qu’après la mise en production. Aucun d’entre eux n’apporte réellement de valeur directe aux développeurs, du moins pas de manière suffisamment significative pour avoir une incidence sur leur quotidien.
Les développeurs sont certainement conscients des avantages qui dépassent le cadre du développement. Dans notre rapport 2018 « État des lieux de la livraison d’applications », les développeurs ne représentaient qu’un faible pourcentage des répondants. Mais ce petit groupe s’est clairement exprimé sur les services applicatifs qu’il souhaitait déployer. Certains de ces services applicatifs — équilibrage de charge, mise en cache et accélération — sont aussi souvent déployés au sein de l’application elle-même que dans l’infrastructure. Les optimisations TCP et les pare-feu applicatifs web (WAF) sont presque toujours des services d’infrastructure, déployés en amont (sur le chemin des données), devant les applications (qu’elles soient monolithiques ou basées sur des microservices).
Tous ces services applicatifs présentent un intérêt : réduction des risques, amélioration des performances, évolutivité. Mais il s’agit d’avantages pour les applications et l’entreprise ; ils profitent aux développeurs après la mise en production de l’application. Il est difficile de trouver — et plus encore de formuler — les avantages de l’infrastructure en amont de la livraison, c’est-à-dire dans le cadre du cycle de développement.
Mais à mesure que nous continuons à adopter les conteneurs et les microservices, la valeur de l’infrastructure avant et après la mise en production devient plus évidente.
Comme pour la plupart des technologies émergentes, les débuts d’une nouvelle architecture applicative s’accompagnent de très peu d’infrastructure. Les développeurs seront peut-être surpris d’apprendre que l’architecture applicative façonne considérablement l’infrastructure des services applicatifs. Le passage aux applications web à trois niveaux a fait émerger l’évolutivité (répartition de charge). L’adoption du Web 2.0 et de sa couche de présentation réactive a donné naissance à une infrastructure d’accélération front-end. Avec l’essor du mobile et la numérisation croissante de tous les secteurs, l’infrastructure s’est adaptée en proposant des services de sécurité tels que les pare-feu d’applications web (WAF), la protection contre les attaques DDoS et la défense contre les bots.
Ce que nous observons actuellement, c’est que les développeurs intègrent les fonctionnalités des services d’infrastructure directement dans leurs applications. Les développeurs transposent dans le code ce qui relevait traditionnellement des services en amont : les nouvelles tentatives assurées par les répartiteurs de charge, le mTLS fourni par les plateformes ou les proxys, et le contrôle d’accès visant à limiter les communications aux clients légitimes.
Il s’agit de responsabilités liées à l’infrastructure qui, en raison du caractère encore émergent des frameworks de conteneurs et de leur adoption rapide, ont été prises en charge par les développeurs.
Mais comme cela a toujours été le cas, la situation évolue. Tout comme les architectures applicatives précédentes ont entraîné des adaptations de l’infrastructure réseau, les conteneurs et les microservices font de même. Seulement, cette fois-ci, les changements ne prennent pas la forme d’un nouveau boîtier. La tendance actuelle consiste à intégrer les services applicatifs dont les développeurs ont besoin dans l’environnement de conteneurs. C’est là qu’intervient le maillage de services, qui apporte directement aux développeurs une valeur réelle et quantifiable.
Comme l’explique Andrew Jenkins, architecte principal chez Aspen Mesh dans un entretien accordé à Linux.com:
« Il est remarquable de voir à quel point il est facile aujourd’hui de commencer à créer un service web. Le code peut tenir dans un tweet. Toutefois, il ne s’agit pas encore d’un véritable service web. Pour le rendre résilient et évolutif, il faut ajouter certaines fonctionnalités au plan de données de l’application. Celui-ci doit prendre en charge TLS, réessayer en cas d’échec, accepter uniquement les requêtes provenant de tel service et non de tel autre, vérifier l’authentification de l’utilisateur, etc. Un maillage de services permet de bénéficier de ces fonctionnalités du plan de données sans avoir à ajouter de code à l’application. »
En amont de la livraison, l’intérêt réside dans la réduction du périmètre et la suppression du code répétitif, mais nécessaire, permettant de gérer la sécurité de base et la mise à l’échelle dans un environnement de conteneurs. Un maillage de services offre une grande variété de fonctionnalités intéressantes, mais ses avantages restent principalement opérationnels : observabilité, traçabilité et mise à l’échelle. Pour un développeur, le principal intérêt réside dans la suppression de code (et donc dans la réduction de la dette technique et architecturale).
L’utilisation d’un maillage de services pour faire évoluer, sécuriser et superviser les applications déployées dans des environnements conteneurisés évite d’avoir à écrire du code qui devrait être pris en charge par l’infrastructure, mais qui, jusqu’à récemment, était confié aux développeurs. Un maillage de services permet notamment d’alléger la charge qui pèse sur les développeurs et de leur rendre un temps précieux, qu’ils peuvent consacrer au développement de services et d’applications créant à leur tour de la valeur pour l’entreprise.
À 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.