software defined infrastructure

Software Defined Infrastructure

Mark Burgess Professor, PhD, BSc

Trends and solutions for networks in an NFV/SDN era

• O - Operation, • M - Maintenance, • P - Provisioning

• PhD theoretical physics • Professor of Network and System Administration • EMANICS network of excellence • CFEngine founder, computer immunology, promise theory • Industry advisor, researcher, working with SDN leaders • Web: http://markburgess.org

About me …

Some conclusions

• Multi-tenant — self-service systems, built on fabrics

• Fixed and stable infrastructure fabrics

(net+compute+storage)

• Dynamic, virtualized names and services on top

• Get rid of middle-boxes (load-balancers, firewalls)

There are no simple answers:

Technology is easy, people are difficult!

Table of contents

I. The business challenge

II. The cultural challenge

III.The technical challenge

IV. Infrastructure fabrics

I. The business challenge

An on-going business transformation

( )

Hypothesis driven deployment in a world of smart infrastructure

Paris

Paris

“Continuous improvement of software as a stream of releases, always ready for use…”

Continuous delivery is ...

Irregular and high riskRegular and low risk

What story are you trying to tell?

II. The cultural challenge:

getting unstuck

Infrastructure culture

AddressabilityLatencyConnectednessGarbage collectionNormalization

Engineering focus

Town planning

Business focus

CADCAM

Stylesheets for infrastructure

“Functional” systems have two aspects

Semantics ( )

and

Dynamics ( )

DevOps

Semantics ( ) and Dynamics ( ) Desired-state and actual behaviour Dev + Ops What you intend + What actually happens

Convergence

Infrastructure(ops)

Intent/function(dev)

Configuration driftPrep/runtime“Consensus”

Unintended changeEmergent side effects

Semantics ( )

Continuity

Availability(ops)

History(dev)

Geography (space)Latency (time)

Usability (consistent)CompatibilityPersistence of worlds

Dynamics ( )

• Convergence ( )

• to a desired end-state / promised outcome

• Divergence (branching decisions) ( )

• intentionally and unintentionally diverging

Competing forces

Controlled and uncontrolled

• Diverging chain reactions ( )

• (branching, many-worlds)

• Convergence to a target ( )

• (possibly parallel sinks)

Deployment or change management?Divergent ( )

“Continuous delivery requires continuous automation ... not power-assisted intervention”

Intervention vs automation

Technology should be simplicity

Significant innovation doesn’t happen until humans change their habits, or get out of the way …

Human Identity inertia ( )

III. The technical challenges

Technical challenges

1.Scale

2.Complexity

3.Knowledge

Atoms ( )

local information, autonomous

Autonomy ( )

freedom to act without dependency

Promises converge ( )

Modelling intent (semantics)

Thinking in promises versus impositions

Impose:unpredictable

Promise:predictable policy

Many parts with

STRONG COUPLING

increases complexity!

Coupling - ecosystem

Don´t confuse tidiness with resilience

Don´t confuse untidiness with disorder

Organization is optimization with constraints

Autonomous agents that keep promises

1. Scaling

Vertical

Horizontal

Simple

Complex

2. Complexity

Weak coupling, and clear relationships

EncapsulationTunnelsVxLANGREEVPN

Centralized(Vertical)

HumanizedPoints of serviceIdentitiesHomeLocalIntentional

Decentralized(Horizontal)

DehumanizedLogisticsReplicasStorageNon-localEmergent

Central BRAIN … (vertical scaling, strong coupling)

Decentralized Society ….(horizontal scaling, weak coupling)

3. Knowledge

Parallel

Serial

The story …

SSH

cron jobscontainers

hands-on

3. Knowledge

Semantics ()

Dynamics (

)

IV. Infrastructure fabrics

Network designed for low density end-points

• New reality:

• High density datacenter (North-South, East-West)

• Internet of Things

• Push networking (UDP)

• TCP brings more security

• Built on top of Ethernet (bus arch)

Scaling network communication

• Read/retrieve/service portal (promises) • Client-server, anycast

• Publish-subscribe (streaming)

• Caching/CDN: fixed addresses not that important

• Signalling (impositions) • Scales vertically (brute force)

• Fixed addressing important

Summary: From impositions to promise thinking

1. Every processing entity in an infrastructure MUST be individually

addressable (SCALE)

2. Remove middle-boxes (COMPLEXITY)

3. Instead of uninvited impositions, get clients to establish a bond

with a service point (KNOWLEDGE)

Sharing resources

How does workload affect the needs for resource sharing?

Where to put workloads and data to best tell the business story?

The failures of vertical network scaling

• Address scaling -> NAT • NAT -> private addressing • private addressing -> L2 /LAN thinking • L2 focus -> tunnels to extend LANs • tunnels -> dynamic address rewriting • dynamic addresses -> collapse under complexity

SDN is fixated on LAN

• IPv4 a flawed model of LAN/WAN • WAN/(LAN x 2) + ARP • Routing AND L2 tunnels

• IPV6• Peer discovery• L3 Index service

•Hint (CDN)

Bad semantics ( ) L3 subnets confused with host groups

Scalabilty

Summarization

Why LAN doesn’t scale, and why tunnels don’t help

Bad dynamics ( ) Abusing L2 tunnelling

Can’t extend a broadcast group indefinitely

Tunnels don’t really simplify navigation, just make it someone else’s problem

Tunnels: VxLAN, EVPN (MPLS/BGP)

High density workloads

Middle-boxes, “network functionality”

Load balancers —> Firewall

Designed for a sparse hierarchical network

• Designed for North-South traffic model

• Pile weight into single point of failure

• Break end-to-end principle

• Addresses don’t match geography

Load balancing by cooperation

Imposition —> Promises

Firewall by cooperation

Imposition —> Promises

Microservices

Autonomous tenants .. many autonomous agents rather than a top down control

Strong vertical integration for human ownership

Weak horizontal integration for scale

We have to separate end-point names/addresses from transport mechanisms

Namespaces ( )

Technology should be simplicity

Tenant networks

Clos non-blocking fabrics (I)

Pattern based provisioning (e.g. CFEngine)

bundle agent clos { vars:

# Generate the interface lists used on the routers

"spine" slist => expandrange("swp[1-5]", "1"); # point to 5 leafsw "leaves" slist => expandrange("swp[1-2]", "1"); # point to 2 spinesw

interfaces:

spine::

"$(spine)" link_services => ibgp_reflector("server");

ToR::

"$(leaves)" link_services => ibgp_reflector("client"); }

Complexity (strong coupling) means cost

Clos non-blocking fabrics (II)

Cable-Free Clos non-blocking fabrics (III) ?

Weak coupling

Addresses that reflect location

3d printed datacenter

Balance exploration against simple targeted outcomes Automate documentation of intent: policy converges ( )

Watch out for the human storyline ( )

Delegate for tidiness with weak coupling ( )

The future

Join the discussion …