Sommet DevOps : Où le réseau a été invité à la fête

Au DevOps Summit NY, on a beaucoup parlé non seulement de DevOps, mais aussi de conteneurs, d’IoT et de microservices. Les sessions se sont concentrées non seulement sur le changement culturel nécessaire pour croître à grande échelle avec une approche DevOps, mais ont également veillé à inclure la « plomberie » réseau nécessaire pour assurer le succès à mesure que les applications se décomposent en architectures de microservices permettant une croissance rapide et la prise en charge de l'Internet des (tous) objets.

Conteneurs et microservices et le réseau

Jerome Petazzo (@jpetazzo ) de Docker a discuté des microservices et de leur affinité naturelle avec les conteneurs, mais l'élément important de sa discussion était la nécessité du « réseau » pour une mise à l'échelle indépendante, la découverte, la résilience et la gestion de l'architecture de plus en plus dépendante du réseau résultant des microservices. En effet, le DNS joue un rôle naturel et important dans la découverte, en garantissant un niveau d'abstraction au niveau de la couche de service nécessaire pour garantir que les services ne dépendent pas des schémas d'adressage réseau, mais exploitent plutôt la capacité du DNS à mettre à jour rapidement l'emplacement réel d'un service (ou d'un point de terminaison de service, dans le cas de l'évolutivité) pour garantir une connectivité transparente.

Cette reconnaissance de la nécessité d’inclure et de s’appuyer, dans de nombreux cas, sur « le réseau » pour des capacités qui se situent en dehors du domaine des applications et de leur infrastructure, était une bonne chose. Le côté applicatif de l’informatique reconnaît la nécessité d’inclure « le réseau » dans ses architectures. Il est donc impératif que le côté réseau de l'informatique reconnaisse la nécessité de les soutenir en adoptant une approche plus programmatique et collaborative pour fournir leurs services. Les microservices, en particulier, font ressortir ce besoin et c'est le sujet de ma session « Comment les architectures de microservices propulsent DevOps dans le réseau » (le lien renvoie vers la présentation). 

John Willis ( @botchagalupe ) s’est penché sur l’infrastructure immuable et nous a donné un aperçu de la manière dont l’infrastructure des applications (serveurs et plateformes) peut et doit être rendue immuable. Le concept s’applique également aux services liés aux applications tels que l’équilibrage de charge, la sécurité des applications et l’accélération . Son argument – avec lequel je suis d’accord, si vous vous posez la question – est que le recours à une gestion à long terme basée sur des scripts peut être semé d’embûches. L'ordre de commande, le manque d'options de restauration adéquates, l'échec général et l'échec à résoudre l'échec dans les scripts sont tous susceptibles d'être très perturbateurs, en particulier dans le réseau de production sensible aux perturbations. En utilisant le modèle d’infrastructure immuable – basé sur le principe selon lequel aucun package, configuration, application ou donnée ne peut être modifié une fois déployé – les organisations peuvent obtenir un environnement plus stable et plus agile (ainsi que gérable). Il a proposé une recette simple pour mettre en œuvre une infrastructure immuable :

1. Disposition nouvelle

2. Nouveau test

3. Diriger le trafic vers de nouveaux

4. Conservez l'ancien pour le retour en arrière

DevOps comme symptôme et non comme remède

Enfin et surtout, j'ai assisté à la session de Mark Thiele ( @mthiele10 ) au cours de laquelle il a affirmé que DevOps est un symptôme d'une organisation saine, plutôt qu'un moyen de parvenir à une organisation saine. Le vice-président de Switch SUPERNAP conseille aux organisations de « partir du principe que la façon dont elles font les choses aujourd'hui ne sera pas évolutive » et de se tourner en permanence vers les personnes et les processus pour permettre l'évolution nécessaire pour répondre à la prochaine grande demande. L’échelle, comme les applications d’aujourd’hui, n’est pas statique et une approche plus agile et collaborative de l’informatique en général est donc nécessaire. Mark s'est davantage concentré sur l'efficacité et la valeur ajoutée pour l'entreprise, soulignant que « l'informatique n'a pas été créée pour réduire les coûts informatiques », mais plutôt pour ajouter de la valeur à l'entreprise. À cette fin, il encourage les organisations à penser en termes de services plutôt que de technologie et à adopter une approche collaborative pour concevoir et fournir ces services.

La collaboration a été un thème commun, avec autant d’attention portée aux silos intra-silos qu’aux silos informatiques eux-mêmes. Il est important de dépasser les silos – qu’ils soient intra ou inter-groupes informatiques – non seulement pour établir et appliquer des politiques concernant les délais de livraison, les performances, l’évolutivité et la sécurité des applications, mais également pour pouvoir définir et mettre en place les processus nécessaires pour optimiser la livraison de bout en bout des applications, du développement à la production, de l’application à l’utilisateur.

Dans l’ensemble, le lien entre les microservices et les conteneurs a été souligné, ainsi que la nécessité de gérer l’explosion des services qui en résulte et l’infrastructure de support avec une approche DevOps. L'IoT sera un moteur important à la fois de la technologie (conteneurs, microservices et approches définies par logiciel du réseau) et de l'approche globale, DevOps, alors que les organisations commencent à se lancer dans ce qui sera certainement semblable à la croissance exponentielle connue à l'ère du .com.

C'est tout pour New York. Bon jeudi !