Embracing Digital Cohesion by Dealing with “Economics” Barrier
Dec 20, 2016
This morning while driving to work I started thinking about how Apple’s iPhone had captured the mobile market and displaced former leaders like Nokia and Blackberry. A similar analogy is how Netflix displaced top video rental stores like Blockbuster. Both these companies have one thing in common: their ability to innovate. How did they manage to innovate?
Innovation comes from within. When employees start thinking about strategic business problems and work to find ways in solving those problems, that’s when magic happens. If there’s something we can learn from history, it’s that we need to innovate to stay relevant. Digital Cohesion ushers in an era of innovation and possibilities. But to truly embrace it organizations need to ensure that their IT workforce is working on new things and not spending their time in just keeping lights on. How do you free your resources and encourage your IT workforce to innovate?
Today, use of automation is rising in all industries due to the decreasing costs of technology vs the increasing costs of employees. So from economics standpoint, its common business sense to automate. In Digital Cohesion world, many digital services will need to be instantly provisioned and then come together giving the end-user a truly great experience. These digital services will act autonomously, and deploy based on your situation, need, and location, as well as your history and feedback from other services or devices that you used. This means that demand put forth on enterprises and service providers will increase exponentially. At Google a typical network engineer manages up to 15,000 servers and at an enterprise up to 50 servers. Of course Google has super human engineers but even then managing 15,000 servers is no small feat. So why this disparity? Google uses automation at a large scale that helps them be agile and at the same time also keeps their operating costs low. Even in Marvel Universe Iron Man needs J.A.R.V.I.S to get continuous feedback on his suit operations.
Figure 1: Iron Man suit has automation in-built
Top reasons for you to consider automation:
Free your staff for more strategic work:
By reducing the effort spent on repetitive and mundane manual tasks—which are incredibly tedious for the people performing them—you free up resources to work on higher-order tasks, such as driving improvements in application delivery. Not only does your business flourish under these conditions, but you also end up with happier and more productive workers. They can be proactive rather than reactive.
Because automation masks the complexities of the underlying infrastructure—dramatically fewer person-hours are required for network operations because the provisioning, managing, and orchestrating of network services have all been simplified—your OPEX is immediately lower.
With regard to CAPEX, by replacing hardware devices with virtual network devices (VNFs), you can scale up and down automatically and add or remove virtual resources to meet changing load demands. This means you no longer have to overprovision network hardware, thus saving on the capital costs of equipment.
Network agility and reliability are no longer mere buzzwords. Dynamic services need agile and self-driving networks(TM). Networks that can autonomously resolve security issues, allocate bandwidth, auto provision, increase productivity and scale fast. And while doing all that help reduce OPEX and CAPEX. The fuel that drives self-driving networks(TM) is automation.
Figure 2: Junos automation feature support timeline
The above figure represents the Junos automation feature support timeline. From Day 1 our Operating System has been API/model driven. This means that when Junos was built, it was built with automation in mind and over time our OS infrastructure has continued with that intention. Today, our OS even supports OpenConfig Models.
Let’s shift our discussion towards managing today’s networks. A network does not just contain network elements from a single vendor. Our customers have diverse networks that are all trying to talk to each other and are essentially made up of elements (router, switch or security) from different vendors like Cisco, Arista, Brocade (Broadcom) and Juniper. The problem comes from network management perspective. If the network administrator wants to configure BGP on Juniper router, he needs to implement a different configuration than when configuring BGP on a Cisco router. Let’s take an analogy: write your introduction in English but in two different syntax - one paragraph in American English and one paragraph in Queens English. Both in English but different flavors. Writing one paragraph each is easy. Imagine writing everything you do in two different flavors every day. You see the problem? Today in networking world that’s the problem that many operators and vendors are trying to solve. Everybody wants to automate but nobody can automate something that is too complex. To understand the above problem lets walk through the history of network management.
First, came the SNMP which was great for network monitoring. With SNMP, administrators used to poll devices regularly to collect management information. It worked great for small networks but as networks scaled retrieving large amounts of data (routing tables) from devices became very slow. Moreover, it wasn’t easy to identify configuration objects from operational state objects. As a result, network administrators got a stale view of the network which prevented faster reaction to network events.
Second, came the workflow automation tools like Puppet, Chef and Ansible that reduced the computing overhead. Ansible has an agent-less architecture which means that there is no agent software running in the switch/router. It’s based on Push mechanism rather than the Pull mechanism of SNMP. The Ansible Engine works with the Perl or Python modules and the Playbook to apply CLI/XML over SSH connection to the router/switch. This eliminates the need to manually enter values on the device. Although this is a step in the right direction it’s not the final destination. There is still the limitation of integrating with OSS which has become expensive and time consuming.
Third, is the NetConf/ YANG model. Netconf is a transport protocol and YANG is a data modeling language. Think of it like, Netconf is English and YANG is grammar and syntax. YANG Models are predefined models (formats) like American English syntax and Queens English syntax. Netconf/YANG provide a way to install, manipulate or delete configurations of network devices.
Today, all the devices can be configured and monitored the same way. But there’s a catch. All the YANG models (different syntaxes) need to be standardized. This means that we need a template that everybody in the world understands. No separate American English or Queens English syntax but a World English syntax for everybody. This need to have standardized YANG models led to the creation of “OpenConfig” – a consortium of network operators sharing the goal of moving networks toward a more dynamic, programmable infrastructure by adopting software-defined networking principles such as declarative configuration and model-driven management and operations.
OpenConfig chose YANG as the data modeling language and gRPC as preferred transport protocol. Today, they have 20+ YANG models and more on the way for each functional block of the network element i.e. MPLS, ACL, Optical Transport and Routing Models. Juniper Networks supports nearly half of these YANG models today and is working aggressively towards enabling more standardized YANG models on its routing and switching platforms. We are working with operators to help them become vendor agnostic and to help them reduce their OSS integration cost.
Let me ask you this: What are you waiting for? It’s about time you put your Iron Man suit on!
“Netconf and YANG – explained in a layman’s term” blog by Pallavi Mahajan.
Meetup on Netconf/Yang by Gurudatt Shenoy and Nilesh Simaria.