Przemyslaw Balejko – Redorer le blason de la réseautique

Ingénieur diplômé de l’École Polytechnique de Montréal, rien ne prédestinait Przemyslaw Balejko à travailler dans la réseautique. Considéré aujourd’hui comme un vrai spécialiste réseau au Canada, il vient de rejoindre NETsatori afin de l’accompagner dans sa croissance. Nous l’avons rencontré quelques jours avant son arrivée dans l’équipe afin de faire connaissance et lui demander son avis sur cinq buzzwords du moment.

Przemyslaw Balejko, ou PRZ comme on l’appelle, est très modeste. Il se considère avant tout comme un très bon généraliste et estime que la réseautique d’entreprise IP est au fond assez simple : il s’agit de transférer des paquets IP d’un point A à un point B au travers des infrastructures de l’entreprise. Cette capacité de simplification des problèmes est sans nul doute la marque de commerce de PRZ. Les clients et les collègues avec lesquels il a travaillé soulignent tous sa grande capacité d’analyse qui lui permet de décomposer des processus complexes pour les documenter et préparer de manière séquentielle de grosses migrations.

Convaincu, comme Nietzsche, que le diable est dans les détails, PRZ aime les architectures bien faites, comme un maître-pâtissier apprécie un gâteau bien monté. De son passage avec CGI chez Bombardier, où il travaillait sur un parc d’équipement réseau de 30 millions de dollars avec 70 à 90 000 ports Ethernet répartis à travers le monde, il souligne la qualité de l’infrastructure, la précision de la documentation et du plan d’adressage. « Certes, dit-il, ces grandes entreprises sont un peu plus lentes à bouger, mais ce sont de superbes environnements bien gérés que l’on peut faire évoluer facilement. ». Mais le marché québécois est aussi constitué de petites et moyennes entreprises, ainsi que d’organismes publics, et les cinq années qu’il a passées chez SBK lui ont permis de se faire les dents sur un spectre très large d’environnements (une centaine en tout), qui vont du meilleur au pire. « Il m’est arrivé récemment de faire un audit sur une toute petite infrastructure constituée d’une switch et de quelques serveurs. Mais il s’agissait d’un tel bric-à-brac – avec l’Internet et le LAN dans le même VLAN, des subnets privés et des cartes réseaux un peu partout – que l’on ne pouvait rien bouger sans tout casser. » C’est là que la capacité d’analyse et de modélisation prend toute son importance, mais aussi celle de vulgarisation pour aider le client en lui expliquant dans des mots simples et compréhensibles des concepts très compliqués. Faisons le test avec nos cinq buzzwords.

Automatisation

« L’automatisation est un outil. Si tu ne comprends pas bien le problème, et que tu ne peux pas le résoudre de manière manuelle, tu ne pourras certainement pas mieux le résoudre de manière automatique. Il faut donc se méfier des buzzwords. Tous les principes de l’automatisation, qui permettent donc d’éviter un grand nombre d’erreurs, sont bons. Ils ont servi de base aux grands joueurs comme à AWS ou Google pour monter leurs infrastructures. Cependant, il te faut aussi une culture d’entreprise qui te permette d’apprendre de tes erreurs et d’opérationnaliser de manière intelligente l’automatisation. Pour que l’automatisation soit un succès, il faut aller bien au-delà de la technologie pour tenir compte de la culture, des processus internes, et de la capacité de faire du DevOps une réalité. »

DevOps

« J’espère que c’est un mariage heureux entre les développeurs et les opérations… Les grandes compagnies comme Netflix, qui sont nées avec le cloud, ont des processus très sophistiqués et sont capables de faire cela. Mais, c’est un autre buzzword qui veut tout dire et rien dire à la fois. On se rend compte que les organisations où cela marche, je pense par exemple à Google, sont celles qui accordent autant de rigueur dans la sélection du personnel de support que des développeurs. Le niveau de qualification de tout le monde y est très élevé. Quel que soit leur rôle, les membres de ces équipes ont tous à la fois une ouverture d’esprit et une capacité d’analyse qui leur permettent de comprendre ce que font les autres. Pour être un codeur chez Google, il faut être un très bon codeur. Ce sont presque les mêmes niveaux de compétence, la même capacité à résoudre des problèmes et à décomposer un algorithme, qui sont exigés pour le personnel des opérations. Chez Google, DevOps, ce sont les deux parties d’un même cerveau. »

