SDN and NFV Era
Showing results for 
Search instead for 
Do you mean 

It's the End of Network Automation as We Know (And I Feel Fine)

by Moderator Moderator ‎07-25-2017 07:38 PM - edited ‎08-03-2017 07:16 PM

c997b419-bell-system-switchboard-1943.jpg

 

  

This article was originally posted on July 5th on The New Stack at https://thenewstack.io/end-network-automation-know-feel-fine/

 

 

Network automation does not an automated network make. Today’s network engineers are frequently guilty of two indulgences. First, random acts of automation hacking. Second, pursuing aspirational visions of networking grandeur — complete with their literary adornments like “self-driving” and “intent-driven” — without a plan or a healthy automation practice to take them there.

 

Can a Middle Way be found, enabling engineers to set achievable goals, while attaining the broader vision of automated networks as code? Taking some inspiration from our software engineering brethren doing DevOps, I believe so.

 

HOW NOT TO AUTOMATE

 

There’s a phrase going around in our business: “To err is human; to propagate errors massively at scale is automation.”

Automation is a great way for any organization to speed up bad practices and #fail bigger. Unfortunately, when your business is network ops, the desire to be a cool “Ops” kid with some “Dev” chops — as opposed to just a CLI jockey — will quickly lead you down the automation road. That road might not lead you to those aspirational goals, although it certainly could expand your blast radius for failures.

 

Before we further contemplate self-driving, intent-driven networking, and every other phrase that’s all the rage today (although I’m just as guilty of such contemplation as anyone else at Juniper), we should take the time to define what we mean by “proper” in the phrase, “building an automated network properly.”

 

If you haven’t guessed already, it’s not about writing Python scripts. Programming is all well and good, but twenty minutes of design often really does save about two weeks of coding. To start hacking at a problem right away is probably the wrong approach. We need to step back from our goals, think about what gives them meaning, apply those goals to the broader picture, and plan accordingly.

 

To see what is possible with automation, we should look at successful patterns of automation outside of networking and the reasons behind them, so we may avoid the known bad habits and anti-patterns, and sidestep avoidable pitfalls. For well-tested patterns of automation, we needn’t look any further than the wealth of knowledge and experience in the arena of DevOps.

 

It matters what we call things. For better or worse, a name focuses the mind. The overall IT strategy to improve the speed, resilience, quality and intelligence of our applications is not called automation or orchestration. While ITIL volumes make their steady march into museums, the new strategy to enable business speed and smarts is incontrovertible, and it’s called DevOps.

 

Initially that term may invoke a blank page or even a transformation conundrum. But you can learn what it means to practice successful DevOps culture, processes, design, tooling and coding. DevOps can define your approach to the network, and is why we ought not promote network automation (which could focus the mind on the wrong objectives) and instead talk about DevNetOps as the application of patterns of DevOps applied to networking.

 

NETWORKS AS CODE

 

The idea of infrastructure-as-code (IaC) has been around for a while, but surprisingly has seldom been applied to networking. Juniper Networks (where I hang my hat) and other networking vendors like Apstra have made some efforts over the years to move folks in this direction, but there is still a lot of work to do. For example, Juniper has had virtual form factors of most series of hardware systems, projects like Junosphere for network modeling in the cloud (many of us now use Ravello), and impressive presentations on IaC and professional services consulting. Juniper’s senior marketing director Mike Bushong (formerly with Plexxi) wrote about the network as code back in 2014.

 

IaC is generally well applied to cloud infrastructure, but it’s way harder to apply to bare metal. For evidence of this, just look at Triple-O, Kubernetes on Kubernetes, or Kubernetes on OpenStack on Kubernetes! That bottom, metal layer is quite the predicament.

 

To me, this means in networking, we should be easily applying IaC to software defined networking (SDN). But can we apply it to our network devices and manage the physical network? I asked Siri, and she said it was a trick question. As an armchair architect myself, I don’t have all the answers.  But as I see it, here are some under-considered aspects for designing networks as code with DevNetOps:

 

1. TOOLING

 

In tech, everyone loves shiny objects, so let’s start there. Few network operators — even those who have learned some programming — are knowledgeable about the ecosystem of DevOps tooling, and few consider applying those same tools to networking. Learning Python and Ansible is just scratching the surface. There is a vast swath of DevOps tools for CI/CDsite reliability engineering (SRE), and at-scale cloud-native ops.

 

