DevOps is dead because of being misused. It's a concept that has lived long enough, uniting practices that are considered good. But nowadays those guys would better be called release engineers, cloud engineers, etc. — we all do automation, business administration, network engineering sometimes, and research how to optimize the performance. We are past that stage when we can't name ourselves

DevOps is more like a marketing approach today.
As the market shapes our perception of things, calling someone a DevOps means that person can do everything, from development and to operations.

So, if you write "DevOps" among your LinkedIn skills, your mailbox will be abound with messages from recruiters.
This is how the market works. It's tough to explain to non-tech specialists the difference between DevOps, System engineer and Cloud engineer

In big companies, such as Amazon or Google, we don't have this title: it is replaced by Software Development Engineer, Cloud Infrastructure Engineer, etc. titles

I generally don't like the "engineer" part in the DevOps role name. What's the difference between a DevOps engineer and a DevOps specialist? For me, DevOps is a philosophy, but the engineer is just engineering. There was a time when answering "what is DevOps?" was kind of a big part of my job. I used to explain this role through the concept of Continuous Improvement — and yes, I still believe in it. You do something today, and tomorrow you check how to do it better, and you should never stop. That's the true DevOps culture.

The person who doesn't explore the ideal state of things, and doesn't strive to understand where to head to reach the ideal, can not be called DevOps. But to be honest, people who are doing actual DevOps are rare, very rare cases.

Netflix will always be the one of DevOps unicorns. Not initiators, but those who make DevOps happen in its native way. At some conference, I heard a talk from the Netflix guy, explaining: "yes, we are doing some DevOps, but for us, it's the result of what we do. You talk about DevOps as some processes that we do, but it's wrong. If you'd try to copy that, you'd fail." So, work with your own context, look where you are today, use the proven practices and elaborate your patterns

Some people say the Internal Developer Platforms are the new DevOps.
I kind of agree: it's getting more structured by abstractions, enabling self-service between teams. Of course, if you have your shop, then serverless is a huge challenge requiring a lot of work you should handle by yourself. But yeah, Kubernetes will do it for you (laughing)

If the company has to hire a person who knows how to improve pipelines and at the same time understands the product, it needs a software engineer who knows modern practices, but not DevOps.

In general, if one's team value consists in producing code, then when it comes to some configurations, engineers should be quite fluent to understand how to fix the things needed to be. Or learn how to do it otherwise. We used to call DevOps a person who does low-level things, but his function is not support code

When considering becoming a DevOps as a roadmap, you should learn working with operating systems, working with networking, typical patterns of the systems, monitoring, CI/CD, and configuration. These are the 6 key areas worth knowing for DevOps. Depending on your T-shape profile you can choose the main one of them to dive in deeper

At almost every conference we hear and speak about some new & hyping frameworks. But in reality, we should dive deeper into the basics and discuss more algorithms, structure, architecture, and basic distribution systems

Hybrid solutions are what we will see through the next 10-20 years. Trust in storing encrypted data in the cloud will grow. And maybe we will observe the clouds being adapted to the specific legislations of different countries

Regarding the future, I believe we will move to serverless and for me it means we won't need so many YAML files