This is actually a follow up of the article I wrote a little while ago on LinkedIn titled “DevOps is NOT Jenkins.” In that article, I ranted about how many people and companies confuse automation tools with DevOps. Now I want to address another misconception that I come across quite often: “DevOps is a role.”
When managers tell me they have all bases covered because their team consists of developers, designers and a DevOps engineer, many questions come to my mind. Having the awareness to at least assign that role in a team is already something. Quite a few engineering managers think that by giving an engineer a DevOps title is enough, but nothing could be farther from the truth. As I mentioned in the LinkedIn article, DevOps is a culture, a process and a philosophy. Adding a DevOps engineer to the team is like declaring someone on the team to be the scrum master and assuming agile is in place. These days, Agile is widely adopted and usually it is not seen as a role, but as a proper methodology. (Although it never surprises me when I encounter a team that is micromanaged while a scrum master is on duty …)
Like Agile, DevOps should be practiced by the team or organization as a whole. At the core of all engineering we should not only address features but also how those things will run in production. And let’s not forget quality assurance, security and compliance when designing a feature or fix. Fixing an issue at the beginning is between 10 and 50 times cheaper than leaving it until all the testing phase is done already, according to a NASA study. “The study revealed that costs escalate in an exponential fashion.”
I suspect that concentrating on just the feature or fix is so much more convenient because it is the immediate business value that is addressed by completing it. Thinking about how a new configuration variable will be injected in production or how this new function is going to be load tested probably takes away from focusing on a adequate and speedy completion. There is even a possibility that taking every possible aspect into account simply is too much to fit in one’s brain. I know I’ve had to force myself to not forget anything with checklists and tools.
In Practice
Every change, feature or bug fix should have a checklist to make sure all the bases are covered. Naturally, the requirements for the change have to be captured with user stories. But also make sure there is a user story for each of the non-functional requirements. Here are some examples of user stories addressing the various concerns:
- As a security officer I want to be aware of any changes in potential security risks so I can adapt my (automated) security checks accordingly.
- As a quality assurance engineer I want to be able to verify the functionality of this feature/fix in isolation and integrated in the product.
- As an operations engineer I want the to be aware of any changes in the runtime contract so I can update deployment systems accordingly.
- As a compliance officer I want to reduce to scope for which compliance regulations are in effect.
There are plenty of tools out there that allow these user stories to be part of a template so it’s easy to embed into the team’s workflow.
Runtime Contract
Defining a “contract” for how the application is configured and run in the target environment when the application or microservices are developed removes many uncertainties at the design phase. The mere fact that such a contract exists forces you to either comply with it or negotiate an amendment, like with any contract. A runtime contract has to define how the runtime is configured and which elements are considered secrets. It also needs to describe how and in which format the service outputs runtime feedback around errors and informational messages. Metrics, startup and shutdown and health checks also must be considered. This is an example of what such a contract could look like.
Broaden the Role
After checklists and contracts have been established, a large part of the process is codified. I typically write these things down in a version controlled document structure so amendments can be easily tracked. However, this still doesn’t relieve us from the misconception that DevOps is just a role in the team. In fact, the DevOps culture within a team or organization probably should be guarded and or facilitated by a person or persons, much like the Scrum master is tasked with facilitating that process and methodology. Probably, the actual automation will be built in large part by the person tasked with the DevOps responsibility, but on top of that it is also their responsibility to raise and maintain awareness of all the aforementioned aspects of testing, deploying and running an application.
As such, I believe that people practicing DevOps are required to be more than average communicators and well-versed in every step of the software delivery life cycle (SDLC). Almost all of the DevOps job descriptions that pass my eyes take great care to mention all kinds of technology and familiarity with clouds and programming languages, but don’t emphasize the communicative requirements. It’s time to take DevOps seriously and start reaping real benefits by embracing it as a methodology.
I’d love to hear your opinions and feedback. Let’s start a discussion below in the comments or on LinkedIn/elexy.
