PostHole
Compose Login
You are browsing eu.zone1 in read-only mode. Log in to participate.
rss-bridge 2025-12-17T21:45:00+00:00

SE Radio 699: Benjamin Brial on Internal Dev Platforms

In this episode, Benjamin Brial, CEO and co-founder of Cycloid, speaks with host Sriram Panyam about internal developer platforms (IDPs) and internal developer portals. The conversation explores how these platforms address the growing challenges of DevOps scalability, multi-cloud complexity, and cloud waste, all of which organizations face as they grow.

Benjamin begins by framing the core problems that IDPs solve: DevOps struggling to scale beyond small teams, the complexity of managing hybrid environments across on-premises, public cloud, and private cloud infrastructure, and the significant issue of cloud waste (averaging 35-45% according to major analysts). IDPs can serve as a bridge between DevOps teams and developers, providing access to tools, cloud resources, and automation for users who aren't DevOps or cloud experts. The technical discussion covers essential IDP components including service catalogs, versioning engines, platform orchestration, asset inventory, and FinOps/GreenOps modules. The episode concludes with Benjamin's practical advice: organizations should focus on understanding their specific pain points rather than following market trends, starting with simple use cases such as landing zones before building complex solutions, and adopt a GitOps-first approach as the foundation for any IDP implementation.

Brought to you by IEEE Computer Society and IEEE Software magazine.

In this episode, Benjamin Brial, CEO and co-founder of Cycloid, speaks with host Sriram Panyam about internal developer platforms (IDPs) and internal developer portals. The conversation explores how these platforms address the growing challenges of DevOps scalability, multi-cloud complexity, and cloud waste, all of which organizations face as they grow.

Benjamin begins by framing the core problems that IDPs solve: DevOps struggling to scale beyond small teams, the complexity of managing hybrid environments across on-premises, public cloud, and private cloud infrastructure, and the significant issue of cloud waste (averaging 35-45% according to major analysts). IDPs can serve as a bridge between DevOps teams and developers, providing access to tools, cloud resources, and automation for users who aren’t DevOps or cloud experts. The technical discussion covers essential IDP components including service catalogs, versioning engines, platform orchestration, asset inventory, and FinOps/GreenOps modules. The episode concludes with Benjamin’s practical advice: organizations should focus on understanding their specific pain points rather than following market trends, starting with simple use cases such as landing zones before building complex solutions, and adopt a GitOps-first approach as the foundation for any IDP implementation.

Brought to you by IEEE Computer Society and IEEE Software magazine.

Show Notes

Related Links

Transcript

Transcript brought to you by IEEE Software magazine.

This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Sri Panyam 00:00:18 Hello and welcome to Software Engineering Radio. My name is Sri Panyam, I’m your host. Today we have Benjamin Brial, CEO and founder of Cycloid, a DevOps platform focused on simplifying and accelerating cloud option. Prior to founding Cycloid, Ben led sales efforts at Enova as their first employee before the company was acquired by Red Hat. There we held the role of EMEA cloud business dev focusing on imaging products like OpenStack and OpenShift. Benjamin, welcome to Software Engineering Radio.

Benjamin Brial 00:00:48 Yeah, nice to meet you. Thank you for the invitation. Always a pleasure to discuss.

Sri Panyam 00:00:53 Yes, Benjamin, I’m excited to talk to you about internal dev platforms and internal dev portals. Tell us more. What is that?

Benjamin Brial 00:01:01 I mean, let’s start with the problems. The problem is quite simple. DevOps is struggling to scale. We are living definitely in a multi-cloud environment. So, managing on premises public cloud, private cloud is always a challenge. And there is also a lot of cloud wasted. On average of 35 to 45% according to major analysts. So based on these problems, the goal is to build a portal and the platform between the DevOps on one side and the developer on the other side. So, the goal is to give access to tools, cloud automation, to end users that are not DevOps and cloud experts.

Sri Panyam 00:01:45 And how do you see this problem, well first of all, diving more into the problem itself at different stages of a company’s lifecycle or just size, how do you see this problem manifest itself? In what ways?

Benjamin Brial 00:01:56 I mean what we see in term of IT transformation, people are starting to build some platform engineering team. Coming from the DevOps to platform engineering, we see that GitOpís approach is necessary but not enough. Generally, on IT transformation, they are moving from traditional way to managing infrastructures with on-premises virtualization and then they start to move to a more DevOps like GitHubís approach. But we see that there is some problem of scalability when it comes to DevOps and there is also some problematic of how you make sure that your DevOps automation is scaled. Is adopted by end user that are not DevOps and cloud expert. So, in term of I would say adoption, there is this need of at which stage you are, it could be IT transformation, then it’s important to set the stage right to have the right automation. But it could be also you have developed your own portal, and you are thinking, okay, I need to focus on the automation and listening my developers to how do I bring them some value and less focusing on the portal itself rather than the automation and the tools that you are embedded natively inside it.

Sri Panyam 00:03:12 You mentioned scalability. Like when do you start seeing it? Let’s say a startup with like, three people, they’re not going to see this, they’re going to be on a very GitHub focused flow, but as a scale where and how do you start seeing these pain points?

Benjamin Brial 00:03:23 Yeah, I mean when you start to hire more and more developers that you start that you are losing some efficiency when it comes to scaffolding some Git repository that you start to have more and more developer tools that you need to use. And that you see that with your couple of, I would say 1, 2, 3 DevOps guy that start to struggle to address the need of developers, then it starts to make sense. Of course, when you are, I would say a small startup, I mean you want to figure out how you provide some value with your platform. With your software and you can handle it with a couple of DevOps. But then more your scale doesn’t matter if you are a scaler or an enterprise, there is these needs to on both sides, how do you create some governance within the DevOps team? We have seen within, my previous company that starting at 15 DevOps we had different way to do DevOps.

Benjamin Brial 00:04:26 So the kind of how do you define what is DevOps, what is automation is key and then comes the topic about IDP portal and platform and more you have some developers in front of it more you’re thinking about, okay, how can I give them access to tools, cloud and automation without having being behind all the tickets? And what we saw also with our experience is that there is this monitoring ticket. If the automation that you created start to bring more tickets than it’s solving, then comes maybe the question about how can I give you access to it. Because yeah, let’s be honest, when you are 20 to 50, you can manage it. Couple of dev, I mean 10, 20 developers, couple of DevOps, 1, 2, 3, it’s manageable. You can handle it. But then when it starts to really scale and or you want to address at the enterprise layer, then you need to figure out how you give access to tools, cloud and automation.

Sri Panyam 00:05:28 It’s interesting you mentioned the automation that you create to fix bugs, creating more bugs. So, there’s two examples I’d love to kind of get from you. One is what is a good example of an automation that is used by teams in an ad hoc way to fix bugs? And what are some common results on bugs that come up because of this?

[...]

Original source

Reply