Talonné par VMware Tanzu, Red Hat OpenShift se met au DevSecOps
Alors que les entreprises s’intéressent de plus en plus aux plateformes DevOps basées sur des conteneurs, Red Hat enrichit OpenShift, tandis que VMware Tanzu veut s’emparer d’au moins une partie de la base installée de VMware vSphere.
Boston – Cela fait plus de 10 ans que Red Hat a lancé OpenShift, mais la véritable compétition entre les éditeurs de plateforme DevOps ne fait que commencer.
Red Hat a commercialisé OpenShift en 2011 et a standardisé sa plateforme de conteneurs sur Kubernetes en 2014, bien avant que l’orchestrateur de conteneurs ne devienne la norme implicite dans l’industrie IT. OpenShift reste, selon les mesures de la plupart des analystes du marché, la plateforme DevOps la plus utilisée. Une catégorie qui a pris forme au milieu des bouleversements de la pandémie de COVID-19 et d’une consolidation de l’industrie ayant vu VMware acquérir Heptio en 2018, formant la base de ses produits Tanzu Kubernetes ; IBM reprendre Red Hat pour 34 milliards de dollars en 2019 ; et SUSE racheter Rancher en 2020. Selon les dernières estimations d’IBM, le nombre de clients d’OpenShift s’élève à environ 3 500 entreprises.
« Ils sont toujours numéro 1 sur le marché, surtout pour leurs offres et efforts consacrés aux conteneurs et à Kubernetes », déclare Rob Strechay, analyste chez Enterprise Strategy Group, une division de TechTarget, également propriétaire du MagIT. « Dans le cloud public, ils tiennent leur rang, tandis qu’EKS Anywhere [d’Amazon] et Anthos [de Google] n’ont pas fait autant de progrès sur site. »
Des plateformes multifacettes, difficiles à comparer
Ici et là, cependant, il y a des failles dans l’armure d’OpenShift, selon l’orientation technique d’un client.
Certains primoadoptants de l’edge computing, tels que l’armée de l’air américaine et le ministère de la Défense, ont favorisé Rancher Kubernetes – par exemple –, étant donné qu’il a été le premier à commercialiser en 2019 une version dépouillée de Kubernetes dans k3s et une prise en charge de l’interface utilisateur pour la gestion centralisée de milliers de clusters déployés en périphérie. Depuis cette semaine, Red Hat OpenShift Advanced Cluster Management prend en charge jusqu’à 2 000 clusters OpenShift à nœud unique.
Les analystes désignent également VMware et sa plateforme Tanzu – malgré l’arrivée relativement tardive de Kubernetes, après des années de lutte pour l’intégrer à la PaaS Cloud Foundry – comme le principal rival actuel de Red Hat, compte tenu des centaines de milliers de grandes entreprises clientes qui utilisent les machines virtuelles vSphere et les outils de gestion IT vRealize. Le PDG de VMware, Raghu Raghuram, a affirmé que la majorité des environnements OpenShift fonctionnent sur vSphere.
VMware a également fait quelques incursions dans le cloud hybride avec son offre VMware Tanzu on AWS, pour tenter de maintenir la pression sur Red Hat, selon Rob Strechay.
« Dans l’écosystème AWS, VMware semble apparaître plus souvent qu’auparavant », affirme-t-il. « Je dirais qu’ils occupent la deuxième place du point de vue des systèmes sur site – c’est un marché mûr pour eux. »
Bien que Red Hat ne précise pas publiquement le pourcentage d’environnements OpenShift exécutés sur VMware vSphere ; le type d’infrastructure sur site qui connaît la plus forte croissance dans les environnements OpenShift est le bare-metal, confirme un porte-parole de l’entreprise. Red Hat propose également OpenShift Virtualization comme alternative aux machines virtuelles.
Pourtant, « VMware est définitivement la plus grande menace pour Red Hat », souligne Charlotte Dunlap, analyste chez GlobalData Technology à Santa Cruz (Californie).
Tanzu et OpenShift se préparent à s’affronter dans le domaine du DevSecOps
La sécurité de la chaîne logistique logicielle est devenue une autre case que les éditeurs de plateformes DevOps doivent remplir – et un autre champ de bataille pour eux – grâce ou à cause des attaques et des vulnérabilités très médiatisées telles que SolarWinds et Log4j.
Red Hat a commencé à remplir des fonctions dans ce domaine cette semaine, lorsqu’il a présenté en avant-première une nouvelle intégration entre OpenShift Pipelines, OpenShift GitOps, Ansible Automation Platform et Red Hat Advanced Cluster Security (anciennement StackRox) pour les clients OpenShift Platform Plus.
Cette intégration – ou modèle, dans le jargon de Red Hat – dépendra du travail de Red Hat sur le projet open source Tekton Chains, où l’intégration avec le projet open source Sigstore pour l’attestation de la supply chain logicielle demeure expérimentale. La version 2.2 de la plateforme d’automatisation Ansible, publiée cette semaine, a également ajouté un mécanisme de signature de contenu via GNU PrivacyGuard, et la version 9 de Red Hat Enterprise Linux améliore la fonction d’architecture de gestion de l’intégrité qui signe les images du système d’exploitation en utilisant des hachages cryptographiques.
Les clients de Tanzu Application Platform (TAP) de VMware qui utilisent le service de construction Tanzu de VMware pour les images de conteneurs peuvent générer automatiquement une nomenclature logicielle (SBOM) pour les applications basées sur Java et Node.js depuis la version 1.0 en janvier ; tandis que Red Hat n’offre pas encore de mécanisme SBOM clairement désigné pour OpenShift. Avec la version 1.1 du mois dernier, TAP a mis à disposition des fonctions de supply chain logicielle pour les images de conteneurs en dehors du service de construction Tanzu, et a lancé sa propre intégration avec le format de signature Cosign de Sigstore pour l’attestation de la chaîne logistique logicielle.
Tous ces projets sont jeunes, y compris Sigstore, rappelle Daniel Kirsch, analyste et cofondateur de Techstrong Research. Red Hat devra les évangéliser auprès de sa base de clients, en plus de les rendre aptes à la production, ajoute-t-il.
« Je ne sais pas si Sigstore a suscité beaucoup d’intérêt jusqu’à présent et s’il bénéficie du même soutien que les autres projets sur lesquels Red Hat travaille », déclare Daniel Kirsch.
En réalité, Sigstore est au centre de l’attention du marché depuis qu’il est devenu partie intégrante de l’Open Source Security Foundation l’année dernière et qu’il a été adopté par la communauté Kubernetes pour sécuriser la supply chain logicielle à partir de la version 1.24 de Kubernetes de ce mois.
« Il ne s’agit pas seulement de savoir si la technologie est viable », ajoute l’analyste. « Il s’agit aussi de savoir qui l’utilise, et si elle aide d’autres clients de Red Hat à réussir des audits de sécurité et d’autres cas d’usage convaincants – pour obtenir l’adhésion, ils vont devoir montrer les résultats commerciaux », note-t-il.
Le Red Hat Summit 2022 a été le théâtre de plusieurs annonces concernant les produits OpenShift, dont celles consacrées au DevSecOps.
Des clients communs pour un choc des titans du DevOps
En fin de compte, l’adoption de plateformes DevOps par les grandes entreprises clientes dépendra probablement de facteurs commerciaux plutôt que de comparaisons techniques, entre des offres qui se chevauchent de plus en plus.
L’assureur santé Blue Shield of California (BSC), par exemple, a présenté au Red Hat Summit son travail depuis début 2020 avec l’aide du service de conseil Open Transformation de Red Hat pour migrer d’une infrastructure et d’un pipeline DevOps basés sur vSphere vers une autre reposant sur des conteneurs.
Alors que Red Hat propose des outils pour chaque étape de ce processus, Blue Shield a conservé son intégration continue orchestrée sur Jenkins et des outils tiers de sécurité des conteneurs comme Anchore et SonarQube. CloudBees, qui soutient commercialement Jenkins, pourrait aussi potentiellement ajouter ses produits DevOps au mélange, mais en fin de compte, la relation de longue date de BSC avec IBM l’a poussé vers OpenShift.
« Nous envisagions initialement IBM Cloud Private, mais IBM était en train d’acheter Red Hat à l’époque et nous a dit de ne pas y penser », relate Ty Lim, chef d’équipe, architecte de l’infrastructure IT chez BSC.
Le produit d’IBM, aujourd’hui abandonné, « était davantage un emballage autour de Kubernetes, mais sans la flexibilité que nous avons obtenue avec OpenShift », avance Ty Lim.
« Passer aux conteneurs réclame bien plus qu’un “simple” lift and shift ».
Ty LimArchitecte de l'infrastructure IT, BSC
Le responsable remercie les services professionnels de Red Hat d’avoir aidé son équipe à intégrer des outils extérieurs à la plateforme OpenShift dans son environnement. À l’avenir, Ty Lim demeure ouvert à l’idée d’envisager Red Hat OpenShift Advanced Cluster Management pour orchestrer plusieurs clusters Kubernetes et Advanced Cluster Security pour sécuriser les conteneurs en production.
En attendant, deux ans plus tard, la transformation de centaines de services d’application au sein de BSC constitue un chantier en cours au moins aussi complexe que le paysage des éditeurs de plateformes DevOps qui l’entoure, indique Ty Lim. BSC se prépare à mettre en production Kubernetes ce mois-ci, mais les pipelines et l’infrastructure conteneurisés de l’entreprise fonctionneront parallèlement aux versions basées sur les machines virtuelles pendant cette transition, qui devrait durer jusqu’en 2023, migration oblige.
« Nous avons dû construire l’infrastructure, mais aussi créer une chaîne d’approvisionnement logicielle de confiance, passer à un modèle de plateforme et faire en sorte que les développeurs se situent dans l’écosystème OpenShift et construisent des applications pour les conteneurs », liste le responsable chez BSC. « Passer aux conteneurs réclame bien plus qu’un “simple” lift and shift ».
