L’Object Storage tient-il toutes ses promesses ?
Le concept de l'Object Storage est né il y a plus de 20 ans. Alors que cette technologie de stockage des données se démocratise, les entreprises font face à un large choix de solutions. Tiennent-elles toutes les promesses originelles, depuis la scalabilité jusqu'à la réduction des coûts ?
Les premiers travaux de recherche à l’origine du concept de l’Object Storage remontent à l’année 1996. Et c’est à une société belge, FilePool (depuis rachetée par EMC), que l’on doit la toute première implémentation du stockage objet à des fins d’archivage. De 1999 à 2019, des centaines de millions de dollars de capital-risque ont été investis dans le développement de solutions basées sur le stockage d'objets, auxquelles il faut ajouter le travail d’ingénierie fourni par les plus gros acteurs du stockage puis du cloud, qui ont naturellement cherché à tirer profit de ce nouveau paradigme. Alors que l’Object Storage se démocratise, il est légitime de dresser l’inventaire des promesses tenues… et de celles oubliées en route.
L’embarras du choix
Le marché du
stockage peine à se consolider, fragmenté entre les spécialistes historiques du
stockage, les outsiders — startups développant des solutions innovantes — et les fournisseurs de Cloud. Alors
que les données n’ont jamais constitué un actif si précieux, les entreprises sont
confrontées à un hyperchoix. Cloud public ou privé, solutions associées à une
appliance ou à des contraintes hardware fortes, software defined storage open
source ou propriétaire, modèles économiques complexes : honnêtement, il
n’est pas facile s’y repérer. Dans ce contexte, une piste intéressante pour
discriminer les différentes solutions nous semble être de revenir aux promesses
originelles de l’Object Storage. Le monde IT produit des innovations en série,
véritables ruptures technologies ou demi-innovations boursoufflées par les
promesses du marketing. Qu’en est-il vraiment de l’Object Storage ?
Scalabilité infinie, vraiment ?
Si l’Object
Storage a tant séduit, c’est qu’il semblait constituer le remède universel à
bien des défis liés au stockage des données – des défis historiquement moins
bien considérés que ceux relatifs au compute, mais la croissance exponentielle
de la production de données change la donne. L’Object Storage, en effet,
s’avère idéal pour stocker les données non structurées et contenus statiques. Il
simplifie par ailleurs la sécurisation des données et améliore leur
disponibilité, en proposant des architectures multisites by design, une
réplication des données efficiente et des fonctionnalités de versioning qui
limitent le besoin de backup. En revanche, la promesse phare de scalabilité
infinie génère quelques déceptions. Pouvoir augmenter la capacité d’une plateforme
de stockage en proportion de ses besoins, ceci sans créer un nouveau cluster
qui "silote" les données alors que la nécessité est de les
agréger, voilà qui constitue un progrès considérable. Mais ceux qui gèrent de
gros volumes de données – on parle aujourd’hui de dizaines de pétaoctets, voire
d’exaoctets – commencent à toucher du doigt certaines limites. Lorsque l’on
augmente la taille du cluster en ajoutant de nouvelles machines, la plateforme
doit généralement rebalancer les données pour équilibrer la charge entre les
différents serveurs. Indolore sur une plateforme de taille modeste et/ou peu
remplie, cette opération de rebalancing peut prendre plusieurs jours ou semaines,
voire des mois entiers, affectant sensiblement les performances du cluster et
donc la disponibilité des données. Des ralentissements d’autant plus
dommageables que ce qui, en général, a justifié l’augmentation de la capacité
de la plateforme est un accroissement des usages. Pour cette raison, il n’est
pas rare que les entreprises renoncent à scaler un cluster d’Object Storage…
pour en monter un autre. Quitte à créer, à contrecœur, de nouveaux silos de
données, qu’on aura du mal à faire communiquer. Une hérésie alors que les
algorithmes d’IA ouvrent d’enfin des perspectives concrètes pour exploiter les "Big
Data".
Une agilité dans la croissance qui manque un peu de souplesse
L’agilité est un concept implicitement associé à la scalabilité. Il est intéressant de le dissocier. Par agilité, il faut entendre la possibilité de démarrer un cluster de stockage de faible capacité, que l’on pourra faire grossir pour suivre le cycle de vie d’un projet. On parle ici d’un facteur d’accélération de x 100 ou x 1 000. Or, on peut observer que toutes les solutions d’Object Storage ne permettent pas de "commencer petit". En conséquence, l’entreprise est souvent contrainte d’investir, au départ, dans plusieurs machines robustes et une capacité de stockage de l’ordre du pétaoctet, quand bien même elle n’en a pas l’usage immédiat.
Des performances souvent mal évaluées
Quand bien même l’Object Storage n’a pas vocation à être utilisé pour stocker
des bases de données ou systèmes de fichiers de machines virtuelles, cela n’est
pas une raison pour reléguer au second plan la question de la performance. S’il
est difficile de comparer les performances d’un type de solution de stockage à
l’autre, c’est que la performance d’une plateforme s’entend en trois dimensions,
dont l’importance est variable suivant le cas d’usage. Il y a bien sûr la
dimension la plus évidente : la capacité. Puis il faut considérer la bande
passante atteignable, exprimée en méga/giga/téra bits par seconde. La bande
passante est importante lorsque l’Object Storage sert en frontal des données
comme de la vidéo, ou des données destinées à être explorées par des
algorithmes de machine learning ou d’intelligence artificielle. Enfin, il faut
tenir compte d’une troisième dimension : la latence, c’est-à-dire le temps
d’accès au premier octet. Dans le cas du stockage d’e-mail – de nombreux petits
fichiers qu’il faut pouvoir afficher à l’utilisateur quasi instantanément –
c’est un critère essentiel. Aussi, contrairement aux promesses marketing, il
est rare qu’une solution soit performante sur ces trois dimensions à la fois.
Mais bien souvent, le temps de s’en rendre compte, il est déjà trop tard !
Agnosticité hardware : je t’aime, moi non plus
L’une des idées fondamentales de l’Object Storage, qui est par nature un software-defined storage (SDS), est de casser le lien entre le hardware et le software de stockage, qui existait avec les NAS et SAN dont les couches matérielles et logicielles sont indissociables. L’objectif de cette séparation : baisser le coût des plateformes, en offrant la possibilité de recourir à des serveurs standards (de type "commodity"). Or, que voit-on sur le marché de l’Object Storage ? Certains retournent à l’appliance, c’est-à-dire l’association entre un matériel spécifique et sa couche software de pilotage. Un choix de conception qui s’explique par la facilité qu’elle offre au développeur de la solution, qui n’a pas à gérer dans son design la possibilité de gérer un parc hardware hétérogène, en termes de caractéristiques techniques, de puissance et de capacité, avec toutes les contraintes que cela peut représenter, y compris au moment du déploiement. En dehors du coût des appliances, cette entorse faite aux principes initiaux de l’Object Storage hypothèque la possibilité de profiter rapidement des évolutions technologiques hardware. Or, une plateforme de stockage est mise en place pour une durée moyenne de 5 à 7 ans, période pendant laquelle se succèderont au minimum 2 ou 3 générations de matériel. Mieux vaut donc pouvoir les faire cohabiter efficacement que de devoir tout migrer à chaque évolution.
La réduction des coûts (TCO) : peut mieux faire !
Au premier abord, n’importe quelle solution d’Object Storage fait chuter les coûts de stockage des données, en comparaison des technologies précédentes. Ceci dit, alors que les usages de la donnée ont tendance à s’intensifier, les modèles économiques pay as you go, où le coût est fonction à la fois du volume de données de stockées et de l’accès aux données (facturation suivant la consommation de bande passante et le volume de requêtes) s’avèrent pénalisant. Sans parler du fait qu’une migration des données est rendue chaque jour plus difficile par le coût exponentiel d’un éventuel rapatriement des données… Bref, le modèle du public cloud storage, aujourd’hui dominant, est séduisant pour un directeur financier, heureux de voir les Opex se substituer aux Capex. Mais le directeur technique ne manquera pas de voir le piège se refermer sur lui.
L’idée n’est évidemment pas de jeter le bébé avec l’eau du bain : l’Object Storage constitue une véritable rupture technologique, malgré quelques déconvenues imputables à des choix d’implémentation, des limites technologiques ou des stratégies commerciales. Retenez simplement que si, pour mieux les comparer, on positionnait les solutions du marché sur un diagramme de Kiviat (diagramme en toile d’araignée), peu de technologies d’Object Storage couvriraient l’ensemble du spectre des critères évoqués de manière satisfaisante. Chaque acteur a tracé sa voie, tournant parfois irréversiblement le dos à certaines promesses de l’Object Storage. Pour ceux, comme nous, qui essaient de rester fidèles aux principes fondateurs, le chantier n’est pas achevé. Sur l’ergonomie, la simplicité de déploiement et d’administration, la rétrocompatibilité avec les applications codées pour du file system, il y a encore des progrès à accomplir pour faciliter l’adoption de l’Object Storage. Les effets de mode technologiques sont éphémères. Les défis posés par le stockage de données ne sont, quant à eux, pas près de disparaître : ni la virtualisation ni la containerisation – les deux tendances lourdes de l’IT – ne pourront tout résoudre. Plus de 20 ans après son invention, le concept de l’Object Storage est encore plein d’avenir.