Don’t get me wrong, there is nothing wrong with be a sysadmin. I’ve been one for a while. But it isn’t what I want to do right now.
I’ve been doing many technology related things (coding, sysadmin, project management, consulting, teaching…) and I’ve learned a lot from all those roles, but right now I want to use my skills and knowledge to help teams to work better.
DevOps was born to improve the value we bring to our customers and users. A way to improve inter-teams’ communications, better (and shorter) feedback loops through the whole organization, better configurations’ management, more reliable and reproducible environments, so we generate more value as a whole.
For some people, a DevOps engineer is a glorified sysadmin who knows the “cloud stuff”, can do the “container thing” and like to play with monitoring and automation tools. Probably a person who can scale your site so it won’t crash when it gets hit by million users.
All this stuff is fun and necessary nowadays, but that’s not DevOps. Just like the person who writes a test for his/her code is not QA, it’s a programmer who writes tests (as it should be), a person who admins system at the cloud is a sysadmin with cloud knowledge (as it should be nowadays), not a DevOps.
What I want to do (and can offer) as a DevOps enabler?
- Trying to understand the business logic before trying any technical change.
- Putting in place, creating or improving the necessary tools to coordinate the different teams and deliver value to the customers and users.
- Being sure that we have the necessary environments for (at least) development, testing and production, and they are consistent, easy to build and reproduce.
- Being sure that all the configuration (for the code and the infrastructure) is well manageable, secure, and easy to audit and change.
- Automating all the processes that can be safely automated, so we can do less repetitive and error prone tasks.
- Being sure that any change we do (code or configuration) gets tested (preferably automatically) in some way to detect errors early and avoid regressions.
- Reducing the complexity of the systems, for each team and for the whole organization.
- Helping to build teams and teaching them the necessary skills (technical and personal) for working with those systems, methodologies, tools and to communicate effectively with the other teams.
- Giving those teams tools for getting better and shorter feedback of the real value they are generating and errors they cause.
This doesn’t mean I can’t contribute to other areas and tasks, but I think there is where I can bring more value and where I should focus.