The Doppler Quarterly (FRANÇAIS) Hiver 2018 | Page 50

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 com-
mun. Par défi nition, si le but consiste à exploiter des environnements en dou-
blon, toutes les capacités invoquées doivent être présentes dans ces deux envi-
ronnements. À l’évidence, si les trois principaux fournisseurs de cloud proposent
des services et des fonctionnalités qui se chevauchent dans une large mesure,
leurs prestations sont très loin d’être identiques. Le résultat ? C’est que toute
mise en œuvre intégrale d’une approche multi-cloud visant à ne pas mettre ses
œufs dans le même panier se limite, par défi nition, au choix du plus petit
dénominateur commun quant aux fonctionnalités partagées par les deux four-
nisseurs de cloud. Là encore, cela débouche sur une pénalité en termes d’agil-
ité. En effet, lorsque l’on envisage les nouvelles fonctionnalités et les nouveaux
services des fournisseurs de cloud, il est nécessaire d’attendre que ces deux
fournisseurs offrent simultanément cette fonctionnalité ou ce service avant
qu’il ne soit possible de les exploiter dans cette forme d’implémentation
multi-cloud.
Similitudes architecturales (ou «|proximité comparable|»)
Il n’est pas rare de trouver différentes piles de technologies dans des divisions
ou des départements distincts, du fait d’acquisitions ou de l’existence de
niveaux d’autonomie élevés entre plusieurs groupes. Il se peut qu’une division
soit fortement dépendante de l’écosystème Microsoft avec SQL Server, .NET et
C#, alors qu’une autre exploite historiquement des technologies Linux, Java et
Open Source. On assiste parfois à des situations dans lesquelles des services
individuels sont amenés à déployer des charges de travail dans le cloud public
pour des raisons de facilité de migration vers un cloud public donné. Azure
propose notamment cette facilité de migration pour les charges de travail liées
à Microsoft. Il est donc fréquent qu’un département ou un groupe choisisse
Azure en tant que cloud public attitré pour ce motif, alors qu’un autre service
optera plutôt pour AWS.
Il est important de préciser que ce modèle est généralement contraire aux
règles de bonne pratique. S’il offre incontestablement certains avantages du
point de vue du cloud (OpEx/CapEx, évolutivité et d’agilité), il génère deux
empreintes de cloud public distinctes, voire davantage, ce qui ajoute encore à
la complexité opérationnelle et restreint les possibilités de parvenir à une
vision cohérente des coûts. Cela débouche, en dernier lieu, sur un doublon
entre deux environnements.
Disponibilité des fonctionnalités («|Best-of-Breed|»)
Bien que les approches multi-cloud soient devenues assez fréquentes aujo-
urd’hui, il semble qu’un modèle différent doive être envisagé pour garantir
davantage de réussite dans l’avenir. Cette architecture multi-cloud promet-
teuse peut être considérée comme la « meilleure de sa catégorie ». Avec cette
démarche, l’état d’esprit est que le risque pour l’agilité, qui est imposé par l’in-
sistance sur une duplication de toutes les fonctionnalités entre les deux envi-
ronnements, coûte au fi nal davantage à l’entreprise que la stabilité théorique-
ment acquise en déployant deux ensembles de fonctionnalités totalement
interchangeables entre les opérateurs de cloud. Ici, le principe directeur est
que pour récolter tous les avantages du cloud, il est absolument primordial de
48 | THE DOPPLER | HIVER 2018