Selon une enquête récente de Virtana Research, 82 % des personnes interrogées utilisent désormais une technique multicloud. Plus des trois quarts (78 %) déploient leur travail sur plus de trois fournisseurs de cloud public. 59 % exécutent la majorité de leurs charges de travail sur un cloud public faisant partie d’un déploiement multicloud. L’enquête a révélé que 51 % prévoient également d’augmenter le nombre d’instances de cloud public qu’ils prennent en charge en 2022. Beaucoup plus fascinant, 34 % envisagent d’utiliser cinq plates-formes cloud ou plus.
Nous avons gardé un œil sur le point d’inflexion multicloud depuis plus de quatre ans, donc je ne pense pas que beaucoup de résultats de ces études surprennent qui que ce soit. Ce que j’ai trouvé intéressant, c’est que 63 % des personnes interrogées ont déclaré que leur entreprise s’appuie sur au moins 5 outils différents pour la migration, l’optimisation des coûts du cloud, la surveillance intégrée de l’efficacité, la gestion des performances des applications et le suivi de l’infrastructure cloud. Une grande partie (83 %) déclare consolider manuellement les données de tous ces outils, éventuellement en utilisant des bases de données distinctes ou même des feuilles de calcul. Beaucoup utilisent ces outils isolément les uns des autres. Seuls 17 % affirment disposer d’une intégration automatisée des informations de leurs outils.
Je ne suis pas un grand fan des informations fournies par des sociétés d’études de recherche pour plus d’une seule phrase dans un court article, mais je pensais que les informations ici était suffisamment intrigant pour justifier une exception. Au départ, cela montre la vérité que la complexité multicloud est un véritable problème. Deuxièmement, cela renforce la nécessité d’accorder une attention particulière à l’introduction de la complexité de la migration avant, pendant et après les versions multicloud. Il illustre l’absence de combinaison d’outils opérationnels. Quelques problèmes de complexité opérationnelle sont résolus si nous libérons des outils dans des silos ; ils généreront simplement plus de coûts et de dangers.
Voici ce que je veux dire alors que je sonne une autre alarme de complexité multicloud : vous pouvez éviter toute complexité inutile et assurer le succès avec une planification supplémentaire avant un déploiement multicloud.
Considérez ces trois points :
Vous ne gérez pas la complexité architecturale en rendant les choses plus complexes. Si vous sélectionnez des outils particuliers qui ne traitent qu’avec un seul public entreprise cloud, la complexité s’aggrave. Si vous ne pouvez pas découvrir une option cross-cloud pour les exigences fonctionnelles typiques telles que la gestion de la sécurité, l’observabilité des performances, l’orchestration des procédures et le suivi et la gestion des informations, pour n’en nommer que quelques-unes, attendez la mise en œuvre jusqu’à ce que vous puissiez découvrir une option cross-cloud pour résoudre ces problèmes.
Lorsque les entreprises déclarent qu' »il n’y a pas d’options inter-cloud » pour certaines procédures fonctionnelles, mon expérience est qu’elles ne recherchent pas aux endroits idéaux, ou qu’elles peuvent avoir un parti pris contre outils et technologies auxquels ils pensent « hors marque ». Une partie du service consiste à ouvrir votre esprit à de nouvelles approches qui peuvent être un peu effrayantes mais qui fonctionnent.
Vous ne pouvez pas améliorer le fonctionnement des systèmes dans un multicloud s’ils sont actuellement un gâchis architectural. Trash in, garbage out– le vieil adage s’applique toujours. Si vous avez des systèmes mal développés dans le centre de données de l’entreprise, ne vous attendez pas à ce qu’un prodige se produise lorsque vous les déplacez vers un cloud public. Vous devrez résoudre les problèmes avant ou pendant la migration, sinon vos problèmes fonctionnels seront exactement les mêmes ou même pires.
Le point le plus essentiel est de concevoir et de planifier comment exécuter votre multicloud dans l’abstrait, puis d’établir une solution sensée qui répond aux exigences opérationnelles de tous les systèmes qui existeront dans le multicloud. Cela signifie généralement que les systèmes hérités, les clouds personnels, l’informatique de pointe et plusieurs clouds publics seront dans le mélange. Ensuite, utilisez cette structure pour choisir la meilleure permettant à l’innovation d’automatiser la plupart des opérations multicloud.
Comprenez que les outils évoluent avec le temps. Certains seront éliminés ou remplacés. Il est donc deux fois plus important de spécifier le besoin que l’outil va combler dans le cadre de notre architecture d’exploitation rationnelle plutôt que de se concentrer sur l’outil lui-même. Ceux qui choisissent d’abord les outils échouent généralement. Ou pire encore, ils continuent avec un service sous-optimisé qui finit par saigner l’entreprise à sec en dépenses fonctionnelles évitables.
Un plan complet est essentiel au succès de tout travail. Pour prospérer avec le multicloud, la stratégie du projet nécessitera beaucoup de travail, de planification et de réflexion. Si un déploiement multicloud se profile à l’horizon, il est temps de vous lancer dans ce plan. Si vous avez déjà des versions multicloud dans votre rétroviseur, il est temps d’effectuer des audits.
Toute l’actualité en temps réel, est sur L’Entrepreneur
