Estafette
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

- Blog: https://buildmage.com

- LinkedIn: https://linkedin.com/in/srirampanyam

#### 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?

Benjamin Brial 00:05:46 Yeah, we were kind of a huge adopter of Terraform infrastructure as code. And we see that we created some blueprint and then there comes the question about how we make the evolution of Terraform and to maintain the day-to-day operation of Terraform. So yeah, we’ll go later as a DevOps we’ll figure out. And then we are waiting for the breaking change. So, you spend a lot of time on it and then you count upgrade all the project in the same thing. So, one example is just Terraform or what we have lived also with customers is where do you set the border between what does Terraform, what does Ansible, what does your Kubernetes platform and where do you want to invest more to make sure that at the end you don’t create legacy automation. And we have lived this that we started with Terraform, but we wanted to also implement the configuration management and finally we see that it’s adapted the same topic with CICD.

Benjamin Brial 00:06:46 We started with Jenkins and then we bring Argo CD, but we at the same time implemented some GitHub actions because it was kind of, and let’s say even not put the AI topic on the top of all of this. So, at some point more there is some time which is passing more. There are these needs of taking care about the automation and how do you maintain all these stack templating. And how do you make sure that you have the engine behind that help you to don’t maintain the STEM stack over and over and over just because there are new people that are deploying. The stack that you have created doesn’t matter if it goes through portal or if it goes through your GitHubís approach right here, the repo and just use it. There is this problematic about I don’t want to manage 20,000 times the same repository.

Sri Panyam 00:07:39 Or the same kind of repositories. Typically, with any development team, at least as they grow, they don’t start to think of their platforms as their first go to choice. They’re cobbling things together. They just put things together, see what works, see what doesn’t work. They build all these scripts, right? And what are the metrics I guess that become evident for a team to pause back and say, hey, what we’re doing in an ad hoc way isn’t working; We need to consider some kind of portalization, I guess. What would you recommend that is? What would you say that is?

Benjamin Brial 00:08:06 Yeah, it’s a good question. Depends about who you are. If you’re the DevOps team or if you’re the dev team, I would say, so I would bring the, an answer to both.

Sri Panyam 00:08:15 Let’s go even earlier. I mean as a startup or as any entity is growing, they will not even know which side of the divide they’re on.

Benjamin Brial 00:08:21 I mean first of all there is topic about score card and how do you evaluate. If you start to feel that okay, we don’t really monitor what we are doing, we start to see that we are losing some time when it’s onboarding new developers or, what is the stacks that we are using or what is the automation behind and all these kind of typical equation where the mouth to mouth approach doesn’t work anymore because we know that as human being, when you pass 50 to 100 people, you can’t know everybody. So, there is this kind of preparation between 50 to 150 where at human size you can’t know anymore older the people. So, you can’t say, yeah, just use this and that and it’ll work. So, I think there is this, when I speak about teams, there is this kind of number of people first of all and also the number of projects that you have.

Benjamin Brial 00:09:14 If it’s a one big monolithic or one project, then it’s kind of easy. If it’s not two microservice approach. But when you start to see the problem of microservice that you don’t know who is doing what, who is managing what and who is owner of which microservice and all this stuff, then it’s, this is the right moment. So, I would say those three metrics, which is the number of people that you have, the number of lack of that you are feeling that there is a need of score cap and to start to track what happened. And the fact that you are starting to ask yourself about who is doing what, which automation, which repository and all this stuff. Then I think it’s the right moment to consider what is your strategy. When it comes to IDP.

Sri Panyam 00:10:02 Yeah. And we talk about people, we talk about projects and there’s clearly process that could be in place both good, bad, ugly, and how do you see like existing process kind of fitting in there and how do you see the process being both a signal and a call for help?

Benjamin Brial 00:10:17 I mean we do speak a lot of about DevOps and developers, but we don’t enough speaking about solution architect and that are working to design the processes to make sure that it’s as smooth as possible, especially for organization that have center of excellences that are trying to think about, okay, which kind of processes should I implement? Because it’s not, I have to, I want to, but because I have to. If you are a regulated company, if you are a public institution company, there is multiple company that are being forced to act in a certain way. So, this is pretty important to make sure that the solution architect, even the security is embedded in the reflection about which processes that I want to take care about all the parties that are integrated, especially when it’s come also to multi-cloud. So, for example, major organization, we know that everybody has a, what to say, the network, the security, the architecture team, the software team, and the DevOps team.

