software defined infrastructure
TRANSCRIPT
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 …