The document discusses how a "layer cake" approach to operations and architecture is flawed and advocates for a more functional programming approach. Some key points: - A layer cake assumes clean boundaries and dependencies between services that don't reflect reality, where dependencies exist between layers and connectivity/proximity matter. - Taking a functional programming approach treats operations as mathematical functions with defined inputs/outputs and no side effects, allowing operations to be decomposed, automated generically, and scaled dynamically. - Examples given include defining database configuration and node setup as independent functions that can work for different database/vendor types rather than being tied to specific layers/abstractions. - Embracing functional and orchestration approaches helps make

1. The Layer Cake is a LIE
A functional programming approach
to operations and architecture

2. Rigid Abstraction Anti-Pattern!
Call to action:
Consider functional interactions
up front in design.
“Abstractions are useful until they are
not”

3. Rob Hirschfeld
Cloud Operations since 1999
OpenStack Board Member since 2011
Founder of OpenCrowbar Project (& RackN)
Cloud Culture & Process Blogger
Education: Robotics & Industrial
Engineering

4. What is a Layer Cake?
Product Architectural Segmentation
Aka “Taxonomy”
Assumes:
● clean boundaries between services
● upward stacking of dependencies
● Under-layers can create resources
● Services APIs are equally available
● Does not show time component

5. Leave No Service Behind...
Just keep stacking
layers (and colors) until
you’ve included the
kitchen sink.
Is everything required?
How do you deploy
that?

6. Ops is messy, not layered
● There are dependencies between
layers
● Things are constantly changing
● We have to connect actions together
● Where matters as much as what
It's not just Ops!
Application design is messy too.

7. Ops is about inter-connect
● No server/service stands alone
● Not everything is equally
reachable
● Order of operations matters
● Connectivity and proximity
matters
● Hidden Interconnects are
FAILURES
Durability and Simplicity are very important characteristics
in Ops

8. Network
Abstractions
Standard
Ops
Tool
Chains
Hardware
Abstractions
User
Interface,
Scale,
& High
Availability
Top of Rack Switch Fabric
BMC management network
Custom
APIs
Puppet
Salt,...
SSH
PXE
TFTP
OpenCrowbar
Orchestration
Chef
App
Firmware
O/S
NCC-1701-r
A
F
O
A
F
O
A
F
O
A
F
O
A
F
O
A
F
O
App
F/W
O/S
A
F
O
A
F
O
A
F
O
A
F
O
A
F
O
A
F
O
App
F/W
O/S
A
F
O
A
F
O
A
F
O
A
F
O
A
F
O
A
F
O
App
F/W
O/S

9. How do we manage inter-
connect?
● Accept The Cake is a Lie
● Decompose Big Work
into Small Work
● Do not hide interconnections
● Apply Functional
Programming

10. Functional Programming?
… that treats computation as the evaluation of
mathematical functions and avoids changing-state
and mutable data …
● Defined Inputs & Outputs
● No Side Effects
● Repeatable Actions
● Black Box
http://en.wikipedia.org/wiki/Functional_programming

11. Interchangeable Parts
Functional Design has very early
roots allowing scale operations.
Famously, Eli Whitney
demonstrated how a decomposed
design could be used to speed
assembly of rifles.
Robust designs can be taken apart and put back
together.

12. Functional Ops is Different
The system construction paradigm focuses
on connections and services instead of nodes
and abstraction layers.
It is easier to automate in a generic way
And platforms can scale it dynamically

13. Can't we ignore this? I <3 Cake!
That was the idea for PaaS, but…
● Containers make it worse!
● Smaller Units (“micro-services”)
● Shorter Life Cycles
● More Portable
● Highly Interconnect
Irony Alert: Docker's #1 feature is layering images (not the same thing, but...)

14. How does this help?
● Clear contracts between operations
● Replaceable work units (functions)
● No Hidden interconnections
● Deterministic execution (not
eventual)
● Easier to Test
We still have complexity, but it's
visible
Hidden connections are fatal
RackN
IPMI/BMC
BIOS
RAID
O/S
CMagent(s)
Clients
Network
Customers’ Applications

15. East-West vs North-South
E-W is dependency focused vs N-S is control
focused
East-West is critical when...
● sequence of operations matters
● the control layer is incomplete
● you have multiple control surfaces
● you have circular dependencies
● you have distributed authors

16. Functional Ops Example 1
Database Configuration Functionally
● Setup the Server Service – target network, credentials
● Setup the Client – target network, register client
● Create the Database – credentials, db name, ACL
Base functions work
● even for a cluster
● different BD types
● work independently of each other (DB as a service)
● Cross-reference issues are resolved externally
● Deterministic

17. Functional Ops Example 2
Milestone 6 Milestone 8Milestone 7: “setup NIC”
Node 2
Vendor B
Node 1
Vendor A
A1
B2
C1
D1
A2 A3
A1 A2 A3
B1
D2
C2
A0
B0
A0
C0
A4

18. Container Orchestration, Oh
my.
This area is very turbulent. My thoughts:
1. It’s not clear how to best orchestrate µServices
2. There are a lot of companies/projects in play
3. This approach is different than cloud IaaS
4. I believe it will disrupt virtualization APIs

19. Functional Ops Take Aways
● Avoid side-effects in Ops scripting
● Establish clear requirements
(inputs/outputs)
● Establish contracts for interconnects
● Do not over define “black box” actions
● Embrace orchestration
● When possible, fail fast and small

20. Thank You