Benjamin Brial 00:11:22 And there is this need to make sure that you have some people, doesn’t matter if you go through GitHub’s approach or if you go through a portal that are working to make them glue between all those people. Even if we know that there is a lot of problematics around the politics, world budget, that people don’t want to lose their field, but you can’t just okay, we don’t care about it. This is one of the main problems about adoption of the IDP world that are coming from more the dev side. They were thinking, okay, we’ll build an IDP and then it’ll be adopted by everyone. No, you won’t force the security, you won’t force the DevOps, you won’t force the infrastructures that taking care about making running. And this is one of the major issues. We come from dev world and say let’s go, it’ll work. And they have to work together. I mean at least it’s not; it’s my belief right?

Sri Panyam 00:12:16 Actually, I mean I was going to jump into some of the architectural components, but I’m really curious about the adoption challenges. The process, the politics, the people. So, you have this entity that is growing to a size where it’s realizing that look, they’re doing a bunch of things and it’s kind of not working because their velocity metrics are going down, their toil is going up and they need something is needed. So, now they either reach out to somebody like yourself or you find them through some channel. What happens then?

Benjamin Brial 00:12:45 I think this problem of adoption is not always a question of techniques. It could be also an equation of this is my project, I want to make it work at any cost. I like to play with new open-source approach. And we have the same problem internally. We love to develop everything by our own because we’re a tech company. And doesn’t matter if you are US or European companies, when you ask a developer, we have this problem, what do we do? They will always say, let’s develop it. It’s a fun project. And then there is this kind of effect that you have with your project because project, you spend so many efforts, this theory that when you have put so many efforts to do this, you don’t want to let it down because yeah, you are almost there.

Benjamin Brial 00:13:35 Which is kind of one tricky thing that I see, which can be complicated to handle, which is kind of very psychological things. And other things when it comes to adoption is that sometimes there is this border of convictions. Let’s say, I will give you some few examples. We are GitHub based organization. So, everything will go through GitHub, every developer will go through GitHub because we will train them to become DevOps. When you have these search convictions, right? It’s complicated to go and when you don’t want to see something, you will find always excuses to don’t want to see something. One example, the other example you can have been that okay, we’ll build a center of excellence. I spent two years to have this center of excellence, and my 20 people budgets to make this center of excellence, and we’ll build for them the automation and it’ll be adopted.

Benjamin Brial 00:14:26 It’s the first steps. But as a human being, if you want that something is adopted by someone, you can’t say only, okay, use what I’ve done. You need to help him adopt and use and contribute. To improve what you have done. And this is a second step, which could be really complicated because it is how do I build the second stage. For example, I give you a factual example. I build a stack, or I build a service catalog where I have my landing zone, and I have the automation on the top of it. You have your repository; it’s scaffolding everything on your Git. So, use it. Okay, you can use it. But let’s say as a developer, I want to change it for my business unit because how do I make this change about everything that you have gave me without breaking everything.

Benjamin Brial 00:15:15 So this is some question that is always difficult to handle when you have spent so much time to build your service catalog. And then for example, another example is you build some forms. Doesn’t matter if you do it yourself or if you do it through a portal, you build some forms and then you end up with 1000 forms. How do you manage the day-to-day operation. How do you make sure that they don’t redevelop something that have been already developed. Because we see on big organization, we have this capability to redo and redo and redo all the time. The same things modular, the five, 10% custom. So, one of the big challenges I will say when it comes to adoption is to make sure that we don’t only think for our ourselves, but we also think for others. And how do you make sure that they can contribute to what you have done? And not only here, I expose you what you’ve done doesn’t matter your strategy API first, backend first, you don’t need a front end or you need a front end or you do it yourself. It’s how do you make sure that it’s not your project, it’s a project that you will be part of. Which is the success of open source. Like it’s not your project, it’s something that you can contribute and then you scale. It’s my belief.

Sri Panyam 00:16:30 It’s interesting you mentioned center of excellence because in a lot of the companyís center of excellence ends up becoming this single point from which ideas kind of emerge or ideas are meant to emerge. And typically, you might have a case where they’re addressing a certain problem, but as the problem space moves within the company, the 80%, 90% case that they are charged with solving might no longer be the problem statement. And the case you mentioned where you have thousand forms coming up or thousands of different informationís coming up, it’s almost like a reaction to what was before, but what is not being addressed today. So, I guess that’s where it sounds like IDPs come in with a set of recommendations on how these processes can be standardized and measured. So now that an entity small, big, medium, large has decided that they need something. And they reach out to somebody who’s experienced in building IDPs. So, what next, like what does an implementation look like for them? They know they want it, they don’t know what it is, what do they do?

