La question de l’utilisation de Cloud Hybride - ou utilisation de services Cloud en parallèle de l’utilisation de datacenters traditionnels - relève des grandes questions actuelles des organisations tant le Cloud a modifié le paysage des systèmes d’informations.
Si les potentialités d’une telle infrastructure sont prometteuses (stockage et traitements virtuellement illimités, provisioning et facturation à la demande, services managés à très haute valeur ajoutée), la cohabitation des deux types d'infrastructures est loin d’être triviale, les approches étant fondamentalement différentes entre les deux mondes.
Mis à part les organisations récentes qui ont bâti leur SI exclusivement sur le Cloud, la majorité des organisations sont à ce jour dans un processus de migration de tout ou partie de ses traitements vers le Cloud. Cette migration peut être très avancée ou au contraire dans une phase exploratoire. Elle peut être voulue complète (plus de gestion d’un datacenter propriétaire) ou partielle (certains traitements et certaines données restent On Premise, d’autres sont déployés sur le Cloud).
Quoi qu’il en soit, sur le chemin vers le Cloud, se pose nécessairement la question du phasage de la migration des applications et des données, qui peut être un processus relativement long pendant lequel les opérations doivent bien souvent rester disponibles. Il s’agit là d’une phase peut-être transitoire, mais néanmoins cruciale pour la transformation du SI.
En définitive, pour toutes les organisations qui migrent vers le Cloud, il existe nécessairement une phase durant laquelle l’organisation doit opérer ses traitements pour partie dans ses datacenters propriétaires, et pour partie dans le Cloud.
Or, il s’agit généralement d’architectures très différentes qui apportent des changements de perspectives sur les domaines techniques, mais également sur le métier lui-même et l’organisation des équipes et les processus internes.
Le tableau ci-dessous donne quelques exemples de changements majeurs :
| Axe d’analyse | On Premise | Cloud |
|---|---|---|
| Capacité / coûts | Prévisible | Élastique |
| Mode de gestion | Projet | Produit |
| Sécurité / Compliance | Contrôle | Transparence |
| Livraison | Fonctionnalités par lots | Évolution continue |
| Résilience | Redondance | Automatisation |
Tirer parti du Cloud et de ses promesses (scalabilité, performance, automatisation, facturation à la demande, réduction des coûts) nécessite un changement en profondeur dans l’organisation, au risque d’utiliser le Cloud comme un simple datacenter supplémentaire.
Quelle que soit la répartition et le découpage des traitements et des données (Cloud / On Premise) le cloud hybride possède, dans la grande majorité des cas, une connexion réseau entre les applications “internes” et les applications hébergées dans le Cloud. Elle peut être de plusieurs types : ligne dédiée (ex: MPLS), VPN sur l’internet, connexion directe sur Internet, ou encore une combinaison de ces types.
Chaque solution a ses avantages et ses inconvénients propres en termes de coût, sécurité, résilience, latence, bande passante… Le choix de cette technologie dépendra de la stratégie de l’organisation, de la nature et de la sensibilité des données échangées ainsi que des besoins de résilience.
Quel que soit le type de connexion, il serait illusoire de considérer que ce lien réseau sera idéal (sécurisé, toujours actif, avec une latence faible et bande passante illimitée).
En parallèle des différentes altérations possibles de la connectivité, les fournisseurs de Cloud publics intègrent la facturation de la bande passante consommée. Il est donc important de limiter la quantité de données transférées, et surtout de découpler les traitements (pas de dépendance synchrone par exemple) entre le Cloud et les infrastructures propriétaires.
Pour pouvoir tirer parti des infrastructures Cloud (scalabilité, haute disponibilité, résilience, performance, élasticité, utilisation de services managés, tolérance à la panne), les applications doivent être conçues et réalisées avec des pratiques de développement Cloud Native, dont les 12 facteurs sont un bon point de départ. Les applications existantes devront vraisemblablement être modifiées pour être portées sur le Cloud, et il est important de noter que cela n'altère pas leur capacité à être déployées sur les infrastructures propriétaires.
Par ailleurs, une application déjà basée sur une architecture de type Clean Architecture - qui permet une adhérence contrôlée à l'infrastructure sous-jacente -, un code de qualité et l'utilisation de technologies open source facilitent sa migration vers la Cloud.
La distinction entre Propriétaire et Cloud impose le choix de l’infrastructure cible pour les différents types de traitements du système d’informations. Ce choix peut être fait au cas par cas, mais il est préférable d’adopter une stratégie de ségrégation au travers de laquelle la stratégie Cloud de l’organisation pourra être mise en place.
La liste suivante donne des exemples de politiques de ségrégation rencontrées fréquemment :
| Critère | On Premise | Cloud | Commentaire |
|---|---|---|---|
| Génération | Application legacy | Nouvelles applications | Modèle “Cloud First”, facilite l’adoption mais ne permet pas à lui seul la migration vers le Cloud |
| Confidentialité de la donnée | Sensible | Publique | Protection de la donnée et conformité aux exigences réglementaires. Difficulté à conserver l’étanchéité des traitements |
| Criticité du traitement | Critique | Non Critique, expérimentation | Permet l’adoption du Cloud en évitant les risques, mais ne permet pas de tirer parti de tous les bénéfices du Cloud |
| Cycle de vie | Production | Développement | Difficulté à aligner les environnements techniques et les pratiques |
| Opérations | Fonctionnement nominal | Pic de charge, Plan de continuité d’activité, Backup | Nécessite une adaptation des applications propre à les exécuter les les deux types d’infrastructure |
| Tier | Back-end | Front-end | Permet de maximiser la disponibilité et les performances face à l’utilisateur final tout en minimisant l’impact sur l’architecture. Pas toujours possible, et nécessite une attention particulière sur le volume de données échangées |
Ces modes de ségrégations ne sont pas mutuellement exclusifs, et l’adoption d’une ligne directrice claire permettra de limiter la complexité de conception et de mise en œuvre, et ainsi d’en limiter les risques.
Les technologies et pratiques étant différentes entre les infrastructures on premise et le Cloud, l’organisation et la gouvernance des systèmes d’informations devra évoluer pour prendre en compte cette double contrainte de fonctionnement de l’existant et d’opérations des traitements dans le Cloud.
La mise en œuvre du Cloud requiert des compétences dont les organisations ne sont pas toujours dotées. Un plan de formation et de recrutement adapté permet le développement de ces compétences en interne. En fonction des profils présents dans l’organisation, il est souvent préférable de faire appel à une expertise externe pour le recrutement comme pour la formation, tant les compétences requises sont pointues et spécifiques.
La création d’une équipe experte dédiée au Cloud est souvent une manière de démarrer l’adoption du Cloud. Pour diffuser les pratiques au sein de l'organisation cette équipe devra évoluer vers un accélérateur des autres équipes (formation, accompagnement) plutôt que vers une instance de validation qui serait un goulet d’étranglement.
Le succès de la mise en place d’une stratégie de Cloud Hybride réside beaucoup dans la capacité à adapter les modes de gouvernance des architectures traditionnelles pour les rendre compatibles avec les changements de paradigme profonds du Cloud.
Par exemple, le provisioning des machines virtuelles ne peut plus être soumis à une procédure manuelle (validation de la demande, création, …) car cela irait en opposition avec l’aspect nécessairement “On Demand” du Cloud.
La difficulté réside donc dans la capacité à adapter pour le cloud les règles de gouvernance de l’organisation tout en gardant une cohérence de management entre le Cloud et le propriétaire.
Le maintien en conditions opérationnelles de deux types d’infrastructures en parallèle est en lui-même une difficulté majeure : les rôles des opérationnels, l’administration des plateformes, l’hétérogénéité des métriques et outils rendent ces tâches lourdes.
La mise en place généralisée de pratiques de conception, développement, d’opérations et de déploiement automatisés (Agile, DevOps) permet de réduire la fracture entre ces deux typologies d’infrastructure, et facilite à la fois les opérations et l’adoption du Cloud.
Certaines technologies promettent également une gestion unifiée de tout type de déploiement, On Premise ou Cloud, sur des plateformes de type CaaS (Container as a Service). En l'occurrence, Anthos, l’offre de GCP, permet la gestion de cluster Kubernetes quel que soit l’infrastructure sous-jacente.
Si le consensus s’établit aujourd’hui autour du container (Docker en particulier) pour la construction et le déploiement d’applications, la marche est haute pour les organisations entre la gestion de VMs et l’orchestration de containers, quoique les fournisseurs d’infrastructures virtualisées facilitent de plus en plus cette transition au sein de leur écosystème. L’utilisation de ces technologies est sans doute une bonne cible pour une stratégie qui viserait la cohabitation long terme d’architectures propriétaires et Cloud, mais probablement pas le premier pas dans cette direction.
Le Cloud Hybride est bien souvent un fait accompli avant d’être une cible stratégique de l’organisation. Le succès de sa mise en place repose sur la mesure des différences profondes du Cloud par rapport aux infrastructures traditionnelles.
Ces différences nécessitent des changements importants dans l’organisation: