Les applications cloud natives ne nécessitent pas de cloud
L’ironie est délicieuse avec le mot à la mode du jour : cloud-native.
La première chose à noter est que le cloud natif, malgré son nom, ne nécessite pas de cloud. N'est-ce pas? Le nom vient de l’approche architecturale consistant à créer une application qui s’appuie sur une infrastructure et qui est conçue autour des concepts du cloud : élasticité, économie d’échelle et calcul distribué. C’est incontestablement le cloud computing qui a introduit ces concepts dans tous les aspects de la distribution d’applications : de l’architecture des applications à l’automatisation, de l’intégration basée sur les API à l’infrastructure. Le cloud computing a changé la façon dont nous développons, créons et déployons des applications. Les applications nées dans le cloud public ont naturellement adopté bon nombre des mêmes dépendances et caractéristiques. Ainsi, le nom représente avec précision l’étymologie du style architectural.
Il existe également un lien indiscutable entre le cloud natif et les conteneurs. Cela en soi le différencie des applications nées dans le cloud qui s'appuient principalement sur des machines virtuelles et des services cloud natifs pour atteindre des objectifs similaires. Le cloud natif et les conteneurs sont étroitement couplés car les orchestrateurs de conteneurs associés (Kubernetes) sont le moyen le plus simple et le plus répandu de coupler les applications avec l'infrastructure requise pour offrir l'élasticité et, à travers elle, l'économie d'échelle souhaitée.
Dans une application cloud native, les composants sont atomisés pour favoriser les économies d'échelle. C'est pour cela que cloud-native et conteneurs sont presque synonymes. Vous devez pouvoir mettre à l’échelle uniquement les fonctions demandées, à la demande. Ce type de partitionnement élastique et fonctionnel des applications a traditionnellement été réalisé grâce à des architectures qui s'appuient sur le routage de couche 7 (HTTP) et le cloud natif ne fait pas exception. Les mêmes principes s'appliquent à ces applications modernes et utilisent généralement un contrôleur d'entrée (un service d'application d'infrastructure) qui gère la distribution des requêtes entrantes vers l'instance appropriée basée sur un conteneur d'un composant d'application.
Ce partitionnement est souvent effectué au niveau de l'API, où les URI correspondent aux appels d'API qui correspondent à des services de conteneur spécifiques. Le contrôle d'entrée dirige les demandes vers le service de conteneur approprié et, à son tour, distribue les demandes sur un pool d'instances de composants/applications. Il s'agit d'un gâteau à deux couches avec un contrôle d'entrée de couche 7 (HTTP) distribuant à un simple équilibreur de charge (POLB) pour la livraison et l'exécution.
De plus, nous avons recours à des registres de services qui, sous-jacents, constituent un autre service d’application d’infrastructure nécessaire pour faciliter l’élasticité des applications cloud natives. Sans mécanisme de découverte de services, l'équilibrage de charge et le contrôle d'entrée ne fonctionnent pas, ce qui rend l'application inutilisable.
Cette relation - entre les composants, les services, les registres de services, les équilibreurs de charge et le contrôle d'entrée - est l'incarnation des principes des applications cloud natives. Les composants et l’infrastructure de l’application sont intimement liés sans être étroitement couplés. Les composants ne peuvent pas atteindre l'économie d'échelle ou la distribution entre les environnements sans le routage de couche 7 et les capacités d'équilibrage de charge classiques. La dépendance entre l’infrastructure et les applications est réelle et essentielle à l’impératif commercial de fournir des applications.
Rien de tout cela ne repose ni ne nécessite un quelconque environnement de cloud computing. Une application cloud native peut être - et est souvent - déployée seule. En fait, si nous examinons les données relatives aux conteneurs et à l'endroit où ils s'exécutent, nous constatons que le « sur site » conserve son ascendance sur les environnements de cloud public.
Il est vrai que l’on peut déployer des conteneurs sur un cloud privé (sur site) – et nos propres recherches continuent de montrer que le cloud privé sur site reste le modèle de cloud le plus populaire actuellement utilisé. Plus des trois quarts (79 %) des répondants à notre étude State of Application Services 2019 ont des applications dans un cloud privé sur site, tandis que le cloud public continue de lutter pour atteindre une majorité de 45 %.
Les applications cloud natives constituent une architecture à croissance rapide qui, vous pouvez en être sûr, continuera de croître au cours des cinq prochaines années. Comprendre leur relation avec les services d’application d’infrastructure et leur dépendance à leur égard est un élément essentiel pour fournir (et sécuriser) avec succès ces applications modernes.