Adopting open networking is an aspiration many businesses will have had long before the global pandemic. And there is a lot of content out there highlighting how open networking can not only increase network engineers’ productivity, but also drive down the total cost of ownership (TCO). But with the Covid-19 lockdown forcing thousands of businesses to work remotely, open networking is now more important than ever before. Unfortunately, many were not ready for it.
Successfully adopting open networking architecture often requires a major business model overhaul - both from a technical and cultural mindset point of view. From testing to deployment and up-skilling IT teams – one of the biggest mistakes made is applying traditional methods and expectations to new infrastructure. A square peg in a round hole. Business workflows have to be realigned to match the benefits of open networking across three common touch-points; documentation, change request, and education and training. Only once this has been done will businesses really be prepared for open network architecture.
Documentation
In traditional networks, documentation is split into three areas; high level design (HLD), low level design (LLD) and user acceptance testing (UAT). And is usually written out of workflow - requiring engineers to stop developing content to document what they’re doing. But this is highly inefficient, as the document is immediately out of date. Static documentation doesn’t accurately reflect the ever-changing requirements of a network.
High level design (HLD) logs why each specific feature is selected for a proposed network infrastructure. But in open networking, rather than simply using HLD as a reference to understand the history of the current networking deployment; it is used as a bill of networking rights that enforces the rules of how applications should be designed and deployed across the network.
Further, a complete paradigm shift is required with regards to LLD. Rather than simply accompanying the HLD by taking features chosen for the infrastructure and providing best practices for each; the LLD should become the simulation and configuration and be stored in a centralized git repository. Open networking aligns the LLD more closely with the final configurations - alleviating a major inefficiency found in traditional networks.
In open networking, the LLD is able to flow natively into the UAT - a series of test criteria that needs to be met to demonstrate a deployment is ready for production. This is thanks to a large proportion of the test criteria that relates to redundancy and connectivity can be dealt with in the testing environment used for the LLD.
Documentation should be a fundamental part of the design process. And by combining code and simulation, these two standard workflows are made a direct part of the documentation process. This process is significantly more productive and time-efficient.
Change requests
Typically, change requests consist of either adding new features or onboarding a new application to existing infrastructure. But traditional networking workflows are highly inefficient - as they rely on engineers emailing independently generated educated guesswork and are mostly ignored until the maintenance window. At which point, working on the basis of no news must be good news, they are applied and prayers are sent to the IT gods with hopes that it works. This leaves many thinking that there must be a better way of implementing change requests.
And there is. Building out automated test pipelines that connect to businesses CRM systems means that any change made has full commit history; holding individuals to account. This also brings into play an approval chain for additional accountability, thanks to all these technologies existing natively in Git; the solution of choice for Infrastructure as Code. In practice, this means all proposed configurations are run against a series of validations, and the report is linked to the original change request ticket.
As such, when it comes to onboarding new applications, the change request is a simple case of applying configuration changes that have already been validated and vetted as per the HLD and LLD. The automation employed here ensures that only validated changes can be pushed into the network.
As more companies look to migrate to remote delivery given the current limitations around travel, it is essential that change requests can be more easily scrutinized. It’s no longer an option to ‘run down to the lab’ to resolve issues. Like NASA engineers who triple check their work before sending instructions to remote satellites, IT networking change requests need the same level of verification.
Training
The biggest mistake businesses make when adopting open networking is failing to train their staff appropriately. To achieve the full benefits of open networking, requires more than simply buying open networking solutions and expecting the networking team to get on with it. It requires a solid level of technical understanding of how to get the most out of open networking; especially when it comes to achieving specific business objectives.
This has to be proactive. As seen in the recent shift towards remote working during the Covid-19-enforced lockdown, those companies that have been most resilient were the ones with the skilled workforce that was capable of doing so. Each employee was appropriately skilled in modern, remote working practices that enabled productivity to remain through open networking principles.
For companies with the budget and time resources, formal training is a great starting point, and should be a mandatory requirement. Especially at large enterprises that normally have big network teams that require training. This creates a skill floor, which stops the engineering team from backing away from responsibilities. From open network fundamentals to containers, VMWare, Openstack and Linux as a core operating system in business, this training should touch on multiple topics beyond networking.
Aside from not paying for proper training, the biggest mistake companies make is not appropriately allocating time for their network engineering teams to naturally learn or optimize their open networking technology portfolio. With the demands of modern networking increasing, far too often teams end up bogged down in the weeds of daily operations, trying to force an open networking solution onto traditional workflows.
The initial rollout of open networking will require more time, as the network team needs to take time to retool and restructure workflows appropriately. By allowing for more time upfront, the business will ultimately be more productive in the long run.
The benefits of open networking are well documented, but if not implemented correctly businesses run the risk of being even more inefficient than when using traditional networks. By focusing on training network engineering teams, alongside automating documentation and change requests, companies can be sure they will be well prepared to reap the benefits of open networking.