Red Hat’s Markus Eisele on Internal Developer Portals

This is Textron tv. Hey guys, thanks for the throw. We're here with Marcus Islay, who's marketing lead for developer tools for Red Hat, and we're talking about the challenges associated with building internal developer portals, which at the moment seem like they're all the rage.

Hey, Marcus, welcome to the show. Hey, Mike, thanks for, for having me. It's a pleasure to be back.

The concept of a developer portal, I think has been around for a long time, but it seems like suddenly it's gaining a lot more traction. What's your sense of what's going on? What's driving this conversation?

That is a, is a very good question. I think that, uh, the urging need to, to handle complexity, to be able to navigate today's tool sets today's requirements is something that is becoming more and more important with the rising macroeconomic pressure around everybody is asked to do more with less. And developers do also feel this pressure.

And I've, I've heard some like studies even saying that developers end up having angst, not like in the wonderful German word of, of being afraid to make the wrong choices. And developer portals with underlying platforms do offer a very unique opportunity to, to give guardrails. Um, instead of like presenting roadblocks to developers so they feel safe, they can perform, they can ultimately be more productive without feeling that kind of pressure from having to make choices.

How do we strike a balance between the guardrails and the developers kind of wanna innovate? Um, a lot of times the choices get narrowed and one of the reasons we had DevOps in the first place was because we essentially rebelled against centralized approaches, and now we're centralizing again. So is this a pendulum that swings or where are we As, as with many things in life?

Um, this for sure is a pendulum. What I do also honestly believe that DevOps is evolving constantly. And we're not saying stop DevOps.

I think we as an industry, we're starting to lean towards something that was coined as, as a new term as it's called platform engineering. So we're basically dedicating, uh, some developers to be the developers, developers. So it's like, not about centralizing, but it's about making more intelligent choices for teams that do scale.

So if we're thinking about it from the perspective of scale, I think it's absolutely valid to say platform engineering scales, DevOps. So it brings all the goodness that we learned by, by having interdisciplinary teams together into an approach, um, that allows developers to yeah, do what they allow love most, which is basically developing. Okay, so we pulled together the platform engineering team, we go out and build a developer portal and we declare victory.

What are we overlooking? Yeah, I think, um, the, the term ultimately is, is, is wonderful. Um, the acronym, I mean, so if we're thinking about IDP, it could mean portal, but it could also mean platform.

So the platform engineering team also implies that there's way more than just the portal. Um, think about the portal as the single pane of glass as like the, the front door where developers go to every day instead of having to navigate endless bookmarks and open like 20,000 pages, um, all to their downstream tooling that they're working with. But a necessity underneath is to make the right choice for these tools.

So make a choice for, um, CI CD tooling. Make a choice for infrastructure provisioning. Make a choice for intelligent cluster installations for management observability, for security tools.

Even so being as close as humanly possible to what developers need, and also making sure the scales in an enterprise context ultimately requires something that is a platform. And I'm not saying this is something that is easily done. I think, um, the, the critical part is to start small and be able to scale this out.

Um, if we're talking about timelines, this will take, and we're not talking weeks, we're probably talking month or even longer. But, uh, the idea behind this is to treat the platform as a product, making sure that the developers really use something that is usable and helps them scale and overcome all these blockers that they experience while having to make all these choices. Is this also an opportunity to kind of finally get after that DevSecOps workflow that we've been after because, uh, you know, it's been hit or miss in a lot of organizations and does the portal kind of create a focal point for putting those kinds of guardrails in place as well?

Absolutely. I think it, it has so many names. We, we've set DevOps, um, we we're now talking DevSecOps, we're talking shift left, we're talking platform engineering.

Ultimately, this all comes down to delivering a secure software development life cycle from left to right. And, and that has many stages. That starts with even process steps where we're talking about awareness training and people being like literally in the know about what kind of vulnerabilities could be there, speaking of the traditional, um, SQL injection, for example.

But it also incorporates tools. And this could be, um, developer tools like steady code analysis on the desktop. It could also be, um, something that is further down the production pipeline where we're talking about identifying and, and even mitigating, uh, vulnerabilities that pop up like CVEs, uh, in, in a production, uh, flow, right?

And it all ends with audits, continuous audits about this process. And I, I, I don't think it will surprise anybody, um, that this will be weaved into, uh, well-oiled machine, like in a software development lifecycle. So I'm hesitating to even call it DevSecOps because what we're looking for is the secure software development lifecycle, and it touches so many disciplines, um, that that has to be standardized and it has to follow the approved patterns and, and they start early, um, like even with, um, ISO 20, uh, 27,001 for example, which is a very old standard, but it, it goes all the way into like what we've done for ages, and it has to be an essential part of that.