Benjamin Brial 00:17:28 I mean we still have some customers which are working I would say through a traditional VMware approach or whatever, the authorization with all the automation, which is not really based on open source that’s saying okay, let’s do some IDP or whatever. And I always explain them, there is no tools that exists that will do the tricks for you if you don’t have people behind. It doesn’t work. So, you need to invest on DevOps platform team, whatever you call it that has both the capability to leverage your automation, create your automation, but also evangelize. Because what you don’t want on this role is someone which is focusing only on the tech aspects that don’t work with your end users to have a recurring loop of, we are working as a team, I’m here to serve you and I’m here to make you something that at some point makes sense.

Sri Panyam 00:18:23 On that quickly, what has that anti-pattern look like in real life in one of your implementations?

Benjamin Brial 00:18:27 Yeah, I mean the anti-pattern is hiring some huge tech expert that don’t want to speak to anyone about this code. And then it ends up doing some really nice tech things that can maybe miss the point about what is your need. Explain me. And what I’ve seen through my career is that the best tech guys are not the best — generally not the best speaker guys. The guy that you want to discuss with that will come to speak to you, to help me understand what you need and how you use it. And I will explain you how you should use it and how you can contribute. So, it’s always, you need to have people that do the automation, and you need to have people that explain it and work with the team. And it’s always complicated to find the, everybody wants the sheep that does everything. But there are not 50 sheep. You can have maybe one or two, right, that are top guys, but at some point, evangelization is not something that you should avoid, or you think because you are developing something which is completely beauty, doesn’t matter if you buy it or if you build it that it will be adopt by yourself. It has to invest on people and product. It’s not only a product topic, right?

Sri Panyam 00:19:48 Right. But if you look at the architecture of a typical IDP, when an enterprise has to take one, what would you recommend ease the ideal architecture or are there stages of evolution that you would recommend? Like where does that fall in? If you’re designing one from scratch today, how would you go about this?

Benjamin Brial 00:20:05 I mean you should be completely agnostic from your cloud infrastructure. So, it doesn’t matter if it’s on-prem, public cloud, Kubernetes, or whatever, but what you are designing should be completely agnostic for it. You should be thinking it’s only this or that. Because what could be true today can be wrong tomorrow. Let’s say you are a startup, you are only on a cloud provider and then you acquire another company, he’s on another cloud provider then, okay, or you are a major organization you say, yeah, today we only do this cloud plus the on-prem. And then you have a new person say now it’s not this one. It’s another cloud provider. So, first agnosticity of the cloud, second open-source automation. You don’t want to have your automation which is linked to a vendor or a constructor of hardware because, by definition, if they are investing on the software which is linked to your low layer, you can make sure that they won’t work to be as agnostic as possible.

Benjamin Brial 00:21:07 They will invest in definitely their architecture. And then there is this topic of portal and platform where at some point it should be also completely agnostic from the automation. And then there is this strategy of build it versus buy it. You should ask yourself the important question, okay, if I build it, when it’s open-source, is it really open source? Is it sovereign? Does it respect the open-source strategy? Meaning multiple contributors from enterprise market behind. Because individual contributor is great. But it doesn’t what scale an enterprise open-source project. You need to have strong partners and vendors that are supporting this or if you buy it, you should find something that is enough flexible to not lock you because like a full product, which is our concern. It is not something that you want to be capable to customize what you have bought. So, this is the kind of typical articulator, right, that you can embed. And then there is this open question about where do you set the border between portal and platform? If you are coming from the cloud management world to the IDP world, could you find something that make the glue? Because otherwise you will have two different software that will have to communicate and then you can create some more automation that is complex to end there and all this stuff. So, there is no tools that does everything right or no software that does everything.

Sri Panyam 00:22:35 That’s a really good segue. I mean where do you draw a line between portal was platform and how would I as a customer know the difference?

Benjamin Brial 00:22:42 What I would say is that portal is the dev word and platform is the DevOps world. But as an end user, you don’t want to take care about all the automation behind and you want to make sure that just like when you’re using something, it’s based that organization layer. And what I see is that this is our play. I’m not here to talk too much about Cycloid, but I never understood how you can separate both of them. Because a portal, we already have it, it’s called Firefox. You can have all yourÖ

Sri Panyam 00:23:16 It’s a UI and API gap.

Benjamin Brial 00:23:17 Yeah. Things need to communicate each other. Self-service portal can’t be separated to the orchestration layer. Otherwise again, you create some friction between the portal and the platform, which is normal. It’s a market of a view. Let’s be honest. US way of designing software are quite simple. They are saying we are coming from the dev web, we’ll build the developer tools interface and then we’ll force DevOps. What we have seen so far is that you don’t force DevOps, you don’t force infrastructure and, on the infrastructure, say you had the cloud management platform world that is kind of dead with all the DevOps and multi-cloud world that trade. So, I think you should figure out how you can build them bridge between these IDP and CMP and doesn’t matter if you buy it or build it, finding something that don’t create more work that you want to solve. And let’s not even speak about AI on the top of it.

