www.isocore.com/mpls2013

Heterogeneous Self-Service Automation for SDN Dev/Test

Alex Henthorn-IwaneQualiSystems

alex.h@qualisystems.com

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