Like security needs to stop being an afterthought. I think as we go along, we're kind of making some progress in the sense that, you know, the Biden administration has asked folks to, uh, especially in federal agencies to secure their software supply chains. But you know, I feel like also we don't do anything unless there's an actual rule or a mandate or a regulation.

So do we need to be a little more prescriptive on the other side of this with some government laws that you gotta adhere to? Because otherwise I feel like everybody just does, you know, the bare minimum, I, I'm, I'm split personally and, uh, for sure can't speak for Red Hat here. I'm, I'm a German.

Um, so I do have a very country specific view into this. We do, um, have some very country specific laws here. I do know that there are industry specific regulations if we're looking specifically into healthcare or even finance.

Um, I, I, as a developer, like personally, I've been bitten by security bucks and they might have been as easy as a SQL injection, um, myself plenty of times. So I do feel an intrinsic need in our industry to, um, deliver secure software. This is not an after afterthought per se, and I do personally not believe that it needs more regulations.

I think it needs more awareness, it needs more attention. And this, the reason for this might be the fact that more and more of our day-to-day life gets digitalized. So we, we just have more software coming across and, and obviously there's exponentially more, um, impact by vulnerabilities across the board, especially if we're looking at, well-established libraries.

I mean the, the prime example is, uh, in the Java ecosystem was log four JA couple of years ago. Um, we all thought logging is solved and there was very few chances that there could be, but it happened to, right? So I guess what I'm saying is, um, we need to be more aware.

Um, does it need more regulations? I don't know. I'm German maybe.

Yes. Let's bring it back full circle. So there's a lot of talk about developer productivity, but do we need to set some expectations here?

Because at least in my experience, it's not like developers are sitting on an assembly line just writing punching code. There has to be a moment of inspiration and that comes intermittently. So what can we expect?

Because you hear a lot of people talk about, you know, software development factories and all these other things, but there's very few developers I know that are inclined to go to work in a factory. So how do we kinda figure out how to inspire them without necessarily making them feel like suddenly they're on an assembly line? Yeah, good question.

And I think the, the idea of having a software factory is, is age old, literally. Um, that, that has been around forever and it never worked. So why should it this time?

I think it doesn't have to, what, what the goal has to be in my eyes, is to remove all the Obi obi ta tasks, right? We need to get rid of everything that basically is daunting and is very, very distant from software development itself. And, uh, if you look at software development, it, it can have flavors in terms of, of programming languages, but for sure it is not messing with white spaces and yamo files.

That is more something that I personally call configuration. So I think, uh, this is exactly the task of the platform teams to make sure that they are giving freedom where freedom is due to make sure creativity stays alive. And that also doesn't reduce developers to just implementing algorithms, but it ultimately, that is what what developers strive for.

They do want to glue a business problem into code, and they do not want to configure infrastructure. So I think that would, for me personally, draw the line between regulations help and like creativity, uh, that will be Team Vari says in in between all of this. Um, some teams might wanna treat infrastructure as code, as their specific area of creativity.

And, and exactly that is what a platform team needs to make sure that the whole product takes into account. All right. So what's your best advice to folks about setting up one of these IDPs and what have you seen that works?

I, I think the best advice is to start small, like set reasonable expectations and solve problems from day one. It is something that will take time. And again, the idea is not to put out regulations over and over and centralized stuff.

The idea is to pave roads. The idea is to help put best practices into a form and shape that is literally applicable by software developers without thinking about it. And as a German, I, I can't get around to mention the, the word outbound because this is what I think about these pathways that I want platform teams to build.

Um, they need to make sure that established and proven ways to develop certain specific pieces, software components, that these get di glued into as many, uh, possible pathways that are applicable for software developers, um, as possible. So it, it is something that will take time. And if you start small, if you set the right expectations, if you focus on on a specific pain point, you will definitely be successful.

All right folks. Well, you heard it here. If there's a lot of time between when I have a great idea and I actually get the joy of writing code, then I'm not gonna do it as often as I should, right?

Because fundamentally, I'm gonna spend a few hours creating a development environment. I'm gonna probably get distracted and find something else to do. So I think IDPs are a step in the right direction, and we'll see how far we get.

Hey Marcus, thanks for being on the show. Thanks, Mike for having me. All right.

And back to you guys in the studio.