No one can be a DevOps. But you should definitely try it

Are you "a DevOps"? You may say you're not;?you're a PO, a dev, a Scrum Master — you might as well be a member of the Finance or HR team and not understand a word of this article! So the short answer is no, you can’t be a DevOps. But rest assured — no one can be one. DevOps?is a mindset, a culture of collaboration, communication, integration and automation between development and operations teams in order to deliver faster and increase quality. It’s not about the specific job title or position of the “DevOps Engineer”, our specialist in the area, but rather about how all of us learn practices and principles that apply to our role in software development and IT operations. By trying this mindset out yourself, you might just save your latest chaotic struggling project. How?

Let’s start from the beginning:

DevOps is most definitely not just a title for engineers.

The emergence of this position in the industry was, however, inevitable. As they try to navigate the digital transformation, companies of all sizes in all industries realize that, with the move to the cloud, the traditional roles responsible for managing the infrastructure, the old servers in the basement, the storage, guaranteeing the uptime of the critical applications, should be replaced by other roles — and there you have it. There comes the DevOps Engineer in every possible size you may want them — graduate, junior, senior, lead…

But can we rewind this tape a couple years? When we barely had started moving to the cloud, the one who bore the responsibilities that today sit with DevOps engineers in projects was no one else than him: The Young, Bold, Adventurous, Rockstar developer who liked to try out new tools. The one everyone called to deploy the code to production (here's a secret: they created a script to do it in three minutes). The one who set up a self-hosted GitLab instance for the team in a spare machine under his desk with 256 MB of memory (probably leading to catastrophic results). The one who first learned Docker. The one who started monitoring the logs and learned about production bugs before the call even came in about them.?Remember?

We should all strive to be that young, bold, adventurous rock-star member of our team and get our hands dirty with these things.

As a PO, as a developer, as a QA specialist, as a designer, maybe as a key stakeholder from a completely different team — not only if you were crowned by fate and fad the DevOps of the team. We should all be DevOps — that’s the key to long-term stability and productivity in our projects. Beware of the silo effect, which diminishes cross-team collaboration and slows down information and delivery. DevOps is not an engineer in another team to whom we drop our work over the wall when it’s done so they find a way to deploy it. They’re a trendsetter in the organization, should be responsible for providing a framework for build, configuration, deployment and observability — but each team should still own the services they develop.

So instead of:

• Working in a siloed manner without collaborating with other teams and without understanding what they are working on in terms of the features you have to integrate with…
• Relying solely on DevOps engineers to deploy your work and configure applications in the cloud…
• Seeing DevOps as just another engineer in another team instead of a mindset the whole company is trying to adopt, and you are also responsible for…

You should:

• Strive to work in a collaborative manner across different teams and departments. In a micro-service architecture, services and applications are typically developed and maintained by different teams. It’s of the uttermost importance to sync with them to get insights into how to adjust course during development, plan integration and catch bugs before they get out of the door.
• Take ownership of the services and applications you are working on. Assume responsibility for the entire lifecycle of your service or application, from development to production. This includes not only writing code but also ensuring that your code is deployed, scaled, and maintained correctly.
• Think about how you’re going to monitor and measure the performance of your service/application. Sometimes the answer is very simple, and may involve adding logs to tracking metrics such as response times, error rates, and resource utilization, among others. By doing so, you can quickly detect and address performance issues before they impact your customers.
• Automate your deployment process. Automating your deployment process can help ensure that your service/application is deployed consistently and reliably. This includes creating deployment pipelines that build, test, and deploy your code automatically. By automating your deployment process, you can reduce the risk of human error and increase the speed of your deployments, and best of all, the whole team is gonna love it. Yes, releasing to production can and should be as painless as pressing a button to merge a branch.
• Embrace a culture of continuous improvement. In a micro-service architecture, services/applications are constantly changing and evolving. To keep up with these changes, you must accept change. Seek feedback from your customers and colleagues, learn by monitoring your service/application's performance, and continuously look for ways to optimize your code and processes.
• Learn new tools and technologies and experiment with them to improve your productivity and efficiency. Everyone is talking about being a learning organization, but it’s hard to implement it without purpose. How about learning about new tools that can speed up the processes inside your own team today instead of studying obscure languages that are predicted to be the next hot one by 2035?

By following these practices, you can start to exercise the DevOps mentality and help your team and organization to achieve long-term stability and productivity in your projects. Be DevOps yourself.

Do you wanna know what these “DevOps guys” are actually doing? How do they deploy 150 services in AWS in 10 minutes? Or what do they even do when Chrome says your certificate is expired? Check out this excellent roadmap with a list of modern technologies DevOps engineers are learning and using.