Run Your Damn Application

Your important new distributed application is a month from the go-live
date. Developers have carefully built it up, piece by piece, with
fault tolerance designed in. It has been performance optimized, and
unit tested to an unprecedented 85% coverage! Now you get operations
and development collaborating to get it deployed, using tools they
both understand. Devops, right?

Yet everyone is angry, frustrated and stressed. The product fails to
run when you deploy it, due to elementary issues. It's slow. The
built-in fault tolerance doesn’t work. Debugging the issues takes
weeks. Your one month to go-live turns into six months, and
development and operations are ready to kill each other at the end.
What went wrong?

It went wrong on day one. For the entire development cycle, every
line of code in the application was exercised, but nobody ever ran the
application. If this scenario sounds familiar to you, come to this
talk and learn why it happened, and how you can address it.

Transcript

1. Run Your Damn Application John Keiser Mad Scientist at Chef @jkeiser2 hate mail to my former self
2. whoami Developer Distributed Systems Polyglot Distributed Storage+Query Browser Compilers Web Platforms Websites Configuration Management
3. Why am I here
4. a developer story
5. this is probably a familiar story
6. Your distributed design is ready Database Database Load Balancer Web Server Web Server Web Server API Server API Server
7. you are doing TDD - user experience driven - just like production
8. You just need a running app
9. First things first, let's get a machine
10. … ok, table that. set us up the database
11. Apache then?
12. This is light years from your skillset.
13. Build component Test component Set component aside GOTO 10
14. 6 months later 85% code coverage speed demon ROCK ON
15. Ops is not so thrilled It seems they are not magic You have no time left
16. It is … late and
 shakily deployed
17. It is … buggy and unusable
18. It is … unstable and unperformant
19. It is … inoperable and undebuggable
20. The dev | ops wall is back up
21. Were people the problem?
22. Was it process?
23. It happened on
 day one
24. 85% CODE COVERAGE NEVER RAN THE APPLICATION
25. too many choices wrong person
26. start with the deployment build in the deployment keep the deployment
27. dev / ops pairing gets you started hard to stay there
28. Create a cluster recipe • Database • Load balancer • Web servers • Logging, Monitoring, Alerting
30. Wait, which database? • Just choose, fast • Let yourself change over time • Smooth ramp, not perfect start • Same for configuration / tuning
31. Create a base app • “hello world” code • build and deploy in recipe • redeploy quickly
33. Build tests • user-level test (“hello world”) • failure test • stress test
35. Make it operable • Embed best practices • log line, perf counter • alert
36. Make useful tools • Fast reprovision (edit->run) • Log and alert tailing • Dashboard
37. the pieces are all there
38. questions? John Keiser @jkeiser2 jkeiser@chef.io