Sri Panyam 00:24:11 I don’t think you’re going to have any talk or chat or podcast with without AI at some point in time. Bonus points if we do. But going back to the divide between portal and platform and UI and API and so how would you describe the technical components of this architecture that can unify them? You mentioned principles like being cloud agnostic, being open source friendly, being enabling customizability. But what about a good IDP architecture can actually enable that? Like what would be the components like key components?

Benjamin Brial 00:24:38 So, in term of software, first there is this service catalog. Building blocks that you need to build, right? Behind it, you need to have an engine that is capable to version everything that you have done, the versioning aspect. Otherwise, you will have to maintain multiple stacks, which are kind of the same. Then you need to have the platform orchestration, which is how do you orchestrate and how to make sure that you have a currency between all the tools that you’re using. Then you have I would believe an asset inventory approach, which is how do you make sure that you give a 360 visibility about your environment? Doesn’t matter if it’s on-prem, public cloud and all this stuff. Then there is this topic which I believe that we need to be tackled is the FinOps and GreenOps module. At some point you want to evangelize your developer and anyone which are not DevOps and cloud expert, even the DevOps to your cloud cost impact and your carbon impact.

Benjamin Brial 00:25:37 Because in the next couple of years you will have some trade off about, yeah, you can’t deploy here because you didn’t pay enough. So, you had to decide why you want, you are capable to deploy, especially with the raise of AI that are really high consuming in term of resources. And then there is this scaffolding approach. Where you need to make sure that the interaction between what you are doing and everything that you have on your Git repository respect some structure. Otherwise, anyone that are deploying a new project will face some difficulties when it comes to find a new project or find a project that already exists. So, all this aspect of about scaffolding and to finish, I’m a strong believer about AI as an assistant, not as a do it for you. And as an assistant to make sure that when others are using what you are doing, you are capable to have a feedback loop that is capable to make sure that it’s respecting best practices.

Benjamin Brial 00:26:35 It’s respecting your API, of course the documentation that should be linked to it, documentation logs and to finish to be capable for anyone to contribute to what you have done. To give them the aspect of plugin system. Where you should be capable to give them the capability to create some plugins in a simple way that is manageable. Because as a platform team, you will never be able to address 100% of the use case. It’ll never exist. You can try as hard as you want, it’s not possible because you will have always someone or a business unit that will tell you, yeah, it’s lovely what you have done, but I want this and that and that. So, you need to build an engine that is capable to handle this capability to integrate some custom needs that you will never be capable to handle. And to finish the last piece on the top of it is the capability to measure what you have done and to collaborate on it to be capable to have some clear feedback loop within what you are doing. I’m not speaking only about the link to your slack or whatever you are using in term of instant messenger. I mean a system that is capable to work as a roadmap system within your product to make sure that you give the capability to also help you improve what you have done. And to communicate on it, to interact, to save some time for both the dev and the DevOps when you want to help them working together.

Sri Panyam 00:28:07 The analogy I can think of is it is a lot easier to launch rockets from space than it is from earth. So, you want to get your rocket space as quickly and fast and cheaply as possible. And a lot of this integration is kind of that because once they have an IDP in place, they get all the benefits, but how do you get them there? How do you get these customers kind of onboarding onto your IDP or even getting like forming things in a very left shifted way so they can start using it. So again, if you think about customers building their own service using GRPC or rest or whatnot in custom frameworks, how do you make integrations easy for them? So, no matter where they are, you can meet them there. Like what can you do?

Benjamin Brial 00:28:46 Use simple things that are been natively automated. You can’t ask them to understand all your ecosystem. It has to be simple; it has to be one good use cases being capable to also integrate in the vibe coding approach where you should be able to test and try and fail fast before you want to invest heavily on a plugging or, you need to be capable to be agnostic from any languages. Because if you force the language, you can make sure that the guys say, oh no, I want to use this and not that because we have the expertise and blah blah blah. So, this plus the fact that you need to have people that evangelize that explain that, go to see the team that go to see the members that okay, we have done that. You can do this. You can’t request everything from the platform that you’re building.

