Cloud Foundry en pleine mutation


Depuis de nombreuses années, le terme "cloud foundry" désigne une technologie prête à la production permettant de créer de grandes plateformes d'applications. L'expérience "cf push", indissociable de Cloud Foundry, est une caractéristique essentielle de cette technologie.
Elle offre aux développeurs une interface pratique pour exploiter des systèmes d'application de manière autonome. Parallèlement, Cloud Foundry permet également aux grandes organisations de fonctionner de manière efficace (Bosh) et d'établir des normes d'entreprise (Buildpacks).
Alors que l'expérience utilisateur a favorisé l'adoption de la technologie par les grandes entreprises au fil des ans, avec une uniformité et une stabilité relativement élevées, l'intérieur de Cloud Foundry a été en constante évolution. Lorsque les premières discussions autour d'une combinaison de Kubernetes et de Cloud Foundry ont vu le jour, l'intégration de Kubernetes en tant qu'orchestrateur de conteneurs s'est imposée comme une évidence.
Le mariage de Kubernetes et de Cloud Foundry va toutefois plus loin et ne s'arrête pas à la gestion des conteneurs d'applications. Pour en montrer les implications, rappelons que l'indépendance de l'infrastructure, la stabilité et - pour les grands environnements - les faibles coûts d'exploitation ne proviennent pas de Cloud Foundry lui-même, mais de sa technologie sœur Bosh.
Bosh est une technologie plutôt peu répandue et sous-estimée qui rend l'orchestration de machines virtuelles avec état aussi systématique et fiable que Cloud Foundry pour les systèmes d'application sans état.
L'interface utilisateur est toutefois beaucoup moins simple et nécessite un certain apprentissage. Avec l'arrivée de Kubernetes, il était donc envisageable dans un premier temps que la pile de fondations cloud ne doive pas beaucoup changer. L'exploitation pourrait continuer à se faire avec Bosh et Kubernetes serait intégré comme ordonnanceur de conteneurs (projet Eirini).
L'énorme élan de Kubernetes ne s'arrête toutefois pas à l'exploitation d'applications sans état, comme le fait Cloud Foundry. Grâce à l'introduction de StatefulSets, Kubernetes est également en mesure de gérer les charges d'applications avec état.
Cela réveille les aspirations des anciens enthousiastes d'OpenStack, qui rêvent d'une interface libre et standardisée pour l'orchestration d'infrastructures virtuelles (VM). L'espoir germe de voir Kubernetes évoluer vers cette technologie générique et s'abstraire ainsi des API d'infrastructure impératives et propriétaires des fournisseurs de cloud public et sur site.
L'enthousiasme est tel qu'avec une foi inébranlable, on accepte aussi les inconvénients, comme par exemple l'isolation nettement plus faible, que les conteneurs apportent par rapport aux machines virtuelles. Un inconvénient qui peut justement se manifester par des interférences mutuelles lors de la colocalisation de bases de données sur un nœud Kubernetes.
Il n'est donc pas étonnant que Cloud Foundry continue à s'adapter à Kubernetes. Un projet d'architecture de SAP se consacre par exemple à la question de savoir si un environnement Cloud Foundry basé sur Kubernetes pourrait reproduire 1:1 les grands environnements de la pile classique, et remet plutôt cela en question. Les contraintes sont trop importantes de part et d'autre.
Au lieu d'encourager le gigantisme de certains environnements, on mise plutôt sur le fédéralisme. Une séparation du Cloud Control Plane, composé de l'API et de l'UI, du sous-système de conteneurs (Eirini) pourrait contribuer à rendre les environnements Cloud Foundry plus légers et à réduire ainsi la barrière à l'entrée pour les petits environnements CF. Un plan de contrôle Cloud Foundry pourrait par exemple servir de nombreux clusters Kubernetes ou différents clusters Kubernetes avec des tâches dédiées.
Le temps montrera quelles approches architecturales seront mises en œuvre et quel sera le degré d'adaptation par les utilisateurs. L'architecte pense, l'utilisateur dirige. Dans tous les cas, il y a des changements passionnants à observer.