$ whoami
Ruby Programmer since 2003
Now a consultant specialising in backends...
... and team building.
I run usergroups and organize conferences as a hobby.
Slide 8
Slide 8 text
http://asquera.de
Slide 9
Slide 9 text
http://padrinorb.com
Slide 10
Slide 10 text
http://eurucamp.org
Slide 11
Slide 11 text
“I don’t want to be woken up
at night, so I call myself a
developer.”
Slide 12
Slide 12 text
I set out to present a more dev-minded
perspective on devops.
Slide 13
Slide 13 text
That was harder then I thought...
Slide 14
Slide 14 text
There’s a talk about the
“transforming devs to devops”
later on.
Slide 15
Slide 15 text
git push developer mindsets/devops
Slide 16
Slide 16 text
Whats the benefit, if you don’t do
a lot of ops?
Slide 17
Slide 17 text
Vagrant
Puppet
Chef
Slide 18
Slide 18 text
Vagrant
Puppet
Chef
Slide 19
Slide 19 text
How did a devops mindset
improve the software I write?
Slide 20
Slide 20 text
A bit of history about myself
Slide 21
Slide 21 text
I started my career in a typical
agency job.
Slide 22
Slide 22 text
LAMP and the DEV/OPS split.
Slide 23
Slide 23 text
It wasn’t even that bad...
Slide 24
Slide 24 text
...until projects got special.
Slide 25
Slide 25 text
scale
scope
Slide 26
Slide 26 text
Suddenly it turned out that one of
the most efficient teams was an
admin, a programmer and a cup
of coffee.
Slide 27
Slide 27 text
Example
Slide 28
Slide 28 text
An example
One of our clients imports and
reencodes videos from a
constantly changing number of
sources each day.
Slide 29
Slide 29 text
Sources
FTP upload
FTP fetch
RSS feeds
RSS feeds that are no RSS feeds
And some more...
Slide 30
Slide 30 text
Destinations
All of them need to be reencoded
to a standard set of sizes and
bitrates.
Slide 31
Slide 31 text
Simple approach
Slide 32
Slide 32 text
Single program with architecture
Slide 33
Slide 33 text
Same architecture, 3 processes
Slide 34
Slide 34 text
Why?
Slide 35
Slide 35 text
Videos per day
Slide 36
Slide 36 text
Critical failures last year
Slide 37
Slide 37 text
Deployments last year
Slide 38
Slide 38 text
New ways of discussing things.
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
Practical things learned in the
process.
Slide 42
Slide 42 text
... beyond writing daemons and
stuff.
Slide 43
Slide 43 text
A different perspective on code.
Slide 44
Slide 44 text
Infrastructure as code.
Slide 45
Slide 45 text
Code for infrastructure.
Slide 46
Slide 46 text
Common CLI tools
Common configurations styles
Common way of doing things
Slide 47
Slide 47 text
Gives insight
Well managable
Well automatable
Slide 48
Slide 48 text
In general, I care less about
internal quality of programs
nowadays then about external
quality.
Slide 49
Slide 49 text
My ugliest piece of code ran 1,5
years in production without a
change.
Slide 50
Slide 50 text
Nobody ever noticed how horrible
it was.
Slide 51
Slide 51 text
I evaluate new software
differently.
Slide 52
Slide 52 text
“Ease of setup” is a red flag.
Slide 53
Slide 53 text
This especially applies to new and
fancy databases.
Slide 54
Slide 54 text
Not having to push any buttons to
start working a database is
problematic, if not dangerous.
Slide 55
Slide 55 text
You might miss things along the
way.
Slide 56
Slide 56 text
“Ease of non-trivial configuration”
is far more important.
Slide 57
Slide 57 text
How to grade that?
Slide 58
Slide 58 text
Set up a production-like system.
Slide 59
Slide 59 text
Keep tally marks on how often it
leaves you puzzled.
Slide 60
Slide 60 text
There is no such thing as “setting
up production too early.”
Slide 61
Slide 61 text
Everything before that is childs
play.
Slide 62
Slide 62 text
The big bangs always happen in
production.
Slide 63
Slide 63 text
My favourite: Expensive
loadbalancers that die during
configuration and need to be
shipped to the manufacturer.
Slide 64
Slide 64 text
Teams need to get used to their
own systems.
Slide 65
Slide 65 text
Metrics and Logging are
important in complex systems.
Slide 66
Slide 66 text
Most pure development teams
underrate them and implement
them too late.
Slide 67
Slide 67 text
They should be there from day
one.
Slide 68
Slide 68 text
Last but not least: internal tooling
can save you a lot of work.
Slide 69
Slide 69 text
Creative ways to talk about it even
more.
Slide 70
Slide 70 text
No content
Slide 71
Slide 71 text
But what about the humans?
Slide 72
Slide 72 text
Giving people say in many things
makes them discuss many things.
Slide 73
Slide 73 text
There are two things I rarely see
in teams with strict roles.
Slide 74
Slide 74 text
1. Platform refactorings
Slide 75
Slide 75 text
Why?
It always means that individual
roles loose ground.
Slide 76
Slide 76 text
Why?
This can get political very quick.
Slide 77
Slide 77 text
Why?
Lack of skill.
Slide 78
Slide 78 text
2. Code reviews
Slide 79
Slide 79 text
Why?
Not enough staff that “is qualified”
to review certain code.
Slide 80
Slide 80 text
The devops mindset takes away a
lot of friction.
Slide 81
Slide 81 text
Less asking permission, more
doing.
Slide 82
Slide 82 text
When your frontend developer
changes your backend API, your
varnish config, your deployment
scripts and the puppet manifests
before handing stuff off to review
to implement a new feature, you
are there.
Slide 83
Slide 83 text
Bonus points if said developer is
the companies apprentice.
Slide 84
Slide 84 text
The devops mindset can be
incredibly empowering.
Slide 85
Slide 85 text
Devops-minded teams can cope
with missing team members
easier.
Slide 86
Slide 86 text
Everyone knows what everything
is roughly doing anyways.
Slide 87
Slide 87 text
Find hacks to gather and spread
that knowledge across your team!
Slide 88
Slide 88 text
No content
Slide 89
Slide 89 text
To sum up:
Slide 90
Slide 90 text
Teams with a strong devops
culture:
can handle more complexity
Slide 91
Slide 91 text
Teams with a strong devops
culture:
can handle more complexity
can find more alternative approaches
to problems.
Slide 92
Slide 92 text
Teams with a strong devops
culture:
can handle more complexity
can find more alternative approaches
to problems.
are more likely to find solutions that
handle well in production.