Ne laissez personne vous dire que le matériel n’a pas d’importance. Il est partout. Dans chaque téléphone portable. Dans chaque Fitbit et gadget technologique que nous possédons. Dans nos voitures. Dans nos ordinateurs portables et nos tablettes. De plus en plus, il s’invite dans nos appareils électroménagers. Dans nos montres. Et apparemment, dans certains cas, en nous. Il est plus petit, plus rapide et omniprésent.
Les applications, quelle que soit leur taille, ont besoin de ressources matérielles. Processeur. Mémoire. Stockage. Réseau. Sans ces ressources, aucune ne fonctionne. Aucune. Qu’il s’agisse d’un centre de données ou du cloud (qui repose sur des centres de données), le matériel est omniprésent. Il fournit la puissance nécessaire aux applications pour rendre nos vies plus connectées, plus collaboratives et plus pratiques.
Mais cela ne signifie pas que le data center ne connaît pas de changements sur le plan matériel. Bien au contraire. Si le matériel reste le socle sur lequel repose toute technologie, les frameworks et les édifices techniques (les applications) que nous construisons par-dessus ont évolué. Dans certains cas, de manière assez spectaculaire. La loi de Moore n’est plus une contrainte dès lors qu’il est possible de mutualiser les ressources et de décomposer les applications en plusieurs services, en exploitant le maillage sous-jacent de ressources de calcul et de mémoire comme un immense système distribué.

Nous considérons ces évolutions des centres de données comme des changements de génération, selon la manière dont nous provisionnons, gérons et consommons ces ressources.
Quatre générations d’infrastructures applicatives
À l’époque de la génération d’infrastructure applicative qui a duré le plus longtemps — la génération zéro —, nous démarrions des machines et lancions des applications, puis nous nous frappions fièrement la poitrine en vantant des années consécutives de fonctionnement sans interruption. Puis vint la virtualisation : nous démarrions des machines et reprenions l’exécution d’applications fonctionnant dans des machines virtuelles. La durée de fonctionnement d’un système unique devint dépassée ; la disponibilité d’une application était désormais la métrique du jour. Dans le cloud, nous lançons des services d’un simple clic et adaptons leur capacité à la hausse comme à la baisse sans avoir à lever le petit doigt. Et dans la génération post-cloud, les conteneurs se clonent comme par magie, à une vitesse qui ferait verdir de jalousie les équipes des stands de Daytona*.
Le temps séparant les générations d’infrastructures applicatives se réduit. Plusieurs décennies séparent la génération zéro de la première génération. La virtualisation existe depuis longtemps, mais elle n’a véritablement atteint sa maturité que vers 2010. Le cloud ? 2015. Les conteneurs ? Ils progressent rapidement, et nous ne sommes même pas encore en 2018. Chaque génération tire parti des enseignements de la précédente, en tenant compte de ses lacunes et de ses inconvénients tout en cherchant à les corriger. La rapidité et le passage à l’échelle sont au cœur de ces améliorations : rapidité de mise sur le marché et de livraison, développement de l’entreprise et des applications sur lesquelles elle repose désormais. Ces deux facteurs ont contribué aux évolutions qui touchent toutes les facettes du centre de données.
Toutes ces applications et tous ces services ont toujours besoin de matériel. Les ressources n’apparaissent pas comme par magie, même si elles en donnent l’impression. C’est en partie pour cette raison que la virtualisation et le cloud se sont développés à un tel rythme. Parce que cela semblait relever de la magie. Mais après tout, la magie n’est qu’une illusion. Dans le domaine informatique, cela signifie que le matériel (et les ressources qu’il fournit) est toujours bien présent. Ce qui a changé, c’est la manière dont nous le provisionnons, le gérons et l’utilisons. Et ces changements ont un impact profond sur chaque baie du centre de données.
Et cela crée un fossé générationnel que les équipes NetOps doivent combler.
Automatisation et réactivité indispensables
L’ampleur et la rapidité avec lesquelles les organisations sont désormais contraintes de fournir de nouvelles applications et API rendent l’automatisation indispensable, que ce soit par le biais du cloud ou de conteneurs, sur site ou hors site. La durée d’utilisation de plus en plus courte des ressources matérielles par les applications et les services applicatifs implique leur réaffectation à un rythme phénoménal. Les processus manuels et les longs délais de démarrage ne peuvent suivre le rythme effréné imposé par de tels systèmes. Il faut donc des infrastructures conteneurisées et cloud (ou du moins similaires au cloud) permettant de créer et de supprimer des services rapidement et fréquemment afin de monter en charge sans délai.
L’automatisation, la consommation des ressources et la vitesse de création des services définissent les différentes générations de centres de données. Le simple passage de la deuxième génération (cloud) à la troisième (conteneurs) modifie radicalement ces caractéristiques. Chaque génération se rapproche davantage d’une réactivité entièrement automatisée en moins d’une seconde, notamment grâce à des profils de consommation des ressources qui ne durent que quelques minutes au lieu de plusieurs mois ou années.