Benjamin Brial 00:29:39 You need to have people that are willing and want to spend sometimes with people that are not DevOps and cloud experts. So, it’s a multifactor approach to help sure that your platform that you are building is also serving the interest of someone which are clearly not DevOps and cloud experiment. It’s complex because let’s be honest, like developers like to develop on their languages and it’s also a question of habit, a question of knowledge and question of convictions. I’m a pro React or I’m a pro View or I’m a pro Go or I’m a Pro C++. You can’t compete against that. You need to adapt to, okay, if you want to do that, this is the schema that you have to respect. I will help you make sure that you can do this and that and keep your things. And of course, if you develop something that at the end help the end user adapt faster and are capable to create some plugging in the easiest way, better. I’m a strong believer that the best UI experience is the UI where you don’t have to explain everything to the end customers, to the end user.

Benjamin Brial 00:30:53 And that it’s obvious that okay I can do this in a simple way, which is the beauty of UI and UX and which is the complex things because developing something which is simple and flexible, this is the most complicated things and this is where we see, I would say the lack of capability of AI that are not designed and thought to make something simple. They’re working on patterns, and we see that the way of how it is created so far, we can’t achieve to have this beauty of a strong UX, UI approach with people that thought about, okay, the simple is the better, the smoother. And I mean when people tell me, AI will replace UI, I say we are not living in the same world, right?

Sri Panyam 00:31:45 I mean if you ask me the best UI, is a line.

Benjamin Brial 00:31:48 So there is still a lot of work to do, right?

Sri Panyam 00:31:53 So you mentioned schema registry. Schema registry or schemas and again, meeting where they are. So, with your service catalog approach and having schema registry, like how does a customer kind of get to a point where they are ready to be part of the service catalog? Like what do they have to overcome? Like what gravitational forces do they have to overcome to get to space?

Benjamin Brial 00:32:12 As an end user or as a DevOps?

Sri Panyam 00:32:14 Bit of both. Like if you, if you think about your customer, right? They have to onboard onto your IDP and again, starting from where they are, they are nowhere near and they need to build up something to get to be ready to have a service catalog that they can start off from.

Benjamin Brial 00:32:26 There is fewer principal project that if they have some, infrastructures, which obviously they have, they can reverse some, terraforms on the fly. Like we have for example, an open-source project which is called Terracognita. You connect it to your cloud, and it generate automation for you on your flight. It won’t do like 100% of the job because you’ll have some requirement as an organization, but it’ll help you maybe to have the first layer of automation. So, you need to have at least some automation. Doesn’t matter if it’s infrastructure as code, configuration management, or CICD pipelines. You need to have a GitHub-first approach. If you don’t have GitHub, most probably your IDP topic will never come because it is linked. GitHub-first approach, then I generally build an IDP on the top of it.

Sri Panyam 00:33:17 I mean to me with the service catalog, you’re still starting over with the service and for service you’ll need some kind of API interface that you want to define and share or spec you want to share. So, if a team has that, let’s say GRPC or an open API spec or a re-spec, right? Is that sufficient or is it still a long way to go before that becomes part of your service catalog?

Benjamin Brial 00:33:36 No, it could be really simple like the landing zone, everybody is speaking about landing zone. It’s a simple thing. But behind this landing zone you could have multiple aspects about the security, the governance, the cloud provider and all this stuff. So of course, you want to have at the end some stacks with security network infrastructures, application layer that is as flexible as possible. But a simple use case, which is the base of everything that we are deploying a landing zone or, the set of tools that we have. For example, I don’t know as a developer, I need to get access to my 10 tools as a developer to develop, or DDI topic. Or scaffolding some new project. It’s not something complicated but take sometimes you can easily build some stacks around this without overthink about which kind of service catalog. It’s things that you are using all the time. So, I would say the simplest one is landing zone and tools that the developer is using.

Sri Panyam 00:34:42 Yeah, and one thing you mentioned that’s interesting was security. How do you see security and or lack of play a role in both the adoption and friction against IDP?

Benjamin Brial 00:34:51 What we see in term of security is that security is also taking the pass of security as code. Like we saw premium software, whatever, everything as code. J policy and stuff like this. So, there is this huge need of a GitHub first approach. Of course security, like at the time weíre more focusing on compliances and, bundle and software plus hardware. But we see that with the raise of Cloud, there is more and more security as code then as soon as you add this approach, you can embed it everywhere inside your pipeline, inside your stack, inside your policy management, everywhere. But more we are diving in the, I would say the cave of infrastructures more the ASCA is less obvious, like let’s be honest. But what we see and what we didn’t see a couple of years ago is that this initiative can even come from the security team that came all the network team for example, that want to give access to everything that they have done in a simple way because they know that they will never understand the clue about everything that we are designing.

Benjamin Brial 00:36:06 Because it’s a world like the security aspect, the network aspect. If you are, you can’t scratch it or you understand what happened or you are in the metrics. So, we see some teams that are coming on this path that go ask code and go for a self-service approach to give access to everything that they have done, respecting best practices, which is GitHub’s first design approach.

