BLOG

La surprenante vérité sur la transformation numérique: Chaos des nuages

Miniature de Lori MacVittie
Lori MacVittie
Publié le 4 juin 2018

Il s’agit du deuxième blog d’une série sur les défis posés par la transformation numérique.

Chaos des nuages.

Un ingénieur astucieux remarque actuellement que cette phrase est redondante. Après tout, le cloud est un chaos, avec son manque de gouvernance et son approche laxiste en matière de sécurisation des applications jetées dans ses profondeurs blanches et moelleuses sans calendrier bien défini.

Arrêtons-nous ici pour noter que le chaos associé au cloud est le plus souvent un problème de personnes et de processus , et non un problème technique.

Cela ne veut pas dire qu’il n’y a pas de défis techniques – ou du moins architecturaux – associés au cloud. Certains d’entre eux sont liés aux complexités des réseaux virtuels. Mais la plupart sont d’ordre architectural. L’un de ces défis architecturaux est lié à la nature même du cloud et à son approche centrée sur chaque application.

Si vous y réfléchissez, le cloud public et son modèle de déploiement sont considérés comme la forme idéale (la « forme de cloud » comme les platoniciens pourraient l’appeler) de cloud. Cela signifie que le cloud privé doit également suivre ses préceptes et présenter les mêmes caractéristiques.

Cela signifie des API et un provisionnement en libre-service. Tableaux de bord et consoles Web. Mais cela signifie également un changement d’architecture vers un déploiement purement centré sur une seule application.  

Les architectures par application sont la norme dans le cloud. Les services sont déployés et configurés pour prendre en charge une application à la fois et créer un chemin des données singulier de l'utilisateur au point de terminaison qui traverse ces services. Cela contraste fortement avec la conception traditionnelle des réseaux de centres de données dans lesquels un nombre important d’infrastructures de services réseau et application sont partagées.

C’est la notion d’« infrastructure partagée » qui devient un défi dans un monde de développement DevOps et Agile qui est aussi axé sur les applications que le cloud public.

Les infrastructures traditionnelles et partagées et les réseaux créent « un seul véritable chemin depuis la porte jusqu’à l’application ». Les défis découlant de cette approche dans le monde numérique en évolution rapide d’aujourd’hui sont les suivants :

  • Alignement des versions d'infrastructure. Une application peut nécessiter des fonctionnalités fournies par une mise à niveau ou un correctif tandis qu'une autre dépend de la version existante. L'infrastructure partagée ne permet généralement pas la diversité des versions sur un même système et peut donc gêner une application au profit d'une autre.
  • Calendriers de déploiement conflictuels. Lorsque les ressources partagées sont impactées, les entreprises entament une phase de négociation au cours de laquelle les parties prenantes des application tentent de résoudre les conflits dans les calendriers de déploiement. Le processus peut être long (et toujours douloureux) et personne n’est gagnant lorsqu’une nouvelle application ou une mise à jour est retardée en raison de conflits de planification. 
  • Rayon d'explosion. Il va sans dire que si mon application provoque l’échec d’un système partagé, toutes les applications s’appuyant sur ce système échouent. Le rayon d’action de l’infrastructure partagée est énorme et constitue un facteur important dans la réticence à fournir un meilleur accès au pipeline de déploiement à ceux qui ne font pas partie du service informatique.
  • Dépannage. Essayer de parcourir les journaux agrégés est pénible. Les entreprises les plus prospères ont été bâties sur rien d’autre que la capacité à exploiter des journaux massifs et à désagréger les données en flux par application. Le dépannage des systèmes partagés est compliqué et prend du temps et a un impact négatif sur le temps moyen de résolution, un indicateur clé de performance critique pour l'informatique moderne.

Dans le cloud, rien de tout cela ne pose généralement de problème. Il existe un chemin par application, car les applications sont généralement déployées selon leur propre calendrier dans leur propre environnement, souvent par des équipes différentes. 