C’est pourquoi le NetOps occupe (ou devrait occuper) une place si importante à l’heure actuelle. En effet, c’est le réseau — traditionnellement fondé sur du matériel — qui subit le plus les répercussions des attentes liées aux infrastructures applicatives de deuxième et troisième générations. Le service informatique doit souvent prendre en charge des infrastructures applicatives couvrant les quatre générations, ce qui implique généralement de mutualiser les coûts et l’infrastructure réseau. Cela passe souvent par des appliances dédiées. Mais même si un service applicatif est hébergé sur une appliance traditionnelle, il doit tout de même pouvoir être consommé par un modèle d’infrastructure applicative de deuxième ou troisième génération.
Le libre-service et l’automatisation doivent être mis à profit pour répondre aux exigences de la dernière génération, tout en maintenant la fiabilité nécessaire à la prise en charge de la première génération. Cela implique une intégration aux systèmes de gestion des tickets et la mise à disposition des données d’analyse via des API et des tableaux de bord. Ainsi, quel que soit le matériel sous-jacent — conçu sur mesure ou standard (COTS) —, le réseau doit se présenter comme une ressource exploitable et automatisable, capable de réagir avec la même rapidité qu’une infrastructure applicative de deuxième ou troisième génération.

Dans certains cas, cela signifie que les services réseau et les services applicatifs doivent adopter le même type d’infrastructure que les applications qu’ils prennent en charge. Les services applicatifs tels que la répartition de charge et la sécurité des applications web sont de plus en plus adoptés par les développeurs et intégrés aux architectures et aux infrastructures applicatives. D’autres, notamment dans le domaine de la sécurité, fonctionnent moins bien (voire pas du tout) dans les environnements de deuxième génération (cloud). Ces services doivent donc être utilisables dans le cloud, conteneurisés et facilement accessibles.
Les écarts générationnels qui coexistent au sein des centres de données peuvent poser problème aux organisations. Ils peuvent freiner, voire bloquer complètement, les initiatives de transformation numérique. Ils accentuent indéniablement les tensions entre les équipes de développement et l’informatique, entre l’informatique et les métiers, ainsi qu’entre l’entreprise et ses clients. Ces tensions peuvent être atténuées grâce aux efforts des équipes NetOps visant à répondre aux modèles de consommation nécessaires à la prise en charge des modèles d’infrastructure de deuxième et troisième générations, au moyen d’API, du libre-service et de l’automatisation.
La complexité et les exigences parfois contradictoires qui existent dans les centres de données matures entre les applications de différentes générations impliquent qu’il revient aux NetOps de relever le défi. Le réseau (et tout ce que cela implique) doit se transformer pour parvenir à prendre en charge simultanément quatre générations d’infrastructures applicatives.
*Les équipes de ravitaillement de la NASCAR cherchent à effectuer un arrêt au stand (avec changement des quatre pneus) en moins de 12 secondes. Le record de l’arrêt au stand le plus rapide n’est que de 8 secondes. La rapidité d’intervention de l’équipe est déterminante pour la réussite du pilote.
À propos de l’auteur

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés

F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.