Response: Linux on Network Switches make sense for your career
Greg Ferro posted an article over at EtherealMind which highlights the shift and desire in the industry to move to Linux based Network Operating Systems (NOS). What Greg intones with the article is a fundamental shift away from CLI-domination and vendor operational toolsets that are vendor specific and lack wide-reaching control. I agree with Greg wholeheartedly.
Linux has provisioning tools that IT teams want to use i.e. Puppet, Chef, Ansible etc. In a data centre with thousands of servers, there are likely just hundreds of network devices. Its makes no sense to have a completely different approach to configuring the network, it would be better to use the same systems that configure and operate servers. — Greg Ferro
Whilst each vendor has a same, same but different approach to configuring their devices there has been a fantastic takeup of deployment, provisioning, and automation toolsets. There is a strong desire as always to do more with less. The industry is seeing convergence in hardware and software stacks. Business Units and Cylinders of Excellence are being cross-pollinated. Being open-minded it is possible that a Linux NOS will herald in the more liberal use of wide-reaching and heavily used tools such as SED/AWK/Puppet/Chef/Anisble, etc.
In just a two years, Cumulus Networks, Big Switch Networks and PICA8 have shown that it is possible to build Linux for networking while offering capabilities and integration far beyond existing products. As they work to stabilise their platforms and add features, the popularity of Linux seems set to increase as customers moved into hyper-converged technology with Linux as the baseline. — Greg Ferro
Without a doubt there are companies out there with much to lose. I work for an incumbent software vendor in the x86 server market. This vendor also delivers network virtualisation. I am standing on the aforementioned precipice of change. Changing an architecture is a challenge because there is more invested than technology. A technology may solve world hunger but if it is hard to use, operate, and support then it will never win. Combining existing tools used widely across different teams and verticals, transferring troubleshooting frameworks onto new technologies, and consuming existing knowledge are paramount. You cannot change an architecture or a way something is delivered with just technology alone.
Another important part here is the standardisation on to the Linux platform. People do talk around the shift from vendor A to vendor B and learning the nuances. I have always taken the mindset of when studying for my Cisco / Juniper / VMware certifications is that I am learning a vendors method of implementing a protocol. BGP/OSPF/Firewall rules are mostly the same across vendors. If you know the protocol and know why you’re configuring an OSPF Sham-link across discontiguous backbones then you can do it on any vendor’s deployment. Investment of knowledge in transferable skills is paramount. Look at the CCIE now days. Granted you’re learning IOS specific CLI but you’re not learning speeds and feeds or nuances of hardware QOS – you’re learning nuances of protocols. Protocols that mostly transcend any one vendor (I overlook EIGRP here but my point stands). Integrating many protocols in more real-world scenarios (I speak to v5 – v4 was abysmal) is brought a breath of fresh air. Once you know these protocols it doesn’t matter what Network Operating System you use. Whether it be JUNOS, IOS, Linux, or something else there is transferability of skills.
As the Large Hadron Collider smashes particles together at insane speed the networking industry is seeing software and applications collide with networking. Applications use Linux more than ever and software functions are residing in Linux (one flavor or another). Linux on my Server infrastructure, my application architectures are built as micro-service architectures on containers or virtual machines running Linux, and my Network Operating System running Linux. There is a clear pattern emerging here and I think we as an industry should see this.