The Layer Cake is a LIE
A functional programming approach
to operations and architecture
Rigid Abstraction Anti-Pattern!
Call to action:
Consider functional interactions
up front in design.
“Abstractions are useful until they are
Cloud Operations since 1999
OpenStack Board Member since 2011
Founder of OpenCrowbar Project (& RackN)
Cloud Culture & Process Blogger
Education: Robotics & Industrial
What is a Layer Cake?
Product Architectural Segmentation
● clean boundaries between services
● upward stacking of dependencies
● Under-layers can create resources
● Services APIs are equally available
● Does not show time component
Leave No Service Behind...
Just keep stacking
layers (and colors) until
you’ve included the
Is everything required?
How do you deploy
Ops is messy, not layered
● There are dependencies between
● 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.
Ops is about inter-connect
● No server/service stands alone
● Not everything is equally
● Order of operations matters
● Connectivity and proximity
● Hidden Interconnects are
Durability and Simplicity are very important characteristics
Top of Rack Switch Fabric
BMC management network
How do we manage inter-
● Accept The Cake is a Lie
● Decompose Big Work
into Small Work
● Do not hide interconnections
● Apply Functional
… 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
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
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
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...)
How does this help?
● Clear contracts between operations
● Replaceable work units (functions)
● No Hidden interconnections
● Deterministic execution (not
● Easier to Test
We still have complexity, but it's
Hidden connections are fatal
East-West vs North-South
E-W is dependency focused vs N-S is control
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
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
Container Orchestration, Oh
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
Functional Ops Take Aways
● Avoid side-effects in Ops scripting
● Establish clear requirements
● Establish contracts for interconnects
● Do not over define “black box” actions
● Embrace orchestration
● When possible, fail fast and small