Comparaison de la mise à disposition des applications : 2005 et 2015

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

James Ward, qui écrit du code (selon sa propre description), a récemment publié un excellent article dans lequel il compare le déploiement d’applications aujourd’hui à ce qu’il était il y a dix ans. L’un des secrets les mieux gardés du secteur informatique dans son ensemble est que les évolutions des architectures et du déploiement des applications ont un impact direct sur la fourniture des applications (le processus qui consiste concrètement à s’assurer que les applications sont rapides, sécurisées et accessibles à leurs utilisateurs). Les changements actuellement induits par les microservices, par exemple, auront des répercussions importantes sur la manière dont ils vont modifier l’architecture réseau ainsi que son modèle de déploiement.

Je sais, je sais. Vous pensez que l’évolution vers les microservices, la conteneurisation et le cloud fait abstraction du réseau, rendant les applications moins dépendantes de celui-ci. Et c’est vrai, du point de vue des développeurs, voire des équipes d’exploitation. Mais un réseau reste nécessaire : les données échangées doivent toujours transiter par ces canaux, et les services qui résident sur le réseau restent responsables de nombreuses fonctions qui accélèrent les applications, les sécurisent et garantissent leur disponibilité. Par conséquent, les changements apportés à la manière dont les applications sont composées et déployées, ainsi qu’à l’endroit où elles le sont, ont nécessairement une incidence sur ces services, même si l’application ignore leur existence (et, honnêtement, elle ne devrait même jamais en avoir connaissance. À cet égard, ils sont comme des anges gardiens.)

Compte tenu de cette relation, même si elle n’est pas réciproque du côté de l’application, l’article de James nous a incités à examiner en parallèle l’évolution de la manière dont nous déployons les applications au cours des dix dernières années.

Architecture de déploiement

2005	2015
File indienne	Plateforme

En 2005, les équipes réseau (NetOps) déployaient les différents services applicatifs nécessaires à la mise à disposition des applications selon une architecture que nous aimons appeler une « file indienne ». Il s’agissait de solutions ponctuelles indépendantes. Pour accélérer une application, il fallait déployer un produit d’optimisation des performances web sur son propre boîtier dédié. Un autre boîtier pour l’équilibrage de charge, un autre pour la sécurité des applications, et ainsi de suite. On finissait ainsi par obtenir de longues chaînes de boîtiers, que le trafic devait traverser dans les deux sens.

En 2004, les contrôleurs de mise à disposition d’applications ont fait leur apparition (mais ils étaient encore très peu matures en 2005) et ont commencé à évoluer vers ce que nous connaissons aujourd’hui, à savoir une plateforme. Ces plateformes fournissent des fonctionnalités et des capacités de traitement communes, et peuvent être enrichies de modules (ou de plug-ins, d’extensions, ou quel que soit le nom que vous souhaitez leur donner). L’approche par plateforme réduit considérablement le temps passé « sur le réseau », tout comme la conteneurisation et la virtualisation réduisent le temps consacré aux échanges entre les applications et les services. Elle permet également de réduire les coûts d’exploitation grâce au partage d’un socle commun — la plateforme — qui uniformise la gestion des différents services applicatifs nécessaires aujourd’hui à la mise à disposition d’une application.

Le passage du produit à la plateforme présente des avantages à mesure que le déploiement d’applications évolue vers des architectures plus éphémères et décomposées, qui s’appuient sur des technologies émergentes telles que les conteneurs et les microservices, ainsi que vers des déploiements dans des environnements cloud. En effet, ces plateformes permettent de déployer divers services applicatifs, ou un seul, à partir d’un même socle standardisé. Cela réduit la charge administrative à mesure que le nombre de services applicatifs déployés augmente, tout en permettant d’ajouter des services selon les besoins au fil de la croissance des applications.

Méthodes de déploiement

2005	2015
Déploiement manuel	Déploiement programmable

En 2005, les interfaces graphiques web commençaient tout juste à se généraliser, et le principal moyen de provisionner et de configurer les services applicatifs était l’interface en ligne de commande (CLI). Comme tout processus manuel, cette procédure prenait du temps et, à mesure que les services applicatifs se complexifiaient, elle en exigeait toujours davantage. Les problèmes liés aux erreurs humaines et leurs conséquences — la présence au sein du réseau augmentant de façon exponentielle l’étendue des dégâts causés par une mauvaise configuration — imposaient des contrôles qui allongeaient encore les délais. Le copier-coller était très répandu, mais pas infaillible, et la charge administrative liée à la gestion des services était suffisamment importante pour que seules les applications les plus stratégiques puissent bénéficier de ces services.

