Please note that this article is a note instead of a tutorial
Working DevOps means pushing small releases faster to get feedback, minimize risk and maximize learning.
Taylorism and Working in Silos
- Adoption of command and control management
- Organizations divided into functional silos
- Decision-making is separated from work
Hand-offs created by working in silos result in mistakes, bottlenecks, and delays
Software development is not like assembling automobiles, is more like craftwork. Taylorism is not appropriate for craftwork.
Software Engineering
- Software is constantly updated
- New features are being added
- System behavior changes over time
Maintain a stable and long-lasting team.
Required DevOps Behaviors
Problem: developers are praised when success, while operations get blamed when failing
- Automated deployment to all environments
- Network design defined by app architecture
- Ephemeral (lasting for a very short time) infrastructure created for each new deployment
- Risk managed through progressive activation instead of a change window
- Builds are repeatable leveraging infrastructure as code
flowchart LR
Silo["Silos and hand-offs"] --> Shared["Shared ownership and collaboration"]
flowchart LR
Fear["Fear of change"] --> Embrace["Risk management by embracing change"]
flowchart LR
Build["Build once, hand-crafted snowflakes"] --> Short["Ephemeral infra as code"]
flowchart LR
Manual["Manual fulfillment"] --> Auto["Automated self-service"]
flowchart LR
Alarm["Alarms, callbacks and escalations"] --> Loop["Feedback loops and data-driven responses"]
Infrastructure as Code
Infrastructure as code describes infrastructure in an executable textual format. Ephemeral infra can be used and then discarded. Servers are built on demand via automation.
Immutable way of working:
- Never make changes to a running container
- Make changes to the image and redeploy
- Keep images up to date
Continuous Integration (CI)
Benefits:
- Faster reaction time to changes, since tests are automated
- Reduce integration risk
- Higher code quality
- The code in version control works
- The master branch is always deployable
Continuous Delivery (CD)
Continuous delivery requires continuous integration
| Continuous Integration (CI) | Continuous Delivery (CD) |
|---|---|
| Building, testing and merging to master | Deploying to a production-like environment |
CI/CD Pipeline
A CI/CD pipeline needs
- A code repo
- A build server
- An integration server
- An artifact repo (like for .jar files)
- Automatic configuration and deployment
Five key principles
- Build quality in
- Work in small batches
- Computers perform repetitive tasks while people solve problems
- Continuous delivery requires continuous integration relentlessly (harsh or inflexible) to pursue continuous improvement
- Everyone is responsible
Organizational Impact of DevOps
Is the culture of the organization agile?
- Small and dedicated teams
- Cross-functional teams (No silos, avoid communicating by ticket system)
- Self-organizing teams (Commit to work one sprint at a time)
Conway’s Law
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Melvin Conway, Datamation 1968
Three different teams make three different tiers
Better to organize around business domains, different small dedicated and cross-functional teams work on their own task, avoiding waiting for other teams for their features
Everyone is responsible
- Actions without consequences can lead to apathy.
- Allowing teams to feel the effect of their actions fosters empathy, resulting in higher-quality work.
Measure and Reward What You Want
Social metrics example:
- Who is leveraging the code you are building
- Whose code you are leveraging
Vanity Metrics vs. Actionable Metrics
Example of actionable metrics:
- Man Lead Time (how long does it take for a new idea to become reality)
- Release frequency (as quickly as possible)
- Change failure rate (as stable as possible)
- Mean Time to Recovery (MTTR)
Old school is focused on mean time to failure (MTTF), like trying to make the server never go down
Comparison of DevOps to Site Reliability Engineering (SRE)
Duty: maintaining stability
| SRE | DevOps |
|---|---|
| Error Budgets based on service-level objectives | CD pipeline |
| When error budget is exceeded, there’s no deployment | “You build it, you run it” |
| Everyone is responsible for code |
SRE and DevOps take different approaches but share common goals
- Both seek to make both Dev and Ops work visible to each other
- Both require a blameless culture
- The objective is to deploy software faster with stability
DevOps + SRE
- SRE maintains the infrastructure
- DevOps uses (consumes) the infra to maintain their application