This transcript was generated automatically by AI. If you find any mistakes, please email us.
0:00:00
(Announcer)
Hello everyone, you're listening to Cloud Next, your go-to source for cloud innovation and leaders insight, brought to you by GlobalDots.
0:00:15
(Ganesh)
The line between developers and DevOps is blurring, but what does that mean for team structures, skills, and leadership paths in tech? Our guest today is Gal Porat, Global Director of DevOps at Plarium. From operations-heavy beginnings to a more fluid AI-empowered era,
0:00:33
(Ganesh)
Gal shares his journey, insights on the evolution of DevOps and what engineers should prepare for in the years ahead. I'm Ganesh the Awesome Solutions Architect at GlobalDots where we research innovations every day so you don't have to. As always, we invite you to join the conversation on LinkedIn.
0:00:48
(Ganesh)
Let us know your thoughts. Gal, you started your career when DevOps was very much an operations-heavy role. What were some of the biggest pain points back then and how have things changed over time, especially now that infrastructure is a lot more accessible to developers?
0:01:03
(Gal)
First of all, thank you for having me. I don't want to sound cliche with saying back in my days, I think in the world of technology, there's always either a pain point or a new advancement that brings a lot of challenges. And then you have a lot of vendors that are solving those problems. And we're really standing on the shoulder of giants.
0:01:30
(Gal)
You know, I don't need to wake up at night and go to a data center to restart the server. I can do so from my console. So it's not a real pain point.
0:01:43
(Ganesh)
You're very lucky to live in that world as well. I used to get woken up in the middle of the night and have to take a big pack of CDs with all the operating systems on and run to the data center. So yeah, those were bad days.
0:01:58
(Gal)
So I think back then, the dev-infra relationship was very different. Developers handed us the code after a sprint of development, and we had to deploy it into production and to maintain it in production until the next sprint. So you would wake up Sunday morning, you would say a little prayer, and you would go to deploy your code into production.
0:02:22
(Gal)
And most of the time it worked, but sometimes you had to roll back and in worst cases, the customer will tell you after a few hours that something is not working. I think that things change with Kubernetes, serverless and microservices. The entire infrastructure thinking had to evolve. I think you build it, you own it, became more than a model. It became the only way to scale in a world full of microservices. Not only that, but relying on DevOps every time you need to deploy something
0:03:00
(Gal)
can create bottlenecks and it doesn't allow you to do things faster. And with the entire CI-CD world, it really held back many developers from inserting code changes. And I think that today's tools, everything is much more accessible. You have your UIs, you don't need to do stuff through YAML, you don't need to work stuff through YAML,
0:03:25
(Gal)
you don't need to work with terminals, you have it all very nicely. So I think there's no excuse for developers to take ownership around what they created. In production as well, I worked in many places where developers where you developers would insert the deploying the code. And then if something goes wrong with their microservices over the night, they would get the call and, you know, be the first one to check what's going on and to give the first treatment, I would say.
0:03:59
(Ganesh)
Makes a lot of sense. And I lived in those days back in before I was working for Global Dots. I remember being on the receiving end of those hand grenades that come over the wall. You know, here's the new release and now go live with it. And that DevOps world was... Well, it was an invented term, which kind of didn't really mean a lot,
0:04:22
(Ganesh)
apart from that you knew how to use a hyperscaler and you understood a bit more about build pipelines than the average Linux engineer. But in our prep talk, you talked about the line between developers and DevOps getting thinner and shrinking, and especially with the rise of AI tools. Can you share what this means for teams or hiring or the skills that people need today?
0:04:44
(Speaker 3)
What does that look like?
0:04:45
(Gal)
So I'll maybe start with what hasn't changed. And I think that having resourceful engineers is something that is mandatory for me as a manager. In DevOps especially, you know, people that are really curious about learning the technology have a deep understanding in what they are doing, know how to ask the right questions.
0:05:13
(Gal)
And especially in DevOps, they have real patience for troubleshooting. They don't just restart a service and if everything goes normal, they close the case, but they want to understand what's going on, how things are built, and I think that's the most valuable skill
0:05:32
(Gal)
that engineer can have. Despite all the AI hype, I think there's no magic skill set. And, you know, two years ago, we heard the term prompt engineer, but now you can barely hear it. So I think that proves that there is no silver bullets or no magic solutions around AI. You still need to have the same skillset you needed five years ago.
0:06:02
(Gal)
But with that said, I do think that AI tools do make our life easier. They suggest, they assist, they guide you. For example, I had a small POC I tested, I deployed an application over a virtual machine. And after a few days, the disk had filled up and the instance was stuck. And if I go back to the beginning of my career, I had some sort of a command that some senior DevOps handed to me and passed through generations about how to extend the file system and the disk.
0:06:43
(Gal)
And if the OS or the file system and the disk. And you know, if the OS or the file system had changed, you had to go to the second and third Google pages to understand what's going on. But I tried the ChatGPT and it felt like you have a senior member with you that actually guides you through what needs to be done. And it's more than that, because you feel comfortable asking him most stupid questions and don't feel any blame. So I think it's a good thing to have. I don't think it would replace, you know, engineers anytime soon. It's just another
0:07:20
(Gal)
tool. And from a manager's perspective, I think that's quite the opposite. Now I need to validate what my subordinates, what my teammates brings to the table. If they just, you know, ask ChatGPT and reply to me the same answer, I need to validate that. I need to understand whether it's still, you know, valid answer. So I think I need to understand whether it's still a valid answer. So I think I need to work a bit harder to verify designs, answers, what can be done, what can be done.
0:07:55
(Ganesh)
Yeah, that makes a lot of sense. And I also agree with you that it's been the same people who were the people you wanted on your team since forever. And they were the badass Linux admins, were also the badass DevOps guys, that were also the badass SREs, that will also be the badass guys who drive AI and whatever, you know. It's the, well, girls. But it's always the same. It's just you want that same technical core skill set, I find. And then when we're talking about these technical roles and many people in these technical roles
0:08:37
(Ganesh)
eventually find themselves managing people without any formal training, that's happened to you as well. What was that transition like for you and what would you give advice would you give to engineers who are looking to step into leadership?
0:08:50
(Gal)
It was quite challenging, I would say. You know, you suddenly are no longer the only technical and need to provide some technical solutions, but you're responsible for a team, sometimes for engineers that are much senior than you or have much more knowledge than you, so it can be quite challenging. I think my top tip for transitioning
0:09:15
(Gal)
to a technical managerial role would be work on your communication, because management brings dual responsibility. You have your internal customers, especially in DevOps, you have your internal in-company customers, and now you have your team, and you need to bridge between those two ends.
0:09:42
(Gal)
It sometimes feels like playing a round of Overcooked or in Israel, it's called the king of the falafel where you need to answer so many needs at once and you need to do some juggling between demands. So it can be quite difficult. And I think communication is the key around that. You're suddenly exposed to so many interfaces. It's not just about you and your own tasks. And you need to balance between protecting your team's bandwidth and external needs or
0:10:15
(Gal)
business demands. And those are not usually aligned. So sometimes the business needs don't align with the best practices on how to do stuff on the infrastructure. Maybe you need to do something quick and dirty and not go through the best practices on how to deploy an application or how to go through infrastructure as code. So you have to balance between protecting your team's bandwidth and meeting external needs. Sometimes you need to pass on requests that doesn't align perfectly with the best practices.
0:10:47
(Gal)
I think the key skill is communication and situate sensitivity, situational awareness, knowing when to say no, when to push back, and generally when you need to be flexible. I think that conversations with your team and with other departments are totally different. Your team talks tech while your internal customers are mostly like business talks and requirements. And you have to learn how to switch between those languages and how to convey messages and how to be compelling.
0:11:24
(Gal)
You don't want to burn out your teammates. So you have to bridge those two ends. And I think it takes time to understand how to reply to any requirement when to say no, when to push your team to do something. And eventually, if all goes wrong, you have to disagree and commit that you have to learn how to use. And I think a good manager can guide you around how to do so, help you develop this situational
0:11:55
(Gal)
awareness of understanding when to use which tool.
0:12:00
(Ganesh)
I think that's the most important tip I can give. Good advice. And I had something of a similar situation when I was a head of a tech ops team a few years ago. And we would constantly get requests from the team to use the most exciting piece of technology or they were convinced that they could use product A and it was going to solve something. A few famous examples, but I'll never forget giving the team a chance when
0:12:31
(Ganesh)
they said, listen, we've optimized our NGINX so much now that we've moved away from Apache and we're using NGINX and we can handle 10x the load that we could before and we don't need a CDN anymore and all these things. And I said, okay, listen, I'm very sure we do need a CDN, but for the sake of an argument because you've pushed it so hard, I will let you do a proof of concept on it. Then we did a proof of concept.
0:12:57
(Ganesh)
We put this thing as a small subsection of the traffic, we put it live, it completely fell apart, it didn't work at all and we definitely needed a CDN. So it's interesting because kind of sometimes even if you know you're right as the manager in those roles, you kind of have to let the team grow a little bit or show that you're allowing some autonomy in there, even if it's not necessarily the best idea. But it'd be interesting to see how you manage that.
0:13:21
(Gal)
The other way around, I think the DevOps world is full of innovation and buzzwords. Some of them don't last after a couple of years and sometimes your team brings in a new technology or a new product and you really need to learn how to
0:13:40
(Gal)
balance between the business needs and technological needs and how to pick your technologies quite well. You don't want to fight to get something, some product deployed and then two years after it loses its community or it become useless. So you want to pick the right products as
0:13:56
(Ganesh)
well. I'm a big fan of the technology radar for that actually. It's a good way to see what other companies are using and before you fall down a rabbit hole of picking something that's going to be discontinued very soon. We mentioned in our pre-chat that you're not a profit, but you do see trends. Based on what you've seen in the last few years, where do you think DevOps discipline is heading?
0:14:21
(Gal)
And what should companies prepare for in your mind? That's a great question. I think I would break it into three parts. I think there's the non-production, there's the production, there's the FinOps, and there's like a more general perspective on what's going on. The first part of the non-prod, I would say that AI is going to drastically reduce the load over this space. You have good automations, you have good tools, as I mentioned before. Everything is much more accessible now to the level that developers can create their own or support the lifecycle of the application.
0:15:00
(Gal)
They can create their own pipelines, they can support the CI-CD flow to a certain extent. But I think this domain is quite mature. I think that LLM is already in a place that it can assist with scripting and configurations and all of the CICD requirements.
0:15:21
(Gal)
And DevOps would be mostly around optimizations or maintenance of the entire Jenkins or the CICD platform. I think now is the time in the realm of the non-production to invest more in the developer experience, to bring more tools that will support developers and will encourage them to take responsibility around their own applications. I also expect major advancement in the world of testing, which will result in more changes pushed to production quite fast,
0:16:00
(Gal)
so this world is going to be hectic. In the production environment, I think that's where the most changes will be in terms of AI. I think we'll have much smarter monitoring, proactive incident prevention, better troubleshooting. As I mentioned before, the human skill set is still going to be curiosity, root cause thinking and AI will help, but you will still need to have those skill sets. I think the biggest challenge for organizations is how to adopt new tools that are AI based,
0:16:40
(Gal)
how they can combine them in their production environments. And in FinOps, I feel today that you have so many good tools that can analyze and recommend and change your spec. I don't think AI is going to greatly impact the FinOps area because this domain is in a quite good place today. I think that organizations need to have more FinOps thinking when developing applications so that applications will be much more robust, will withstand restarts or scale up or scale up or scale down the application.
0:17:25
(Gal)
I think in the FinOps domain, I'm quite skeptical here that AI will do a major improvement. I think that right now, there are really good tools that helps you to be optimized in terms of requirements, scaling up or down your workloads. I think the challenge and what organizations need to do is to involve more FinOps thinking
0:17:51
(Gal)
when architecting applications, meaning having applications much more robust that can scale up or down and then those tools can have much more effect. You can see much more cost reduction. And again, I might be wrong here, but I think that there are so many good capabilities today that are not being used. AI is just, I think,
0:18:16
(Gal)
something that will be on top of the existing capabilities and not change something significantly in terms of FinOps. And on a general perspective, I think that now is a great time to empower not only developers, but also DevOps or other roles to develop more internal tools, stuff like just-in-time access, reporting, or operation tools.
0:18:44
(Gal)
I mean, And I think every organization will benefit from having more responsibilities or be open to more development from tech folks that are not only developers.
0:19:15
(Ganesh)
Makes a lot of sense. And on the sort of internal application creation or internal developer. I also think that AI is just a dream machine for enabling anybody who wants to vibe code a UI for something that doesn't have a UI. You can certainly do that almost instantaneously, which used to be very difficult back in the day.
0:19:40
(Ganesh)
If you wanted to build a UI for something, you had to have somebody who really knew what they were doing. So, yeah, there's definitely a lot of scope in there for people to do more interesting things with their data or with this something specific to their company. So it's a great time. We're coming towards the close, but we like to ask everybody who comes on the show the
0:20:00
(Ganesh)
DeLorean question, which is if you could go back in time and give yourself one piece of professional advice, what would that be?
0:20:07
(Gal)
I think that being a DevOps manager in mid-sized companies can be quite a lonely role. At the end of the day, your peers are engineering managers that are most likely developers. And they don't share the same pain as DevOps. On the contrary, I think that some of them are your customers. And it might feel a bit lonely where you don't have anyone to share the pains with, to consult with, and you need some sort of a community. So I would advise myself to
0:20:46
(Gal)
look for a community of operation managers, DevOps managers, to get some more of their insights to know better to understand that, you know, you're not alone in this challenging role, I would say. And I think I don't know if there's something like that, but a community for DevOps managers to share their experience, tips and challenges. I know that in larger organizations there might be more than a single group of DevOps or it might be a different case.
0:21:20
(Gal)
But in mid-sized companies, usually it comes down to certain person like myself that is managing the entire DevOps department.
0:21:31
(Ganesh)
That's a very honest answer. Thank you for that. It's surprising how many of these job roles are like that. Particularly if you're a CISO or higher up or head of or something, you do find yourself isolated. But strangely, with Telegram and WhatsApp and signal groups, I find that they'll do a good place, particularly for those lonely roles.
0:21:55
(Ganesh)
Because I'm in a WhatsApp group with lots of CISOs in the UK, and they express things that they would never be allowed to be expressed on LinkedIn, for example. But in a private community, they can get help and advice on things that they would never be allowed to be expressed on LinkedIn, for example, but in a private community, they can get help and advice on things that they would be punished for in a public format. So we have some ways at least these days. Wonderful, Gautam, thank you so much for your time.
0:22:18
(Ganesh)
Pleasure having you on the show. Any closing remarks?
0:22:20
(Gal)
I think that unlike development and programming, which are here for the past few decades, DevOps is quite a younger area that is still evolving, especially now with all of the AI hype. And I think that organizations need to embrace cultivating the DevOps culture. Because at the end of the day, it's something that has a great impact over organizations, and it needs to be much more well understood.
0:22:58
(Ganesh)
Wise words. And thank you for your time. Really appreciate it. This episode was produced and edited by Daniel Ohana and Tomer Molvidzon, sound editing and mix by Bren Russell. I'm Ganesh The Awesome. And if you're ready to deep dive
0:23:13
(Ganesh)
and start transforming the way you approach cloud practices and cybersecurity strategies, then the team and myself at GlobalDots are at your disposal. We are cloud innovation hunters and we search the globe looking for the future tech solutions
0:23:26
(Ganesh)
so we can bring them to you. We've been doing it for over 20 years. It's what we do. And if I don't say so myself, we do it pretty well. So have a word with the experts, don't be shy, So have a word with the experts, don't be shy,
0:23:36
(Ganesh)
and remember that conversations are always for free.
