Openshift versus Cloud Foundry : un match décisif

Le PaaS laisse place aux écosystèmes de containers

OpenShift et Cloud Foundry ont tous deux adopté une approche open source et la containerisation comme un moyen pratique pour déployer des applications basées sur une plateforme. Au départ, tout du moins.

Cloud Foundry est une PaaS open source dans le cloud avec laquelle les containers et les technologies associées sont pensées comment des éléments d’une suite beaucoup plus large et complète. Il s’agit d’un environnement de développement et de déploiement d’applications lié à un framework. Les utilisateurs peuvent héberger Cloud Foundry où bon leur semble (sur site, dans le cloud public et privé). Auparavant, la plateforme avait son propre orchestrateur, Diego. Celui-ci a finalement été abandonné au profit du standard Kubernetes.

Red Hat avait également un orchestrateur propriétaire, GearD, mais s’est converti à la religion Kubernetes. Il a modifié sa stratégie afin de faire d’OpenShift une plateforme pour déployer toutes les applications des entreprises à l’aide du célèbre gestionnaire de containers. Il est moins question de développement que de proposer un écosystème pour n'importe quel modèle d'application : stateful ou stateless, nouveau ou ancien, dans le cloud ou dans un data center. OpenShift n'est plus un vrai PaaS ; il définit les capacités, pas les modèles de programmation.

Afin de différencier OpenShift et Cloud Foundry, il est essentiel de comprendre ces deux partis pris parce qu’il y a deux manières de les percevoir ; tels qu'ils se présentaient auparavant, c’est-à-dire comme des PaaS, et tels qu’ils sont actuellement : des écosystèmes de containers intrinsèquement liés à Kubernetes.

À moins qu’une entreprise utilise un petit nombre d’applications et de modèles de développement, et qu’elle puisse le faire en interne ou à l’aide de logiciels fournis par la communauté Cloud Foundry, elle ne devrait pas adopter une architecture PaaS. Presque toutes les entreprises utilisent un mélange de logiciels codés à la main avec un large éventail de modèles et d'outils de développement, donc un seul PaaS n'est pas la bonne réponse.

Ainsi, la containerisation orchestrée par Kubernetes est la réponse choisie par les deux éditeurs. RedShift était l’un des premiers à l’adopter, Cloud Foundry a récemment rejoint cette communauté. Pour les différencier, il faut donc comprendre la manière dont ils utilisent l’orchestrateur.

Architecture

Au niveau de l’architecture, Cloud Foundry conserve son statut de PaaS, ce qui veut dire que les entreprises pourraient être obligées d’adopter un modèle de développement propriétaire proposé dans la plateforme. Les composants logiciels sont étroitement intégrés avec les outils qui servent tout au long du développement et du déploiement.

Ces softwares sont beaucoup plus difficiles à porter parce qu’ils reposent sur un framework propriétaire mis en place par Pivotal. Depuis que Kubernetes est l’orchestrateur attitré de CF, il est possible de déployer des applications containerisées depuis n'importe quelle source, mais ce sont des applications liées à Kubernetes.

D’une certaine manière, OpenShift repose sur une chaîne intégrée d’outils placée autour de l’application. Contrairement à CF, les développeurs écrivent une application et la déploient ensuite via la plateforme. Tout ce qui peut fonctionner dans un container peut être lancé à l’aide d’OpenShift. Certains outils comme Istio peuvent réclamer d’ajuster le design et le développement des applications, mais ils sont tous open source et largement utilisés. En effet, Red Hat défend un environnement ouvert du sol au plafond.

Intégration

Les entreprises ne mettent pas tout dans le cloud. Par ailleurs, la plupart de leurs applications ne peuvent ou ne devraient pas migrer des données entre le cloud et les datacenters ou les exécuter de manière distribuée entre ces environnements IT. Le grand atout de Kubernetes et des containers, c’est de fournir un modèle universel. En principe, celui-ci permet aux applications de fonctionner uniformément depuis n’importe quel cloud ou ressources dédiées. Cela dépend de l’intégration des outils eux-mêmes.

