"how to start with devops"

First of all, I would like to emphasize that DevOps is a culture and not a role. In my opinion one could compare it with a team of commandos that have their own expertise, e.g. sniper, marine, sapper (think about the commandos series). The combination of these expertises, basically working together, makes it possible to accomplish missions or creating business value as soon as possible.

LowOps and NoOps

Since a couple of weeks I found that after lot's of conversations with people, that a rather talk about LowOps these days. If I implement a solution then this means that it is completely automated and that a colleague can deploy machines themselves rather than asking me. Sometimes it is not immediately possible to automate it completely, but then I ensure that it is automated for myself to ensure that I only have to run one command in order to get the work done (LowOps), instead of wasting a couple of hours. If I have created such solution, I ensure that a ticket has been created for a colleague to automate my personal solution for everybody. Example: a collegue of mine transformed one of my bash script in a bot that it now run every night. This means that the knowledge has been transferred and that a NoOps solution has been created and we can both focus on new tasks.

Figure 1: https://www.gslab.com/blog-post/what-is-noops/

First of all, I would like to emphasize that DevOps is a culture and not a role. In my opinion one could compare it with a team of commandos that have their own expertise, e.g. sniper, marine, sapper (think about the commandos series). The combination of these expertises, basically working together, makes it possible to accomplish missions or creating business value as soon as possible.

LowOps and NoOps

Since a couple of weeks I found that after lot's of conversations with people, that a rather talk about LowOps these days. If I implement a solution then this means that it is completely automated and that a colleague can deploy machines themselves rather than asking me. Sometimes it is not immediately possible to automate it completely, but then I ensure that it is automated for myself to ensure that I only have to run one command in order to get the work done (LowOps), instead of wasting a couple of hours. If I have created such solution, I ensure that a ticket has been created for a colleague to automate my personal solution for everybody. Example: a collegue of mine transformed one of my bash script in a bot that it now run every night. This means that the knowledge has been transferred and that a NoOps solution has been created and we can both focus on new tasks.

Figure 1: https://www.gslab.com/blog-post/what-is-noops/

"how to start with devops"

Ensure that you are part of a team with mixed competences and that the team has to deploy the software themselves. Talk with all team members and start with tasks that nobody wants to do as there is a lack of knowledge or willingness. If you start with a task then you will bump into things you do not know. Start to watch videos, attend meetups, buy and read books, read blogs and official documentation about tooling, ask colleagues to review your pull requests and communicate and listen well to people, document things well and prepare and demonstrate solutions to colleagues (knowledge sharing). The last suggestion is to keep an eye on the work-life balance.

"how to start with devops"

First of all, I would like to emphasize that DevOps is a culture and not a role. In my opinion one could compare it with a team of commandos that have their own expertise, e.g. sniper, marine, sapper (think about the commandos series). The combination of these expertises, basically working together, makes it possible to accomplish missions or creating business value as soon as possible.

LowOps and NoOps

Figure 1: https://www.gslab.com/blog-post/what-is-noops/

"how to start with devops"

First of all, I would like to emphasize that DevOps is a culture and not a role. In my opinion one could compare it with a team of commandos that have their own expertise, e.g. sniper, marine, sapper (think about the commandos series). The combination of these expertises, basically working together, makes it possible to accomplish missions or creating business value as soon as possible.

LowOps and NoOps

Since a couple of weeks I found that after lot's of conversations with people, that a rather talk about LowOps these days. If I implement a solution then this means that it is completely automated and that a colleague can deploy machines themselves rather than asking me. Sometimes it is not immediately possible to automate it completely, but then I ensure that it is automated for myself to ensure that I only have to run one command in order to get the work done (LowOps), instead of wasting a couple of hours. If I have created such solution, I ensure that a ticket has been created for a colleague to automate my personal solution for everybody. Example: a collegue of mine transformed one of my bash script in a bot that it now run every night. This means that the knowledge has been transferred and that a NoOps solution has been created and we can both focus on new tasks.

Figure 1: https://www.gslab.com/blog-post/what-is-noops/