One thing’s for sure: The world of networking and networking administration is quickly changing. Part of this change is an evolution from old-school, proprietary centralized networking to more open options. This evolution has several different effects on the way network designers, administrators and engineers design and operate the network. This blog will focus on the different options available for modern automation, and how the Cumulus Linux approach provides the greatest amount of flexibility.

Breaking the Stranglehold

It wasn’t too long ago that the few big networking vendors had an almost unbreakable grip on organizational networking implementations, and correspondingly, with the way these implementations were managed. For most, this included the configuration of the various types of networking equipment using a command-line interface (CLI) and proprietary commands. Automating these types of solutions most often required either an offering developed by the vendors themselves, or the use of an application programming interface (API) written to interface with their products.

The question is whether this was a good thing or not. Generally, vendor-specific solutions have their advantages because they’re able to interface closely with the specific device code and take advantage of communications between the device coding team and the tools coding team.

The problem with these environments is that they’re very specific, which means they only work well with devices from that vendor; and sometimes only with specific types of devices within that vendor’s offerings. Because of these limitations, many different organizations choose to use more vendor-neutral options.

Closed vs. Open Solutions

The chief options for modern network implementations broadly break down into two main categories: closed and open solutions. Closed solutions have a private code base; that is, the code is authored and edited by vendor employees. The largest vendor in this space is an example of such a closed environment. Open solutions, in contrast, have codebases that are either fully or partially open to the public, and able to be reviewed and potentially modified by other developers.

This openness permits a great amount of flexibility. The last few years have seen the introduction and rapid rise of offerings that utilize commodity networking hardware combined with software; this is where Cumulus Linux comes in. Keep in mind however that Cumulus Linux isn’t software-defined networking (SDN) as traditionally defined. It isn’t a controller-based central solution where cheaper networking devices are deployed; it is the network operating system itself. But it can be deployed in a traditional SDN-style deployment because it’s highly automatable.

Solution Management Options

As noted earlier, the two main ways that networking equipment is managed on modern networks is either via CLI or API. CLI has been around the longest, and is often preferred by networking engineers when it comes to quick edits and changes on a small number of devices. But for networks with many devices, using the CLI quickly becomes a giant time sink.

This is where API-based offerings really shine. They can define a process that enables the network engineer to automate actions that would have previously been done via the CLI. The number of different tasks that can be completed in this way is vast; but they can also be limited by the APIs provided by the specific vendor. This is one of the key advantages of Cumulus Linux.

When using a system that is only accessible via APIs developed and maintained by the vendor, the access to that system is limited to what they write into their code. While you may be able to manage many via the API, there will likely be necessary features that aren’t available.

The advantage of a pure Linux implementation like Cumulus Linux is that access to its management isn’t limited to the modules developed for it; any Linux automation tool or technique can be used for management. If there isn’t an option that meets a specific need of yours, use any other available tool on the Linux platform to develop a system that meets your requirements.

Linux has been around for decades, and its long development history means that a large number of tools can be leveraged to meet whatever requirements are defined. The other advantage to keep in mind is that there are going to be multiple options available for almost any requirement, and because of this the tools selected can be customized around the strengths of the teams that will be using the resulting solution. For example, both Chef and Puppet have built-in Linux modules that can be used. Other options include customized offerings using Python, PERL or any supported languages, which in this case is extensive.

Automation and Choice

The key point to take out of this is that with offerings like Cumulus Linux, the automation options available aren’t limited by any specific vendor’s implementation; this flexibility, on top of its other advantages as an open solution, make it a must-consider alternative to popular closed solutions. This is also a reason Cumulus Linux will remain a force to reckon with as the networking space continues to evolve.

Interested in reading more of our latest blogs? Follow the link here.