Sri Panyam 00:36:29 This sounds like there is still a bit of legwork that teams have to do to develop a security as code culture. But for, and I’m going to go on a limb here for a big proportion of the population that is not adopting this culture, how do you get them over that hurdle so they can be IDP ready?

Benjamin Brial 00:36:49 I mean our conviction is that you should respect the borders and the competencies of each business unit, and your platform should be capable to include the complexity of this big organization. And this is one of the key adoptions. For example, on our side, we have some forms. Those forms are presented for the end user with 10 different teams behind the one that are handling the CICD, the one that are in the network, the one that are doing the security aspect and all this stuff. And again, you can’t request everything from everyone becoming the expert of everyone. It’s not possible when you have 5,000 or 10,000 IT team. You can’t expect everybody expert from everything. It doesn’t scale. It’s not the case and it’s obviously not possible. So, your software should be capable to handle this capability of you present your work, but you are working in an ecosystem. You are not alone. That is why again, GitHub’s by design and your IDP should be capable to interact with your automation below. And that is why we’re a strong believer about the open-source automation, which we link to it.

Sri Panyam 00:37:56 Is there a risk that you could end up becoming a center of excellence and kind of becoming that bottleneck in day-to-day process? Like how do you manage that risk?

Benjamin Brial 00:38:07 I mean, as a software? Yes, definitely. It’s a huge challenge to do it yourself. I mean people started with a couple of guys, let’s develop an IDB. How do you want obviously to compete with software and vendor that have 4,100 developers for time that are pushing so hard on it. Let’s be tangible little bit. It’s really complicated, and the ecosystem world is huge. But what is interesting again is that on this AI topic is the capability to test and try and fail fast. To don’t look for the, the performance, the beauty of the code, the day-to-day operation and don’t create that. You will, but through AI you can test and try and see if it’s adopted and everyone can with few vibe coding, develop something that he thought and he present and then let’s monitor it to see if it’s used or not. And then if it’s used, let’s invest some developers to do it. And I think between this mix of decreasing time to test, I would say time to use and see if it’s makes sense, the time to market. Then you invest some developers to make something respecting the best practices. Doesn’t matter if it’s on-prem, I mean if it’s do it through self or through a software vendor.

Sri Panyam 00:39:24 I think we touched upon the cultural challenges, adoption, the people side of it, the, the organizational side of it. What about technical? Like again, people want to adopt, they’re really excited about this. What’s been the most technically challenging option that you had to go through with the most excited and the most enthusiastic customer?

Benjamin Brial 00:39:40 I mean the biggest issue that we have, Sri, a lot of customers, is the internal battle between on premises and cloud, which are generally not the, for enterprise market, not the same one. Which is normal. Let’s say you have done 20 years of traditional virtualization. You are used to do some, not tips, but to go through a new UI that make the magic for you, right? And it’s working and then well kind of used to a little bit of insatisfaction, right? Then you say, okay, now you do some CICD infrastructure code configuration management, security as code and you’ll help anyone be capable to adopt and contribute to what you have done. Of course they will say no. And they will find thousands of excuses why cloud is not good or on-prem is not good. So, they’re fighting against each other. Which is true.

Sri Panyam 00:40:37 But that’s what’s like a cultural organizational issue. Not a technical problem though.

Benjamin Brial 00:40:40 Yeah. And the bigger challenge is how do you make sure that you have — and this is why drift control exists — and how do you make sure that you cover as much as possible the automation for your infrastructures. Doesn’t matter if it’s on-prem and public cloud on Kubernetes. It’s complex because you still have some mainframe, you still have some tools that you want to deprovision, but you content provision it. Let’s keep an example Jenkins. Everybody wants to go out from Jenkins for good or bad reason. But yeah, they want to move, and you say, okay, how many projects do you have? 7,000, will take a little bit some time to move from, so how you provide the unified experience to make sure that as an enterprise you don’t take some decision that at the end will be achieved in the next five to 10 years.

Benjamin Brial 00:41:32 You need to be be capable to provide a unified experience. And this is a technical challenge because if we take just one pass, which is Kubernetes. As a market we say forget the traditional app let’s only care about native cloud application. It’s the future. You will migrate everything. It didn’t. Obviously, in the market Kubernetes application as you know, five, 10 years ago it was huge. Like, everybody were Kubernetes. And then when you speak to the customer at the enterprise layer, you say, what is the percentage of Kubernetes that you have ready? Couple of percent. Wow. So, this is technical challenge that how do you build the gap between traditional environment that are not DevOps and GitHub-ready. The native one. Of course, the new one will be native. And more DevOps and GitHub oriented. But how do you make sure that mainframe and all the traditional work, I mean Cobal is already, is still existing. In multi-bank. It’s not in the plan to change it because if you touch it, you are scared that, whatever. So, the biggest technical challenge that I see is that you provide a unified experience. Doesn’t matter if you are using traditional tools and application, and infrastructures and the data tools and the native bound in the cloud application infrastructure. And this is the biggest things because there are huge customers that faith is problematic about how I integrate my legacy within my IDP topic.

