Une infrastructure jetable pour des applications jetables

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

Programmes de conférences. Navigation lors d’événements. Tâches spécifiques, comme acheter une maison ou obtenir un prêt automobile.

Si vous avez installé une application pour l’un de ces usages, vous avez installé ce que l’on appelle une « application mobile jetable », ou DMA. Ces applications sont conçues pour un usage unique et destinées à être « jetées » comme des brochures. Elles sont supprimées jusqu’à ce qu’on en ait de nouveau besoin. Elles sont nécessairement légères, agiles et très volatiles. Elles peuvent n’exister que pendant une courte période — par exemple pour accompagner un événement comme une élection, la Coupe du monde ou un festival de musique — ou rester disponibles longtemps côté « serveur », mais pas côté client, comme pour guider l’utilisateur dans le processus d’obtention d’un prêt immobilier.

Ces applications sont de plus en plus populaires et sont considérées comme une sorte de « micro-application » (très similaire aux microservices, mais conçue pour être développée par des tiers plutôt qu’en interne).

S’il est important de souligner l’existence de ce type d’applications, c’est parce que leur durée de vie peut être très variable. Du début à la fin de leur cycle de vie, elles peuvent n’exister que quelques jours, quelques semaines ou quelques mois. Elles apparaissent soudainement, puis disparaissent tout aussi vite. Elles sont, pour la plupart, jetables, et l’infrastructure qui les prend en charge l’est donc probablement aussi.

À l’ère des centres de données virtualisés, où le logiciel dévore l’informatique, cette idée n’est plus aussi folle qu’elle a pu le paraître autrefois. Après tout, ce n’est pas comme si nous jetions du matériel valant plusieurs milliers de dollars. Ce ne sont que quelques données que l’on peut facilement déployer et supprimer d’une simple pression sur la touche Entrée.

Cela peut convenir si votre seule préoccupation en matière d’infrastructure est un serveur web/applicatif. Mais il se trouve que ces applications doivent pouvoir monter en charge et bénéficier d’une optimisation des performances (ce sont, après tout, des applications mobiles dont l’essentiel du traitement s’effectue côté serveur — dans le cloud), ce qui implique plusieurs composants relevant généralement de l’infrastructure réseau : services d’équilibrage de charge, de mise en cache et d’optimisation. Ces composants doivent donc eux aussi être « jetables ». Ils doivent pouvoir être déployés sous forme logicielle (ou virtuelle) et s’accompagner d’un ensemble robuste d’API et de modèles permettant de les provisionner et de les configurer rapidement, puis de les supprimer. Cela signifie également qu’ils doivent être prêts pour le cloud, compatibles avec le cloud ou « cloudifiés » (selon le terme marketing que vous préférez), afin que l’infrastructure et les services prenant en charge ces applications jetables soient aussi flexibles et jetables que les applications qu’ils fournissent.

Cela signifie également qu’une approche DevOps devient de plus en plus importante pour gérer ces environnements très volatils, dans lesquels un nombre bien plus élevé d’applications sont déployées puis abandonnées selon des cycles plus courts. Une approche monolithique reposant sur « une seule application pour toutes nos offres » ne correspond pas nécessairement à la manière dont les applications mobiles jetables sont conçues et déployées. Celles-ci sont ciblées et répondent à un objectif précis : elles fournissent un ensemble spécifique de fonctionnalités qui ne sera jamais étendu. Les autres fonctions et usages sont alors assurés par d’autres applications, ce qui augmente le nombre total d’applications nécessaires et accentue la pression exercée sur les équipes d’exploitation chargées de les déployer et de les mettre à disposition. Chacune de ces applications possède des services, des configurations et des exigences de supervision spécifiques qui doivent être adaptés à l’application. Dans le monde des applications, il n’existe pas de solution universelle. Cela marque une nette différence avec un environnement dans lequel la configuration de l’infrastructure peut rester pratiquement inchangée pendant toute la durée de vie de l’application, à l’exception de quelques ajustements liés aux performances ou à la sécurité. Pour les équipes d’exploitation chargées de gérer l’infrastructu, cela implique davantage de travail, une complexité accrue et des interventions plus fréquentes.

C’est pourquoi il est de plus en plus important que l’infrastructure ne soit pas seulement logicielle ou virtualisée et ne se contente pas de proposer une API robuste de provisionnement et de configuration, mais qu’elle s’intègre également aux écosystèmes d’automatisation en plein essor de frameworks et d’outils populaires tels que Puppet et Chef, VMware et Cisco, OpenStack et Salt Stack. Ces frameworks permettent à la livraison continue de s’étendre du développement aux opérations et offrent les moyens de mettre l’infrastructure en production aussi facilement que de la retirer.

Le logiciel dévore l’informatique, mais il faut y voir une bonne chose. Le DevOps, en tant qu’approche de la gestion du cycle de vie couvrant l’ensemble des applications et des infrastructures, est indispensable pour gérer la croissance engendrée par les logiciels qui dévorent le monde. Une enquête mondiale menée par CA et Vanson Bourne a mis en évidence les avantages quantifiables de l’adoption d’une approche DevOps, 21 % des personnes interrogées indiquant qu’elle permettait de proposer davantage de nouveaux logiciels et services, et 18 % constatant une réduction du délai de mise sur le marché.

Ce niveau d’agilité et de rapidité est indispensable pour prendre en charge des applications jetables et l’infrastructure jetable nécessaire à leur déploiement. L’un des principaux problèmes rencontrés par les services informatiques tient au fait que le réseau reste un obstacle. Selon une étude d’EMA, « la lenteur des processus manuels de reconfiguration de l’infrastructure pour l’adapter aux changements » a été citée par 39 % des organisations comme un problème majeur en 2014.

L’application du DevOps au « réseau » contribuera à éliminer cet important point de blocage sur le chemin de la mise en production. Cela implique notamment de nous défaire de nos idées préconçues sur la nature du réseau (c’est du matériel ! On ne peut pas y toucher ! Ce n’est pas mon domaine !) et de commencer à déterminer quelles parties du réseau peuvent être considérées comme aussi éphémères que les applications qu’il fournit.

À 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