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.
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
OFFICE OF THE CIO
IT Automation is Top of Mind
APPLICATIONS DRIVE BUSINESS
Server Automation Hit the "Sweet Spot"
Evolution / Revolution
• Server Virtualization and Cloud
• History over +7 years
• Open-Source Community
built on IT
IT Automation Engineers
IT Framework Companies
TIME TO "LEVEL-UP"
Networking must now find a way to the "Sweet Spot"
Complexity of IT
Tolerance for Human Error
Not Only Configuration
Plan & Model
OFFICE OF THE
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
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
RIPPED FROM A NET.ENG BLOG
Kurt Bales, Senior Network Engineer
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":
Charting a Path to the "Sweet Spot"
simple → complex
• Native Python data types (hash/list)
• Junos specific not required
• XML not required
• Junos specific
• Abstraction Layer
• NETCONF transport only
• Vendor Agnostic
• No abstractions
Junos config in
text, set, or XML
Jinja2 is template
defined by the junos-ez
Juniper + Community
Easily retrieve data and extract as
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
Juniper + Community