Nous voici en 2015, en pleine révolution DevOps. La programmabilité, qu’elle repose sur des API ou sur des configurations basées sur des modèles, change la donne partout, y compris dans le réseau. Les services applicatifs peuvent désormais être automatisés via des API à l’aide de frameworks populaires tels que Puppet et Chef, préintégrés à des solutions d’orchestration comme Cisco APIC et VMware NSX, ou pilotés sur mesure avec Python, Perl, bash et curl. Les modèles de services applicatifs favorisent la standardisation et la réutilisation, et encouragent à traiter l’infrastructure « comme du code », afin d’étendre les pratiques de livraison continue au réseau.

Bien que moins répandue que la livraison continue dans le développement d’applications, la livraison d’applications a évolué (et continue d’évoluer) afin de prendre en charge des options de déploiement programmables qui réduisent les délais de mise sur le marché grâce à un provisionnement plus rapide des services, tout en diminuant les coûts d’exploitation grâce à l’automatisation et à la réutilisation.

Formats de déploiement

2005	2015
Infrastructure lourde	Virtualisé

En 2005, la course était lancée pour concevoir des équipements réseau plus imposants, plus performants, plus rapides et offrant davantage de fonctionnalités. L’augmentation des débits Ethernet et l’essor fulgurant des applications web ont entraîné une expansion parallèle des systèmes haute capacité déployés sur le réseau afin de répondre aux exigences des services applicatifs.

Aujourd’hui, l’accent est mis sur la densité et l’utilisation optimale des ressources. Cela passe par la virtualisation et le cloud computing, tous deux rendus possibles par la virtualisation des plateformes de fourniture d’applications. Ces plateformes peuvent désormais être déployées dans des environnements cloud tels qu’AWS, Microsoft Azure et Rackspace, ainsi que sous la forme d’une appliance virtuelle pouvant être installée sur du matériel dédié ou standard. Cette capacité est indispensable, non seulement pour prendre en charge les environnements cloud, mais aussi pour s’adapter aux architectures émergentes telles que les microservices. Aujourd’hui, les microservices et les serveurs eux-mêmes sont, comme le souligne James Ward, « jetables, immuables et éphémères… »

Cela signifie que de nombreux services applicatifs qui entrent dans le domaine du DevOps — équilibrage de charge, sécurité des applications et optimisation — doivent répondre aux critères d’un centre de données défini par logiciel. Ils doivent au minimum pouvoir s’intégrer, à grande échelle, dans un modèle immuable et jetable. De nombreuses plateformes de mise à disposition d’applications en sont déjà capables aujourd’hui et, associées à des options de déploiement programmables, elles sont prêtes à relever le défi.

Responsabilité du déploiement

En 2005 — et encore aujourd’hui dans de nombreuses organisations —, l’équipe réseau était entièrement responsable du déploiement et de la gestion de la mise à disposition des applications. Tous les aspects de cette mise à disposition, de l’achat à la configuration en passant par le provisionnement, étaient, et sont encore souvent, pris en charge par les opérations réseau. Ce modèle cloisonné entraînait des retards, le temps de définir précisément les exigences, de créer des tickets et de laisser les ingénieurs provisionner et configurer manuellement les services applicatifs nécessaires à la mise à disposition d’une application.

Aujourd’hui, c’est encore le cas dans de nombreuses organisations, mais l’impact du cloud et des microservices, associé à l’adoption du DevOps, est en train de changer la donne. La demande d’une informatique en tant que service est forte, et la responsabilité de la configuration des services applicatifs se déplace vers les équipes d’exploitation, voire de développement. Les services étroitement liés aux applications doivent être situés plus près de celles-ci, tant physiquement que topologiquement. Le DevOps se retrouve ainsi aux commandes et devient responsable du provisionnement et de la configuration de ces services.

Cela ne signifie pas que l’équipe réseau se désintéresse de la fourniture des applications. Il existe un important segment d’applications et de problématiques d’entreprise qui nécessitent que les services applicatifs soient fournis de manière plus traditionnelle, en privilégiant la fiabilité plutôt que l’agilité. Ces services relèvent toujours, et continueront probablement de relever, de l’équipe réseau. Mais d’autres relèvent déjà de la responsabilité des équipes DevOps, et cette tendance va se poursuivre.

La mise à disposition des applications a beaucoup évolué au cours des dix dernières années. D’un ensemble de produits, elle est devenue une plateforme unifiée, s’est dotée de capacités de programmation et est passée de systèmes matériels imposants à la prise en charge des hyperviseurs et du déploiement dans le cloud. Alors que les applications mobiles, les microservices et le DevOps continuent de transformer radicalement la manière dont les applications sont conçues, déployées et mises à disposition, les services qui assurent leur livraison et garantissent leurs performances, leur sécurité et leur disponibilité devraient eux aussi continuer d’évoluer.

À 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