Cloud hybride : à quoi sert-il vraiment ?
Cet article fait le point sur tout ce qu’il faut savoir sur le cloud hybride, sa définition, ses cas d’usage, ses pièges à éviter et ses perspectives.
Le cloud hybride fait miroiter une double promesse : d’une part la flexibilité, l’évolutivité et la maîtrise des coûts d’une infrastructure cloud public et, d’autre part, les performances, le contrôle et la sécurité de systèmes informatiques internes. En pratique, il s’agit souvent d’un compromis dicté par la nécessaire prise en charge de différents processus métiers, cas d’usage, obligations légales, compétences informatiques et budgets.
Aux États-Unis, le National Institute of Standards and Technology (NIST) définit le cloud hybride comme une infrastructure cloud composée d’au moins deux infrastructures cloud distinctes de type privé, public ou mutualisé qui, bien qu’indépendantes, sont reliées par une technologie propriétaire ou normalisée assurant la portabilité des applications et des données.
En d’autres termes, peu d’entreprises utilisatrices du cloud auront recours à un seul et unique fournisseur. En fait, elles utiliseront sans doute diverses variantes alliant infrastructure cloud et applications à la demande (SaaS).
Même si la définition du NIST n’est pas explicite sur ce point, le cloud hybride comprend vraisemblablement une part de technologie sur site. C’est en ce sens qu’AWS et Azure proposent les infrastructures hyperconvergées AWS Outposts et Azure Stack, à installer sur site pour faire le pont entre un datacenter local et leurs services en ligne.
De grands acteurs comme IBM et NetApp incluent explicitement l’informatique sur site dans leur offre de cloud hybride. Selon le premier, ce type de cloud « combine et unifie le cloud public, le cloud privé et l’infrastructure sur site pour créer une même infrastructure IT flexible, aux coûts maîtrisés ».
Pour le second, c’est « un environnement pluriel de ressources informatiques, de stockage et de services composé d’une infrastructure sur site, d’un cloud public et de services cloud privés ». Grant Caley, directeur technique de NetApp pour le Royaume-Uni et l’Irlande, apporte une précision supplémentaire : dans un véritable cloud hybride, une application exploite des composants sur site et dans le cloud.
Les usages du cloud hybride
Le grand atout du cloud hybride est le surcroît d’agilité ou d’évolutivité qu’il apporte aux processus IT existants. Quand une application fonctionne aussi bien dans le cloud que sur site, il est inutile d’y ajouter la complexité d’une solution hybride. Les entreprises recourent plutôt au cloud hybride pour étendre et flexibiliser les applications existantes, ou pour moderniser leurs interfaces sans pour autant les transférer totalement dans le cloud.
On pense par exemple à une application dont la partie base de données s’exécute en local pour des raisons de performances, de sécurité et de réglementation, tandis que l’interface avec les clients côté web s’exécute dans le cloud.
Les entreprises adoptent aussi le cloud hybride pour connecter des applications cloud à leur IT historique. L’utilisation d’applications à la demande, Office 365, Salesforce ou autre, en parallèle aux systèmes historiques sur site, se répand : le cloud hybride devient de facto le mode par défaut.
Aujourd’hui, le cloud hybride sert en premier lieu à assurer la continuité de l’activité et la reprise après désastre, via la réplication en cloud des données importantes et des systèmes sur site.
Le modèle est relativement simple à mettre en place. Une entreprise peut fermer un datacenter secondaire et transférer sa charge de travail dans le cloud, tout en conservant sur site son système de production. Là où un second site classique de reprise après désastre s’avérait trop onéreux, le cloud hybride permet de mettre en place un basculement actif-passif à moindre coût.
Le cloud hybride sert aussi à moderniser les applications et à prolonger l’utilisation des anciens systèmes. Toutefois, les responsables informatiques constatent que certaines applications ne migreront jamais dans le cloud, à cause de leur architecture ou parce que la raison économique n’est pas justifiée ; en l’occurrence on pense aux applications qui arrivent en fin de vie ou qui ne servent qu’à peu d’utilisateurs. Dans ces cas-là, les entreprises vont développer des applications ou des interfaces web dans le cloud public pour se connecter à leurs systèmes de données, par exemple leur progiciel de gestion intégré (ERP).
Certaines entreprises sont passées à ce modèle pendant les confinements, pour connecter sans trop d’effort les télétravailleurs aux systèmes sur site via un réseau privé virtuel (VPN). Citons aussi les cas d’usage où, par sécurité ou obligation légale, les entreprises gardent les données principales en interne et utilisent le cloud pour l’évolutivité. D’autres fois, il s’agit de porter dans le cloud des données de l’entreprise pour les soumettre à des analyses, à des processus décisionnels, voire au Machine learning et à l’intelligence artificielle.
Les pièges de l’architecture cloud hybride
Le tout premier piège du cloud hybride réside dans sa complexité. Les entreprises doivent gérer deux infrastructures informatiques, éventuellement avec plusieurs fournisseurs de cloud, la partie sur site exigeant des locaux physiques ou un espace dans un datacenter en co-localisation.
Sauf à traiter le cloud et les ressources locales comme des blocs technologiques différents exécutant des applications distinctes, les logiciels devront être conçus pour fonctionner dans plusieurs environnements, ce qui implique d’adapter la couche applicative, mais aussi la couche du système d’exploitation et du système de fichiers ou de stockage. Chaque composant doit pouvoir prendre en compte le déplacement des charges de travail et des données vers et depuis le cloud.
Et la fiabilité de la bande passante est essentielle. Mais même avec un bon débit, l’approche hybride ne conviendra pas aux applications qui exigent une latence faible. Enfin, malgré les indéniables atouts des options hybrides ou multicloud en termes de redondance, les DSI n’en oublieront pas pour autant les inconvénients, à savoir la gestion des différents contrats fournisseurs et la multiplicité des outils de gestion système.
Pour savoir si une charge de travail convient au cloud hybride, on peut s’intéresser à la force de gravité des données. Si le datastore principal d’une application est sur site, la meilleure solution sera sur site ou hybride.
Si les données résident surtout dans le cloud, par exemple dans les applications riches en contenus et médias, d’e-commerce ou d’objets connectés (IoT), l’approche cloud-first est à privilégier. Pour les applications nécessitant un contrôle strict des risques ou des performances, une solution 100 % sur site ou tout en cloud est souvent préférable.
Et ensuite ?
Les approches hybrides ou multicloud devraient prendre de l’importance, notamment parce que le risque de dépendance envers un fournisseur n’est pas moindre dans le cloud qu’avec les technologies sur site.
Les DSI et les éditeurs d’applications ont par conséquent segmenté les logiciels et les charges de travail pour faciliter leur portage entre différents clouds, mais aussi entre un cloud et une architecture sur site.
Parmi ces stratégies, notons le déplacement d’un jeu entier d’applications d’un environnement à l’autre, ou l’allocation instantanée d’un surcroît de capacité dans le cloud, pour booster les performances ou traiter un pic de demandes.
Les conteneurs et autres architectures en microservices le permettent, ainsi que les solutions matérielles sur site des fournisseurs de cloud. L’important est de s’assurer de la portabilité et de la sécurité des données, un chantier toujours en cours à ce jour.