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.
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!
- What is DevOps
- Build your first Python App using Google App Engine
- Learn Ansible
- Things I learned working for IT Consulting companies (as it relates to DevOps, Agile, Cloud and team building)
- The best guide for Agile that you'll ever find
- Talking about building a Learning culture
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
- Measuring everything
- Make decisions based on data
- Make data easily available
- Higher quality software through repeatable, predictable delivery
- Reduction of defects
- Reduce cycle time of ideation (I have an idea) to production (released in prod)
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
- Simple Design
- Pair Programming
- Collective Ownership
- Continuous Integration
- 40-hour week
- On-site Customer
- Coding Standard
- Sit Together
- Whole Team
- Informative Workspace
- Energized Work
- Pair Programming
- Weekly Cycle
- Quarterly Cycle
- Ten-Minute Build
- Continuous Integration
- Test-First Programming
- Incremental Design
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/.
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”.
- 12 Factor — https://12factor.net/
- 6R’s Application Treatment Plan — https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/
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.
- 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
- 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 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/
(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:
- Configuring AWS Accounts & setting up guardrails: https://aws.amazon.com/controltower/features/
- The quickest and best way (imo) to run k8s: https://cloud.google.com/kubernetes-engine/
- Do you even need a k8s cluster? Sometimes you just need someone to host your app for you: https://cloud.google.com/appengine/
And that’s (a little more than) one afternoon teaching DevOps.
Also posted on medium as Teaching DevOps in one afternoon.
Top comments (0)