For more content like this subscribe to the ShiftMag newsletter.

Viktor Farcic works at Upbound, the company behind Crossplane, as a – in his words – “developer advocate, product manager, maybe. Something like that”.

He is also a member of the Google Developer Experts, CDF Ambassadors, and Docker Captains groups, a published author and a host of the YouTube channel DevOps Toolkit, and a co-host of the DevOps Paradox podcast.

In his videos, Viktor often explains the concepts behind DevOps, compares different tools, or shares his knowledge. We’re not sure if he would approve of the term DevOps influencer, but he is an influential voice in the community and, hence, the best person to share his opinions on some burning questions from the industry.

How would you define DevOps, anyway?

Farcic: Many people, companies, and teams misunderstand what DevOps is. Hence, we got roles like DevOps engineer, essentially the same as people did before.

I do not believe there is such a thing as a DevOps engineer. If the whole point of DevOps is to enable communication and collaboration between people who work in Development and those who work in Operations, then what does a DevOps engineer do? That’s just a different title for the same job.

I believe that DevOps is all about self-sufficiency. It is about enabling teams to do everything they need related to their project.

Suppose they work on a frontend application or backend application or anything else. In that case, they should be in complete control of the lifecycle of their application from the beginning, from the idea until it is running in production.

That is much more efficient than throwing things over the wall: OK, I’m finished coding, let me send it to a different department that will do testing, and then they will send it to another department that will deploy it somewhere, and then they will send it to a different team that will do something else and so on and so forth. That is very inefficient.

DevOps is all about joining development and operational skills into a single team that can do everything.

*What about all the buzz about internal developer platforms replacing DevOps? *

Farcic: Internal developer platforms are systems or platforms, as the word says, that enable everybody in the company to perform all the activities they need to do to do their job without relying on others and waiting for others to do that.

In practice, certain experts are codifying their experience into services. Hence, if you’re a database administrator, you’re an expert. Instead of waiting for somebody to ask you to create a database for them or to configure it, you can codify that knowledge, transform it into a service and plug it into that platform so that everybody else can do it themselves instead of asking you to do things for them. Click a button, fill in some fields, and create some YAML; whatever the system is, should be the mechanism for others to create and manage that database without you.

And you should focus on managing those services instead of managing requests from people to do something. That applies to everything.

It applies to infrastructure, containers, building, testing or whatever that something is. If you’re an expert in something, you should codify that experience and expose it as a service to others.

When we combine all those services, we get a platform. We get what we call today the internal developer platforms. It’s a place where people can perform activities related to their work, but they’re not their core expertise because nobody can know everything. But we should be able to perform all the tasks we need for our project. Platform engineering is all about creating internal developer platforms.

How come you ended up in the field of DevOps?

Farcic: The answer is simple, laziness. Most of the time, I’m lazy, or to be more precise, I do not want to do the things I don’t want to do. I want to concentrate on things that bring value.

Early on in my career, I spent a tremendous amount of time automating myself out of my job to let machines do the boring parts and me do the things that interest me.

That had many forms in the past. I automated my tests, I automated my processes through CI/CD pipelines, and so on. Right now, that is in the form of DevOps. I’m finding better ways to enable myself and others to do things.

Many of your videos compare different developer tools or explain how a certain tool works. Do you sometimes feel like there is a new dev tool every day? Do you feel the tooling fatigue?

Farcic: Having more tools is not necessarily better for an individual, but it’s better for the industry as a whole. That’s how we advance. There is a group of people who think that they can do something better. They start a new project, they create a new tool, and that tool competes with other tools in that area.

Without an increased number of tools, we would not have competition. We would be stuck with the tools from 30 years ago.

I will never be against new tools because that would mean I’m against innovation. But that’s for the industry as a whole. For individuals, for developers, that can be overwhelming. That’s normal.

But that’s OK if people focus on what their expertise is. I expect a Node.js developer to explore new libraries for Node.js. I expect Kubernetes experts to explore new ways to create custom resource definitions in Kubernetes. I expect cloud managers to look forward to the new APIs in AWS for new services. That’s all good.

The problem arises when companies assume that everybody will focus on everything, and that’s when people get overwhelmed with tools.

But if people focus on specific areas, that shouldn’t be a problem because exploring new tools that help their core expertise improve and the job they’re doing improves is a good thing. Even if we spend one day every week exploring new tools that result in higher efficiency, we ultimately win.

Which new or existing trends or niches will be emerging as key in the next few years?

Farcic: It’s easier to say what trends would be emerging in a specific sub-niche or category like security, automation, building, or running stuff. But if I were pressed to answer for DevOps, the answer would be – Kubernetes is key. It feels like Kubernetes has been with us for a long time, but we are only starting now.

What comes next is the disappearance of Kubernetes, but not in a sense that we will not be using it, but in the sense that it will become an implementation detail backed by higher-up structural layers.

We will see companies, teams, and providers offering services on top of Kubernetes that will eventually wholly remove it. You will be able to deploy or manage applications or infrastructure very efficiently with Kubernetes without even seeing Kubernetes.

*Experts in the field often say there are no junior DevOps engineers. Do you agree? *

I don’t think that there is such a thing as a DevOps engineer, to begin with.

And if there is such a thing as a DevOps engineer, it couldn’t be a junior person simply because DevOps combines development and operations. Starting your career in that area would be silly because that means that you would focus both on infrastructure and systems and development from the very beginning of your career.

It makes so much more sense early on when you’re junior to focus on learning one thing: how to write code, use AWS, or focus on Linux. And eventually, over time, you will be able to extend your focus, to extend the number of areas you are an expert in, and then you can call yourself a senior.

But if DevOps was a thing, if a DevOps engineer was a thing, which I don’t believe it is, that means that those engineers would need to know almost everything. That’s not a good starting point for a junior.

You create videos, speak at conferences, are active on social media, co-host a podcast, and are the author of two books. Where do you get inspiration and motivation for creating content and sharing knowledge?

Farcic: I am an old person. I have been in this industry for a long time, and many people helped me when I started and through my career. In the second half of my career, I feel that it’s my responsibility to return the favor. It’s my responsibility to help and teach people younger than me. And when they become seniors and principals, they should be helping their younger colleagues.

It is also gratifying for me, and I learn something when I teach others. I have support from the companies and organizations I am involved with. It’s my way of giving back.