Cloud Foundry supporte les outils associés à Kubernetes pour la surveillance des déploiements hybrides et multicloud, des flux de travail et du service Mesh. Malheureusement, ceux-ci ne sont pas forcément préinstallés au moment de la mise en place de Cloud Foundry. Cela devient une tâche imposante qui incombe alors à l’entreprise. Les éléments PaaS de CF sont stateless, les utilisateurs doivent donc effectuer un travail d’harmonisation avec les applications stateful déployées à l’aide de Kubernetes dans un centre de données.

Openshift fournit un écosystème complet pour celui qui veut exécuter, gérer, surveiller, sécuriser des containers et les workflows associés. Les sociétés doivent sans doute ajuster ces dispositifs suivant leurs besoins, mais Red Hat les a pré-intégrés et correctement documentés. De même, les applications au sein de l’écosystème OpenShift sont plus faciles à synchroniser et comme cet écosystème peut virtuellement assimiler n’importe quelle application, le niveau de difficulté d’intégration est bas.

Développement d’applications front-end

Les entreprises imbriquent des composants en provenance du cloud public et de leur data center au sein d’une même application. Souvent, elles développent le front-end en adoptant une approche cloud native séparément des autres processus. Pour ce faire, elles s’intéressent fortement aux stratégies low-code/no-code. À ce titre, la comparaison entre OpenShift et Cloud Foundry amène son lot de pour et de contre.

Le modèle de développement stateless inhérent à l’architecture de CF est le plus adapté aux applications front-end. La virtualisation de l'infrastructure permet d'harmoniser le déploiement des ressources entre cloud public et data center. La portabilité de ces logiciels dans les environnements d’hébergement s’en trouve améliorée.

Or la mise en œuvre de CF dans le cloud s’avère complexe et demande d’y allouer beaucoup de ressources. Si les programmeurs n’utilisent pas le framework inclus et adopte une approche de développement différente, ils doivent la gérer autour de la plateforme principale sur Kubernetes. Par ailleurs, Cloud Foundry embarque un seul environnement low code/no code d’importance : Mendix.

De son côté, OpenShift ne porte pas d’initiative particulière pour la conception d’applications front-end cloud natives. Toutefois, il ne restreint pas le choix d’un environnement et ne dicte pas les pratiques en matière de construction de code. Les utilisateurs peuvent, en principe, sélectionner celui qui leur convient le mieux.

Perspectives et évolutions des éditeurs

Pivotal, qui a développé l'essentiel des fonctionnalités de Cloud Foundry, a été racheté par VMware, ce qui devrait se traduire par une réduction significative des effectifs. La Fondation associée continue le support du produit, mais certains doutent de son avenir. Son destin repose sur VMware : reste à savoir s’il ne veut pas l’embarquer au sein de vSphere, qui est également devenu une sorte de PaaS.

IBM, le nouveau propriétaire de Red Hat, distribue également Cloud Foundry via BlueMix. Red Hat est l'un des plus grands éditeurs de logiciels open source. OpenShift est construit à partir d'outils communautaires soutenus par une large base de développeurs. Bien qu'il y ait une certaine incertitude quant à la façon dont IBM intégrera Red Hat dans ses efforts de vente, le géant de l'informatique dispose de ressources suffisantes pour prendre en charge le produit qu’il met considérablement en avant.

Et le gagnant est...

Il est rare qu'une comparaison technologique soit aussi décisive, mais dans cette bataille OpenShift contre Cloud Foundry, OpenShift est clairement le vainqueur. L’importante base d'utilisateurs de Cloud Foundry va devoir garder un œil sur le maintien de la solution par VMware, vérifier si un autre acteur prend le relais, et si le projet open source peut survivre sans un sponsor attitré.