Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How devops improved my dev

How devops improved my dev

1c88d7906e3ffa450aedff2f5f1d1299?s=128

Florian Gilcher

April 18, 2013
Tweet

More Decks by Florian Gilcher

Other Decks in Programming

Transcript

  1. None
  2. None
  3. The hotel wireless was terrible, sorry for the lack of

    pictures.
  4. $ whoami

  5. $ whoami $ cat .profile | grep export export GIT_AUTHOR="Florian

    Gilcher" export GIT_AUTHOR_EMAIL="florian.gilcher@asquera.de" export GITHUB_NICK="skade" export GITHUB_ORGANIZATIONS="asquera,padrino" export TWITTER_NICK="@argorak" export TM_COMPANY="Asquera GmbH"
  6. @argorak

  7. $ whoami Ruby Programmer since 2003 Now a consultant specialising

    in backends... ... and team building. I run usergroups and organize conferences as a hobby.
  8. http://asquera.de

  9. http://padrinorb.com

  10. http://eurucamp.org

  11. “I don’t want to be woken up at night, so

    I call myself a developer.”
  12. I set out to present a more dev-minded perspective on

    devops.
  13. That was harder then I thought...

  14. There’s a talk about the “transforming devs to devops” later

    on.
  15. git push developer mindsets/devops

  16. Whats the benefit, if you don’t do a lot of

    ops?
  17. Vagrant Puppet Chef

  18. Vagrant Puppet Chef

  19. How did a devops mindset improve the software I write?

  20. A bit of history about myself

  21. I started my career in a typical agency job.

  22. LAMP and the DEV/OPS split.

  23. It wasn’t even that bad...

  24. ...until projects got special.

  25. scale scope

  26. Suddenly it turned out that one of the most efficient

    teams was an admin, a programmer and a cup of coffee.
  27. Example

  28. An example One of our clients imports and reencodes videos

    from a constantly changing number of sources each day.
  29. Sources FTP upload FTP fetch RSS feeds RSS feeds that

    are no RSS feeds And some more...
  30. Destinations All of them need to be reencoded to a

    standard set of sizes and bitrates.
  31. Simple approach

  32. Single program with architecture

  33. Same architecture, 3 processes

  34. Why?

  35. Videos per day

  36. Critical failures last year

  37. Deployments last year

  38. New ways of discussing things.

  39. None
  40. None
  41. Practical things learned in the process.

  42. ... beyond writing daemons and stuff.

  43. A different perspective on code.

  44. Infrastructure as code.

  45. Code for infrastructure.

  46. Common CLI tools Common configurations styles Common way of doing

    things
  47. Gives insight Well managable Well automatable

  48. In general, I care less about internal quality of programs

    nowadays then about external quality.
  49. My ugliest piece of code ran 1,5 years in production

    without a change.
  50. Nobody ever noticed how horrible it was.

  51. I evaluate new software differently.

  52. “Ease of setup” is a red flag.

  53. This especially applies to new and fancy databases.

  54. Not having to push any buttons to start working a

    database is problematic, if not dangerous.
  55. You might miss things along the way.

  56. “Ease of non-trivial configuration” is far more important.

  57. How to grade that?

  58. Set up a production-like system.

  59. Keep tally marks on how often it leaves you puzzled.

  60. There is no such thing as “setting up production too

    early.”
  61. Everything before that is childs play.

  62. The big bangs always happen in production.

  63. My favourite: Expensive loadbalancers that die during configuration and need

    to be shipped to the manufacturer.
  64. Teams need to get used to their own systems.

  65. Metrics and Logging are important in complex systems.

  66. Most pure development teams underrate them and implement them too

    late.
  67. They should be there from day one.

  68. Last but not least: internal tooling can save you a

    lot of work.
  69. Creative ways to talk about it even more.

  70. None
  71. But what about the humans?

  72. Giving people say in many things makes them discuss many

    things.
  73. There are two things I rarely see in teams with

    strict roles.
  74. 1. Platform refactorings

  75. Why? It always means that individual roles loose ground.

  76. Why? This can get political very quick.

  77. Why? Lack of skill.

  78. 2. Code reviews

  79. Why? Not enough staff that “is qualified” to review certain

    code.
  80. The devops mindset takes away a lot of friction.

  81. Less asking permission, more doing.

  82. 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.
  83. Bonus points if said developer is the companies apprentice.

  84. The devops mindset can be incredibly empowering.

  85. Devops-minded teams can cope with missing team members easier.

  86. Everyone knows what everything is roughly doing anyways.

  87. Find hacks to gather and spread that knowledge across your

    team!
  88. None
  89. To sum up:

  90. Teams with a strong devops culture: can handle more complexity

  91. Teams with a strong devops culture: can handle more complexity

    can find more alternative approaches to problems.
  92. 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.
  93. Their immediate answers are more complex.

  94. Thank you for listening.

  95. How did devops change your development style?