The Ops Community ⚙️

Drew Khoury
Drew Khoury

Posted on

Teaching DevOps in one afternoon

A non-technical friend of mine approached me wanting to know everything they could about DevOps. He asked if he could have a few hours of my to pick my brain and ask me some questions. If only he know how much joy that brings me.

So we used One DevOps Please as our springboard for the conversation. It worked well enough and we got to spider out into other conversations where he had questions. There were many times I had to pause and say “that’s a conversation for another day” so I wanted to capture some of those topics that we didn’t get to delve into. I figured it would be about the same effort to turn it into a blog post and share it with the world.

Existing Blogs

It’s no surprise that I already have a lot of blog posts within this theme. Feel free to explore those, or skip ahead to the new stuff!

Umbrella Themes

For this post I’d like to break down “DevOps” into three main themes. I believe that the “people” side of things greatly influences how we do the technical parts so in some ways it’s one of the most difficult and most import parts to get right.

People, Culture & Ways of Working

  • Continuously improve (Growth mindset)
  • Encourage innovation
  • Foster collaboration

Measurable

  • Measuring everything
  • Make decisions based on data
  • Make data easily available

Continuous Delivery

  • Higher quality software through repeatable, predictable delivery
  • Reduction of defects
  • Reduce cycle time of ideation (I have an idea) to production (released in prod)

People

Customer Focused — app teams or cross-functional teams with your org may be your customer.

How is your organization structured? https://web.devopstopologies.com/

Agile — no need to be overly prescriptive. Understand where “Agile” came from and what they indended to do with it: https://agilemanifesto.org/principles.html

Extreme Programming: https://www.agilealliance.org/glossary/xp/

  • The Planning Game
  • Small Releases
  • Metaphor
  • Simple Design
  • Testing
  • Refactoring
  • Pair Programming
  • Collective Ownership
  • Continuous Integration
  • 40-hour week
  • On-site Customer
  • Coding Standard
  • Sit Together
  • Whole Team
  • Informative Workspace
  • Energized Work
  • Pair Programming
  • Stories
  • Weekly Cycle
  • Quarterly Cycle
  • Slack
  • Ten-Minute Build
  • Continuous Integration
  • Test-First Programming
  • Incremental Design

Measure Everything

Let’s say it together “measure everything”.

In particular having metrics that are focused on Business Value Drivers are key.

Metrics should be captured and key metrics displayed on dashboards & TVs so they’re easily accessible.

Teams should produce APIs to be consumed internally — https://cachethq.io/.

Site Reliability Engineering.

Particularly for large organizations it can help to understand where each teams is at on their journey. Usually I’ll see teams try and go through some sort of journey of maturity in “DevOps”, “Cloud”, “Agile” or just “Good Software Development Practices”.

Maturity Assessments:

Continuous Delivery

This is really the art of getting code from laptop to production, and yes it can be part art, part science and a little bit of magic sometimes.

https://continuousdelivery.com/

  • Low risk releases. blue-green deployments
  • Faster time to market automate the build and deployment, environment provisioning, and regression testing processes
  • Higher quality automated tools that discover regressions within minutes
  • Lower costs investing in build, test, deployment and environment automation, we substantially reduce the cost of making and delivering incremental changes to software by eliminating many of the fixed costs associated with the release process
  • Better products work in small batches. This means we can get feedback from users throughout the delivery lifecycle based on working software
  • A/B testing & hypothesis-driven approach to product development
  • Happier teams continuous delivery makes releases less painful and reduces team burnout

https://continuousdelivery.com/implementing/patterns/

  • Only build packages once
  • Deploy the same way to every environment
  • Smoke test your deployments
  • Keep your environments similar

Trunk Based Development

A branching model to aspire to (or at least understand and learn from): https://trunkbaseddevelopment.com/

  • short iterations
  • less than few day story size
  • short build times
  • feature flags
  • humans and CI use same scripts
  • Compile > Unit Test > Integration > Functional
  • Quick build notifications
  • Shift Left — Undesirable to find out about breakages AFTER the commit

Containers

Containers are an amazing innovation that have many every day uses. They can be used locally, in your build servers, for development and production deployments. You can also use them to test new services and keep your laptop free of clutter!

How to build, test and deploy modern code in a repeatable fashion: https://3musketeers.io/

Containers 101…

https://en.m.wikipedia.org/wiki/Kubernetes

https://en.m.wikipedia.org/wiki/Docker_(software)

https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

https://danlebrero.com/2018/07/09/kubernetes-explained-in-pictures-the-theme-park-analogy/

(Don’t) Build it yourself

The phrase “undifferentiated heavy lifting”: https://aws.amazon.com/blogs/aws/we_build_muck_s/

When it comes to investing time you should consider the implications of “building and managing infrastrcuture yourself” vs “letting specalisits do the heavy lifting”. This might mean different things for different people, but here are some examples:

And that’s (a little more than) one afternoon teaching DevOps.

Also posted on medium as Teaching DevOps in one afternoon.

Top comments (0)