Pour some coffee, put on some relaxing music and join us for the tenth episode of The Hüb where Marjan Bugarinović shares the valuable experience he obtained while working as a DevOps engineer at Zühlke.
"Welcome to the Hüb – a place where our experts frankly share their opinions, ideas and expertise, their knowledge of the industry, its future and important trends."
What is DevOps? How big an impact does it have? What are the main skills one should have working as a DevOps on a project?
Pour some coffee, put on some relaxing music and join us for the tenth episode of The Hüb where Marjan Bugarinović shares the valuable experience he obtained while working as a DevOps engineer at Zühlke.
One of the definitions of DevOps is a set of practices, tools, and people who coordinate and collaborate to produce better, more reliable products.
On a daily basis, DevOps deals with the acceleration of the entire process from coding to the final delivery of an application to a client. It basically covers development and operations and it is often believed that this is the task of one engineer or one role. Perhaps, but DevOps is more like a culture that should infuse the entire team.
People also confuse a DevOps engineer with a Site Reliability Engineer, or SRE. SRE is indeed a role, but the difference is that SRE is actually one of the implementations of DevOps. This means it has some of the postulates that DevOps applies or prescribes, but it has an additional aspect that is not so prominent in DevOps. We could imagine that DevOps is like some kind of interface, whereas SRE is like a class that implements that interface.
The first and basic skill is to understand DevOps practices and DevOps culture.
Being a software developer or system administrator can have its own advantages when moving to DevOps. If you know how to code, you can more easily master the part of DevOps that refers to automation. On the other hand, system engineers bring in something very important, familiarity with the infrastructure, which is something that programmers tend to disregard. I would say that these two combined make up the second and third skill a DevOps engineer should have.
However, this does not mean that by working as a DevOps engineer your work should revolve around automation and tools. A DevOps engineer should know how to code, but this is not of vital importance, though it will be of great help. Knowledge of infrastructure systems should be at a high level.
The trouble is that we again see the emergence of the previous barrier between Dev and Ops (which in places still exists), when we stop calling Ops engineers sysadmins but DevOps. We improve this by employing people who are familiar with DevOps practices and DevOps postulates, and who will work on educating the rest of the team and participate in the application of DevOps practices on the project itself and in the everyday education of the team. The idea, or goal, of DevOps is to shorten the software development lifecycle, and with a kind of continuous delivery, lay stress on the high-functional quality of software.
This depends on the project itself, but I think that on complex projects the role of a DevOps engineer is essential from the very beginning, because it involves making decisions about the very infrastructure and the manner of organization of the entire development workflow and pipeline.
The DevOps role is also to participate in designing and implementing this, to participate in creating certain procedures, to participate in defining different environments and, of course, to be there for the programmers and constantly educate them as much as possible on the use of automation tools. This is one of the things that a DevOps engineer is there to help with; above all, he or she should be there to set some processes, tools and culture, and help the programmers use the whole of that lifecycle and participate in it with more ease.
There are some postulates which are basically DevOps postulates but affect the entire project. They can be found precisely in a book entitled “The DevOps Handbook”. They are as follows:
Depending on the project and client, we could begin with this third step at an organizational level, by supposing that we, the employees, are the clients in the organization process, and with this approach work on an everyday experimentation and continuous learning, thinking about which potential procedures relating to DevOps would be good to apply in the company.
There is also a segment known as DevOps security, which focuses on secure development. Its purpose is to ensure that code development is secured at every phase. It is very difficult for one person to do this, so the DevSecOps role started emerging, with a greater focus on security. The idea of DevSecOps is that security should be integral part of a project.
This depends on individual preferences and background. The most important thing for a person who wants to become a DevOps engineer is to be ready to learn every day and to react to change.
For a start, I always recommend some of the books that make DevOps more familiar to engineers themselves, such as “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation” by Jez Humble and David Farley.
If you are not approaching DevOps from the engineering profession, for example for a student who wants to immerse themselves in DevOps, I would recommend “The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data”. This book is a novel and though it is even a bit unrealistic, it can be used as a starting point – to see the challenges with the current workflow and how to best react to those challenges.
Another book I would recommend that is more technical than this novel is the one I mentioned earlier, “The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations”. This book helped me grasp some basic principles of DevOps – what DevOps actually is and how to begin applying it on my project.
Initially I didn’t like the idea that I should become part of DevOps just because that was a trend, what I liked more was the idea that DevOps would allow me to participate in the process of creating something of high quality, and in a very fast and simple manner. That was my reason. So, I started with “The DevOps Handbook” and later on did some python bash scripting. I immersed myself in some tools related to infrastructure automation, or the automation of virtual machines for development, then I dealt with particular CI/CD tools such as GitLab, GitHub, Azure DevOps, Jenkins, and so forth.
One of the things I am interested in which is narrowly related to continuous feedback is observability. This and the Kubernetes ecosystem are the two main things that I am currently exploring.
I see observability as a way in which a system that we have developed or are developing can provide continuous feedback. This means that we need to apply certain tools and practices that will make it possible to monitor the performance of the applications, the infrastructure and, moreover, how a code is being executed, better known as traceability.
Kubernetes, I see it as building blocks for future infrastructure - where you don’t have to worry about where your application runs, you just need to concern yourself with writing it. This of course doesn’t mean that a Kubernetes ecosystem and architecture can be implemented everywhere, even though many unfortunately do follow this path. My opinion is that we should build systems that follow Kubernetes architectural designs.
Of course, there’s also constant work with cloud providers, such as Azure, AWS, and Google Cloud, which interests me and makes me more curious.
In addition to this, I am more and more often engaged in interviewing potential candidates, so I have recently become more interested in the recruiting process.
What I find interesting here is that in interviews there are no wrong answers, each answer matters in its own way. It is also important when a candidate gives an answer that is completely unrelated to the question. How they react determines whether they are a person who is ready to learn, to fail, and who believes it is OK to fail for the sake of learning. It is also important that, apart from having technical knowledge, a person should be ready to give and receive positive or constructive feedback. This is one of the things we emphasize a lot, and of course we are concerned about whether a person is proactive and ready to learn.
Marjan started his journey with Zühlke as an Expert DevOps Engineer in December 2019.
Since then, he has worked on several projects that have covered a wide range of technologies, frameworks and programming languages. Some of them include Kubernetes, AWS and Azure, Terraform, Python, Java, Scrum framework, etc.
In his spare time, he is passionate about nurturing his curiosity by reading books, listening to podcasts and doing rock climbing.
