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 use...
Rob Hirschfeld
Cloud Operations since 1999
OpenStack Board Member since 2011
Founder of OpenCrowbar Project (& RackN)
Clou...
What is a Layer Cake?
Product Architectural Segmentation
Aka “Taxonomy”
Assumes:
● clean boundaries between services
● upw...
Leave No Service Behind...
Just keep stacking
layers (and colors) until
you’ve included the
kitchen sink.
Is everything re...
Ops is messy, not layered
● There are dependencies between
layers
● Things are constantly changing
● We have to connect ac...
Ops is about inter-connect
● No server/service stands alone
● Not everything is equally
reachable
● Order of operations ma...
Network
Abstractions
Standard
Ops
Tool
Chains
Hardware
Abstractions
User
Interface,
Scale,
& High
Availability
Top of Rack...
How do we manage inter-
connect?
● Accept The Cake is a Lie
● Decompose Big Work
into Small Work
● Do not hide interconnec...
Functional Programming?
… that treats computation as the evaluation of
mathematical functions and avoids changing-state
an...
Interchangeable Parts
Functional Design has very early
roots allowing scale operations.
Famously, Eli Whitney
demonstrated...
Functional Ops is Different
The system construction paradigm focuses
on connections and services instead of nodes
and abst...
Can't we ignore this? I <3 Cake!
That was the idea for PaaS, but…
● Containers make it worse!
● Smaller Units (“micro-serv...
How does this help?
● Clear contracts between operations
● Replaceable work units (functions)
● No Hidden interconnections...
East-West vs North-South
E-W is dependency focused vs N-S is control
focused
East-West is critical when...
● sequence of o...
Functional Ops Example 1
Database Configuration Functionally
● Setup the Server Service – target network, credentials
● Se...
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...
Container Orchestration, Oh
my.
This area is very turbulent. My thoughts:
1. It’s not clear how to best orchestrate µServi...
Functional Ops Take Aways
● Avoid side-effects in Ops scripting
● Establish clear requirements
(inputs/outputs)
● Establis...
Thank You
Upcoming SlideShare
Loading in …5
×

Functional Ops - the cake is a lie

1,115 views

Published on

Apply Function Programming to Operations.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,115
On SlideShare
0
From Embeds
0
Number of Embeds
104
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Functional Ops - the cake is a lie

  1. 1. The Layer Cake is a LIE A functional programming approach to operations and architecture
  2. 2. Rigid Abstraction Anti-Pattern! Call to action: Consider functional interactions up front in design. “Abstractions are useful until they are not”
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. Thank You

×