heterogeneous self-service automation for sdn dev/test
DESCRIPTION
TRANSCRIPT
www.isocore.com/mpls2013
Heterogeneous Self-Service Automation for SDN Dev/Test
Alex Henthorn-IwaneQualiSystems
SDN Ties Network to App LifecycleApplication Lifecycle is Agile
Network as Utility• Waterfall timeframes
OTT NFV CUST OSS/BSS
Dev/Test Cycle
Network as API• Agile timeframes• Implies automation
+
Automation Challenge: SDN Evolution
Multi-GenerationalHeterogeneous
Multi-VendorNetworks
Multi-GenerationalHeterogeneous
Multi-VendorNetworks
+SDN
BEFORE AFTER
MagicalThinking
Automation Challenge: Fragmentation
Cloud/SDN Stacks
Code
AutomationTools
Automation Challenge: Networking
A “stack” is not the same as a topology
Most automation approaches don’t fundamentally understand “topologies”
NFV will create complex topologies
Multiple controllers—more complex
Cross-domain—even more complex
Network teams have few programmers, majority are non-programmers
Programmer bottleneck
Knowledge not systematized
Non-programmer productivity:• Limited, dependent, silo’d
Hard to sustain automation projects
Automation Challenge: Code-Centric
Heterogeneous SDN Self-Service Automation
SDN Self-Service Automation
OTT NFV CUST OSS/BSS
SDN App Dev/Test CyclePurpose:
Increase agility of SDN app dev/test cycles
What’s Needed for SDN Self-Service Automation?
Integrated resource mgmt. and workflow automation
• Non-programmer friendly
Programmer-maximizing, sustainable approach
Hybrid driver model
• Arbitrary topology creationo Choose from resource inventoryo SDN switches & controllerso Legacy, non-SDN switches and routerso VMs, servers, storage, bare metal, etc.
• Visual workflow authoringo Any actiono Provisioning
• Hierarchical Integration: o Workflows can call topologies as objects
Integrated Resource Mgmt & Workflow
o Continuous Integrationo Testing
Highly flexible, non-programmer friendly
Both Resources & Actions as Objects• Infrastructure resource inventory• Drivers: infrastructure resources (VMs,
servers, storage, cloud, networking)• Provisioning actions (such as provisioning
VM)• Testing tasks (such as running a traffic
load test)
Limited scope of object functionality• Easy to maintain
Organized in a shared library• High re-use
Highly Sustainable Object Library Approach
Combination of pre-packaged device drivers with easy driver creation
Independent driver creation:• Integrates and “objectizes” any API• Import existing scripts (TCL, python, etc.)
—no “starting from zero”• Easy to capture and objectize CLI, SNMP,
terminal interactions
Hybrid Driver Model
Cloud-based SDN API validation via self-service catalog
Offers consistent, reusable topologies of SDN switches and controllers for app developers & testers
• On demand
• Auto-baselined
• Back-end built on software-driven test lab
Current Use Case: SDN Sandbox for API Validation
SDN Application 1
SDN Application 2
Sandbox 1 Sandbox 2
This model is applicable to pre-production testing
Test Labs: Indicator of Agility
Equipment Reservation
System
Testbed Design System
Connectivity Mgmt System
Provisioning System
Highly Manual, Inefficient,
Low-Utilization Infrastructure
Software-Defined,Self-Service Ready
Infrastructure CloudsOR
Automation Maturity Model
Local&
Manual
Level 1
Ad Hoc
Level 2
Shared
Software-Driven Resource Mgmt
Continuous Integration
Level 3
Operational
Object-Library Automation
Practice
Continuous Delivery of End-to-End Environments
Level 4
Enterprise
Multi-Lab Resource
Consolidation
Lab as a Service
Level 5
Strategic
Agile Customer Support and Collaboration
Sales Enablement
Continuous Deployment