Sri Panyam 00:43:15 It almost sounds like if the biggest challenge that you have is technical, that’s a really good problem to have. Because typically it’s a combination of Technical Cost Organization, TCO, and you never really find one axis that takes over all three.

Benjamin Brial 00:43:30 I mean, it’s a really interesting project for everyone. For the management, bringing the IT team not only as a cost, but also as a providing some solution to help the developers. It’s also interesting in term of cost approach. Because at some point with the sovereign topic, you need to mitigate your risk with the current, US ecosystem right now. And you don’t want to be linked to one provider, doesn’t matter who you are. Asian, European or US organization. So, I mean what we see on this topic about the IDP, which is Cycloid is that there is a huge, people want to go make something that makes sense. Both dev and DevOps and it’s kind of finally find a middle ground where people can speak. Because automation, right, okay, well learn it or use it. I don’t want to learn, I am not, and I don’t have time to learn, and I don’t understand how to use it, right?

Sri Panyam 00:44:32 You don’t want it to become an M+1 problem.

Benjamin Brial 00:44:34 Yeah, definitely.

Sri Panyam 00:44:36 Changing gears, I have a billion-dollar question for you. Well, actually a trillion-dollar question. AI, I think that’s got to say it all. Where do you see AI impact IDP or vice versa, and what does it mean for you as a company?

Benjamin Brial 00:44:48 So we’ve seen a trend that is say IDP is dead welcome AI agentic software. Do I buy this or not? Clearly not. I think organization that people are looking for more people. More interaction. And do we really want to discuss with the bot, whatever the intelligence that they have behind? I don’t buy this.

Sri Panyam 00:45:13 They’re also looking to cut cost though.

Benjamin Brial 00:45:15 Yeah. But do you really want as a an IDP having some features that help the developer, the DevOps to save some time when it comes to AI? Yes, I buy this. Yes. I buy the capability to develop some plugging as fast as possible. Yes. I buy the AI that are drilling all the tests and make sure that it’s respecting the documentation, your API and saving some time for both dev and DevOps. Yeah. But at some point, do I buy that AI will replace a really nice way towards UX, UI interface? No, I don’t. Because to buy this, meaning that people will have to understand all the process to design, build, migrate and run, doesn’t matter if it’s on-prem traditional application tools and cloud. No. You develop an interface to simplify the way to be capable to interact with this and through an LLM, whatever you don’t want to have someone, and you’ll never have someone and say okay, I want to do this and that and that and that and that. And then taking consideration that at every equation that you have, you have an eight to ten second wait, right?

Sri Panyam 00:46:33 But some would say that that’s a feature. I mean I may agree with that, but like some say that’s about the defining quality of AI today is that simplified chat interface.

Benjamin Brial 00:46:43 We’ll see what is the future? My bet is the next 12 to 18 months you will have an AI crash. Which will lead to all the VC fund enterprise software that have been overrated on the valuation. Most probably we will have 80% of VC that will bankrupt. And now what we see is that as a global economy, VCs and private equity are looking for profitable company. So, I’m at some point paid by our customers. And there is this huge problem about the AOI and the level of investment that have been made by the AI market in front of the revenue that they generated. And based on few papers that you can easily find on internet, if you take off all the AI investment that have been made in the US, the US is in recession. Economically wise.

Benjamin Brial 00:47:36 So I mean there is this huge question about how does an organization is real level over the time. And we see that on the last five years, three years since the COVID, like the startup ecosystem took a huge hit like, between 50 to 70% you’re on your decrease investment out of the AI bubble, then I don’t know. What I see is that people are explaining me that bomb AIG will take longer, maybe will not happen the way of how we have built the LLM or not enough good. We should rethink the way of how we structure it. We’ll see, right?

Sri Panyam 00:48:21 I mean, I think your countryman Yann LeCun has some good points for sure.

