What does it mean to be a Dev(Sec)Ops Engineer?
As much as I try to keep this a light topic, I can’t seem to do so. There are so many skills and tasks I do everyday that involves so much. If you’re looking for a simple, clear answer, fact is, there’s none. Well, define it yourself. The following is MY definition.
My motivation for this post is simple.
Many have claimed to be DevOps engineers (of some sort) and slap that title on their name cards without touching code. Even if you do touch code, that doesn’t mean you do “DevOps”.
No, DevOps is not a unicorn that shits out enterprise-grade magic products.
Let me begin by telling you a story about water.
During my DevSecCon 2017 presentation, I draw parallels between water and software. Both require manpower and skills to develop and improve the respective products.
Disclaimer: The below is my own example and if there are factual inaccuracies, please leave me a comment or correct me. I am not water expert nor in the industry; I am just using it as an example to illustrate my point.
Let’s say, for example, in the successful case of providing NEWater for the whole of Singapore, it is not crazy to assume that it involves two important roles, namely — water researchers and civil engineers — working on this nation-wide project. They both have very different responsibilities; the former will be tasked to research and use methods that are effective and efficient for our nation’s water situation, the latter will be designing the water-pipes for delivery of the cleaned water from the treatment plants to the consumers (as clean water is no good sitting in the plant). There is a separation of duty.
What used to be the “old” way of doing software has a clear separation of duties. Developers, akin to water researchers, will work on their applications to develop new features; and when that is done, the applications is passed on to people in operation, akin to civil engineers, to deploy and push the applications out into production environment. It worked great for a while until businesses found this method to be slow, un-cooperative and even poisonous to the business.
In the world of DevOps, this separation of duty dissolves — like salt in water. A DevOps engineer does everything end-to-end.
We build and create new features for an application [NodeJS]; build the environment to deploy the application into [AWS]; build the pipelines to automate our deployment into those environments [Jenkins]; create and maintain the infrastructure / network settings [AWS / security groups / Ansible]; create notifications and alerting on operations [PagerDuty]; enable logging on all backend systems [Splunk]; securely deploy the secrets into the application [Vault]. Oh don’t forget, we also take responsibility of the security on top of all these and without sarcasm, this is my forte.
At a technical level, that’s what a DevOps Engineer does. Sounds like a unicorn yet?
The movement for DevOps is one aligned to satisfy business needs. A need to update software faster; to push features out sooner; to retain attention-seeking users. Yes, the industry is hiring more unicorns.
For previous waves of developers and/or system administrators: if you want to step your game up and join this DevOps hiring wave, do not be trapped in the bubble of isolating your skill set to just developing your Java app, or administering databases, or configuring firewalls, etc… (there is a declining demand for these jobs…)
Some thoughts to ponder upon:
- Do you develop features for a web/mobile/any application?
- Do you deploy using continuous integration and continuous delivery/deployment (CICD)?
- Do you use / build a CICD pipeline?
- Do you deploy rapidly? (“rapidly” is subjective so I’ll leave this open…)
- Do you use any cloud services / servers? AWS, Google Cloud
- Do you refresh your stack often?
For managers, please do not just hire 1 DevOps engineer and hope he/she shits out magic enterprise-grade product. It will be death by a thousand cuts. A team of 1 is a single-point-of-failure fueled by a very tired, unhappy, unicorn and the shit is probably insecure.
For organizations wanting to get on this DevOps wave, please do not simply change the titles of existing system admins and developers because this is not the way to build a DevOps team. I feel one should start from scratch to disrupt your current development process.
For hiring managers, look out for candidates who knows full-stack knowledge as described above. I believe the best way to interview a candidate is to show you how he/she shits magic (gives examples of all the above bullet points) during the time of the interview. In all seriousness, it takes a DevOps engineer to recognize another— just like unicorns, that’s why we, humans, aren’t able to see unicorns.
if (unicorn) {
print(“magic”);
}
My last cry for a better DevOps movement: I also recommend reading The Phoenix Project.
BONUS: For current DevOps engineers, take on DevSecOps. Implement DevOps with security at speed. One way is to have your security as code — much like infrastructure as code. ;)
So what exactly is DevSecOps?
In short, DevOps with security. In long, I’ll have to follow up with another article to explain what I feel around this term. Read more at www.devsecops.org
I am a hacker — physical, cyber and cultural — much akin to that of Mr. Robot but minus the malicious. Or at least I think I am. Imagine Elliot working for a company to make new features, and secure an application.
