Your SlideShare is downloading. ×
A Network Engineer's Approach to Automation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

A Network Engineer's Approach to Automation

2,833
views

Published on

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

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

Published in: Technology

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,833
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
72
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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).
  • Transcript

    • 1. A NETWORK ENGINEER'S APPROACH TO AUTOMATION #NoCLI (not-only CLI) Jeremy Schulman @nwkautomaniac 2013 December
    • 2. Why?
    • 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. 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. COMMUNITY "TRIBES" Admins Users Non-Programmers IT Automation Engineers "DevOps" Quasi-Programmers IT Framework Companies Software Engineers Hardcore-Programmers
    • 6. When?
    • 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. NETWORK AUTOMATION Not Only Configuration Plan & Model ✔ 1 Report ✔ ✔ 5 2 ✔ 4 Troubleshoot Configure & Deploy ✔ 3 Visualize & Monitor
    • 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. What?
    • 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. RIPPED FROM A NET.ENG BLOG Kurt Bales, Senior Network Engineer www.network-janitor.net
    • 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. How?
    • 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. 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. 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. Where?
    • 19. PROJECT DOCUMENTATION Juniper "TechWiki" https://techwiki.juniper.net/Projects/Junos_PyEZ
    • 20. Follow on Twitter: @nwkautomaniac moving soon to github.com/Juniper in Jan 2014