J'ai récemment eu une énorme révélation sur les réseaux. Voyez-vous, j'ai passé près de 25 ans à travailler dans l'informatique, plus précisément dans les communications de données (oui, je suis si vieux !). J'ai rencontré tellement de produits incroyables qui n'ont jamais réussi sur le marché, et j'étais assis là, une boisson à la main, à me demander "Pourquoi tant de bons produits ne sont pas 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 simple est le CALAGE. Le timing, c'est tout. J'ai travaillé pour des entreprises qui élaboraient des solutions incroyablement cool. L'une d'entre elles faisait quelque chose d'étrange il y a environ 8 ans, appelé "Zero Trust". Personne ne semblait s'intéresser à cette technologie, et le terme ne trouvait pas d'écho. 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 dans une plateforme familière.
Les changements en soi ne valent souvent pas la peine. Le coût de la modification d'un élément pour réduire vos coûts d'achat peut souvent signifier un changement important dans la façon dont votre équipe d'exploitation du réseau gère le matériel, cela ne vaut probablement pas la peine de se prendre la tête et vous continuez généralement à faire comme vous l'avez toujours fait. Mais qu'en est-il lorsque la plateforme entière change, pas seulement dans votre entreprise mais pour le monde entier ?
Les transitions de plateforme sont importantes
Les transitions de plate-forme se produisent généralement lorsque les gens ne peuvent plus vivre leur vie comme avant, ou lorsqu'il y a un changement de garde. Au fur et à mesure que les anciens meurent et prennent leur retraite, les nouveaux refusent de faire les choses à l'ancienne, ils jettent l'ancien cahier des charges ou ils automatisent les parties 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 les favoris tels que Cisco, Arista, Juniper, Nvidia, Dell, etc.
- L'Open Source est toujours gagnant à long terme
Mais la gestion du 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 "fabrics") car les points de défaillance uniques sont un moyen sûr de vous obliger à mettre à jour votre CV.
Si seulement il existait une grande technologie open source pour gérer un ensemble de dispositifs exécutant des conteneurs...
C'est Kubernetes, idiot !
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 le monde dans lequel nous vivons ? Il y a beaucoup de 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 incroyable de construire et d'exploiter vos équipements. Mais ne nous croyez pas sur parole, il suffit de regarder le cloud. À quelle fréquence configurez-vous le réseau physique de vos clusters Kubernetes dans le cloud ? JAMAIS. Vous n'y pensez même pas. Et les propriétaires d'applications deviennent gras, muets et heureux quand ils n'ont pas à penser au réseau. Mais essayez d'exécuter Kubernetes dans votre propre centre de données ou en périphérie, pas si vite ! Tout d'un coup, vous devez à nouveau faire face au modèle opérationnel du réseau traditionnel, et c'est une excellente raison pour laquelle les gens resteront dans le nuage et paieront 5-10x pour héberger leurs charges de travail. Parce que c'était trop difficile.
Mais plus maintenant
Chez Hedgehog, nous fusionnons le plan de contrôle natif de Kubernetes avec le réseau open source qui est l'ADN de la communauté SONiC. Et pouvez-vous dire que je suis excité à ce sujet ?
Dans une série d'articles de blog, je vais vous révéler les réponses aux questions qui vous trottent probablement dans la tête en ce moment. Je vous promets que cela va être passionnant et, comme tout bon présentateur, je vous offrirai des friandises à la fin (sous la forme d'un logiciel libre gratuit et d'un modèle d'intégration 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 dur pour créer le 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 demander une réunion et nous pourrons répondre à toutes vos questions.
Josh Saul est le pionnier des solutions réseau open source depuis plus de 25 ans. En tant qu'architecte, il a construit des réseaux centraux pour GE, Pfizer et NBC Universal. En tant qu'ingénieur chez Cisco, Josh a conseillé des clients du secteur financier du Fortune 100 et a évangélisé les nouvelles technologies auprès des clients. Plus récemment, Josh a dirigé des équipes de marketing et de produits chez VMware (racheté par Broadcom), Cumulus Networks (racheté par Nvidia) et Apstra (racheté par Juniper). Josh vit à New York avec ses deux enfants et est un passionné de plongée sous-marine.