The Doppler Quarterly (FRANÇAIS) Édition spéciale 2019 | Page 15

Multicloud
Ce terme semble relativement explicite : l’infrastructure de cloud est déployée par plusieurs four-
nisseurs de cloud public, avec ou sans cloud privé existant. Quoi qu’il en soit, c’est lorsque l’on se
penche sur les motivations qui poussent certaines entreprises à envisager des approches et des
architectures de cloud multiple que les choses deviennent intéressantes.
Diminution des risques (« ne pas mettre tous ses œufs dans le même
panier »)
Lorsque des organisations décident de migrer vers le cloud public, leur préoccupation habituelle
est leur perception du risque de dépendance vis-à-vis d’un prestataire externe comme Amazon,
Google ou Microsoft. Il est courant, en guise de réponse, de se questionner sur la pertinence de
réduire au minimum le risque perçu en faisant appel à plusieurs fournisseurs de cloud, auxquels
sera respectivement confiée la gestion complète d’un environnement distinct. Cette configura-
tion offre une option supplémentaire dans le cas où la relation avec un fournisseur devient inten-
able pour une raison quelconque. De plus, elle permet en théorie de maintenir l’exécution des
services en cas de défaillance de l’un des fournisseurs. Cette approche relève d’une logique
instinctive ; pourtant, quelques faits plaident également en sa défaveur.
Le premier défi est dû à la complexité causée par la gestion d’un ensemble supplémentaire d’ar-
chitectures et de relations opérationnelles pour chacun des fournisseurs. Vu que la plupart des
entreprises fonctionnent déjà dans un cloud hybride, cela fait au total trois environnements à
entretenir et à exploiter. Faire appel à plusieurs fournisseurs de cloud n’est donc pas mission
impossible, mais l’enjeu doit être bien compris. Il convient de noter que certains fournisseurs pro-
posent des produits et services tiers de grande valeur qui peuvent contribuer à fournir des
couches d’abstraction normalisées, en réduisant théoriquement au minimum la complexité de
gestion de fournisseurs de cloud multiples. Un bon exemple dans ce domaine est celui de Pivotal
Cloud Foundry, qui est notamment connu pour sa capacité à exécuter des applications dans plu-
sieurs clouds en même temps.
Mais une remarque importante ici, c’est que sitôt que vous dépendez d’un « fournisseur d’abstrac-
tion », vous recréez de fait le point de défaillance lié au fournisseur unique que vous aviez tenté
d’éviter au départ. En outre, il existe presque toujours un temps de latence entre la diffusion d’une
fonctionnalité par les fournisseurs de cloud et sa capacité de prise en charge par les fournisseurs
d’abstraction. Il en résulte une pénalité en termes d’agilité. Étant donné que l’agilité de l’entre-
prise et le délai de mise sur le marché des nouveaux produits et fonctions sont pour les organisa-
tions des motivations extrêmement importantes de migrer vers le cloud au premier chef, le
renoncement à une partie de cette agilité devient contre-productif. Enfin, puisque l’objectif est de
prendre en charge des environnements en doublon par le biais de capacités cohérentes et ce,
quel que soit le fournisseur de cloud opérant sous la couche d’abstraction, il est impératif que
chaque fournisseur de cloud possède les mêmes capacités sous-jacentes. Et c’est là que se dresse
la prochaine difficulté.
Le deuxième et plus important défi posé par l’approche de « répartition des œufs » découle de la
tendance à rechercher le plus petit dénominateur commun. Par définition, si le but consiste à
exploiter des environnements en doublon, toutes les capacités invoquées doivent être présentes
dans ces deux environnements. À l’évidence, si les trois principaux fournisseurs de cloud propo-
ÉDITION SPÉCIALE 2019 | THE DOPPLER | 13