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
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Â
Functional Ops - the cake is a lie
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
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
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