#69: DevOps: not a job position, but culture and mindset
DevOps is a movement to bridge the gap between developers and operations teams. Traditionally, these two groups were separate and rarely interacted with each other. Developers didn’t quite understand how software is deployed and managed. Operation teams, on the other hand, treated software as a black box. DevOps encourages synergy between these two roles. Developers should take responsibility for their software. Including how it runs and behaves on production. Ops should understand the software they run. But more importantly, they should adopt well-established software engineering principles. For example, automation, auditing, testing, and fast feedback. Ideally, devs and ops should work together in a single team, toward a common goal.
Modern teams that practice DevOps have a few characteristics. First of all, continuous integration and deployment workflows. That includes infrastructure as code. Tools like Terraform describe our infrastructure in a declarative manner. Adding more servers or updating packages is now controlled via pull requests. Just like any other code change. But it gets better! Such a pull request may include automated tests and even cost estimation! You know, how many dollars will you have to pay extra after merging that PR.
By the way, paying close attention to cloud costs is another movement, called FinOps. When cloud pricing is so fine-grained, every tiny infrastructure change can be measured. For example, does adding a new database replica to improve redundancy, make economic sense?
Also, these days developers care much more about security. This is often phrased as shift-left. It means security auditing and testing are moved much earlier in the development lifecycle. This approach is called DevSecOps As you can see, software development became much more multidisciplinary these days. But that’s a different story.
Anyway, what about developers? They no longer simply throw JARs or DLLs over FTP, so that “someone will deploy it, somehow”. Instead, the software is written in such a way that it’s easy to deploy anywhere. For example, developer packages their application in Docker containers. But that’s just the beginning.
Software should be observable via logs and metrics. Every application should be able to tell if it’s healthy and how it’s doing. Universal metrics are exposed in such a way that both devs and ops can understand them. In a distributed system developers should also pay attention to troubleshooting assistance. I mean distributed logging and tracing, essential to track down bugs.
Developers should also define and build alerts that can be monitored and triggered. All these concerns were nonexistent before the DevOps movement. This led to poor software being delivered. And upset operations teams, unaware of what kind of software they really run.
Nowadays, developers take full responsibility for what they deliver. And operations learned a lot from modern software engineering practices. The overall goal of DevOps is to deliver software faster, more frequently, and with fewer defects. This is done via a combination of:
- CI/CD
- infrastructure-as-code
- observability
- cloud computing
It’s worth noting that SRE, Site Reliability Engineering, seems to predate DevOps. This practice, invented at Google, is somewhat similar to DevOps.
That’s it, thanks for listening, bye!
More materials
- DevOps on Wikipedia
- GitOps
- The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
- Site reliability engineering
- Tools
- Listen to other related episodes: