A Network Engineer's Approach to Automation


Published on

Exploring a novel approach to bridging the gap between Network Engineers and automating networks

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • This is *not* a story of OpEx reduction. That story is tired and old.w/o IT automation, it's a "Pick Two" scenario: BV + BA = (-BC), too much risk to disrupt the business BV + BC = (-BA), lack of agility, cannot handle competitive pressures BC + BA = (-BV), too much churn to the business prevents growthw/IT automation, you get all three.
  • "DevOps" is considered by some as the "evolution/revolution" of server admin.Networking has not reached our "Pivot Point". SDN, NFV, etc. is talked about as being this Pivot. We haven't made it thru the other side yet.Hubot: http://hubot.github.com/Boxen: http://boxen.github.com/
  • Hard-core typically means classically trained (BSCS/EE)Quasi typically means may or may not be classically trained, but they have the mind to do it, and the mental environment to do itNon means they can't be in the headspace of a programmer, they just want to use tools to get things done.SometimesMr.Blue and Mr.Green are the same guy.
  • the 'day one' using the shell is a real big deal. Asking a Net.Eng to "day one" write programs is hard/non-starter at times. They need to ease into it, and start interactively = CLI like experience. Also writing code requires a specific "headspace" of concentration that is generally not available to Net.Eng due to constant distractions/fire-fighting.
  • http://www.network-janitor.net/2013/11/on-python-networks-and-the-py-junos-eznc-library/
  • http://forums.juniper.net/t5/Network-Automaniac/Python-for-Non-Programmers-Part-1/ba-p/21644
  • Need to cite URL for ncclient.
  • The vast, vast, vast majority of initial users will use the 'unstructured' approach simply to kick-start device configurations (initial config). The Resources are used for lifecycle management of specific items, like adding/deleting VLANs, firewall rules, etc. The Resource map to IT framework tools that require these types of abstractions.At the time of this writing, creating new Resources requires quasi to hardcore programming skills. Work will be done in the framework to make this process easier.
  • Creating Tables and View "widgets" does *NOT* require any programming. It does require someone to create YAML files (structured text) that defines what they want the abstractions to contain. This definition requires the YAML writer to understand the Junos XML structures; but it does not require them to code XML. The "understanding" part is very simple once explained (<command> | display xml rpc) and (<comand> | display xml) or (show configuration <...> | display xml).
  • A Network Engineer's Approach to Automation

    1. 1. A NETWORK ENGINEER'S APPROACH TO AUTOMATION #NoCLI (not-only CLI) Jeremy Schulman @nwkautomaniac 2013 December
    2. 2. Why?
    3. 3. OFFICE OF THE CIO IT Automation is Top of Mind Business Agility Business Velocity Sweet Spot Business Continuity Business Value Lower Cost Reduce Risk Improve Service
    4. 4. APPLICATIONS DRIVE BUSINESS Server Automation Hit the "Sweet Spot" Evolution / Revolution • Server Virtualization and Cloud • History over +7 years • Open-Source Community manually configured ad-hoc bash perl scripting physical, virtual, cloud orchestration puppet, chef salt, ansible, other IT frameworks infra.apps built on IT frameworks (Hubot, Boxen) paradigm pivot-point!
    5. 5. COMMUNITY "TRIBES" Admins Users Non-Programmers IT Automation Engineers "DevOps" Quasi-Programmers IT Framework Companies Software Engineers Hardcore-Programmers
    6. 6. When?
    7. 7. TIME TO "LEVEL-UP" Networking must now find a way to the "Sweet Spot" Service Velocity Complexity of IT Up Time $ Tolerance for Human Error Resource Pools Budgets
    8. 8. NETWORK AUTOMATION Not Only Configuration Plan & Model ✔ 1 Report ✔ ✔ 5 2 ✔ 4 Troubleshoot Configure & Deploy ✔ 3 Visualize & Monitor
    9. 9. OFFICE OF THE NETWORK ENGINEER I am not a "Programmer" I think about the network & complex networking planning I spend a lot of my time fire-fighting the network I need automation tools to help me do my job I know I need to "level-up" with automation but I need something that helps me get started I'd like to use Python since it is shaping up as the standard
    10. 10. What?
    11. 11. NETWORK ENGINEER'S PUNCH LIST • Get started "day one" using Python interactive shell • Do it the way a network engineer thinks and interacts with the network, not like a Programmer/API • Do not require "programmy" knowledge of XML, Junos, NETCONF • Give me "CLI access" if I get stuck, but don't make me use CLI screen-scraping • Give me access to both config and operational data in standard Python types like dictionary (hash) and list • Make it Open-Source so I don't have to wait for "The Vendor" to add/fix things, enable Community
    12. 12. RIPPED FROM A NET.ENG BLOG Kurt Bales, Senior Network Engineer www.network-janitor.net
    13. 13. INTRODUCING "JUNOS PyEZ" Open and Extensible "micro-framework" • Remote device management and "fact" gathering • Troubleshooting, Audit and Reporting • Operational data • Configuration data • Configuration Management • Unstructured config snippets and templates • Structured abstractions • Generalized utilities for file-system, softwareupgrade, secure file copy (scp), etc. Check out the blog series "Python for Non-Programmers": "J-Net Forum"
    14. 14. How?
    15. 15. LAYERED APPROACH Charting a Path to the "Sweet Spot" Python Shell Python script interactive IT Frameworks Custom Applications simple → complex • Native Python data types (hash/list) • Junos specific not required • XML not required junos-pyez open-source, Juniper ncclient open-source, Community • Junos specific • Abstraction Layer • micro-framework • NETCONF transport only • Vendor Agnostic • No abstractions
    16. 16. CONFIGURATION CHANGES Unstructured Junos config in text, set, or XML format "snippets" that contain variables Jinja2 is template engine Structured "snippets" Resources (no variables) Structured abstractions defined by the junos-ez micro-framework Juniper + Community "templates" (merge variables) write-only read-write Junos Configuration
    17. 17. TROUBLESHOOTING, AUDIT, REPORTING Easily retrieve data and extract as native Python Structured abstractions defined by the Junos PyEZ micro-framework Conceptually like database tables and views that define the fields of data you want No coding required to create abstractions Juniper + Community Views Tables Junos Configuration Operational Data read-only
    18. 18. Where?
    19. 19. PROJECT DOCUMENTATION Juniper "TechWiki" https://techwiki.juniper.net/Projects/Junos_PyEZ
    20. 20. Follow on Twitter: @nwkautomaniac moving soon to github.com/Juniper in Jan 2014