[kcdc 2022] devops, 12-factor and open source

Speaker: Justin Reock @jreock

For more, see the table of contents


  • “It’s no longer the big beating the small, but the fast beating the slow”
  • Book: The Goal – Eliyahu Goldratt. Theory of Constraints for Business Productivity. Business fiction.
  • Book: Phoenix Project. Similar to The Goal but software business fiction
  • Book: The Machine that Changed the World
  • Book: Organizational physics – the science of growing a business. Short. Why businesses fail


  • Change focus from costs to throughput
  • Layoffs reduce costs but decreasing costs
  • Need to both decrease costs and increase throughput
  • Cost = organizational cost
  • Inventory = Code
  • Throughout = Money
  • Doesn’t really matter what improve as long as constantly improving something because entropy makes things worse if do nothing.


  • Chose supported free software and open first policy
  • Deploy in cloud/containers
  • If do container and not 12 factor, don’t see benefits
  • APIs are everything now. Govern APIs
  • Build fail-fast culture. Near instant release (and therefore patch)

Problems with Closed Development

  • Slow to obtain
  • Inflexibility in growth/scaling. ex: fixed number licenses
  • Can’t modify
  • Can’t benefit from others
  • Lose growth vs giving competitors features
  • Less oversight, less security


  • Individual physical servers
  • Virtual machines
  • Containers (stripped down OS powered by one underlying OS)
  • Created ecosystem with proliferation of microservices – Kubernetes (Greek word for captain). Now can have virtual datacenter in a box


Series of characteristics to increase odds of success in cloud/containers. The less you do for an app, the more friction you will have going to cloud/containers.


  • Codebase – in version control, deploy often
  • Dependencies – explicitly declare and isolate
  • Config – store in env. Env variables popular again
  • Backing Services – treat as attached resources
  • Build. release, run – separate strategies
  • Processes – one or more stateless processes
  • Port binding – how to expose services
  • Concurrency – Docker gives for free
  • Disposability – fast startup, graceful shutdown
  • Dev/prod parity – keep as similar as possible
  • Logs – push events out to central system via event streams
  • Admin processes – manage as one offs


  • About flow
  • Use left and right brained activities
  • Problem solving – hypothesis and feedback from build system.
  • Feedback feels good and keeps in state of creative flow
  • The longer you wait for a build, the less happy you are
  • Few track local build times.
  • Waste waiting for and debugging local and CI builds
  • 10x developer – organizational culture matters more than individuals

Benefits of faster cycle time

  • Less idle time
  • Less content switching – people can’t multi task. Also, bad for brain to try
  • More focus
  • Build more often
  • Earlier quality checks
  • Few expensive downstream incidents
  • Smaller change sets
  • Fewer merge conflicts
  • More efficient troubleshooting
  • Faster mean time to recovery


  • 1970s – JIT manufacturing
  • 1980s – Business process reengineering
  • 1990s – Change management
  • 2000s – Agile, Lean Six Sigma
  • 2010s – DevOps
  • 2020+ DPE (developer productivity engineering)


  • Engineering approach to productivity
  • Acceleration and analytics tech to improve dev experience
  • build cache – Gradle has option to use. Also Gradle Enterprise brought to Maven
  • Aligns with management goals – faster TTM (time to market), reduced cost, improved quality
  • https://gradle.com/learning-center-by-objective/
  • https://gradle.com/developer-productivity-engineering/handbook/

My take

Good mix of current and historical examples from outside computing (I didn’t blog about the history part), I hadn’t heard of 12-Factor prior to reading the abstract for this talk. I would have liked more time on it since it is a third of the title, but the talk flowed well as is.

[kcdc 2022] building rugged devops pipelines with github

Speaker: Brian Gorman @blgorman

Repo: https://github.com/blgorman/codemash-rugged-devops

For more, see the table of contents


  • Process, not product
  • Can’t buy tool (but can buy an existing team)
  • Goal: reduce cycle time form idea to production with minimal error
  • Automated testing
  • Gates – automated and human, quality, release
  • Avoid 2am support calls. Or at least only have to push a button to recover

Shift left

  • Less cost if find bug early
  • Reusable processes
  • Push quality upstream
  • Dev machine is as far left as can go
  • Build scanning tools into process
  • Sell the vision


  • Cloud env exists
  • Templates


  • .github/workflows – folder
  • Actions tab to see result


  • on: the triggers (ex: push, pull_request)
  • env: (ex: branch)
  • jobs: want you want to do
  • with: trigger another job

Infrastructure as Code

  • Declarative
  • Repeatable Results
  • Ensures no configuration drift
  • Azure has imperative and complete options for ARM templates – complete is destructive and dangerous. Anything added outside code deleted.
  • Tools – ARM templates (Bicep) , Terraform, Ansible, Puppet/Chef, Pulumi


  • App registration so github actions get access to Azure and add credential
  • Setup github token

SonarCloud Scanner

  • Most popular
  • Not free
  • Can choose whether to require fixing of warnings


  • Brining in dependencies without knowing
  • Alerts on insecure package
  • Options for security updates


  • Zap Scan
  • Baseline (lightweight) scan for pull requests
  • Full scan overnight
  • For penetration test, provide valid URL so can try to hit it
  • WhiteSource – GP Security Scan


  • Azure DevOps pipelines easier if new team
  • Azure DevOps has better gating
  • GitHub getting better.

My take

The room was full. When I walked in, Brian was talking. I was worried he started early, but did not. He was just talking to the audience who arrived early separate from the session. It was a good intro to github actions. Also if it has been a while (more features now.) I’m glad the code was in a repo so I could read it on my screen. I’m sitting in the back (because my talk is right after this and I need to leave early) and can’t read the code from here. It’s also nice to have as a reference. I also like that he covered integrations like Sonar.

[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 🙂