DevOps is rather a confusing term. Everyone uses it a lot and not everyone is able to define what it really means.
Here are some thoughts of what our team think when we hear DevOps:
- CI/CD.
- Source-code, compilation.
- Kubernetes, Ops responsabilities.
- Automated tests.
These are some good talking point, as they definitely have to be considered when we want to introduce DevOps processes in a project or organization. But what it is then? To me, DevOps is a culture.
Usually, in a classic software project we always had this divide between the work of the developers and the system admins which is more operational. As devs strove to try new technologies and add new features, the ops wanted stability in production. This difference in mindset could create an unfortunate situation. Indeed, devs would send their new features “over the wall” to the ops. They would hope for the best and that it would work in production (hopefully with some sort of QA in between). The culture of DevOps is a wish to break that wall. A wish to make developers care about the state of their code in production and to empower ops with automation tools to reduce human errors. We want both side to understand each other and communicate more, it is a change in mindset.
DevOps Topologies
Today we discussed about the different team organizations for DevOps presented here: https://web.devopstopologies.com/
Our favorite topologies are the shared (Type 2) and container-driver (Type 8) topologies. Indeed, since we are a small sized team, we can’t really have dedicated ops people for our projects. That’s why sharing responsibilities makes sense. Regarding the container based topology, the same reasoning leads us to think that encapsulating the “DevOps” responsibilities with the container and its deploy workflow allows us to focus more easily on the development work.
Finally, I asked my colleagues what is the most valuable part of following a DevOps mindset. We agreed that using the right tooling is a big enabler for projects. With maximum automation, correctly implemented, we can remove the need for human interaction in some part of our workflows and therefore reduce human errors.
Morgan Ridel