N'adoptez pas une mentalité héritée du passé au multicloud

Le Cloud existe depuis 15 ans et il semble que beaucoup d’entre nous soient encore en train de « migrer » vers celui-ci. Plutôt qu’un simple transfert ponctuel, le déploiement vers le cloud est devenu une autre option dans le cycle de vie du déploiement des applications, et les applications évoluent pour mieux utiliser les ressources en étant « cloud-natives ». Alors que les organisations adoptent de plus en plus de clouds multiples et multi-cloud, il est important de se demander quels autres aspects doivent également changer dans le domaine des applications et des opérations. Voici quelques conseils à prendre en compte lors du déploiement, notamment sur ce qu’il faut éviter…

N’appliquez pas un processus lent à un système agile

La complexité des opérations informatiques et des centres de données modernes dépend en grande partie de la gestion de projets et de processus pour suivre les compétences et les étapes requises pour que les déploiements et les changements se déroulent en douceur. Le déploiement d’un nouveau service comme une base de données nécessite une installation physique, une configuration du réseau, une configuration de application et un audit de sécurité, souvent de la part d’équipes différentes. En fonction du retard de chaque équipe, la configuration d’un serveur pouvait facilement prendre deux semaines, mais le processus était un moyen efficace de garantir que chaque étape était exécutée correctement et d’éviter les conflits.

Avec le cloud, toutes ces étapes peuvent potentiellement être exécutées automatiquement, simultanément, presque instantanément et, surtout, sans interruption. Lorsque l'agilité est essentielle, comme lors du développement ou dans un pipeline de déploiement CI/CD mature, un processus fiable peut être remplacé par un code fiable attaché à un processus léger. Lorsqu’il fallait du temps et des compétences pour réaliser une action complexe, il était logique de planifier, de mesurer et de répartir. Pour le cloud, une opération peut être effectuée rapidement avec des conséquences limitées. La planification et le suivi doivent donc être ajustés afin de ne pas nécessiter plus de ressources que l’opération elle-même.

N’intégrez pas d’anciennes techniques de gestion dans les nouvelles technologies

Un autre concept hérité du passé est celui des silos verticaux de compétences. Dans les réseaux locaux (LAN), il peut être judicieux de disposer d’équipes distinctes pour la mise en réseau et la sécurité. Pour des raisons techniques et historiques, le réseau fournit l’accès, puis la sécurité le restreint. Cette séparation est profondément ancrée dans l'informatique, chaque discipline disposant de son propre matériel spécialisé, de sa propre surveillance et souvent même de centres d'opérations distincts (NOC vs. (SOC).

À l'intérieur des clouds, la mise en réseau est étroitement liée à la sécurité de chaque point de terminaison, avec une valeur par défaut d'absence d'accès pour la plupart des services. Bien qu’il existe des constructions dans les clouds pour simuler le comportement des réseaux locaux existants, l’effet principal est de supprimer la sécurité entre les nœuds. Ce manque de sécurité doit ensuite être corrigé, souvent en installant une édition virtuelle d’un pare-feu tiers, exactement comme les réseaux locaux. En revanche, l’orchestration cloud native peut mettre en œuvre des politiques de sécurité dynamiques par charge de travail, créant automatiquement une micro-segmentation pour autoriser tout le trafic nécessaire et bloquer tout le reste, sécurisant ainsi étroitement le réseau.

Ne traitez pas le cloud comme un centre de données

Si les organisations traitent le cloud comme l’informatique du monde physique, avec des pratiques héritées, elles recréeront les inconvénients hérités associés. Les silos entre les fonctions informatiques entraînent des retards de processus et des problèmes de communication, plutôt que l'agilité des charges de travail orchestrées. La séparation entre le réseau et la sécurité réintroduit la possibilité héritée d’un écart de couverture (un endroit où il y a du réseau mais pas de sécurité externe) et les politiques de type hérité basées sur la localisation ignorent les avantages basés sur l’identité d’un modèle de confiance zéro . Aucun de ces problèmes n’existe nativement dans le cloud.

N’abordez pas les connexions au cloud et aux réseaux traditionnels de la même manière

Dans la perspective du multicloud, un autre aspect des pratiques informatiques et opérationnelles actuelles devra changer : un changement de perspective passant de la « connexion des utilisateurs au cloud » à la « connexion des applications entre les clouds ». La plupart des produits actuels de réseau d'accès au cloud sont dérivés d'une technologie permettant de connecter une succursale à une autre, réappliquée avec le cloud comme destination. Cependant, les clients nous ont indiqué qu'ils ont rencontré des problèmes lorsqu'ils ont essayé d'utiliser des solutions simples basées sur IP de couche 3 pour connecter des clouds, notamment des problèmes de connectivité tels que le chevauchement d'IP et des problèmes de sécurité tels que la perte de métadonnées d'identité natives en transit. Il s’agit de problèmes fondamentaux qui ne peuvent pas être résolus en analysant le trafic de couche 3 pour obtenir la meilleure « détection d’application ». La mise en réseau multicloud nécessite une approche cloud native : orchestration de la mise en réseau et de la sécurité entre les clouds.

Si vous recherchez une solution, F5 Volterra est une solution multi-cloud pour orchestrer la mise en réseau, la sécurité et la distribution application sur les clouds publics et privés. Vous pouvez l'essayer aujourd'hui en allant sur : Tarifs | Volterra