Portworx : « nous fournissons sur site les services du cloud »

Portworx, la filiale de Pure Storage dédiée à l’édition d’une couche de stockage pour Kubernetes, ajoute à sa solution des services payables par souscription. En l’occurrence, une fois qu’elle a installé la plateforme Portworx sur ses clusters Kubernetes, une entreprise peut s’abonner à des fonctions liées au stockage, comme la sauvegarde ou la reprise d’activité, mais aussi à des moteurs de base de données du marché. Ceux-ci sont spécialement packagés pour fonctionner avec Kubernetes et être pilotables depuis une seule console SaaS.

Le catalogue de ces services supplémentaires est baptisé Portworx Data Services, ou PDS. Lancé il y a moins d’un an, il comprend des versions prêtes à l’emploi d’Elastic Search, Redis, PostgreSQL, Cassandra, Kafka ou, tout dernièrement, MongoDB.

La stratégie qui consiste à proposer une couche d’infrastructure – le système de stockage persistant Portworx pour Kubernetes – puis de commercialiser derrière des services de plus haut niveau peut paraître étonnante. Pour mieux comprendre cette approche, LeMagIT s’est entretenu avec Murli Thirumale (en photo), le co-fondateur de Portworx, qui continue de diriger la filiale même après le rachat par Pure Storage.

LeMagIT : Pourquoi les entreprises ont-elles besoin d’une couche de stockage qui puisse être enrichie par des services de plus haut niveau ?

Murli Thirumale : Parce que du stockage extensible avec de la sauvegarde ou des bases de données est l’offre telle qu’elle est présentée dans les clouds publics. Et que les entreprises veulent pouvoir bénéficier d’une offre similaire sur site, dans leurs datacenters privés.

LeMagIT : Pourriez-vous nous expliquer ce que vous demandent exactement les entreprises ?

Murli Thirumale : Nous constatons une évolution du concept de DevOps [l’équipe technique qui travaille en soutien des développeurs d’applications, NDR]. À présent, les entreprises parlent véritablement d’équipe d’ingénierie de la plateforme. C’est-à-dire une équipe qui a la responsabilité de créer une plateforme cloud-native en self-service, au moins pour les développeurs, si ce n’est pour les métiers. Il ne s’agit plus simplement de fournir un socle, mais de fournir aussi des services de plus haut niveau, comme les bases de données, la sauvegarde, la reprise d’activité après sinistre. Il faut bien comprendre que cette équipe gère les paramètres, mais pas les applications elles-mêmes. Les applications sont gérées par les développeurs.

LeMagIT : Proposer d’enrichir votre solution avec des fonctions comme la sauvegarde ou la reprise d’activité est cohérent pour un système de stockage. Mais pourquoi des bases de données ?

Murli Thirumale : Les services de base de données en cloud comme RDS, chez AWS, sont très populaires. 47 % des clients d’un cloud utilisent son service de base de données. Mais 54 % de ces clients ont toujours un datacenter sur site. Et ces entreprises veulent disposer sur site des mêmes services que dans le cloud.

À l’heure actuelle, 85 % des nouvelles applications sont développées sous la forme de containers. Et elles le sont avec des bases de données comme MongoDB, Cassandra ou PostgreSQL. C’est l’usage – récent – de ces bases de données en conjonction avec Kubernetes qui nous fait d’ailleurs entrer dans l’ère post-DevOps.

PDS est en fait un équivalent sur site de RDS. PDS donne accès à PostgreSQL, Cassandra, Redis, MongoDB, toutes les bases de données modernes. À la fois des bases de données SQL et NoSQL. Il donne aussi accès aux services de distribution des données, comme Kafka et Spark. Pour l’équipe d’ingénierie de la plateforme cloud-native, il suffit juste de connecter le support de PDS dans les containers.

Et force est de constater que nous avons fait le bon choix : PDS est un produit excessivement populaire ces derniers temps, avec des ventes qui se démultiplient de mois en mois.

LeMagIT : Mais quel est l’intérêt d’acheter MongoDB, PostgreSQL ou autre auprès de vous, plutôt que l’installer soi-même ?

Murli Thirumale : Parce que notre version est livrée clés en main. Nous vous livrons l’opérateur qui relie votre base de données à Kubernetes, qui vous permet de ne payer qu’à l’usage, qui rattache votre base de données à notre portail d’administration en SaaS.

