IDPs Give Developers More Freedom to Write Code

When Markus Eisele was starting out at the beginning of this century, just as the dot-com boom was starting to go bust, life as a software developer was relatively simple.

“I was lucky enough to just start with application servers and a couple of really big books that basically outlined how to do things in Java,” Eisele, now Red Hat’s senior principal technical marketing manager, told The New Stack. “I was just building my career literally on a bunch of APIs, and I didn’t really have to learn new stuff because it rarely changed. It was a platform, an application server, maybe a couple of vendors, and we’d been talking about vendor lock-in, but that’s been pretty much it.”

Fast forward a couple of decades, the developer world has gotten a lot more complicated. Large teams began to reach even larger scales, new methodologies like Agile and XP appeared on the scene, and technologies like Kubernetes and microservices brought with them new degrees of service, decomposition, and complexity. This was all topped with what Eisele called “this fancy artificial mixture of ‘you build it, you run it,’ with developers being responsible for running something in production.”

There also are growing numbers of regulations that continue to differ from region to region or industry to industry — think GDPR, HIPAA, and PCI DSS — and the Biden Administration’s 2021 Executive Order 14028 around cybersecurity that included such mandates as the use of software bills-of-materials (SBOMs). A similar one, the EU’s Digital Operations Resilience Act (DORA), was approved in late 2022.

And all this promises to continue to pile up with the accelerating adoption of AI, machine learning, and automation and the growing numbers and sophistication of cyberattacks.

Not Enough Time to Code

“People started to realize that there’s a large difference between saying ‘Agile’ and ‘DevOps’ and being Agile and doing DevOps,” Eisele said. “This is where many of our customers are. They basically are not Netflix, they’re not Facebook, they are not Amazon. In size they are, but technically they can’t execute in that way and not because they don’t want to. They probably can’t because they are under heavy regulations.”

The push in the development world has become bridging the gap between what has proven to be highly efficient and agile and that still complies with the growing government regulations and requirements, he said. Developers are at the heart of what every modern company needs to do because they are delivering business value.

The burden of managing complex and distributed technology environments and keeping in regulatory compliance is burning developers out and keeping them from doing what they love most: writing code and creating software, Eisele said.

In the past few years, solutions like internal developer portals — central places for storing all the necessary knowledge about software development operations, workflows, and analytics in an increasingly fragmented development environment — have arisen. There also are Golden Path templates — sometimes known as a Paved Road or Paved Path — that offer developers a highly defined and supported avenue, complete with tooling and processes, for building software and delivering it to production more quickly.

Enter IDPs

More recently, internal developer platforms (IDPs) have hit the scene, creating another way to simplify the development process by putting necessary tools in one place. The Internal Developer Platform site says an IDP “is built by a platform team to build golden paths and enable developer self-service.”

According to Red Hat, “By consolidating and simplifying elements of the development process, the basic objective of an IDP is to make a development team’s day-to-day work more manageable, efficient and collaborative.”

They deliver standardized sets of tools and services for all dev teams, automate tasks like setting up development environments and configuring build pipelines, centralized collaboration places for developers, and governance frameworks for adhering to best practices and complying with security and regulatory requirements.

App developers are the ones that primarily use an IDP, with Ops teams responsible for the initial configuration and maintenance. The process starts with Ops teams “creating an IDP by setting baseline templates that visually consolidate the elements of the development process and governing permissions. From there, developers are able to adjust those configurations and spin up fully provisioned environments,” the company wrote.

IDPs work with internal developer portals, which address the user experience and act as the interface to the platform.

“The platform aspect is basically inevitable when you’re thinking about all the downstream technologies that are necessary,” Eisele said. “The portal is just the landing space. It may provide you views — plug-ins or the document management or the service registry in the sense of legacy CCMDB [Change & Configuration Management Database] or something.”

He added that “the real value starts where you are able to deliver a fully integrated experience, not only from the UI and frontend perspective but also going all the way into the infrastructure.”

IDP vendor Humanitec noted in a column last year how McKinsey and Co. outlined five architectural planes within a platform, with most having at least developer control, integration and delivery, and resource planes, with monitoring and security being other planes that can be added in.

A Central Place for Everything

Driving the growing interest in IDPs is having documentation, automation, and monitoring all in the same place, Eisele said. Internal developer platforms also enable DevOps teams to better balance the need to address the growing security and regulatory requirements and the drive to continuously innovate, iterate, and update in highly competitive environments.

Essentially, developers have to worry less about ensuring that their software is secure and stays in compliance and can focus more on the creative side of software development, even as AI throws new curveballs. Organizations need to know whether the data they use to train large language models (LLMs) comply with copyright and licensing regulations. That information can be delivered to teams via IDPs.

Right now, AI development and more typical software development are essentially two separate — although similar — lifecycles that come with different terms. However, Eisele said he expects that “all the AI hype is coming back to something that is ultimately close enough to application development that it can easily be integrated on the same platform.”

Centralizing all these tools, information, and services lifts a lot of the mundane tasks from developers’ shoulders, which may explain why IDPs are seeing growing interest. Red Hat has seen a growing number of first developments from customers and Eisele predicts the trend to continue. He also expects the trend will continue to tip in the direction of platform approaches over portal-focused initiatives.

For an old-school developer like Eisele, being able to focus more on writing code is a huge win that comes out of IDPs.

“Ultimately, [IDPs] reduce the amount of unnecessary day-to-day tasks,” Eisele said. “Just think of your average browser with 50 tabs open. That is reduced to one tab ultimately because you know exactly where you need to go. … It’s a significant reduction in mental load because you can literally know exactly where you need to click to gather certain information because it is the same for every service you’re working on, for every application you’re working on.”

“You can literally go back to being productive.”