denisovd - Fotolia
In this week's roundup of posts from around the SDN blogosphere, an engineer considered the problem of inconsistent programmatic interfaces when it comes to network automation. An analyst urged buyers to keep it simple when choosing between various network products. And another expert shared how automation reduced the configuration of one data center from five weeks to four minutes.
Will OpenConfig fix automation problems?
In a recent post on Packet Pushers, network professional Ethan Banks suggested that OpenConfig might help solve the network automation challenges created by a lack of standard programmatic interfaces.
Like CLI syntax, descriptive language models vary from vendor to vendor, and Banks argued that variety -- while the spice of life -- is not the spice of operations. Inconsistent models and interfaces could throw a frustrating wrench in the promise of automation.
"By Thor's hammer, how am I going to automate my network's configuration if every time I turn around I've got to tweak a script, add a module, wait for a vendor to patch my automation tool, or otherwise screw around with my operational processes to accommodate a new platform?"
But Banks wrote that there is hope in OpenConfig -- a working group of network operators trying to develop vendor-neutral data models for network configuration and management. OpenConfig participants include Facebook, Google, AT&T, Verizon, Microsoft, Yahoo and Apple.
One of Banks' primary concerns regarding OpenConfig: Will vendors support it? He wrote that Cisco already has, and Juniper suggested it will too. Banks predicted that others will follow suit, partly because the project's participants are powerful customers.
Read more of Banks' thoughts on OpenConfig, including why OpenConfig emphasizes models rather than APIs.
Keep it simple (stupid)
Gartner analyst Andrew Lerner discussed his strategy in solving a networking problem, especially when marketing hype and vendor religious wars confuse the issue. In the case of a tie between two or more viable options, he advocated choosing the simpler one.
Lerner offered SDN as an example, arguing that vendors go overboard in marketing it as a panacea to all networking woes. Instead, he suggested drilling down on the specific problem you face. Think about what product or service will actually address your particular challenge, or in Lerner's words: "Don't mow the lawn with scissors" (even if the scissors are software-defined). Struggling with agility? Explore targeted automation tools, rather than a complete SDN overhaul.
How to reduce five weeks of configuration to four minutes
Speaking of automation -- as so many SDN bloggers currently are -- Dan Conde, an analyst at Enterprise Strategy Group (ESG) in Milford, Mass., also wrote about the subject in a post this week. Conde recalled how automation helped dramatically speed up a recent data center configuration project.
Conde said that Adam Mills, a network engineer at Riot Games -- which runs the popular online game "League of Legends" -- discussed the automation project at AnsibleFest San Francisco 2015. Previously, Mills flew around the world setting up data centers to support the company's massive gaming traffic, but with automation he now accomplishes the same work remotely and far more quickly. When Riot Games built out a data center in Japan, automation reduced configuration time from five weeks to just four minutes.
Although Mills used Ansible, Conde wrote that ESG research indicates networking professionals generally prefer Python or other traditional scripting languages. He added that even software-defined networks can benefit from automation -- an SDN controller doesn't eliminate the need for automation scripts.
Learn more about ESG's research on automation.
Future of network analytics
On his blog EtherealMind, network professional Greg Ferro predicted that analytics, enabled by SDN, will play a critical role in the networks of the future. Today's visibility tools read data from network traffic, but tomorrow's analytics tools will cross-reference information from multiple sources -- such as call center logs and network application performance -- to offer new insights to administrators.
Ferro said that network data aggregation without meaning is of limited use, which is why adoption of traffic tools like NetFlow and sFlow has been slow. Source data from such monitoring tools requires heavy processing.
While Cisco boasts an entire portfolio of analytics products, Ferro said that he would hesitate before investing in any of them -- as the company has "a Google-like history of abandoning products." Instead, he suggests experimenting with less expensive network analytics tools from startups.
Look to NASA for an important lesson in automation
SDN, meet DevOps
What do we want? More automation!