Deutsch
Before companies can profit from network automation, they need to overcome a series of challenges. These include missing standards or a lack of qualified network specialists. Our third article in our blog series on automated networks will show you how you should go about automating your network.
Network automation offers many advantages: central and efficient management across a uniform system of rules, relief from manual activities thanks to automated configuration, plus a higher degree of network security and availability because the likelihood of error is reduced. Automation will become even more important in the future, since multi-cloud scenarios are on the rise and so networks are becoming increasingly complex.
But companies must overcome a series of challenges on the way to an automated network.
There is no blueprint
There is no blueprint and no well-established route for migrating to a (semi-)automated network. Although standardisation committees – such as the Open Networking User Group (ONUG), the OpenDaylight Project and OpenStack – are developing practical architectures for more software-based networks, it is still far from clear which standards, providers and products will establish themselves on the market.
IT departments are faced with a multitude of options when selecting providers and products which support automation of manual processes in the network. It is not easy to make the right decision here. There is a choice of established IT providers such as Cisco, Juniper Networks, Hewlett Packard Enterprise (HPE) and VMware, newcomers like Anuta Networks, Apstra, Cumulus Networks or Glue Networks, as well as SD-WAN specialists, for example Cradlepoint or Riverbed Technology. The huge bandwidth of products can make the decision process considerably trickier and, above all, slow it down. So companies such as HCD Consulting AG support their customers by choosing the appropriate products and supporting automation projects from start to finish.
And yet: in a study carried out by Juniper, 33 per cent of the customers and partners interviewed regarded the lack of an end-to-end solution as a barrier to network automation.
Network experts need to have a rethink
43 per cent of those asked said that lack of training and qualifications is preventing the introduction of automated networks. Until now, network engineers hardly had to do any programming, or think in terms of detailed step-by-step processes. However, the latter is a prerequisite for automation, because the first thing the IT team has to do is define and standardise all the individual works steps – down to the smallest detail. In addition, issues such as data models or common base components were previously a field for software developers and software architects, but did not feature in the portfolio of most network engineers.
Another potential obstacle: network technicians could feel limited or threatened by automation in their line of work and start worrying about losing their jobs. This begs the question: is the disappearance of boring manual work really such a great loss? And isn’t it true that the volume of work often increases with new technologies? We believe that network experts who are open to innovation can remain relaxed as they await this development.
Still a lack of standards for SDN
For SDN, the premium form of network automation, there has until now been a lack of standardised interfaces via which the SDN architectures of different network service providers can work together. Because currently, providers usually have to use different systems and interfaces (APIs) to manage different aspects of their networks. The consequences are friction losses and inefficiencies in the provision of end-to-end services. Organisations such as the Metro Ethernet Forum (MEF) and the TM Forum are currently working hard to develop standardised APIs for coordinated services across automated and interconnected networks.
To date, there are still too few products which support open SDN protocols such as OpenFlow. OpenFlow enables virtual networks to be managed even beyond provider boundaries. Although there are already enough software controllers for this, there are only a few OpenFlow-compatible hardware components. This is because SDN results in proprietary hardware, such as switches, losing significance. In contrast, SDN controllers and the appropriate management tools become more important.
Proceeding step-by-step
No matter whether companies just automate parts of their networks or rely completely on SDN: management should regard IT as a strategic resource and not as a cost factor. In this case, the IT team would have sufficient funds to get properly trained in network automation and then implement it step-by-step.
In practice it is best to start with a simple process, e.g. automating data collection from network devices and using the data to generate reports. Another example is error detection: checking whether the port to which the user is connected is generating errors. The next steps for network automation would be automated provision and configuration of new devices, new locations or new services. The final step would be event-oriented automation – where the network reacts to external events autonomously, adapting its configuration in real-time.
Related articles:
- Network automation – an introduction
- Application examples for automated networks
- SDN – top class network automation
Questions?
Just ask!
I am Alexander Zagler from the HCD sales team. I will be happy to advise you or assist you with any questions. You can phone me on +41 58 590 110-0 or reach me using our contact form.
Contact us