2. CHAIN THE TOOL CHAIN: A PIPELINE AS CODE

 

When we approach the network as code, we need to consider network elements and their configurations as building blocks created in a code-development pipeline of dev/test/staging/production phases. Stringing together this pipeline shouldn’t be a manual process; it should be mostly coded to be automatic.

 

As with software engineering, there are hardware and foundational software elements with network engineering, such as operating systems that the operator will not create themselves, but rather just configure and extend. These configurations and extensions, with their underlying dependencies, can be built together, versioned, tested, and delivered. Thinking about the network as an exercise in development, automation should start in the development infrastructure itself.

 

3. IMMUTABLE INFRASTRUCTURE

 

Virtualization and especially containers have made the concept of baking images very accessible, and immutable infrastructure popular. While there is still much work to do with network software disaggregation, containerization, and decoupling of services, there are many benefits of adopting immutable infrastructure that are equally applicable to networking. Today’s network devices are poster children for config drift, but to call them “snowflakes” would be an insult to actual snowflakes.

 

Applying principles of immutable infrastructure, I imagine a network where each device PXE-boots into a minimal OS and runs signed micro-service building blocks. Each device has declarative configs, decoupled secret management and rotation, and logging and other monitoring data with good overall audit ability and traceability — all of which is geared to take the network off the box ASAP.

 

Interestingly, practices such as SSH’ing into boxes would be rendered impossible, and practices that “savvy” network automators do today like running Ansible playbooks against an inventory of devices would be banished.

 

4. UPGRADES

 

Upgrades to network software and even firmware/microcode on devices could be managed automatically, by means of canary tests and rolling upgrade patterns. To do this on a per-box or per-port basis, or at finer levels of flows or traffic-processing components, we need to be able to orchestrate traffic balancing and draining.

 

If that sounds complex, we can make things simpler. We could treat devices and their traffic like cattle instead of pets, and rely on their resilience. Killing and resurrecting a component would restart it with a new version. While this is suitable for some software applications, treating traffic as disposable is not yet desirable for all network applications and SLAs. Still, it would go a long way toward properly designing for resilience.

 

5. RESILIENCE

 

One implication of all this is the presence of redundancy in the network paths.  As with any networking component, that’s very important for resilience. Drawing inspiration from scale-out architectures in DevOps and the microservices application model, redundancy and scale would go hand-in-hand by means of instance replication. So redundancy would neither be 1:1 nor active-passive. We should always be skeptical of architectures that include those anti-patterns.

 

Good design would tolerate a veritable networking chaos monkey. Burning down network software would circuit-break to limit failures. Killing links and even boxes, we would quickly re-converge as we often do today, but dead boxes, dead SDN functions or dead virtual network functions would act like phoenix servers, rising back up or staying down in case of repeated failures or detected hardware failures.

 

The pattern for preventing black-swan event failures is to practice forcing these failures, and thus practice automating around them, so that the connectivity or other network service and its performance is tolerant and acceptably resilient on its own SLA measuring stick, whatever the meta-service in question may be.

 

DOING DEVNETOPS

 

In each one of these above topics lies much more complexity than I will dive head-first into here. By introducing them here, my aim has been to demonstrate there are interesting patterns we may draw from, and some operators are doing so already. If you’ve ever heard the old Zen Buddhist koan of the sound of one hand clapping, that’s the sound you’re likely to hear from your own forehead, once the obviousness of applying DevOps to DevNetOps hits you squarely in the face.

Just as the hardest part of adopting DevOps is often cited to be breaking off one manageable goal at a time and focusing on that, I think we’ll find the same is true of DevNetOps. Before we even get there in networking, I think we need to scope the transformation properly of applying DevNetOps to the challenges and design of networking, especially with issues of basic physical connectivity and transport.

 

While “network automation” leads the mind to jump to things like applying configuration management tooling and programming today’s manual tasks, DevNetOps should remind us that there is a larger scope than mere automation coding.  That scope includes culture, processes, design and tools. Collectively, they may all lead us to a happier place.

 

This article was originally posted on July 5th on The New Stack at https://thenewstack.io/end-network-automation-know-feel-fine/

 

Title image of a Bell System telephone switchboard, circa 1943, from the U.S. National Archives.

 
 

