Charity Majors gives us 6 tips on how to make better technical decisions in DevOps

1. A Young Lady’s Illustrated Primer to
Architecture and Technical Decision-Making
Charity Majors, honeycomb.io
@mipsytipsy

2. A Young Lady’s Illustrated Primer to
Architecture and Technical Decision-Making
Charity Majors, honeycomb.io
@mipsytipsy

3. Prelude: Story Time

4. The curious tale
of how
The Dog Ate My Homework
and I missed
my talk

5. … thank you!
Tel Aviv is awesome. <3

7. “Software is eating the world”
~pmarca
“and your brain, probably”
~me

8. Making better choices
with software.

10. 2000
“u can haz LAMP stack”

11. 2005
“Would you care to come over and
discuss service oriented architectures
and REST APIs? Over tea, perhaps.”
“Splendid! And have you heard
of this ‘NoSQL’ oddity?”
“I am sure tis but a passing fad.”

12. 2010-2013ish
Infrastructure
Virtualization
Config management
RDBMS
Services with REST APIs
Continuous integration/delivery
Agile
“DevOps”

13. 2016: welcome to the jungle
even more logos

14. Accelerating trends in 2016
Polyglot storage
Composable infrastructure
Containerization, microservices
Coupling platforms (*aaS)
Storing more and more data forever

15. Cambrian
Explosion of
technical
complexity

16. the paradox of choice
this is actually really hard on humans.

18. tips for making
better technical decisions

19. Technology serves the mission

20. Software is the enemy
• Every piece of software adds
fragility and points of failure
• Everything you write will need to
be debugged and maintained
• It is easy to add software, and
hard to remove it

21. Resist software sprawl.
Can you solve the problem with your existing tools?
h/t @jessitron: http://blog.codeship.com/growing-tech-stack-say-no/

22. Optimize globally,
not locally
If you pick the perfect language/storage solution for every local
problem, you will have an unmanageable mess.

23. Have a gating process for major
new components
• What is the relative gain?
• Manufacture friction if necessary
• Don’t micromanage outside the critical path

24. Choose boring technology!
• Failure modes are well understood
• Rich library support for languages
• For databases, extensive production hardening
• Tooling and support for observability, debugging
h/t @mcfunley, http://mcfunley.com/choose-boring-technology

25. Understand your appetite for risk
• Early startups have massively greater
tolerance for risk.
• Use that risk! But spend it on your core
differentiators.

26. more considerations:
• Can you pay someone to do it better, for cheaper?
Value your own team’s time.
• Replacing a thing? Great: define a timeline and get rid
of the old thing.
• You *should* give preference to things your team has
expertise with.
• Fuck hacker news.

27. Are they friendly and welcoming? Do they have a code of
conduct, do they deal with assholes effectively? Do they value
new contributors or are they tribal and snobby?
It is totally legitimate to make software
choices that are influenced by the quality
of the community.

28. Operational Impact
The more mature your company becomes, the more your technical
choices must be driven by operational impact.
Corollary: make as many ops problems as possible
not your problem.

29. Celebrate the engineers who remove code, deprecate, and
refactor, as much as those who add features.

30. Manifesto:
1. Technology serves the mission.
2. Reuse solutions.
3. Create friction for adding new components.
4. Choose boring technology, when you can.
5. Spend your risk tokens on key differentiators.
6. The longer you survive, the more operational impact trumps all.

32. remember, it’s gonna be worse in 2017. <3

33. thanks kids!
enjoy #devopsdaysTLV!
thanks to@jessitron, @mcfunley and @ferlatte ~ @mipsytipsy