[2019 oracle code one] DevOps Theory vs Practice

DevOps Theory vs Practice: A Song of Ice and Tire Fire

Speakers: Viktor Gamov (@gamussa) & Baruch Sadogursky (@jbarauch)

Deck: https://jfrog.com/shownotes/

For more blog posts, see The Oracle Code One table of contents

Humor from imaginary thought leader (make sure you enjoy sarcasm in this section)

  • “Everybody’s software must be releasable at absolutely any time” – even if drunk?
  • “Everyone must have 100% test automation” – even if release 3-4 times a user to 2-3 users. cost makes sense
  • “We do Continuous Security well” – even if hire security person so have someone to blame
  • “Your greatest threat is an outage. Not an employee; just trust your employees” – even if CIO leaves bus with all data.
  • “VMs are the enemy of DevOps. This is where you must focus your innovation, Docker and Kubernetes” – Even for app just migrated from mainframe and not container ready
  • “You are a beautiful unique snowflake as are your problems. No vendor could possibly understand them.” So should invent own framework b/c written by other people.
  • “Our company is based in SF b/c that’s where the best engineers are”. Expensive b/c rent high

Four Questions

  • Is org/team ready to adopt new tech?
  • Is it even good tech? What do you know besides the demo? Where is it on Gartner’s hype curve? Thoughtworks Technology Radar – https://www.thoughtworks.com/radar
  • What problem do I solve by using this tech? What problem are you trying to solve? Not resume driven development
  • Will solving this problem help my organization?

Random notes

  • You are not NetFlix. Running chaos monkey on your network of ATM machines not a good idea.
  • Master Excel or Google Spreadsheets

Maturity models

  • Think about capabilities when trying to accelerate software development, not maturity models
  • Bad maturity models are bad
  • Bad models – goal driven. Get to goal and then are “done” improving, one size fits all from book, checkboxes for tools, write and forget
  • Good models – process driven, focus on outcomes
  • Components – evaluation factors (ex: is there a CI process), scoring methodology (is there partial credit), self assessment vs 3rd party assessment (how know if good process), progress tracking (of evolution), visualization (to show to people with different levels of involvement)
  • Different levels of detail for capabilities
  • Account for priorities of different teams – engineering, ops, business
  • Only use primary colors
  • Involve team in involving model definition and assessment
  • Partner with forward looking teams
  • Evolve model over time

My take

The intro was hilarious. The content was good as well 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *