Pourquoi une approche par application des services applicatifs est importante

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Je ne sais pas lire dans les pensées (mes enfants ne seraient pas d’accord, mais là n’est pas la question), mais je sais lire les réponses à notre enquête « State of Application Delivery ». Et lorsque je les examine du point de vue des personnes qui se définissent comme développeurs d’applications, un tableau très intéressant se dessine.

Les développeurs accordent de l’importance à la rapidité. À la sécurité. Et à la capacité de montée en charge. Pas nécessairement dans cet ordre, mais ces trois aspects comptent pour eux. Et ils ne se contentent pas de s’en préoccuper : ils reconnaissent également la valeur des services applicatifs pour les aider à atteindre ces trois objectifs.

En d’autres termes, les développeurs ne veulent pas seulement de vagues services applicatifs d’« accélération » ; ils veulent des services précis offrant des optimisations TCP et une mise en cache. Ils veulent également un pare-feu applicatif web et un peu de répartition de charge.

Le problème est que la plupart de ces services applicatifs sont fournis selon un modèle d’infrastructure partagée. Chaque application dispose de sa propre « représentation virtuelle », mais celle-ci réside physiquement sur un logiciel ou un matériel partagé.

Cela peut entraîner de réels problèmes et explique en partie les tensions qui subsistent entre les équipes informatiques et les développeurs d’applications. C’est cette mutualisation des systèmes qui nous a valu les fenêtres de changement, les comités de validation et les déploiements du samedi soir (avec des pizzas pour nous faire patienter), autant de processus qui ralentissent le développement et rendent le déploiement frustrant pour toutes les personnes concernées.

Nous ne déployons plus d’énormes applications monolithiques. Même si nous n’avons pas cédé à la frénésie des microservices en décomposant les applications en centaines de petits services, nous avons tout de même davantage d’applications dont les déploiements sont plus fréquents. Des applications développées au cours de sprints d’une semaine plutôt que dans le cadre de projets s’étalant sur un an, et qui nécessitent de publier des mises à jour plus rapidement et plus souvent.

C’est finalement davantage pour cette raison que le cloud (public) a connu un tel succès. Parce qu’il s’agit de mon application et de mon infrastructure, et que je n’ai pas à attendre Bob, Alice ou John avant de déployer une mise à jour. Parce que tout m’appartient et que, si quelque chose tourne mal, j’en assume l’entière responsabilité.

Cette même approche est également possible sur site (et préférable, à mon avis). Il faut pour cela que tous les éléments qui composent la chaîne de livraison d’une application prennent en charge le même type d’approche par application que le cloud a rendu souhaitable.

En substance, une approche par application pour fournir les services réseau et applicatifs nécessaires revient à dédier un sous-réseau à l’application, autrement dit un VLAN de mise à disposition applicative. Tout est centré sur cette application, avec des services dédiés.

Ce type d’isolation n’est pas seulement bénéfique pour les calendriers de déploiement, il l’est aussi pour tous les autres. Les défaillances sont inévitables et, lorsqu’elles surviennent, il faut en limiter autant que possible le rayon d’impact. Une architecture propre à chaque application permet de circonscrire étroitement les conséquences d’une défaillance, pour le plus grand bonheur de toutes les personnes d’astreinte « au cas où », puisqu’elles n’ont pas reçu cet appel. Je peux publier et déployer chaque semaine sans perturber les applications qui ne le font qu’une fois par mois. Mon application, mes services, mon calendrier de déploiement.

Une architecture propre à chaque application facilite également le diagnostic des problèmes qui surviennent en production. Et ils sont fréquents. En effet, 50 % des développeurs ont signalé des problèmes en production après la mise en production du code dans le cadre d’une enquête Atlassian de 2017. Il est impossible qu’une modification effectuée par quelqu’un d’autre ait une incidence sur l’application. Vous pouvez vous concentrer directement sur les systèmes concernés au lieu de perdre un temps précieux à déterminer quels systèmes pourraient être impliqués.

Une architecture par application est naturellement mieux adaptée au cloud, qu’il soit public ou privé, car c’est sur cette hypothèse que repose le modèle. Chaque application dispose d’un ensemble dédié de services applicatifs permettant d’assurer son évolutivité, d’améliorer ses performances et de la sécuriser.

En réalité, une architecture par application était inévitable. Ce n’est pas la première fois que je le dis. Le poids des applications est trop important pour être ignoré, et les exigences de sécurité de plus en plus propres à chaque application pour assurer sa protection rendaient inéluctable l’adoption, tôt ou tard, d’une approche par application.

Et c’est une bonne chose, car les services applicatifs que souhaitent les développeurs sont, le plus souvent, propres à chaque application. Ce qui fonctionne pour l’une ne fonctionnera pas nécessairement pour une autre, et peut même se révéler contre-productif. En adoptant une architecture par application pour la mise à disposition des applications, vous pouvez non seulement vous assurer que les développeurs disposent de ce qu’ils souhaitent et de ce dont ils ont besoin pour faire évoluer, sécuriser et accélérer les applications, mais aussi mieux prendre en charge le modèle en libre-service qu’ils attendent du cloud, qu’il soit sur site ou hors site.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

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 Vittie