Comment le cloud et les conteneurs favorisent la désagrégation des services applicatifs

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

• Les applications déterminent les décisions concernant tous les aspects de l’infrastructure de mise à disposition sous-jacente, de son emplacement à son format. 55 % des organisations choisissent un cloud en fonction des besoins et des exigences des applications. 40 % souhaitent pouvoir choisir le format adapté à l’application. (État des lieux de la mise à disposition des applications 2018)
• À mesure que les architectures cloud et de microservices décomposent et distribuent les applications, l’infrastructure partagée devient un fardeau plutôt qu’un avantage, ce qui entraîne une hausse des dépenses d’investissement et des coûts d’exploitation
• Les coûts, la configuration et les mises à niveau sont des facteurs clés pour la prise en charge d’architectures propres à chaque application avec des services applicatifs dédiés.
• Une approche par application des services applicatifs est nécessaire pour prendre en charge les applications et architectures modernes

Ces dernières années, nous avons assisté à un effort concerté de la part des fournisseurs de services cloud – Amazon, Microsoft, Google, entre autres – pour répondre au besoin bien réel des entreprises en matière de services applicatifs.

On trouve aujourd’hui sur les marketplaces cloud un nombre croissant de services applicatifs répondant à des besoins de sécurité (comme les pare-feu applicatifs web), de performances (mise en cache) et même de gestion des identités. Cela n’a rien de surprenant. Les entreprises s’appuient en moyenne sur 16 services applicatifs différents pour rendre leurs applications plus rapides et plus sûres. Ce nombre augmente chaque année. Les entreprises ne vont pas y renoncer au profit de la rapidité du cloud.

À cet égard, les services applicatifs influencent à la fois les clients et les fournisseurs de services cloud. Mais cette influence n’est pas à sens unique. Le cloud — et, de plus en plus, les conteneurs — a également un impact considérable sur les services applicatifs et leur mode de fourniture.

Alors que les entreprises continuent d’investir dans le cloud privé (sur site) et d’expérimenter les conteneurs, elles constatent que le modèle traditionnel de fourniture de services applicatifs n’est pas toujours adapté.

À l’instar de la plupart des services réseau, les services applicatifs sont depuis longtemps fournis par l’intermédiaire d’une plateforme (souvent appelée contrôleur de mise à disposition d’applications, ou ADC) reposant sur un matériel fiable et évolutif. Ces équipements ont été conçus pour offrir une haute disponibilité et une grande évolutivité, et peuvent prendre en charge des centaines d’applications simultanément. Les infrastructures partagées, qu’elles soient réseau ou applicatives, présentent depuis longtemps des avantages en matière de coûts. Il était logique de répartir les dépenses d’investissement et d’exploitation entre plusieurs applications.

Jusqu’à l’émergence d’applications et d’architectures pour lesquelles ce n’était plus le cas.

De plus en plus d’applications et d’architectures nécessitent une approche davantage axée sur l’application. La diversité actuelle des microservices, par exemple, exige une plateforme rapide, évolutive et abordable sur laquelle déployer des services applicatifs pour une seule et même application.

Les plateformes de services partagés ne peuvent pas répondre à ce besoin aussi efficacement qu’une plateforme conçue spécifiquement pour chaque application. Il y a trois bonnes raisons à cela :

1. Coût. Vous n’allez pas acheter un minibus de douze places si vous êtes la seule personne à l’utiliser. Tout cet espace supplémentaire coûte plus cher à l’achat comme à l’usage. Dans les situations appropriées (et pour les applications qui s’y prêtent), une infrastructure partagée réduit le coût par application et se révèle très pertinente sur les plans financier et opérationnel. Mais si vous ne cherchez à prendre en charge qu’une seule application, elle ne fait qu’augmenter les dépenses sans apporter de valeur ajoutée.
2. Configurations. Les applications et architectures modernes sont développées et déployées en prévision de mises à jour fréquentes. Si vous partagez une plateforme avec huit autres applications, dont les calendriers de mise à jour diffèrent, leurs responsables risquent d’être quelque peu contrariés si un problème survient et affecte leurs applications. Sans compter que plus les configurations sont nombreuses et volumineuses, plus leur lecture et leur vérification prennent du temps chaque fois qu’elles doivent être rechargées ou modifiées.
3. Mises à niveau. Lorsque Bob veut mettre à niveau cette plateforme partagée, mais pas vous, qui l’emporte ? Si Bob obtient gain de cause — et que cela provoque le dysfonctionnement d’une application — personne n’y gagne. La mise à niveau d’une infrastructure partagée peut être une perspective inquiétante. Elle peut également nécessiter davantage de temps pour actualiser ou mettre à niveau (voire migrer) les configurations vers les versions les plus récentes, ce qui nous ramène directement au premier problème et aux coûts qui peuvent s’accumuler.

Il existe un besoin (et une demande) pour une plateforme de services applicatifs spécialement conçue pour ne prendre en charge qu’une seule application. Le fait de limiter son périmètre de responsabilité à une seule application réduit la taille (et la complexité) de la configuration, circonscrit à cette application les conséquences d’une mise à niveau ayant échoué et diminue les coûts d’acquisition et d’exploitation.

À cause du cloud, des conteneurs et des microservices. À cause du DevOps et de l’économie numérique, qui poussent les organisations à livrer plus rapidement et plus fréquemment.

Les applications et les architectures évoluent. Les environnements évoluent. Les services applicatifs — et leurs mécanismes de mise à disposition — doivent donc évoluer eux aussi.

À 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