Announcements
Juniper Networks Technical Books
Labels
About the Author
  • Prior to Juniper acquisition, Ankur was the Founder and CEO of Contrail Systems Inc - a pioneer in standards based network virtualization and scale-out networking software. Ankur has over 15 years of experience in building world-class networking products and leading high performance teams. Prior to Contrail, Ankur served as Chief Technology Officer and VP of Engineering at Aruba Networks, where he played critical roles in the rapid expansion of team, products, and global businesses. Before Aruba, Ankur helped drive Juniper’s initial entry into and expansion of the Ethernet Switching market. Ankur received his MSEE from Stanford University & BSEE from the University of Southern California.
  • David Noguer Bau is the head of Telco Vertical Marketing at the SP Strategic Marketing team in Juniper Networks. He has extensive experience in Service Provider network evolution and regularly runs executive sessions with technical and marketing teams of important telecom operators to accelerate the adoption of virtualisation. David is based in Barcelona and has over 15 years of experience in the telecommunications sector. Prior joining Juniper Networks, Mr. Noguer Bau spent seven years at Nortel where he was a Business Development Manager specializing in Carrier Ethernet and Broadband areas. Before Nortel he worked at Eicon-Dialogic as Technical Manager in Spain. David has been the Country Marketing Chair at Metro Ethernet Forum for Spain. Mr. Noguer has wide experience speaking at international Conferences. He was graduated as Computer Engineer by Universitat Autonoma de Barcelona (UAB) and has an executive MBA from EADA Barcelona and executive education at the Thunderbird School of Global Management (Arizona) and the Henley Business School (UK). The views expressed here are my personal opinions , have not been reviewed or authorized by Juniper Networks and do not necessarily represent the views of Juniper Networks.
  • Donyel Jones-Williams is the Director of Service Provider Product Marketing Management overseeing all of Juniper's Service Provider Products for Juniper Networks. In this role, he leads all of the internal and external marketing activities for Juniper with respect to routing, automation, SDN and NFV. Prior to joining Juniper Networks in January 2014, Donyel was a Senior Product Line Manager for Cisco Systems with in the High End Optical Routing Group managing product lifecycle for multiple products lines helping telecom providers operate efficiently and effectively including; ONS 155xx Product Family, ONS 15216, ONS 15454 MSTP, Carrier Packet Transport Product Family, ME 2600x, & ASR 9000v. He also negotiated favorable agreements with 3rd-party vendors furnishing components and parts and conducted both outbound and inbound marketing (webinars, case study-development, developed and delivered both business & technical at Cisco Live 2005-2012). Donyel graduated from California Polytechnic State University-San Luis Obispo with a Bachelor of Science in Computer Science. While attending Cal Poly SLO he was a collegiate student athlete playing football as a wide receiver and a key member of the National Society of Black Engineers. Donyel is now an active volunteer for V Foundation.
  • Remarkably organized stardust. https://google.com/+JamesKelly
  • Jennifer Blatnik is vice president of cloud, security and enterprise portfolio marketing at Juniper Networks with focus on enterprise deployments of security, routing, switching, and SDN products, as well as cloud solutions. She has more than 20 years of experience helping enterprises solve network security challenges. Before joining Juniper, Jennifer served multiple roles at Cisco Systems, Inc., including directing product management for security technologies aimed at small to medium enterprises, as well as supporting managed services, cloud service architectures and go-to-market strategies. She holds a B.A. in Computer Science from University of California, Berkeley.
  • Jerry oversees all aspects of OpenLab which serves as a catalyst to spark the development of new innovative software applications or solutions that leverage the power of SDN/network programmability and intelligence. OpenLab is unique within Juniper and with its polished facility, globally accessible lab, and educational programs – such as the SDN “hackathons,” it serves as a tool for customer, partners, and academia. Prior to this position, Jerry led the development, management and marketing of the company’s strategic partnerships for video/unified communications, optical networking, and content/media delivery. In addition to handling the day-to-day oversight of the partnerships, he established new cross-partner go-to-market processes to drive and manage joint field opportunities. Before joining Juniper, Jerry led the Lucent Technologies application hosting/service provider marketing organization. He has over 25 years of experience in the data networking field with a focus on strategic alliance development, marketing, and technical field support. Jerry possesses a BS degree in Computer Science from St. John’s University in New York. He is active as a Juniper ambassador within the technology and academic community which includes advisory board positions with both NJIT and Rutgers in New Jersey.
  • I have been in the networking industry for over 35 years: PBXs, SNA, Muxes, ATM, routers, switches, optical - I've seen it all. Twelve years in the US, over 25 in Europe, at companies like AT&T, IBM, Bay Networks, Nortel Networks and Dimension Data. Since 2007 I have been at Juniper, focusing on solutions and services: solving business problems via products and projects. Our market is characterized by amazing technological innovations, but technology is no use if you cannot get it to work and keep it working. That is why services are so exciting: this is where the technology moves out of the glossy brochures and into the real world! Follow me on Twitter: @JoeAtJuniper For more about me, go to my LinkedIn profile: http://fr.linkedin.com/pub/joe-robertson/0/4a/34a
  • Mark Belk is the National Government Chief Architect at Juniper Networks
  • Mike Marcellin is Senior Vice President and Chief Marketing Officer, leading the global marketing team responsible for marketing Juniper’s product and services portfolio and stewarding the brand, driving preference for Juniper in the market, training our partners and account teams, and developing a differentiated information experience for our customers. Before joining the global marketing organization, Marcellin led business strategy and marketing for Juniper’s industry-leading portfolio of high-performance routing, switching and security products. Prior to joining Juniper in 2010, Marcellin served as Vice President of Global Managed Solutions for Verizon, where he oversaw product development and marketing of its managed IP networking, hosting, security and IT solutions for businesses around the world. He also served as Vice President of Global Product Marketing for Verizon Business, executive director of Verizon Business’ IP and Ethernet portfolio as well as leading the company’s eCRM marketing division. Marcellin began his career with MCI in 1994. Marcellin is a Board Member for the Telecommunications Industry Association and a Board Member of US Ignite, an NSF-sponsored initiative. Marcellin holds two patents and was a Rodman Scholar at the University of Virginia, where he received a bachelor of science degree with distinction in systems engineering. He is based in Sunnyvale, California.
  • I love the intracacy and intimacy of succesful communications. Why and how people engage with each other is fascinating. I am also consumed with the way IT changes behaviours, values and expectations in society. I bring this sense of wonder to my role in EMEA Service Provider Marketing Programs at Juniper Networks. Down time: My passions are music, reading, politics, Derby County and playing the guitar (and the harmonica). You can follow me elsewhere: twitter: @neilpound my personal blog: http://neilpound.tumblr.com/ my LinkedIn account: Neil Pound
  • Paul Obsitnik is Vice President of Service Provider Marketing for Juniper Networks Platform Systems Division (PSD), responsible for the marketing of Juniper’s portfolio of high performance routing, switching, and data center fabric products to Service Providers globally. Paul's team is responsible for marketing strategy, product marketing, go-to-market planning, and competitive analysis worldwide for the Service Provider segment. Obsitnik has extensive experience in marketing, sales and business development positions with a proven track record in creating technology markets. He has served in senior marketing and sales management positions at several companies including BridgeWave Communications, ONI Systems, NorthPoint Communications and 3Com. Paul holds a Bachelor of Science with Honors in Electrical Engineering from the United States Naval Academy and a Master of Business Administration from the Harvard Graduate School of Business. Obsitnik is based in Sunnyvale, California.
  • Praful Lalchandani is a Product Manager at Juniper Networks focussing on the Data Center portfolio. Praful is a seasoned veteran in the networking industry, with experience spanning over 15 years building networking products and helping service providers, cloud providers and enterprises with their networking requirements.
  • Pratik Roychowdhury currently leads product management for Juniper's SDN and Cloud Software product namely Contrail. He has been with Juniper Networks for the last six years, leading product management activities for Juniper’s Network Virtualization and Network Programmability products and taking some of these products from concept to release. Overall, Pratik has spent 16+ years in the hi-tech industry assuming various roles including product development at Citrix, strategy & product management at early stage start-ups, and technology investment banking at UBS. Pratik has a B.Tech in Electrical Engineering from Indian Institute of Technology and an MBA from Univ of Michigan, Ann Arbor (Ross School of Business).
  • VP of engineering, Juniper Networks & founder, AppFormix Entrepreneur and founder with successful exits from two networking startups. Sumeet holds more than 20 patents with technologies implemented in shipping products and has received numerous awards from organizations as diverse as MIT and Interop. His AppFormix team at Juniper Networks is shipping an automated, real-time monitoring environment that uses AI and machine learning to autonomously mitigate application and network function issues before they impact QoS or user experience.