Le moment "Aha !" du réseautage

J'ai récemment eu une grande révélation sur les réseaux. J'ai passé près de 25 ans à travailler dans les technologies de l'information, en particulier dans le domaine des communications de données (oui, je suis aussi vieux que ça !). J'ai rencontré tant de produits incroyables qui n'ont jamais réussi à s'imposer sur le marché, et j'étais assis là, un verre à la main, en train de me demander "Pourquoi tant de bons produits ne parviennent-ils pas à être adoptés ? On dirait presque que les meilleurs produits, dotés de nouvelles technologies étonnantes, échouent plus souvent que les produits ennuyeux.

La réponse est simple : le CALENDRIER. Le timing est essentiel. J'ai travaillé pour des entreprises qui élaboraient des solutions incroyablement intéressantes. Il y a environ 8 ans, l'une d'entre elles proposait un concept étrange appelé "Zero Trust". Personne ne semblait s'intéresser à cette technologie, et le terme n'avait aucune résonance. Aujourd'hui, il y a probablement une centaine de startups ZT ou ZTNA qui essaient d'être la prochaine licorne. Le timing est essentiel.

Parfois, il y a des startups qui produisent de manière incroyable. évident des éléments de technologie sur lesquels tout le monde s'accorde, mais qui ne parviennent pas à faire évoluer le marché. Par exemple, tout le monde s'accorde aujourd'hui à dire que l'utilisation de Linux comme système d'exploitation pour un routeur ou un commutateur est judicieuse, mais il y a dix ans, cette idée était quelque peu bizarre. Aujourd'hui, vous auriez du mal à trouver un NOS que n'est pas basé sur linux, ou au minimum offrir un "guestshell" linux afin que vous puissiez exécuter vos scripts d'automatisation sur une plateforme familière.

Les changements en eux-mêmes ne valent souvent pas la peine. Le coût d'une modification visant à réduire vos coûts d'achat peut souvent impliquer un changement important dans la manière dont votre équipe d'exploitation du réseau gère le matériel, ce qui ne vaut probablement pas la peine de se casser la tête et de continuer à faire les choses de la même manière. Mais qu'en est-il lorsque l'ensemble de la plateforme change, non seulement dans votre entreprise mais dans le monde entier ?

Les transitions de plateforme sont importantes

Les transitions de plate-forme se produisent généralement lorsqu'il n'est plus possible de vivre sa vie comme avant, ou lorsqu'il y a un changement de garde. À mesure que les anciens meurent et prennent leur retraite, les nouveaux refusent de faire les choses à l'ancienne, ils jettent l'ancien manuel ou ils automatisent les tâches répétitives.

L'installation de Linux sur un commutateur de réseau est une bonne idée, mais elle n'a pas suffi à inciter les architectes de réseau à mettre à niveau leurs appareils et à modifier leurs modèles opérationnels. Cette nouvelle façon de programmer les réseaux n'était pas liée à une transition majeure du marché et, par conséquent, elle n'était pas suffisamment convaincante pour inciter les utilisateurs finaux à migrer.

Cela dit, pourquoi suis-je si enthousiaste à l'idée d'un AUTRE système d'exploitation en réseau ouvert ? Je dois être un glouton pour la punition, non ?

Deux phénomènes majeurs se produisent aujourd'hui dans le domaine des réseaux.

SONiC est là et c'est une plateforme de transition qui change la donne.

SONiC a grand élan sur le marché. Les architectes de réseau doivent réfléchir à la manière de surfer sur la vague, car se tenir droit et se laisser frapper est un moyen sûr d'échouer. Une transition majeure du marché est sur le point de se produire. Que propose SONiC ?

• Une façon normalisée de programmer les dispositifs de réseau
• Un système d'exploitation ouvert et composable qui peut être adapté à chaque cas d'utilisation.
• Liberté de la chaîne d'approvisionnement - vous avez des centaines d'options, y compris des favoris tels que Cisco, Arista, Juniper, Nvidia, Dell, etc.
• L'Open Source est toujours gagnant à long terme

