A way too long but entertaining talk given at the September 2015 Cloud Foundry Meetups in Vancouver and Calgary, Canada. Content is a mashup of my own slides and from many colleagues @ Pivotal.
2. 2
YOUR HOST
2
Stuart Charlton
@svrc
Pivotal Software, my dream company
Led IT Ops & Cloud Architecture
at a Railway (long story)
Former CTO of an early, tragically
executed startup
Assistant in the destruction of the
global economy while on Wall Street
ex-BMC, BEA, Rogers, Infusion
3. PRIOR TO TAKEOFF
• There are many opinions, these are mine
• Some nuance emphasized, some lost
• There will be pictures of nude containers
• There will be digging into Cloud Foundry
3
5. AND YET…
• amazon.com
• Mean time between deployments: 11.6s
(in 2011, it’s better now)
• Max deployments in a single hour: 1,079
• Mean hosts receiving a deploy: 10,000
• Max hosts receiving a deploy: 30,000
5
6. WHY WE ARE HERE
• All businesses are software businesses
or losing to one that is
• Demands are getting “impossible” (Mobile, IoT)
• We keep making the same mistakes
• We must deploy at scale quickly and safely
• We (devs/ops) must reclaim our lives from the
mess we’ve made
6
7. THERE’S A LOT OF
CONFUSION OUT THERE
• Hopefully this talk gives a useful roadmap
• Where do things fit, how things “sort of” work
• Be able to call bullshit on statements like…
• X is going to take over the world
• It’s game over for Y
• This one weird trick is all you need
7
8. CLAIMS
• The current trend of the IT industry is to
forcefully eliminate IT operations as we
traditionally know it*
• Stop feeding blood to the machines
• Stop sweating over config/change management
• Evolving from toolchains to platforms
• Leverage: Instead of “operating” software,
we build and maintain
software that operates the software
• *inspired by the professional movements in devops, microservices, continuous delivery;
provocative wording borrowed from Todd Underwood (Google) and his PostOps LISA 2013 talk
8
9. SO?
• We all have operating platforms
• Not everyone’s platform is great
• What makes a platform good?
• Patterns and Constraints in Context
• Encourages good architecture
• Opinionated, not free form
• Will you build your own,
or join a community? 9
10. THIS TALK
• Let’s design a cloud native platform
• Just these easy steps…
• Interlude: Two philosophies of systems
• Converged and Immutable
• Interlude: What’s in a Container?
• Containers, Docker, Droplets
• Interlude: Schedulers for Fun and Profit
• Cloud Foundry Diego
• Combining this all into Cloud Native Platforms
• Designing for Cloud Native 10
11. LET’S DESIGN A CLOUD
NATIVE PLATFORM
In the time allotted
We Hope
11
13. FOLLOW THE
THOUGHT CHAIN
• Some people started solving problem X
and then moved to problem Y
13
14. FOLLOW THE MONEY
• Some people tried to solve problem X,
found it hard to sell or get funding,
moved to problem Y
• This can occur up or down the value chain
14
16. 1. CONVERGENT CONFIG
MANAGEMENT
• Aka “These Scripts Need to Grow Up”
16
Model&Oriented Action&Oriented
• Focused on single server config
17. 2006-2010
CLOUDS ARE FORMED,
MORE THINGS TO DO
• Assume you have an Infrastructure Cloud
• Servers, Networks, Storage, Disks
• On Demand, Fungible Resources
• Many nuances & details here matter
but we need to punt on them today
17
18. 2. CLOUD
ORCHESTRATION
• Make the clouds sing
• “I need X disk attached to Y compute on Z
network”
18
Cloud Formation / HEAT
Terraform / BOSH
19. DAWN OF TIME-2015
“I HATE MY PACKAGE
MANAGER”
• Slow, versioning, dependencies, hard to
build, hard to share, etc.
• I know, I’ll build a new package manager!
19
20. 3. VARIOUS UNITS OF
SHARE, INSTALL, DEPLOY
• There are basically six types
• Deployment Artifact
• OS Package Installer
• OS Container
• Tarball/ZIP
• VM Image
• Composite Release 20
21. WHAT’S IN A PACKAGE
STANDARD?
• File System Format
• Metadata
• Build Script
• Registry
• Dependencies
• Metadata
• Processes
21
22. COMPARING PACKAGES
22
Droplet VM Image Docker
File System Tarball Block Tarball deltas
Metadata YES OVA YES
Build Script Buildpack Various Dockerfile
Registry Droplet Reg Various Docker Reg
Dependencies NOPE NOPE NOPE
Processes YES OVA YES
23. WHAT DOCKER GOT
RIGHT AS A PACKAGE
• Vendor your dependencies
• Make sharing fast (copy-on-write / deltas)
• Make launching fast (OS containers)
• Enable social sharing of full runtimes
(Docker hub)
• A cross-distro “swiss army knife” package
23
24. WHAT DROPLETS GOT
RIGHT AS A PACKAGE
• Droplets: Heroku / Cloud Foundry
• Vendor your dependencies
• Make updating fast (deltas of your dev artifacts)
• Make launching fast (OS virtualization)
• Awesome developer experience
(standard build/deploy in 60 sec that still uses
your familiar artifacts) 24
26. OPEN QUESTIONS
• Do you want to run just any Docker image?
• Opaque contents are a nightmare to maintain
• Opaque contents are a nightmare to secure
• Performance with layered Union FS
• Containers are successful in production with the
proper constraints
26
27. INTERLUDE 2:
TWO PHILOSOPHIES
• Converged Config Managers were
created before clouds were a big deal
• Definitely before containers were a big deal
• Didn’t really have ability to config clouds
(they do now)
• Clouds changed some assumptions on
how we treat servers 27
28. TRADITIONAL INFRA
• “collection of pets”
• pet them, hug them, love them, name them
after Lord of the Rings characters
• upgrade them when they die
28
30. CONVERGED CONFIG
• Phoenix servers, should be able to re-create
• In practice, lots of silent dependencies
• Day 2? Each evolution requires tinkering on
the manifests & scripts
• Constraints, opinions are up to the user
30
31. IMMUTABLE INFRA
• Immutable by contract, not fully
• s/immutable/(disposable | prefabricated)/
• e.g. assume these things never
change, and if they do, kill them
• Ops tinkering happens in the build
• Ops pipeline rarely changes,
just deploy new stuff
• Use load balancer / router for control 31
113. ?
Garden-Windows
provides a container experience for Windows 2012
that will only get better with Windows 2016
allows us to build a cf push experience
117. 5. STRUCTURED
PLATFORMS AND
FRAMEWORKS
• ie. something that will encourage good
architecture and operational constraints
• Don’t do undifferentiated heavy lifting
• Be productive right away
• Join a community making these design
decisions together 117
133. SUMMARY OF PLATFORM
CAPABILITIES
• Immutable Infrastructure all the way
down
• VMs AND Containers
• BOSH-like management AND container
scheduler AND reliable container staging/
build
133
134. SUMMARY OF PLATFORM
CAPABILITIES
• Layer 7 Dynamic
Routing/Load Balancing
(Layer 3 is nice too)
• Log Aggregation
• Multi-Tenant API
• Authentication & Authorization
134
136. THE CHOICE
• Build all that from tools
• Hope you get the right constraints &
patterns nailed
• Adopt a structured platform
• Fill any gaps with toolchain
136
137. DESIGNING FOR
CLOUD NATIVE
• 12 Factor
• Microservices
• Support Services
• Discovery, Config, Circuit Breaking
137
138. 12 FACTORS:
A CONTRACT
138
•One Codebase/Many Deploys
•Explicit Isolated Dependencies
•Config via Environment
•Attached Backing Services
•Dev/Prod Parity
•Separate Build/Release/Run
•Ephemeral Processes
•Export Services via Port Bindings
•Scale Out via Processes
•Disposable Instances
•Logs == Event Streams
•Admin Tasks == Processes
Factors for the Developer Factors for App Architecture
140. MONOLITHIC
ARCHITECTURES
• Modularity Dependent Upon Language /
Frameworks
• Change Cycles Tightly Coupled
• Inefficient Scaling
• Can Be Intimidating to New Developers
• Obstacle to Scaling Development
• Requires Long-Term Commitment to
Technical Stack 140
142. MICROSERVICES
• Services Oriented Architecture AND
Services-Oriented Delivery
• Modularity Based on Bounded Contexts
• Enable Frequent Deploys, Efficient Scaling
• Individual Components Less Intimidating to New
Developers
• Enables Scaling of Development…
142
143. CONWAY’S LAW
143
Any organization that designs a system (defined broadly)
will produce a design whose structure is a copy of the
organization's communication structure.
Melvyn Conway, 1967
http://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities
144. SPAN SILOS WITH
MICROSERVICES
144
Data Access
Service
HTML JavaScript MVC
Service
UISpecialists
Middleware
Specialists
DBAs
BusinessCapability
BusinessCapability
BusinessCapability
Siloed
Functional
Teams
http://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities
Siloed
Application
Architectures
Cross-
functional
Teams
Microservice
Architectures
145. PARTITIONING
• By Noun (e.g. product info service)
• By Verb (e.g. shipping service)
• Single Responsibility Principle
(http://programmer.97things.oreilly.com/wiki/
index.php/
The_Single_Responsibility_Principle)
145
146. YOU MUST BE THIS TALL
•RAPID PROVISIONING
•BASIC MONITORING
•RAPID APPLICATION
DEPLOYMENT
•DEVOPS CULTURE
146
http://martinfowler.com/bliki/MicroservicePrerequisites.html
https://www.flickr.com/photos/gusset/3723961589
147. ONE PIECE
CONTINUOUS FLOW
147
Product
Mgr
UX Dev QA DBA
Sys
Admin
Net
Admin
Storage
Admin
BUSINESS CAPABILITY TEAMS
USING MICROSERVICES
PLATFORM OPERATIONS
TEAM
Self
Service
API
148. SUMMARY
• The current trend of the IT industry is to forcefully eliminate IT
operations as we traditionally know it
• Cloud Native Applications
• Microservices, Continuously Delivered on a Platform
• Lots of experimentation between the DIY and Structured approach
• Do it Yourself - Evolution of the toolchain approach
• Structured - Community centered around sharing an architecture
codebase & culture
• Cloud Foundry is currently the most successful structured
platform
• Many DIY pieces are growing fast in popularity (Docker, K8S, etc)
148
150. WITH THANKS
150
This presentation includes content / inspiration by:
Matt Stine
Andrew Clay Shafer
Onsi Fakouri
+ many others @ Pivotal
+ Todd Underwood @ Google