This document discusses building an operations framework from scratch if necessary. It recommends using Chef instead if possible. The key components of such a framework would include an API, domain logic, operations implementations, database, and resources to transition between states. Building it as a framework allows others to subclass the core components. Benefits include testability, availability, debuggability, and auditability. Challenges include the work required and integrating with other tools.

1. How To Build Your
Own Ops Framework
(If You Really Have To)
!
@svanderbleek

2. Do You Really Have To?
No
Use Chef

3. Desirables
Testable - Unit, Integration, Acceptance
Available - Bootstraps into cluster, no single point failure
Debuggable - Failure modes for deployments, swap-over
Audit-able - Who/What triggering changes in system

4. Just Chef?
Chef server high availability? Setting it up on your stack
will be non-trivial
Chef-Spec isn’t enough
Cucumber-Chef is cool
Test Kitchen - under rapid development

5. Components
Api - Entry Point, Control
Domain - Business Logic
Ops - Meat
Database - Persistence
App - Frontend

6. Api
Endpoints - Rack GET, POST, PUT etc
Entities - Output JSON Representation
Representations - Consume JSON Representation
Services - Interface to Domain and Ops
Clients - Interface to API for Domain/Ops/Command Line
Execution - Abstract asynchronous implementation

7. Domain
Resources - States and logic
Provisioners - State machines over Resources

8. Ops
Providers - Do steps as commanded by provisioner
Cloud Services - Get things done
Testing Tools - Prove things got done on actual
provisioned resources

9. Database
It’s just a database
stores data
Ok, has the Mappers that map Resources to MongoDB
and back
Can boostrap MongoDB Cluster

10. Resources
Can transition between states
Transitions are also resources (Inception)
Ours: Image, Cluster, Settings, Users, Permissions

11. Providers
Define implementations of each state resource state
Ending states and pending/doing states
Tell provisioner success/failure

12. Provisioner
Control provider flow
Tell client what’s up with resource state
Success and failure are transition events
Run inside Execution with run id of Transition

13. Example Flow
Image :pending
Image :build_pending
Image :building
Image :built

14. Make It A Framework
Just build your own subclasses of Resource/
Provisioner/Provider
And then the same for Entity/Endpoint/Service
Plus Mapper for Database
Ok … This is hard

15. Roadmap
DSL to build Resource/Provisioner
Api side is already DSL, Grape and Grape-Entity
The Frontend needs test coverage
Open Source
Profit?

16. Key Process Benefits
Write acceptance tests using RSpec matchers that run on
instances created by Api
When a deployment fails Api provides ssh access to
machine to diagnose failure
One stop shop for managing settings and service discovery
Failover built in, fundamental construct
Endpoints have Entities, self documenting

17. But
It’s not done yet
Lots of work
Monolithic? How to integrate with small tools team
builds

18. Bootstrap 3 Looks Nice

19. Static App Server, Ember.js with Emblem

20. This will change our life
Someday

21. Cool Sources
Test-Driven Infrastructure with Chef
DevOps Weekly
Just Release It!
Classics: Patterns of Enterprise Architecture/Growing
Object Oriented Software Guided By Tests