Aux débuts du cloud, qui ne remontent pas à si longtemps, il était courant de voir des rapports sur sa croissance et son adoption vanter la pénétration sans précédent du « cloud » sur le marché, sans faire de distinction entre ses principaux modèles (à savoir l’IaaS, le PaaS et le SaaS, au cas où vous l’auriez oublié). Cela donnait l’impression que ces trois modèles connaissaient tous une croissance fulgurante et que le cloud allait, comme certains le prédisaient, faire disparaître le centre de données tel que nous le connaissions.
Quelques années plus tard, nous disposons désormais d’analyses plus détaillées du marché, qui montrent que l’essor spectaculaire du cloud s’est principalement produit du côté du SaaS, les responsables des métiers (LOB, « line of business ») ayant perçu les avantages de passer d’un modèle où l’informatique déploie des logiciels prêts à l’emploi pour leur compte à un modèle où le SaaS leur fournit immédiatement ce dont ils ont besoin. Incontestablement, la plus forte croissance du « cloud » à ce jour tient au transfert des activités de l’entreprise depuis les infrastructures sur site vers des applications « dans le cloud ».
Il faut savoir que « d’ici 2018, 59 % de l’ensemble des charges de travail dans le cloud seront de type logiciel en tant que service (SaaS), contre 41 % en 2013. Cisco prévoit que, d’ici 2018, 28 % de l’ensemble des charges de travail dans le cloud seront de type infrastructure en tant que service (IaaS), contre 44 % en 2013. Les charges de travail de type plateforme en tant que service (PaaS) représenteront 13 % de l’ensemble des charges de travail dans le cloud en 2018, contre 15 % en 2013. Le graphique suivant présente une analyse comparative des prévisions relatives à l’IaaS, au PaaS et au SaaS pour la période 2013-2018. » (http://softwarestrategiesblog.com/tag/idc-saas-forecasts/)
Ainsi, lorsque vous demandez de manière générale à une organisation si elle adopte le « cloud », elle vous répondra probablement par l’affirmative. Cela ne vous indique en rien quel type de cloud elle adopte et rend donc presque impossible toute prévision ou analyse des difficultés auxquelles elle pourrait être confrontée du fait de cette adoption. Après tout, chaque modèle de cloud présente ses propres défis : si certains sont communs — la gestion des identités peut poser problème dans les trois modèles —, d’autres ne le sont pas — la sécurité des applications web concerne principalement les applications déployées sur une infrastructure IaaS, et non les solutions SaaS.
En résumé, le terme « cloud » n’a pas vraiment de sens sans un quelconque qualificatif.
Cela vaut également aujourd’hui pour le SDN, où différents modèles coexistent, chacun ayant ses propres exigences architecturales et, par conséquent, ses propres défis.
Prenons cette diatribe de mon collègue Nathan Pearce sur l’inclusion des protocoles de superposition (VXLAN et NVGRE) dans la définition du SDN : Quel protocole SDN vous convient le mieux ?. Nathan fait remarquer à juste titre que, si nous incluons les protocoles de superposition dans la définition du SDN, nous devons également considérer d’autres protocoles d’encapsulation comme relevant du SDN.
Le problème, bien sûr, est qu’à l’instar du cloud, le SDN pâtit d’une définition très large englobant plusieurs modèles. Il y a la définition traditionnelle (ou classique, si vous préférez), fondée sur OpenFlow et limitée au réseau sans état (couches 2 à 4). Il y a aussi le modèle architectural, axé sur l’exploitation opérationnelle du réseau, qui aborde la programmabilité du SDN sous l’angle de l’automatisation du provisionnement et de la gestion. Cette approche est souvent désignée de manière générale par l’expression « gestion et orchestration du réseau » (MANO).
Il existe ensuite un modèle hybride, qui s’appuie sur la programmabilité pour créer un réseau automatisé couvrant l’ensemble de la pile. Il englobe les sept couches du modèle OSI, mais met l’accent sur la capacité du réseau à adapter son routage et l’application des politiques en fonction du trafic en temps réel. On parle plus précisément de « réseaux automatisés ».
Chacun de ces trois modèles présente ses propres défis (ainsi que ses avantages). Et rien n’empêche une organisation de les combiner pour atteindre ses objectifs (un peu comme les 82 % d’organisations qui prévoient d’adopter une stratégie multicloud (RightScale, State of the Cloud 2015)). Mais il n’en reste pas moins que si vous demandez à quelqu’un si son organisation adopte ou met en œuvre le SDN et qu’il vous répond « oui », vous n’avez aucune idée de ce qu’elle fait réellement. S’agit-il d’OpenFlow ? D’OpenStack ? D’OpenDaylight ? D’Open-on-a-écrit-quelques-scripts-pour-automatiser-le-réseau ?
Les statistiques actuelles sur l’adoption du SDN ne sont guère encourageantes et sont assurément très loin du niveau atteint par le cloud au même stade de maturité du marché.
Mais compte tenu de la disparité des définitions, il est tout à fait plausible (et probable) que la situation actuelle ne traduise pas un manque d’adoption ou d’intérêt, mais plutôt l’absence d’une définition commune.
Je vais étayer cette affirmation avec des données qui montrent que les organisations ne disent peut-être pas qu’elles font du SDN (ni du DevOps, d’ailleurs, qui souffre lui aussi d’une lassitude liée aux définitions), mais qu’elles en font probablement.
Dans les résultats compilés pour notre tout dernier rapport « State of Application Delivery » (l’édition 2016, qui sera disponible en… 2016), le nombre de répondants déclarant effectivement « faire du SDN » était plutôt décevant, compte tenu du nombre d’années pendant lesquelles le SDN a été présenté comme « la chose à faire ». Mais lorsqu’on examine les réponses concernant l’utilisation de l’automatisation et des scripts, une tout autre histoire se dessine : 67 % des répondants utilisent au moins un outil ou framework d’automatisation, et plus de la moitié en utilisent au moins deux.
Et par « outil » ou « framework », j’entends notamment Python, Juju, Chef, Puppet, OpenStack, VMware et Cisco.
L’utilisation de tels frameworks et outils témoigne d’un intérêt plus marqué pour les deux dernières définitions du SDN, celles qui mettent l’accent sur l’automatisation et l’orchestration, plutôt que pour la définition classique fondée sur OpenFlow.
Mais nous (c’est-à-dire ceux d’entre nous qui ont élaboré l’enquête) n’avons pas posé de questions sur chacun des modèles de SDN ; nous avons posé des questions sur le « SDN » en général. La définition reste donc sujette à interprétation, tout comme le terme générique « cloud » rendait les résultats des premières enquêtes sur son adoption sujets à interprétation.
Nous devons faire preuve de plus de discernement dans notre utilisation du terme SDN et dans la définition que nous lui donnons. Inclut-il les protocoles de superposition ? Les exclut-il ? Parlons-nous d’automatisation du réseau ou d’automatisation des réseaux ? Ou nous concentrons-nous sur les modèles de réseau classiques pilotés par OpenFlow ?
La réponse à cette question permettra à terme à chacun de mieux comprendre dans quelle mesure le SDN est — ou non — adopté aujourd’hui et évitera (espérons-le) que la tête de mes pauvres collègues n’explose lorsque quelqu’un suggère que les protocoles de superposition devraient être inclus dans la catégorie « SDN ».
À 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.