Mais la gestion de SONiC n'a pas été une promenade de santé. Ce n'est pas le routeur CLI de votre grand-père. Et qui gère un seul appareil de toute façon ? Les réseaux d'aujourd'hui sont des applications distribuées soigneusement construites (parfois appelées tissus) parce que les points de défaillance uniques sont un moyen sûr de vous obliger à mettre à jour votre CV.

Si seulement il existait une excellente technologie open source pour gérer un ensemble d'appareils exécutant des conteneurs...

C'est Kubernetes !

Il devrait être évident pour tous ceux qui lisent ceci que Kubernetes est la technologie de facto pour l'orchestration des applications. Et en réalité, Kubernetes est la principale méthode utilisée pour contrôler VOTRE infrastructure. Mais pourquoi le réseau est-il si loin derrière cette nouvelle technologie ? Cloud Native monde dans lequel nous vivons ? Il existe de nombreux GRANDS Interfaces de réseau de conteneurs (CNI) et Fournisseurs de réseaux Kubernetesmais ils ne traitent que de ce qui se passe une fois que le trafic applicatif a atteint l'entrée de votre cluster. Vous devez toujours brancher tous ces nœuds K8s sur quelque chose.

Deux transitions de plateforme valent mieux qu'une ! Que se passe-t-il lorsque ces deux vagues fusionnent ?

Si vous êtes comme nous, vous savez que la réponse est une nouvelle façon de construire et d'exploiter votre équipement. Mais ne nous croyez pas sur parole, regardez simplement le cloud. À quelle fréquence configurez-vous le réseau physique pour vos clusters Kubernetes dans le cloud ? JAMAIS. Vous n'y pensez même pas. Les propriétaires d'applications sont heureux de ne pas avoir à se soucier du réseau. Mais si vous essayez d'exécuter Kubernetes dans votre propre centre de données ou à la périphérie, ce n'est pas si rapide ! Tout d'un coup, vous devez à nouveau gérer le modèle opérationnel du réseau hérité, et c'est une excellente raison pour laquelle les gens resteront dans le cloud et paieront 5 à 10 fois plus cher pour héberger leurs charges de travail. C'est la raison pour laquelle les gens restent dans le nuage et paient 5 à 10 fois plus pour héberger leurs charges de travail.

Mais plus maintenant

Chez Hedgehog, nous fusionnons le plan de contrôle natif de Kubernetes avec la bonté du réseau open source qui est l'ADN de la communauté SONiC. Et pouvez-vous dire que je suis enthousiaste à ce sujet ?

Par le biais d'une série d'articles de blog, je vais révéler les réponses aux questions qui vous passent probablement par la tête en ce moment. Je vous promets que cela va être très excitant, et comme tout bon présentateur, à la fin je vous donnerai des bonbons (sous la forme d'un logiciel open source gratuit et d'un modèle d'onboarding clé en main).

Alors pourquoi devriez-vous évaluer Hedgehog ?

• Les mêmes API et opérations que vous utilisez pour le reste de votre infrastructure peuvent être utilisées pour approvisionner et gérer votre réseau physique.
• Il est beaucoup plus facile de trouver des personnes capables de gérer k8s et de faire tourner des applications dans ce système que de trouver des personnes capables de gérer des NOS propriétaires de plusieurs fournisseurs.
• Vous pouvez prendre en compte tous les fournisseurs de matériel disponibles, ce qui améliore les options de la chaîne d'approvisionnement et minimise le risque commercial.

Nous travaillons d'arrache-pied à la mise au point du meilleur produit, une mise en réseau si simple qu'elle semble disparaissent dès que vous l'allumez.

P.S. Si vous souhaitez en savoir plus sur notre révolution, veuillez cliquer sur le lien suivant demander une réunion et nous pourrons répondre à toutes vos questions.