Lately, I find myself in conversations about DevOps. The interest it awakens is very big, and I notice several misunderstandings. Josep Ruano has an amazing article on what DevOps is NOT about.
Yes, sometimes you have to start by demystifying some prejudices on the term 🙂
Developing the ideas Josep mentions on the post when people ask “What do I have to do to become DevOps?” I tend to answer very categorically:
Be curious and listen to your co-workers. DevOps is not a certification you get by taking training, it’s an attitude towards your teammates: doing everything you can to understand them and empathizing with them.
Now please, let me extend it a little. In the brief time I studied robotics, I especially remember a couple of lessons that have accompanied me for a long time and have been very useful to me. The day I received my first robotics class, the teacher walked in and made an announcement that would break down the preconceptions of many students. Very slowly, but giving off an unusual passion among university professors, he said:
Robotics is a multidisciplinary field, where you work with teams of electrical, electronic, mechanical, physical engineers… I am not going to teach you how to program robots. You already know that, being in last year of Computer Engineering.
I am going to teach you the physics, mechanics, control, electricity, and electronics that you need to know so the day you work on a team, you understand your colleagues and you can speak knowledgeably (as engineers).
Throughout the rest of the course, the classes were a repertoire of knowledge dissemination lessons from other fields. I like to call them “small engineering enlightening festivals.” Even today, despite not having dedicated myself to robotics, I leverage that extra knowledge from other fields, applying them to my daily work.
And what does this have to do with being DevOps?
I still haven’t talked about development or operations, not even computer science! I think you already sense where I’m going with this, therefore:
- Programmers: You have to understand what happens when a service is operated. Understand the concurrence and how does it affect the systems below.
- What happens when new code is deployed? Where does it go?
- What implications does it have?
- What happens when a server starts up?
- What happens inside of a database?
- What alerts does the code you have written generate?
You must understand what your operations team does, why do they do it the way they do, and facilitate the systems operations. Don’t stop yourself from trying to install and deploy a system with your application. Now we have great Cloud resources: it’s fast and very affordable.
- Operators: you have to understand how your development team programs, as well as frameworks and how these are used in developments.
- Don’t be shy and develop an example application to understand what developers do.
- Try to free yourself from having to deploy to production, the goal should be dedicating yourself to more valuable tasks: optimization, instrumentation, etc.
- Take your time to understand the development flows follow to test, integration, verification, etc.
- Give your team the possibility to do these actions autonomously.
- Finally, think about developing tools to make your developers more autonomous.
In the end, no one expects you to be experts in one field or another, or that one or another profession fades away. Instead, it is about speaking to each other properly and getting an understanding of each other to make life easier for you.
Lately, working together for a common purpose: customers.
So, one of these days, sit next to your nearest SysAdmin or Developer to discuss and reiterate solutions on some of the problems you face, looking at what you can do for each other to solve them.
Welcome to DevOps.