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!
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
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"
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
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).