Orchestration

« Les systèmes sont de plus en plus complexes aujourd’hui et l’orchestration permet d’imaginer un contrôle central et intelligent des divers composants. Grâce à l’orchestration, un système est plus efficace que la somme des parties. Il faut, par contre, être conscient que réaliser cela dans la réalité, c’est-à-dire en tenant compte de la complexité technologique et organisationnelle des grandes entreprises, n’est pas une entreprise facile. C’est au moment de faire l’intégration des différents systèmes, des langages et des technologies que l’on découvre la difficulté de faire de l’orchestration. »

Infonuagique

« Je pense que le cloud a réellement révolutionné la manière dont on peut tester un produit ou un modèle d’affaires. L’on peut très rapidement mettre en place des ressources, les faire monter en puissance et, si nécessaire, les fermer tout aussi facilement si le projet ne s’avère pas rentable. Cela offre donc une flexibilité incroyable. Mais, ce n’est pas plus simple pour autant en termes de réseau, au contraire même. La seule chose vraiment commune est TCP/IP. L’enjeu, pour nous, est souvent que l’on ne sait pas comment l’opérateur a monté son réseau. La configuration autant que le troubleshooting sont donc beaucoup plus complexes. En fait, l’opérateur te donne un blueprint, des objets, une API, un peu comme des blocs Lego. À toi maintenant d’assembler le tout en lisant l’énorme documentation pour comprendre les spécificités de ce fournisseur en particulier. Tout se joue dans les détails. Par exemple, les cartes Ethernet virtuelles que l’on a dans une instance AWS ne fonctionnent pas du tout comme les vNICs de VMware. Il y a des petites dépendances qui sont particulières au cloud qui vont empêcher le réseau de fonctionner tel qu’attendu. Une infrastructure infonuagique comporte plus de limitations, particulièrement au niveau des protocoles. Ainsi, si je fais du BGP sur mon réseau, je peux mettre en place ce que je veux comme politique et configurer autant de routes que je désire. Tout cela ne sera pas réalisable de la même manière dans une infrastructure cloud. Il faut aussi être conscient que chaque environnement de cloud est apparemment similaire, mais, en fait, très différent. Pour un néophyte, les différences ont l’air mineures. Et c’est vrai, mais quand vient le temps de réaliser le projet et de faire en sorte que les sites et les systèmes se parlent, ce sont ces infimes détails qui font que le tout fonctionne, ou pas. Les différences entre Azure et à AWS sont très présentes, et je ne parle même pas de Google Cloud qui est encore un autre univers en soi. Que ce soit Oracle, IBM, Alibaba, et bien entendu AWS ou Azure, tous proposent un carré de sable qui a l’air identique, mais qui contient de petites différences qu’il s’avère fondamental de bien maîtriser si l’on veut réussir un projet. »

Résilience

« Dans le contexte de la COVID-19, et de l’importance de pouvoir travailler à distance, la résistance des réseaux est devenue prioritaire. Ce qui est dommage, ce qu’il faut un événement comme celui que l’on vit actuellement pour que les entreprises se rendent compte de l’importance d’avoir un réseau et une infrastructure solides. Il ne faudrait pas devoir choisir entre résilience et performance. Les deux sont parfaitement compatibles, mais, souvent bien entendu, la troisième variable, financière celle-là, pèse un poids important dans les décisions d’investissement en infrastructure. Dans tous les cas, la résilience sur le papier est toujours bien. L’important, en fait est de s’assurer d’avoir fait préalablement une analyse très fine et, a posteriori, de tester son réseau. Si l’on a un backup et un processus de failover entre des liens redondants, il faut les tester. Idéalement, il faudrait, tous les week-ends, passer d’un lien à l’autre et effectuer des tests de charge. »

Sans nul doute, l’apport de Przemyslaw Balejko pour NETsatori sera de démontrer de manière claire aux clients l’importance de ne pas considérer le réseau comme une simple commodité et de les amener à accorder l’attention nécessaire à cette portion de l’infrastructure par laquelle transitent aujourd’hui 100% de leur activité.