Talk about changes in Software Defined Infrastructure, given in China 2015

1. Software Defined
Infrastructure
Mark Burgess
Professor, PhD, BSc

2. Trends and solutions for networks in an NFV/SDN era
• O - Operation,
• M - Maintenance,
• P - Provisioning

3. • 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 …

4. 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)

5. There are no simple answers:
Technology is easy, people are difficult!

6. Table of contents
I. The business challenge
II. The cultural challenge
III.The technical challenge
IV. Infrastructure fabrics

7. I. The business challenge

8. An on-going business transformation
( )

9. Hypothesis driven deployment in a world of smart infrastructure

10. Paris
Paris

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

12. Irregular and high risk
Regular and low risk

13. What story are you trying to tell?

14. II. The cultural challenge:
getting unstuck

15. Infrastructure
culture
Addressability
Latency
Connectedness
Garbage collection
Normalization

16. Engineering focus

17. Town
planning
Business focus

18. CAD
CAM

19. Stylesheets for infrastructure

20. “Functional” systems have two aspects
Semantics ( )
and
Dynamics ( )

21. DevOps

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

23. Convergence
Infrastructure
(ops)
Intent/function
(dev)
Configuration drift
Prep/runtime
“Consensus”
Unintended change
Emergent side effects
Semantics ( )

24. Continuity
Availability
(ops)
History
(dev)
Geography (space)
Latency (time)
Usability (consistent)
Compatibility
Persistence of worlds
Dynamics ( )

25. • Convergence ( )
• to a desired end-state / promised outcome
• Divergence (branching decisions) ( )
• intentionally and unintentionally diverging
Competing forces

26. Controlled and uncontrolled
• Diverging chain reactions ( )
• (branching, many-worlds)
• Convergence to a target ( )
• (possibly parallel sinks)

28. Deployment or change management?
Divergent ( )

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

30. Technology should be simplicity

31. Significant innovation doesn’t happen until humans change
their habits, or get out of the way …
Human Identity inertia ( )

32. III. The technical challenges

33. Technical challenges
1.Scale
2.Complexity
3.Knowledge

34. Atoms ( )
local information,
autonomous
Autonomy ( )
freedom to act without
dependency
Promises converge ( )
Modelling intent (semantics)

35. Thinking in promises versus impositions
Impose:
unpredictable
Promise:
predictable policy

36. Many parts with
STRONG COUPLING
increases complexity!

37. Coupling - ecosystem

39. Don´t confuse tidiness with resilience

40. Don´t confuse untidiness with disorder

41. Organization is optimization with constraints
Autonomous agents that keep promises

42. 1. Scaling
Vertical
Horizontal
Simple
Complex

43. 2. Complexity
Weak coupling, and clear relationships
Encapsulation
Tunnels
VxLAN
GRE
EVPN

44. Centralized
(Vertical)
Humanized
Points of service
Identities
Home
Local
Intentional
Decentralized
(Horizontal)
Dehumanized
Logistics
Replicas
Storage
Non-local
Emergent

45. Central BRAIN …
(vertical scaling, strong coupling)

46. Decentralized Society ….
(horizontal scaling, weak coupling)

47. 3. Knowledge

48. Parallel
Serial
The story …
SSH
cron jobs
containers
hands-on
3. Knowledge
Sem
antics (
)
Dynam
ics(
)

49. IV. Infrastructure fabrics

50. 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)

51. 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

52. 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)

53. Sharing resources
How does workload affect the
needs for resource sharing?
Where to put workloads and data to
best tell the business story?

54. 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

55. 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)

56. Bad semantics ( )
L3 subnets confused with host groups
Scalabilty
Summarization

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

58. 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)

59. High density workloads

60. Middle-boxes, “network functionality”
Load balancers —> Firewall

61. 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

62. Load balancing by cooperation
Imposition —> Promises

63. Firewall by cooperation
Imposition —> Promises

64. Microservices
Autonomous tenants .. many
autonomous agents rather than
a top down control
Strong vertical integration for
human ownership
Weak horizontal integration for
scale

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

66. Namespaces ( )

67. Technology should be simplicity

68. Tenant networks

69. Clos non-blocking fabrics (I)

70. 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");
}

71. Complexity (strong coupling) means cost

72. Clos non-blocking fabrics (II)

73. Cable-Free Clos non-blocking fabrics (III) ?
Weak coupling

74. Addresses that reflect location

75. 3d printed datacenter

76. 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

77. Join the discussion …