Infrastructure jetable pour applications jetables

Ordres du jour des conférences. Navigation événementielle. Des tâches spécifiques, comme acheter une maison ou obtenir un prêt automobile.

Si vous avez installé une application pour l'une de ces choses, vous avez installé ce qu'on appelle une « application mobile jetable » ou DMA. Des applications conçues pour un cas d'utilisation unique et avec l'espoir qu'elles seront « jetées » comme des brochures. Supprimé jusqu'à ce qu'il soit à nouveau nécessaire. Ces applications sont nécessairement petites, agiles et très volatiles. Parfois, ils n'existent que pendant une courte période - par exemple pour soutenir un événement comme une élection, la Coupe du monde ou un festival de musique - ou ils existent pendant une longue période du côté du « serveur », mais pas du côté du client, comme lors d'un processus de 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 le développement tiers et non interne).

La raison pour laquelle il est important de noter l’existence de ces types d’applications est qu’elles peuvent avoir des durées de vie très différentes. Du berceau à la tombe, ils peuvent n’exister que quelques jours, quelques semaines ou quelques mois. Ils apparaissent et disparaissent tout aussi rapidement. Ils sont jetables, pour la plupart, et donc l’infrastructure qui les soutient est probablement également jetable.

À l’ère des centres de données virtualisés et des logiciels qui dévorent l’informatique , cette notion n’est pas aussi folle qu’elle pouvait le paraître. Ce n’est pas comme si nous jetions du matériel à plusieurs milliers de dollars, après tout. Ce ne sont que quelques éléments qui peuvent être facilement installés et démontés en appuyant sur la touche Entrée.

Cela peut être une bonne idée si votre seul problème d’infrastructure est un serveur Web/d’application. Mais il se trouve que ces choses ont besoin d'évolutivité et d'aide en termes de performances (ce sont des applications mobiles, après tout, avec la plupart du traitement effectué côté serveur - cloud) et cela implique plusieurs éléments de ce qui est généralement considéré comme une infrastructure réseau. Équilibrage de charge, mise en cache et optimisation des services. Cela signifie qu'eux aussi doivent être « jetables ». Ils doivent être déployables par logiciel (ou virtuels) et être accompagnés d'un ensemble robuste d'API et de modèles grâce auxquels les éléments peuvent être rapidement provisionnés, configurés et ultérieurement supprimés. Cela signifie également qu'elles doivent être prêtes pour le cloud, activées pour le cloud ou cloudifiées (quel que soit le terme marketing que vous préférez lui appliquer) afin que l'infrastructure et les services prenant en charge ces applications jetables soient aussi flexibles et jetables que les applications qu'elles fournissent.

Cela signifie également qu’une approche DevOps est de plus en plus importante pour gérer ces environnements très volatils dans lesquels de nombreuses autres applications sont livrées et supprimées dans des cycles plus courts.  Une approche unique et monolithique « une application adaptée à toutes nos offres » n’est pas nécessairement la manière dont les applications mobiles jetables sont conçues et fournies. Ils sont ciblés et déterminés, ce qui signifie qu'ils visent à fournir un ensemble spécifique de fonctionnalités qui ne seront jamais étendues. D’autres fonctions et objectifs sont ensuite fournis via d’autres applications, ce qui augmente globalement le nombre d’applications nécessaires et exerce une pression supplémentaire sur les opérations pour déployer et fournir ces applications. Chacune de ces applications possède des services, des configurations et des exigences de surveillance spécifiques qui doivent être adaptées à l'application. Il n'existe pas de solution unique dans le monde des applications. C’est une différence marquée par rapport à un monde dans lequel la configuration de l’infrastructure peut rester en grande partie inchangée pendant toute la durée de vie de l’application, à l’exception des ajustements de performances ou de sécurité. Cela signifie plus de travail, plus de complexité, plus souvent pour les opérations qui doivent gérer l'infrastructure.

C'est pourquoi il est de plus en plus important que l'infrastructure ne soit pas seulement logicielle ou virtualisée, qu'elle présente non seulement une API de provisionnement et de configuration robuste, mais qu'elle se concentre également sur la participation aux écosystèmes d'automatisation croissants de frameworks et d'outils populaires comme Puppet et Chef, VMware et Cisco, OpenStack et Salt Stack. Il s’agit des cadres permettant à la livraison continue de sortir du développement et d’entrer dans les opérations et de fournir les moyens par lesquels l’infrastructure est aussi facilement mise en production qu’elle est éliminée.

Les logiciels dévorent l’informatique, mais cela doit être considéré comme une bonne chose. DevOps en tant qu'approche de gestion du cycle de vie à travers le spectre des applications et des infrastructures est nécessaire pour gérer la croissance générée par les logiciels qui dévorent le monde. CA et Vanson Bourne ont découvert des avantages quantifiables liés à l'adoption d'une approche DevOps dans une enquête mondiale , avec 21 % des répondants déclarant qu'un plus grand nombre de nouveaux logiciels et services étaient possibles et 18 % ont constaté un délai de mise sur le marché plus rapide.

Ce type d'agilité et de rapidité est indispensable si vous souhaitez prendre en charge des applications jetables et l'infrastructure jetable nécessaire pour les fournir. L’un des principaux problèmes informatiques est le fait que le réseau est toujours un obstacle. Selon une étude de l'EMA , « les processus manuels lents de reconfiguration de l'infrastructure pour s'adapter au changement » ont été cités par 39 % des organisations comme un problème majeur en 2014.

L’application de DevOps au « réseau » contribuera à éliminer ce point d’impédance important sur le chemin vers la production. Une partie de cet effort consiste à abandonner nos idées préconçues sur la nature du réseau (c'est du matériel !) C'est intouchable ! (Ce n'est pas mon domaine !) et commencer à réfléchir aux éléments du réseau qui sont mûrs pour être traités comme jetables, au même titre que les applications qu'il fournit.