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

sent des services et des fonctionnalités qui se chevauchent dans une large mesure, leurs presta-
tions sont très loin d’être identiques. Pour quel 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éfinition, au choix du plus petit dénominateur commun quant aux fonctionnalités partagées par
les deux fournisseurs de cloud. Là encore, cela débouche sur une pénalité en termes d’agilité. En
effet, lorsque l’on envisage les nouvelles fonctionnalités et les nouveaux services des fournis-
seurs 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éparte-
ments distincts, du fait d’acquisitions ou de l’existence de niveaux d’autonomie élevés entre plu-
sieurs 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é. Microsoft 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 Microsoft 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 pra-
tique. S’il offre incontestablement certains avantages du point de vue du cloud (OpEx/CapEx,
évolutivité et 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 sur un doublon entre deux environnements.
Disponibilité des fonctionnalités (« Meilleur de sa catégorie »)
Bien que les approches multi-cloud soient devenues assez fréquentes aujourd’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 prometteuse 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’insistance sur une duplication de toutes les fonctionnalités entre les deux environnements,
coûte au final davantage à l’entreprise que la stabilité théoriquement 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 tirer parti des meilleurs services et fonctionnalités de leur catégorie.
Une bonne vision de cette recherche des meilleurs éléments implique la sélection d’un fournis-
seur de cloud principal. Ce fournisseur aura le rôle de centre de gravité pour les opérations dans
le cloud, et fédérera toutes les fonctions d’identité et de sécurité primaires. Il est bien entendu
plus simple d’exploiter les nouveaux services et fonctionnalités proposés par le fournisseur prin-
cipal, mais l’entreprise doit aussi se ménager explicitement la possibilité de solliciter un autre
14 | THE DOPPLER | ÉDITION SPÉCIALE 2019