how the role for devops is evolving
TRANSCRIPT
HOW THE PRACTICES OF DEVOPS ARE EVOLVING
from servers to services
@patrickdebois - Small Town Heroes
Things I did (I’m proud of)
OPSDEV
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
4 areas of improvement
OPSDEV
Area 1: Extend delivery to production
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
OPSDEV
Area 2: Extend operations feedback to project
Area 1: Extend delivery to production
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
OPSDEV
Area 2: Extend operations feedback to project
Area 1: Extend delivery to production
Area 3: Embed Projectknowledge into Operations
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
OPSDEV
Area 4: Embed Operations knowledge into Project
Area 2: Extend operations feedback to project
Area 1: Extend delivery to production
Area 3: Embed Projectknowledge into Operations
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
OPSDEV
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
Technical Loop
Business Loop
Business Loop
LIVE RESULTSINTERACTION MODERATIONSTUDIO CONTROLPART OF THE SHOW
Focus on the Business
“Backend” services
“IT support” services
Our “Office” services “Community” services
“Frontend” services
“Mobile” services
SNS/Push Cognito
(almost)NO SERVERS
A bit further down the rabbit hole …
Github
service not available
undocumented changes
inconsistent behaviour
different behaviour under load
(almost)NO MAINTENANCE
LessMaintenance
increased riskwhen not available
More speed
With increased risk
Functions As a Service (FAAS)aka
“serverless”
Case1 Generate “personalised” image
Browser -> Pre-signed S3 -> Lambda -> SQS -> Redis
Case2 Animated gif/movie/meme editor
API GW -> Lambda -> Img magic movie -> s3
You are an Agent
You make promises to others in the system
Your promises should be verifiable
A promise does not guarantee an outcome
Conditions should be part of your promise
It needs to be clearly documented otherwise it’s not a promise
It needs to be mutually agreed (not obligation) otherwise it’s not a promise
You might depend on other agents to keep your promises
Other agents make promises to you
Their promises need to be verifiableclearly documented & mutually agreed (not obligation)
But you can not make promises on behalf of other agents (bottom up vs top down)
Promises can be conflicting in a system
but the conflict can only be from internal promises (as we can not be responsible for others promises)
To keep a promise you should have a choice Push vs Pull
Single Leaves = SPOF
To create choice you need to eliminate the single leaves (SPOF)
All problems in computer science can be solved by
another level of abstraction
… except for the problem of too many layers of indirection …
David Wheeler (inventor of subroutine)
Every promise binding is the basis for relationship(Dunbar)
Agents with a similar goal can be grouped into a Super Agent
Single Leaves = SPOF
You need multiple Super Agents to have a choice again
Forksv1 v2 v3
v1 v2 v3
To keep promises agent can introduce different world views (versions)
Slows down
A super agent might get slow internal communication speed is key
Opportunity for personalised
service providers
Scaling Promises keeping your promise while changing your size (is hard)
container re-use non-deterministic
limits not clear under stress
services
devops
Holy Cow!
“I introduced devops and all I got was a remote API”
It’s devops Jim but not as we know it
emerging practices
communicate the status
of your promise and monitor others
monitor your services
and expose your own metrics (API)
expose insights to other agents
(API)
show that you care about
other agents
expose your logs
be clear on what happens when it fails
backup external data (give an API please)
provide & seek fast feedback
on your promise change status
be clear on your dependencies and expect the same
of other services
be proactive to make others keep their
promises
give insights on changing promises
blog to communicate your service
skill level
talk at conferences to indicate
your willingness to share
make it convenient for other agents to use
provide feedback to other agents
show that you listen to those that depend on you
show that your participation by improving
the field
show that your engineers
are not afraid of talking to people
let other agents influence your changing
promises
“The collaboration between dev & ops is now
extended to external 3rd parties”
“make clear promisesto other agents”
“And verify the status of other agents promises”
“To keep your promise to the business”
External Services are the next silo
think “Supply Chain”
https://vimeo.com/101735252
DevOpsDays Minneapolis 2014 Jeff Sussna, Promising Digital Service Quality
Questions?
