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

• Les applications déterminent les décisions sur tous les aspects, de l'emplacement au format de l'infrastructure de livraison prise en charge. 55 % des organisations choisissent un cloud en fonction des besoins et des exigences des applications. 40 % souhaitent pouvoir choisir le bon format pour l'application. (État de la mise à disposition des applications 2018)
• À mesure que les architectures cloud et microservices se fragmentent et distribuent les applications, l'infrastructure partagée devient un fardeau au lieu d'un avantage, ce qui augmente les coûts d'investissement et d'exploitation. 
• Le coût, la configuration et les mises à niveau sont des facteurs clés de la prise en charge des architectures par application avec des services d’application par application.
• Une approche par application pour les services d'application est nécessaire pour prendre en charge les applications et les architectures modernes

Au cours des dernières années, nous avons assisté à un effort concerté de la part des fournisseurs de cloud (Amazon, Microsoft, Google, etc.) pour répondre aux besoins des entreprises en matière de services applicatifs.

Vous pouvez trouver aujourd'hui sur les marchés du cloud un certain nombre (et ce nombre ne cesse de croître) de services d'application qui traitent de la sécurité (comme les pare-feu d'applications Web) ainsi que des performances (mise en cache) et même de la gestion des identités. Ce n’est pas une surprise. Les entreprises dépendent en moyenne de 16 services applicatifs différents pour rendre leurs applications plus rapides et plus sûres. Chaque année, ce nombre augmente. Les entreprises ne vont pas les sacrifier pour la vitesse du cloud.

À cet égard, les services applicatifs influencent à la fois les clients et les fournisseurs de cloud. Mais ce n’est pas une voie à sens unique. Le cloud – et de plus en plus les conteneurs – ont également un impact significatif sur les services applicatifs et la manière dont ils sont fournis.  

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

Comme la plupart des réseaux, les services d’application sont depuis longtemps fournis via une plateforme (souvent appelée contrôleur de distribution d’applications ou ADC en abrégé) prise en charge par un matériel évolutif et fiable. Ces appareils ont été conçus pour une haute disponibilité et une évolutivité élevée, capables de prendre en charge des centaines d'applications simultanément. Les infrastructures partagées – qu’il s’agisse de réseau ou d’application – présentent depuis longtemps des avantages en termes de coûts. Il était logique de répartir les dépenses d’investissement et d’exploitation sur plusieurs applications.

Jusqu’à ce que des applications et des architectures apparaissent là où cela n’était pas possible.

Il existe un nombre croissant d’applications et d’architectures qui nécessitent une approche plus axée sur les applications. La ménagerie moderne des microservices, par exemple, exige une plateforme rapide, évolutive et abordable sur laquelle déployer des services d’application pour une seule application.

Les plateformes de services partagés ne peuvent pas répondre à cette demande comme le ferait une plateforme par application spécialement conçue. Il y a trois bonnes raisons à cela :

1. Coût. Vous n’allez pas acheter une camionnette douze passagers si vous êtes la seule personne qui l’utilisera. Tout cet espace supplémentaire coûte plus cher au départ et à l'exploitation. Dans les bonnes situations (et pour les bonnes applications), l’infrastructure partagée réduit le coût par application et présente un grand sens financier et opérationnel. Mais si vous essayez de prendre en charge une seule application, cela ne fait qu’augmenter les dépenses sans ajouter de valeur.
2. Configurations. Les applications et architectures modernes sont développées et déployées avec des mises à jour fréquentes à l'esprit. Si vous partagez une plateforme avec huit autres applications, qui ne sont pas sur le même calendrier, elles pourraient être un peu contrariées si quelque chose se passe mal et affecte leurs applications. Sans compter que plus les configurations sont nombreuses et volumineuses, plus il faut de temps pour lire et vérifier ces configurations à chaque fois qu’elles doivent être rechargées ou modifiées.
3. Mises à niveau. Lorsque Bob souhaite mettre à niveau cette plateforme partagée et que vous ne le souhaitez pas, qui gagne ? Si Bob gagne – et que cela bloque une application – personne ne gagne, c’est sûr.  Les mises à niveau d’infrastructures partagées peuvent être une proposition effrayante. Ils peuvent également entraîner un temps supplémentaire consacré à la mise à jour ou à la mise à niveau (ou même à la migration) des configurations vers les versions les plus récentes, ce qui nous ramène directement au problème numéro un et aux coûts qui peuvent s'accumuler.

Il existe un besoin (et une demande) pour une plateforme de services applicatifs conçue spécifiquement pour prendre en charge une seule application. En réduisant la responsabilité à une seule application, la taille (et la complexité) de la configuration est réduite, le rayon d'action d'une mise à niveau échouée est limité à une seule application et le coût d'acquisition et d'exploitation est réduit.

À cause du cloud, des conteneurs et des microservices. En raison de 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 changent. Cela signifie que les services d’application – et leurs mécanismes de distribution – doivent également changer.