Benjamin Brial 00:48:25 And let’s not even mention about the carbon impact and the multi-criteria impact that he has in term of limit of resources. We know that by 2030 the capability for data AI that double every six months, won’t be possible. And there is this problem about which data do you inject and the level of data that are generating with LLM and all the problem of LLM. And do you really want that on your infrastructures? There is a margin of errors. And my belief is that we should always keep human in the loop. That at some point we should have someone and understand what happened and that you don’t want to create some technical debt. Which is one of the main challenges also about AI code generated. Is how do you make sure that you have someone that understand what have been done that can read, then can challenge, and can make some change. And this is a collective, I would say, challenge that we have when we use AI. Is the where do we set the border between a junior and intermediate and or a senior expert developer. Is how do you use it? How do you make sure that you don’t create some security issues, right? So, with AI, we can spend an hour discussing this.

Sri Panyam 00:49:47 On that note though, like, I mean with the current state of AI and whether it’s a bubble or not, how would you or anybody implementing slash integrating IDPs, like how would you hedge that bet? Like what would you do to hedge that bet?

Benjamin Brial 00:50:01 I mean, you need to understand what you’re doing. For me, AI is a tool. If you want to use the tool, know how to use it. Know how to do it and know what this tool is capable to do. You need to know what you are doing. You can’t rely on something that you don’t understand. And this is the only advice if you want to build and or implemented some AI functions inside your IDP is make sure that you control what you are doing. And that you keep human in the loop. Because if you wipe your GitHub base because AI made a mistake, you have to face the consequences. And we are not speaking about theoretically. We know that AI is capable to understand that they made a mistake, not really know how, why. But I think keeping always the human in the loop is really necessary.

Benjamin Brial 00:50:56 Otherwise, I mean I’m coming from the infrastructure world, so I’m more kind of prime guy rather than dev-first oriented, you should be careful with what you’re doing. Especially as we are speaking about infrastructures and, that already bring a lot of power. I mean infrastructure as code is already a lot of power. So, you can, delete a word project. Like doesn’t exist anymore. So, what I will say is again, understand what you’re implemented, make sure that you don’t suffer from the hype, because again, you will be judged on the ROI. And you should monitor and make sure that what you’re doing is makes sense and, that you should keep your sovereignty approach. Because otherwise the money that you spend right now, you will have to pay much more later. Because we know that today AI business model is not profitable and one way or the others, we always know that it is the customers that pays.

Sri Panyam 00:51:51 Yep. I’m sure this is a topic that we can talk on for hours.

Benjamin Brial 00:51:55 With pleasure.

Sri Panyam 00:51:56 As we come to a close, what about IDPs and platform engineering that, I mean, what are other areas that our customers should be aware of and can dig more into

Benjamin Brial 00:52:04 In term of IDP and platform engineering, you should really work within your organization to understand your pain points. Don’t focus on the market trend. We have to the same as AI. What is the problem that you want to solve? Let’s go back to the essential. What is the problem that you want to solve? And before building a rocket, let’s build the first step. Because we always have a lot of architects that built the rocket. But let’s start with step one. And make sure that we learn by doing things, which I believe is really important because sometimes we can buy huge project with a lot of investment and then comes the problem of ROI. So, it’s not fancy, but it is again asking the good question, which problem do I want to solve and how do I solve it before looking for tools that will, doesn’t matter the tools, help you work on this problem. I mean, this is what I will think about it.

Sri Panyam 00:53:08 And our listeners on this show how can they learn more about platform engineering? How can they learn more about IDP and Cycloid?

Benjamin Brial 00:53:14 I mean our \site; the documentation is completely open. We have some open-source project that you can use it for free. We won’t !!! up the licensing model just because you are using our open-source project. I mean you can test or try definitely without any issues. So, I mean it’s a win-win situation.

Sri Panyam 00:53:34 Will we be speaking at any upcoming conference or events where folks could hear more from on this topic?

Benjamin Brial 00:53:39 Today we are at the Gartner conference in London. We’ll be in two weeks, in the Gartner, the developer environment, also ecosystem. And in France we’ll be also in the DevOps Rex where we will have some recs with one of our big customers that have implemented this IDP topic.

Sri Panyam 00:53:58 And for our listeners, we’ll link everything that Ben mentioned in the show notes. Any final thoughts for our audience?

Benjamin Brial 00:54:05 Thank you for listening. If you arrive until here and you listen my word, you can write me directly and I will send you some goodies for free. Because it’s already one hour and eight minutes. So, I mean, this is really good just to drop me some message on LinkedIn and you’ll receive some goodies., after.

Sri Panyam 00:54:23 Thank you very much, Ben. It’s been fantastic having you. This is Sri Panyam from Software Engineer Radio. Thank you for listening.

Benjamin Brial 00:54:30 Thank you for your invitation.

[End of Audio]

---

[Original source](https://se-radio.net/2025/12/se-radio-699-benjamin-brial-on-internal-dev-platforms/)

Reply