Pour préserver notre santé mentale (et notre centre de données), nous devons adopter cette approche sur site, que ce soit dans un cloud privé ou non.

Vous continuerez à bénéficier de services réseau partagés. Les pare-feu, les IPS/IDS, les attaques DDoS et l'inspection des utilisateurs sont très neutres par rapport aux applications et peuvent (et doivent) être appliqués à l'échelle de l'entreprise. Pour tout le reste, il existe des services et une infrastructure par application (spécifiques à l’application, si vous préférez). Cette séparation logique préserve la stabilité et la sécurité de l’entreprise tout en permettant un environnement plus volatil et peut-être instable plus proche des applications. Il préserve également un chemin des données pour les applications traditionnelles (héritées et héritées) qui ne nécessitent pas le type de vitesse et de support nécessaires aux applications plus récentes. Le réseau par application peut être un cloud privé, plusieurs clusters de conteneurs ou une combinaison des deux.

Le mariage des deux donnera naissance à un réseau plus stable, plus résilient, mais également plus flexible et plus rapide. 

Une approche par application du réseau présente de nombreux avantages en plus d'atténuer les problèmes découlant d'une approche partagée associée à des architectures d'applications et des modèles de distribution modernes :

  • Pipelines et calendriers individuels. Je peux planifier mes propres déploiements lorsqu’ils sont prêts, car ils n’ont d’impact sur aucune application ou infrastructure autre que la mienne. Cela offre une flexibilité pour prendre en charge les différents horaires que vous devez prendre en charge dans un centre de données moderne.
  • Rayon d'explosion restreint. Si mon déploiement provoque un crash sur mes systèmes dédiés, c'est entièrement de ma faute. Cela n’a aucun impact sur les autres applications. Cette approche de chemin des données dédié par application facilite encore davantage le dépannage, car je peux être sûr que les journaux et les messages d'erreur sur tous les systèmes m'appartiennent et appartiennent à mon application.
  • L'échelle ne se limite pas aux ressources de la plateforme. Dans un monde extrêmement instable et dynamique, il est presque impossible de savoir quand la prochaine vague de visiteurs arrivera ou si certains contenus deviendront viraux ou, Dieu nous en préserve, si vous êtes attaqué. Quelle que soit la cause, lorsque la demande d’applications sur des systèmes partagés (matériels ou logiciels) augmente, l’échelle est limitée aux ressources disponibles sur la plateforme. L’utilisation d’une architecture par application atténue cette contrainte et permet aux composants individuels d’évoluer selon les besoins pour répondre à la demande.
  • Prend en charge une véritable infrastructure en tant que modèle de code. Les systèmes partagés utilisent des configurations partagées, même s'il s'agit simplement d'une configuration de base avec des politiques par application. Ce modèle peut provoquer le chaos lors de la tentative d’implémentation d’un modèle d’infrastructure en tant que code , en particulier lorsque plusieurs applications tentent de se mettre à jour en même temps. Les modifications peuvent avoir un impact sur d'autres applications sans avertissement, ou les actions de validation et de clonage peuvent échouer en raison du verrouillage des ressources par d'autres lorsque vous en avez besoin. Une architecture par application garantit que les artefacts de déploiement appartiennent à une seule application et peuvent être gérés correctement par les propriétaires de l'application (qu'ils soient dev, DevOps, NetOps ou).


Même si une architecture par application ne résoudra pas tous les problèmes liés à la transformation numérique, elle peut contribuer grandement à maîtriser le chaos engendré par le cloud. Il offre de plus grandes opportunités de standardisation de la sécurité ainsi que de prise en charge des environnements multi-cloud que deviennent la plupart des entreprises.

Restez à l'écoute pour le prochain article de cette série, dans lequel nous verrons comment vous pouvez gérer ceux qui ignorent la sécurité en raison des pressions de mise sur le marché découlant de la transformation numérique.