How to Choose an Internal Developer Portal for Your Org

If you’re investigating developer portals, you may already see the need for one in your organization. 

Perhaps you’ve noticed that onboarding developers to new services takes too long, that teams spend a lot of time in meetings instead of writing software, or that finding documentation and service owners has become increasingly difficult. 

Even if you already recognize the problems, the tough part is finding the solution that works best for your org. There’s an increasing number of tools and platforms, all with their own integrations into your org’s tool suite. Sometimes they’re focused on service discoverability. Other times they focus on operational needs. So how can you bring together all the needs of your org and ensure that you have a holistic solution—not just another tool?

To help you get started, we’ll walk you through considerations for establishing your internal developer portal and how it can meet your needs across your development lifecycle.

What is an Internal Developer Portal?

Internal developer portals (IDPs) provide a central hub for your developers to build, operate, and integrate with tools and services across your developer ecosystem. An IDP offers self-service functionality, documentation, and easy integration to those tools and services.

Implemented correctly, an IDP allows developers to quickly find all information about a given service—including which team owns it, how it impacts other services in the ecosystem, and whether it adheres to the organization’s software standards. This helps developers onboard faster, prioritize work effectively, and self-serve more efficiently day-to-day. 

Internal Developer Portals and the software lifecycle

Whether your organization follows traditional software development lifecycles (SDLCs) or more modern agile, lean, or continuous lifecycles, the OpsLevel IDP can support all phases:

• Ideation & Discovery
• Development
• Testing
• Deployment
• Operation
• Deprecation

With your IDP and service catalog, you can ensure all the information relevant to your software is in one place. 

Where you want to focus your efforts will depend on your organization’s needs and pain points. Let’s dive into these a bit further to show you what problems they solve.

In a microservice architecture, creating a new service can happen frequently.

Ideation and discovery

During ideation and discovery, we begin to understand the needs for the software we’re about to build. This phase includes analysis of requirements and product-market fit, identifying risks, design of a solution, and prototyping. In some software methodologies, it also involves user interviews, prototyping, and lightweight product testing.

Most importantly, the discovery phase involves setting appropriate goals and metrics for the product.

All of this data will become important as you build out the software product—and with an IDP, you’ll have a central place to store the documentation and track relevant metrics.

Development

Once we know what we’re building and why, development begins. In a microservice architecture, creating a new service can happen frequently—and you may have noticed that many of your teams run into a similar pattern each time. 

When teams create new products or services, they create the code repository, the project, the CI/CD pipeline, and more, all from scratch. Though the team is focused on shipping a new product, they have to first complete this setup work—and it isn’t one of their core competencies. This work is important, but it isn’t done as frequently by your developers.

If the process involves a lot of manual setup, inconsistencies between teams start to develop. For example, between different teams, the CI/CD pipelines may handle secrets differently or use different deployment conventions. These inconsistencies across teams can lead to security vulnerabilities, poor deployment patterns, and support burdens as each team needs to deal with a different snowflake of processes and configuration.

The benefits of an Internal Developer Portal

So how can IDPs help? Your IDP can include templates, automation, requirement checks, expectations, and anything else you need to build consistent and standard services. This makes standing up a new service easy. The development team doesn’t have to learn everything about your infrastructure and CI/CD pipelines to start, and new services are guaranteed to use the same standards as existing services.

Building out an IDP that supports service creation can provide the following benefits:

• Automation - The team won’t spend time repeating boilerplate setup.
• Standardization - The new service will utilize common configuration standards across your org.
• Deployment management - Your org can work with a proven and visible deployment pipeline that is automated and has the proper governance built in.
• Focus on the product - Automating service creation through your IDP allows teams to focus on building the product or service.
• Improved Speed to market - Teams spend less time on learning the tools and pipelines when shipping new services.

The potential to improve service creation through an IDP doesn’t end there. Next let’s move on to testing and the benefits of IDPs during that phase.

Testing

The testing phase and its place in the SDLC timeline vary based on your software development methodology and your testing strategy. At a minimum, however, automated tests should be an integral part of your approach.

With an IDP, you can also integrate and visualize the maturity of a product or service by setting test coverage goals and automating notifications when those conditions aren’t met.

Deployment

Deployment management was already covered in the development portion above. Your IDP has ensured that teams and products use a consistent deployment pattern. But what else can an IDP provide in the case of deployments?

Ideally, your IDP will also provide visibility into:

• Recent deployments - knowing when software was deployed helps ensure that the underlying services are kept up-to-date. 
• Deployment tracking - software deployments that coincide with an outage or incident can provide insight into the root cause.
• Changes in service metrics and reliability - as you deploy new versions of the software, you want to ensure that your software reliability and quality remain high. Deviations from your expected values may indicate a problem.

Operation and service maturity

Service maturity provides consumers confidence in the quality and operational readiness of your services.  And for the service owners, it ensures that they have visibility into potential quality or standardization gaps of their service.

Why should you incorporate service maturity into your IDP?

• It provides a central place to not only identify services and APIs, but also where you can understand production behavior and production readiness through integrations with monitoring and quality checks.
• It can highlight SLOs and track performance of those SLOs.
• It allows for easier incident management across services.
• With standardized checks, you can track required changes for security, quality, and other updates across the organization.

Whether your development teams monitor their own services or you have a dedicated operations team, monitoring your service or responding to incidents requires central access to the information most relevant to operations. For example, your IDP can provide a central place to monitor availability and other metrics. The IDP can also include operational information like playbooks, incident logs, and postmortems.

Eventually, successful services need to scale to provide the right level of support for their clients. With an IDP, you can easily contain all the relevant metrics and quality checks that ensure the service moves in the right direction.

Deprecation and retirement

Finally, software services retire over time. Sometimes they’re replaced or rewritten, other times they become unnecessary. To help your organization with this natural process, your IDP can include relevant documentation on deprecating the service. Your client teams can easily find information on deprecation timelines, as well as where to go next. And once again, having one place to go for this information can make things easier for your teams across the org.

Getting started now will make it easier to adopt more platform features later.

How OpsLevel helps teams across the software lifecycle

Establishing the best developer portal for your organization provides benefits across the software lifecycle, from discovery through deprecation. That means freeing up your developers to onboard faster, self-serve for information, and build and maintain high quality software.

The IDP provides a holistic solution that covers a lot of needs, including integrating your service catalog with your CI/CD, metrics and monitoring, quality checks, and documentation. So when’s the right time to begin investing time into an IDP? Getting started now will make it easier to adopt more platform features later.

Are you ready to explore a solution that will not only meet your needs today, but grow with your needs tomorrow? To begin building the vision for your organization’s IDP, get a demo of OpsLevel.

‍

This post was written by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.

‍