Depuis ce portail, l’équipe en charge de la plateforme est capable d’installer, administrer et maintenir toutes ces bases de données de la même façon. Qu’importe qu’il s’agisse de MongoDB ou de Redis. Les mises à jour fonctionnent de la même façon, les patches fonctionnent de la même façon.

Ces opérateurs nécessitent un développement particulier, en partenariat avec l’éditeur de la base de données, pour que tout fonctionne de manière transparente. C’est un effort que nos clients n’ont pas à faire eux-mêmes.

LeMagIT : Ces entreprises qui passent du concept de DevOps au concept d’équipe d’ingénierie de plateforme cloud-native, qui sont-elles exactement ?

Murli Thirumale : Initialement des banques, des opérateurs et de la grande distribution. C’est-à-dire des entreprises qui ont la culture de l’innovation et qui sont toujours les premières à tester de nouveaux concepts pour se transformer. En l’occurrence, ce sont des entreprises dont les applications évoluent si fréquemment qu’il y avait plus qu’ailleurs un intérêt à les développer sous la forme de containers. Ces entreprises-là se sont intéressées à Kubernetes dès 2018 et elles représentent aujourd’hui la majorité de nos clients. Cependant, cette année, d’autres entreprises leur ont emboîté le pas. Nous voyons arriver des équipes d’ingénierie de la plateforme dans les instituts de recherche, notamment dans la recherche pharmaceutique, chez les industriels...

LeMagIT : Votre solution est dédiée aux serveurs sur site et à Kubernetes. Mais quelles sont les perspectives de Kubernetes dans les datacenters ?

Murli Thirumale : Un autre phénomène récent est que les DSI commencent à remplacer les clusters VMware existants. Par exemple, 25 % des déploiements de Kubernetes se font sur du bare metal [serveur physique, NDR], sans aucune VM. Les DSI font cela parce que Kubernetes a la faculté de déployer le prochain container sur le prochain serveur disponible. De fait, via la containerisation, vous obtenez le même résultat qu’avec la virtualisation. Il n’est plus nécessaire de virtualiser la machine et cela vous permet de gagner en performances.

En ce qui nous concerne, nous virtualisons le stockage. C’est-à-dire que nous rendons le stockage de votre datacenter disponible pour vos containers, à la demande. Nous sommes en quelque sorte le vSAN de Kubernetes. Donc les entreprises n’ont plus besoin d’investir dans les produits d’infrastructure de VMware : vSphere, vRealize, vSAN.

Et quand bien même les entreprises auraient besoin de virtualisation, pour des raisons d’isolation par exemple, elles pourraient le faire avec KubeVirt. KubeVirt, c’est la faculté de déployer des VMs sans payer pour VMware.

LeMagIT : Outre les bases de données, vous proposez donc des services de sauvegarde et de restauration de ces sauvegardes en cas de sinistre. Quelles sont vos chances de vendre ces produits face à des géants de la sauvegarde comme Veeam, lequel se décline sur Kubernetes avec Kasten ?

Murli Thirumale : Nous avons une approche différente. Nos fonctions de sauvegardes sont conçues pour que l’équipe en charge de la plateforme puisse laisser les développeurs lui indiquer à quelle fréquence il faut faire des snapshots, avec quelle rapidité il faut restaurer telle ou telle sauvegarde.

Comprenons-nous bien : nous ne sommes pas là pour proposer une solution d’archivage. Nos concurrents proposent d’archiver régulièrement les clusters à des fins de réglementation, sans que les développeurs aient à intervenir.

Nous, nous proposons une sauvegarde vivante, qui permet au développeur de revenir en arrière une fois qu’il a expérimenté des choses. Une plateforme qui lui permet d’indiquer quels sont les containers qu’il faut restaurer en priorité. Et tout cela, pendant qu’il écrit son application. Pour que ce cas d’usage soit possible, il faut que la sauvegarde soit intégrée au système des paramètres de la plateforme, celui sur lequel les développeurs signifient leurs décisions et celui que pilote l’équipe en charge de la plateforme.

Nos fonctions sont intégrées à l’architecture, en cohérence avec les usages. C’est le principe de la plateforme Portworx. Et c’est une exclusivité.