As an engineer who graduated from the École Polytechnique de Montréal, nothing predestined Przemyslaw Balejko to work in networking. Considered today as a true network specialist in Canada, he has just joined NETsatori in order to accompany it in its growth. We met with him a few days before he joined the team to get to know him and ask his opinion on five current buzzwords.
Przemyslaw Balejko, or PRZ as he is called, is very modest. Above all, he considers himself to be a very good generalist and believes that IP enterprise network is fundamentally quite simple: it is about transferring IP packets from point A to point B through the company’s infrastructure. This ability to simplify problems is undoubtedly PRZ’s trademark. The customers and colleagues he has worked with all point to his great analytical capacity which allows him to break down complex processes in order document them and prepare large migrations in a sequential manner.
Convinced, like Nietzsche, that the devil lies in the details, PRZ likes effective architecture, just as a master pastry chef appreciates a well-assembled cake. From his time with CGI at Bombardier, where he worked on a $30 million network equipment fleet with 70 to 90,000 Ethernet ports distributed around the world, he emphasizes the quality of the infrastructure, the accuracy of the documentation and the IP address structure. He notes, “These large enterprises move a little slower, but they are great, well-managed environments that are easy to scale.” On a similar note, the Quebec market is made up of small and medium-sized businesses, as well as public organizations, and the five years he spent at SBK allowed him to familiarize himself with a very broad spectrum of environments (about 100 in total), from the best to the worst. “Recently, I had the opportunity to audit a very small infrastructure consisting of a switch and a few servers. But it was such a mess – with the Internet and LAN in the same VLAN, private subnets and network cards everywhere – that
adjustments couldn’t be made without jeopardizing the whole system. “That’s where the ability to analyze and model is important, as well as the capacity to help the customer by explaining very complex concepts in simple, understandable words. Let’s do the test with our five buzzwords.
“Automation is a tool. If you don’t understand the problem and you can’t solve it manually, you’re certainly not going to be able to solve it better automatically. So beware of buzzwords. All the principles of automation, which help to avoid a lot of errors, are good. They have been used by big players like AWS or Google to build their infrastructures. However, you also need a corporate culture that allows you to learn from your mistakes and to intelligently operationalize automation. For automation to be successful, you need to go well beyond technology to take into account culture, internal processes, and the ability to make DevOps a reality. »
“I hope it’s a happy marriage between developers and operations… Big companies like Netflix, which were born with the cloud, have very sophisticated processes and are able to do this. But it’s another buzzword that means everything and nothing at the same time. We realize that the organizations where it works, I’m thinking of Google, for example, are those that are as rigorous in selecting support staff as they are in selecting developers. The qualification level of everyone there is very high. Whatever their role, the members of these teams all share both an open mind and an analytical capacity that allows them to understand what others are doing. To be a coder at Google, you have to be a very good coder. It’s almost these same skill levels, this same ability to solve problems and break down an algorithm, that is expected of operations staff. At Google, DevOps is two parts of the same brain. »
“Today, systems are increasingly complex, and orchestration makes it possible to imagine a central and intelligent entity controlling all the various components. Thanks to orchestration, a system is more efficient than the sum of its parts. On the other hand, one must be aware that achieving this in reality, i.e. taking into account the technological and organizational complexity of large companies, is not an easy undertaking. It is when integrating different systems, languages and technologies that we discover the difficulty of orchestration. »
“I think that the cloud has really revolutionized the way you can test a product or a business model. You can very quickly put resources in place, scale them up and, if necessary, dismantle them just as easily if the project doesn’t prove to be profitable. So, it offers incredible flexibility. But it’s not simpler in terms of the network, on the contrary. The only thing really common is TCP/IP. The challenge for us is often that we don’t know how the operator has set up his network. The configuration as well as troubleshooting are therefore much more complex. In fact, the operator gives you a blueprint, objects, an API; a bit like Lego blocks. Now it’s up to you to put it all together while reading the huge documentation to understand the specifics of this particular provider. It’s all in the details. For example, the virtual Ethernet cards present in an AWS system don’t work at all like VMware vNICs. There are small dependencies that are specific to the cloud that will prevent the network from working as expected. A cloud infrastructure has more limitations, especially at the protocol level. So, if I’m doing BGP on my network, I can set up whatever policy I want and configure as many routes as I want. All of this will not be achievable in the same way in a cloud infrastructure. You also have to be aware that every cloud environment is seemingly similar, but in fact, is very different. To a novice, the differences look minor. And that’s true, but when it comes to getting the project done and getting sites and systems talking to each other, it’s those tiny details that make it all work, or not. The differences between Azure and AWS are very present, and I’m not even talking about Google Cloud, which is yet another universe in itself. Whether it’s Oracle, IBM, Alibaba, and of course AWS or Azure, all offer a sandbox that looks identical, but contains small differences that are fundamental to master if you want to succeed in a project. »
“In the context of COVID-19, and the importance of being able to work remotely, network resilience has become a priority. What’s unfortunate is that it takes an event like the one we’re currently experiencing for companies to realize the importance of having a strong network and infrastructure. We should not have to choose between resilience and performance. The two are perfectly compatible, but, often, of course, the third variable, the financial one, weighs heavily in infrastructure investment decisions. In any case, resilience on paper is always good. The important thing, in fact, is to make sure you have carried out a very detailed analysis beforehand and, afterwards, to test your network. If you have a backup and a failover process between redundant links, you need to test them. Ideally, every weekend, you should switch from one link to another and carry out load tests. »
Without a doubt, Przemyslaw Balejko’s contribution to NETsatori will be to clearly demonstrate to customers the importance of not considering the network as a mere commodity and to get them to pay the necessary attention to this part of the infrastructure through which, nowadays, 100% of their business passes.