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

Speaker: Justin Reock @jreock

For more, see the table of contents


References

  • “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

Constraints

  • 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.

DevOps

  • 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

Path

  • 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

12-Factor

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.

https://12factor.net

  • 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

Coding

  • 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

Trends

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

DPE

  • 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] creating a culture of appreciation

Speaker: Ash Banaszek @ashbanaszek

For more, see theĀ table of contents

Tools

  • Interviews
  • Spotcheck with collegaues
  • DoveTail for affinity mapping

What is recognition

  • Exercise: what makes you feel appreciated. Last time and when was. For me, it was yesterday when a manager (not me) acknowledged a milestone our team made on a key project.
  • Poll to see when last felt appreciated. Most recent but some were longer than 6 months ago.
  • For some people, it is only during annual review
  • Making your employees and coworkers feel valued by you and the company
  • Be specific, descriptive and timely
  • Why are you giving it? What was the impact? Be honest.
  • Mono directional – I am recognizing you
  • Within the week is best
  • Email is ok. Doesn’t have to be formal
  • Tailor to the recipient – not everyone wants public attention

Less good examples

  • Think about how makes feel when manager has to pay for thank yous because companies don’t want to
  • HR sent note with pin for 10 years and manager signature. Ritual, not an accomplishment. Not personalized. Form letter.
  • Too late – forget
  • Where is the bar. If you are never appreciated, better than nothing.
  • Checking a box
  • Recognition is not the same as team building.
  • Don’t want to wait 6 months. Less impact the longer you wait.

Formats

  • Gift
  • Money
  • Time off
  • Face time
  • Public praise
  • Personal note
  • What is best varies by person.
  • Exercise: think about what motivates you
  • Less genuine if do same thing for everyone.

Better

  • Be specific. Mention something did. Not just 10 years.
  • “The team did great on X. We are going out bowling to celebrate”. Better if list specific things during the event for specific people

Why helps

  • Feel happy
  • More productive when believe colleagues respect and appreciate them, gratitude from manager

What is worth recognition

  • Save time/effort
  • Make things better
  • Outside job scope
  • Stretching skill set
  • Doing job while under tough circumstances
  • New certification
  • Going to conference and presented
  • Example of learning from failure (before too late)
  • Something cool
  • Recognize for things reinforce

Tips

  • Block calendar – Ash blocks half an hour to think about gratitude, check in on mentees/managers, send out notes
  • Include in project milestones (if x is true, we will do y)
  • Put in performance goals. Makes measurable. I recognized X people.
  • Talk about it with team/leadership
  • Must be visible and supported by the top to be part of the culture. Example: if X, team has lunch with you
  • Tailor recognition – ex: gifts, meals, emails
  • Remember is it s a thank you gift
  • Vary approach for effect
  • Make it easy to give
  • Make it a habit – schedule time
  • Build reputation for gratitude. People want to work with people who appreciate them
  • Reinforce people recognizing others

Who to recognize

  • Not just managers can do
  • Teammates
  • Other work teams
  • People in roles above you
  • Contractors

Traps

  • “But that’s their job anyway; Already get paycheck, that is recognition” – think about what done that special
  • “What if people don’t think it’s fair” – not recognizing anyone because someone might be upset. Need to make it fair. Find out how doing if less visibility.
  • “My folks don’t need to coddled; don’t want to be recognized” – culture failure
  • “We already have a yearly bonuses” – not specific, descriptive or timely
  • “There’s not on my team, someone else can do it” – all working towards same goal
  • “It’s not worth my time” – well worth ROI because others more productive
  • Fear of “watering down” recognition – number vs specific recognition/scope. Needs to be equivalent in nature to what did
  • Inauthentic – can’t just want productivity gain
  • Ignoring standard practices – if everyone else recognizes anniversary, feel ignored
  • Folks feeling isolated/unseen – talk to others to find out how doing
  • Overcompensating – feels like want something when disproportionate.
  • Checking the box
  • If barrier to entry too high, people won’t do. Ex: having to find a paper form

My take

Ash asked everyone in the first two rows to wear a mask. People complied. I was impressed they got compliance. The talk was interesting. The examples were relatable and fun. The “what to consider” was helpful in getting me to reflect. I like the reinforcement of specific, descriptive and timely throughout! They said we’d be asked to talk to each other but that didn’t happen so I was wondering when that was coming. At the end, we wrote down what would have been in the brainstorming groups and shared out loud. Seemed equally effective.

[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

DevOps

  • 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

Prereq

  • Cloud env exists
  • Templates

Actions

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

YAML

  • 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

Security

  • 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

Dependabot

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

OWASP

  • 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

Q&A

  • 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.