Streamlining Development Workflows With Internal Platforms

Development teams today face increasing complexity as they strive to deliver innovations quickly while ensuring quality, security, and scalability. Markus Eisele, Head of Developer Tools Marketing at Red Hat, discusses how an internal developer platform (IDP) can optimize workflows to boost productivity.

Q: What are the main pain points developers face today that hinder productivity and innovation?

A: DevOps has arrived in many companies. The need to achieve “more with less” and bring applications to market quickly leads to companies spreading the existing trends. Parallel to the “more” responsibility for the DevOps teams and individual developers, the toolbox of the full-stack developers is expanding nearly on a monthly basis with new tools and approaches. This inevitably leads to fewer real specialists who are able to master the complexity of modern applications and their landscapes.

The training of new colleagues is becoming increasingly difficult, and developers see the increasing responsibility coupled with the growing technological stack as more of a burden and blocker for productivity. This is commonly referred to as cognitive load and negatively influences developer happiness, leading to burnout and dissatisfaction with work and even workplaces.

Q: How specifically can an internal developer platform help standardize processes and tools to streamline work?

A: What is necessary to solve the challenges starting with cognitive load can be twofold. One approach is to reduce the choices and create strong reference architectures and master solutions. While this is a suitable solution for bringing down technology complexity, it is also seen as a hurdle and roadblock for innovation. A better approach is to create best practices and golden paths from existing solutions and give teams the ability to capture them in a way that other teams can easily replicate them. Coupled with everything developers need to not only find them but also quickly access documentation enhanced with direct system access in a self-service fashion, you have the core building blocks of a developer portal. 

This portal ideally comes with a standardized set of technologies, for instance, ArgoCD and Tekton Pipelines, which should be available pre-configured and ready to roll. Both portal and underlying capabilities make up the so-called developer platform. Basically, it provides an optimized experience on a well-known and established platform that is curated by a dedicated platform engineering team working towards the best possible experience for their users.

Q: What collaborative benefits can developers gain from an IDP approach? How does it improve teamwork?

A: This depends on the capabilities of the IDP. Something broadly found is the open-source project Backstage. Backstage's core features can be changed and adapted through a plug-in mechanism. There are plenty of opportunities for platform teams to help developers with teamwork and collaboration. The most simplistic approach is to help teams adopt a centralized documentation standard for services and applications funneled through IDP mechanisms. But there are more specialized plug-ins available that can address every upcoming need.

Q: How can an IDP simplify and improve onboarding and self-service for developers?

A: Most obvious is the single point of access to all the tools, resources, and documentation needed to work on their projects. Instead of having to screen endless documents and different bookmarks, the portal allows for quick, centralized access to everything relevant. Beyond that, it enables developer autonomy and productivity by allowing them to request resources, spin up fully provisioned environments, deploy, and roll back without depending on the platform or ops team. 

Onboarding is also accelerated through access to standards, best practices, and workflows for development, testing, and deployment that are encapsulated in templates for an easy project start. A side effect of centralization is improved visibility and governance of the software development life cycle by tracking and monitoring the performance, quality, and security of applications and services.

Q: In what ways can an IDP provide more scalability for development teams and projects?

A: Frequently mentioned is the ability to provision resources and environments more quickly and easily. Reducing the time and waiting for the cost of setting up and ultimately maintaining infrastructure. The standardization aspect during provisioning, as well as monitoring of the total amount of provided components, can’t be neglected here. 

IDPs can also support multiple languages, frameworks, and, ultimately, platforms, allowing developers to use the best tools for their needs and preferences while still complying with company standards and policies.

Ideally, all this happens in a highly automated fashion implemented with the latest standards and tools suitable for handling large-scale environments.

Q: How does an IDP approach help consolidate documentation and make it more usable for developers?

A: The unique and key point here is the unified way developers can navigate and explore documentation relevant to their projects. 

An IDP typically offers powerful search capabilities, allowing developers to quickly locate specific information. Backed by version control features, they enable developers to track changes and updates to documentation over time. 

Collaboration is facilitated through built-in tools that allow team members to contribute to and maintain documentation collectively. This collaborative environment ensures documentation stays up-to-date and accurately reflects the current state of a project.

Q: Can you provide some real-world examples or use cases of companies seeing better productivity/innovation after implementing an IDP?

A: A common theme is the ability to adapt developer portals exactly to developer use cases and company infrastructures. Especially the plug-in system, and in particular, the new dynamic plug-in system, which allows companies to quickly integrate new capabilities into their development toolchain and maximize their IDP implementation advantages. 

Q: What advice would you give development leaders considering an IDP approach – where should they start?

A: When development leaders start thinking about developer productivity, they are quickly tempted to look for productivity enhancements coupled with the measurable success of their initiatives. This leads to misguided approaches adopting certain metrics and pushing teams hard to follow a strict approach across the entire organization. 

An IDP is built on the idea of guardrails instead of roadblocks and is intended to standardize through best practices and collaboration. I strongly suggest starting from the minimum viable product approach and making sure teams get an opportunity to shape the IDP the way it maximizes their productivity before applying any metrics and stringent rules. 

I strongly believe that developer productivity is at the core of successful organizations and is almost a guarantee for a motivated team. Treating IDPs as a part of a process to make people more productive through the removal of overgrown processes and regulations is a good place to start. 

Q: What are some common pitfalls or mistakes to avoid when implementing an internal developer platform?

A: The guarantee to failure is treating an IDP as “another tool” to add to the toolbox. This is the one thing that will absolutely not work. The concept is meant to provide teams with the individual solutions necessary to get their work done more efficiently and not as another corset they have to fit their daily routines into. 

Do not treat an IDP as an extended ticketing or control system. Treat it as a helper to scale best practices and successful efforts to bring them to more teams across your organization.

Q: Where do you see IDPs headed in the future? How will they continue to evolve to meet developer needs?

IDPs may become the centerpiece of developer workflows. While we typically talk about inner- and outer-loop development tasks during software projects, the outer-loop has been somehow focussed on operationalizing and deployment. 

With IDPs, the source code and deployment configuration, coupled with all the relevant documentation and configuration, can be accessed and worked on in a central repository that becomes the heart of initiatives. 

Independent of whether it is a service or a complete application. While the number of technologies involved doesn’t necessarily change, the teams can work more focused and securely on the basis of established patterns and proven approaches, turning a loose documentation place into an active collaboration platform. 

Ultimately, I expect IDPs to become the new approach for application development. Another entry point with applications and services as a first-class object providing context and information tailored to individual developers on the basis of a potentially complex multi-cloud environment, abstracting away the unnecessary complexity.