On pourrait penser que le multicloud n’est pas si compliqué à mettre en œuvre et qu’il s'agit simplement de déployer et de gérer un peu plus qu'un cloud public. Mais malheureusement, ce n’est pas le cas. Alors que de plus en plus d'entreprises déploient des architectures multicloud, elles reproduisent encore et encore les mêmes erreurs. En particulier celles-ci, que vous pouvez peut-être éviter.
Première erreur : concevoir et construire un multicloud en pensant CloudOps.
De nombreuses entreprises déploient deux ou trois clouds publics - parfois plus - sans avoir une idée précise de ce qu’implique la gestion à long terme d’une architecture multicloud. Quand un déploiement multicloud passe en production, un grand nombre de services clouds deviennent redondants (notamment le stockage et le calcul), un phénomène lié à l'exploitation préalable de plusieurs clouds publics. Sauf que tout cela devient trop lourd à gérer pour l'équipe chargée des clouds. Ces derniers sont dans l’incapacité de rendre tous ces services hétérogènes opérationnels comme ils le devraient, et la qualité du service en souffre. Le déploiement est également beaucoup trop risqué en termes de sécurité et de gouvernance. Plusieurs moyens permettent d'éviter cela. D’abord, ne vous lancez pas dans le multicloud si vous n'êtes pas en mesure d’en assurer les besoins opérationnels et limitez-vous à des déploiements de clouds uniques. Car cela pourrait vous priver des meilleurs services et réduirait la valeur d’usage du cloud. Une seconde approche, la plus appropriée, consiste aussi à automatiser pratiquement tout et à exploiter les abstractions (à partir d’un point unique) pour gérer la complexité, tout en bénéficiant des meilleurs avantages.
Deuxième erreur : opter pour tout ce qui est « natif du cloud ».
Gardez à l'esprit que les outils qui recouvrent les clouds publics sont les plus utiles. Ils permettent d’utiliser les mêmes interfaces et les mêmes automatismes d'un cloud à l'autre dans votre multicloud. Cela semble être un choix évident, mais de nombreuses entreprises qui passent d'un cloud unique à un cloud multiple conservent les outils natifs fournis avec tel cloud public en particulier, notamment les outils de sécurité et d'exploitation. Les entreprises qui décident de conserver des outils de gestion et de surveillance spécifiques pour AWS, Microsoft ou Google devront apprendre et exploiter un outil par cloud public. Ce qui n’est pas très efficace. On peut comprendre facilement comment éviter ce problème, mais il est plus difficile d’appliquer la bonne méthode. Même si les applications natives du cloud sont très bien en elles-mêmes, ce n’est tout simplement pas une bonne idée d’utiliser uniquement des outils natifs pour toutes sortes de tâches de gestion et de sécurité.
D’une part, il faudra disposer de personnes qui comprennent chaque outil. Ensuite, il n'y aura pas de communication ni de coordination entre les clouds. Et enfin, l'automatisation devra se faire à plusieurs endroits au lieu d'un seul. La solution consiste à rechercher des outils pouvant couvrir tous les clouds et comportant des interfaces cohérentes entre clouds. Le multicloud est une science en constante évolution. Les fournisseurs de clouds publics ne délivrent ni bons conseils, ni bons outils, parce que ce n'est pas dans leur intérêt de pousser leurs clients vers le multicloud. Cependant, s'ils essaient de vous faire adopter un modèle de conception qui accroît votre complexité, vos coûts et vos risques, un conseil : évitez de les suivre.