What Is an Internal Developer Platform?

   These days we all feel the pressure of shipping more frequently and keeping up with the demands of our customers. With this need to get things done, we see a need to improve the efficiency and focus of our development teams.

More specifically, many of us have noticed that the developer experience could be improved. Developers today often need to know not just their application tech stack, but the infrastructure, CI/CD pipeline, configuration management, and more.

If we could remove the repetitive tasks around configuring deployments, infrastructure, and environments, we could give them the ability to focus.

As you may have noticed, even with our automated pipelines and infrastructure as code, developers still spend a lot of time manually completing similar tasks whenever we set up a new service.

And if your organization has embraced microservices or serverless, that happens fairly frequently. Therefore, teams’ contexts switch frequently between building applications and creating the environment for them. And every team needs people skilled in those technologies.

To resolve the repetition and bottlenecks, many companies turn to internal developer platforms (IDP).

Internal Developer Platform Definition

IDPs provide a self-service platform where developers can quickly set up new applications, configure them, provision infra and dependencies, and deploy to your infrastructure. And for operations, logging, monitoring, and alerting, pre-configured scaffolding provides the basics for every team.

Owned by your platform engineering team, an internal developer platform consists of more than a generic CI/CD platform; it’s an opinionated and standardized path for all teams to take when deploying their services. And to remove friction, all of this is automated and self-service, allowing developers to get back to writing their application logic.

Evolving Needs

With application development, our needs evolved over time. Experiences varied across the years. Technology stack, company size, and company culture influenced the journey toward the need for IDP.

For example, the increase in popularity of microservices and serverless meant that developers would not only be deploying more frequently but that they’d be setting up new services.

Then, with the move to off-prem data centers and cloud providers, we found that developers had to know a lot about deploying to specific vendors. Whether it’s AWS, GCP, or any other provider, specific knowledge about those providers was required to attain the reliability and flexibility needed for our applications.

These factors drove a need for DevOps, where teams knowledgeable about their services could also own and operate them once in production. But there were some problems.

DevOps and Autonomy

With the rise of DevOps and teams owning and supporting their app’s lifecycle, many companies moved from a centralized ticket-based system and centralized tools to one where each team owns their own CI/CD and operations.

In many cases, this didn’t create the improvements folks expected. Though the team had the utmost flexibility, both standards and security were inconsistent.

And every team had to have one or two DevOps experts, with each team re-learning the same lessons that other teams in the organization learned.

Every team had to determine how to deploy, how to configure environments, and where to store secrets and credentials. In some organizations, you could find multiple deployment and rollback strategies within a single department.

None of these solutions provided what development teams needed: easy, fast, and self-service provisioning. They needed something that worked consistently and allowed the development teams to focus on the product and not the infrastructure.

Fortunately, as we moved to the cloud, teams saw how easy it was to provision their own infra through our hosts’ self-service tools. And we saw the need for IDPs.

 While application teams traditionally drive the need for more frequent deploys, operations teams historically pushed to reduce the rate of change.

The Need for an Internal Developer Platform

In short, we need to automate and improve consistency across our ecosystem. And we need to make it easy to onboard new developers and new services as we grow. But to do this we must focus on our products’ needs, our processes, and our culture.

While application teams traditionally drive the need for more frequent deploys, operations teams historically pushed to reduce the rate of change. The fewer things change, the easier it is to maintain, and the fewer outages and incidents that occur.

However, with growing complexity, there’s always something that will need to be upgraded, patched, or scaled. And relying on manual processes will result in slowness and frustration.

Internal developer platforms improve productivity for developers. They improve the developer experience, allowing devs to self-service infrastructure and dependencies. These platforms can also bake in auditability and best practices, giving product teams the focus they need to build features and improve products.

In addition to helping product teams, IDPs remove repetitive tasks from operations teams, giving them the time to improve the platform, automate additional features, and build off of the feedback they get from the product teams.

Taking away the repetitive toil will allow operations engineers to envision and build the future of the development ecosystem instead of catching up on tickets.

So what are some signs that it’s time to invest in an IDP? If your team:

 
• has multiple services or a growing microservice environment
 
• has an increasingly complex serverless environment
 
• needs auditability and governance, has multiple services or microservices, and has the autonomy to create new services when needed
 
• spends 20+% of their time on deployment or infra configuration.

The more complex your ecosystem (multiple services, clouds, etc.), the more an IDP can help.

Costs vs. Benefits of Your IDP

For certain organizations, it doesn’t make sense to invest in an IDP.

Whether you build, buy, or choose some combination of the two, you will still need people who know how to handle your infrastructure. You’ll need folks who can provision databases, initialize the setup of projects, and create an elegant deployment pipeline.

But, eventually, you’ll need them not to do those tasks, and not to build tools that do those tasks. They’ll need to move on to other things. In their place, build or enhance a platform that allows those tasks to be done.

Defining Your IDP

You’ll want to make sure that you start with the right building blocks. Those blocks consist of IDP components and a solid set of guiding principles.

Components of IDP

First, let’s talk about the components of your internal developer platform. Though you might not be able to build or configure everything at once, consider what the following components would look like in an ideal situation.

Configuration Management

With configuration management, you’ll have a consistent pattern for configuring your applications. From environment variables to secrets and credentials, individual teams don’t need to decide how to manage and safeguard configuration.

Infrastructure Orchestration

Internal developer platforms automate the provisioning, scaling, and operations of infrastructure. It uses the APIs provided by Kubernetes, OpenShift, or others in order to simplify the process. Additionally, if you’re multi-cloud or multi-vendor, your infrastructure orchestration should work seamlessly across providers.

Environment Management

Having the right environments available for each team will improve velocity. Also, having a consistent pattern across the organization will prevent confusion and misconfiguration. For some companies, dev, staging, and production environments are enough. Others have more refined needs. Still, others can go from dev straight to production. When building your IDP, consider where you currently are and where you want to get to.

Deployment Management

The IDP provides an automated CI/CD pipeline so that teams don’t need to set it up individually. Deployment and rollback strategies should be simple and consistent across the org. Automated tests, linters, and code analyst tools should be set up already with zero configuration needed by the development teams.

Role-Based Access Control

Everyone should have the access they need to do their jobs. The more automated this is, and the more holistic the solution, the better. And when new developers come on board, your RBAC should give them access to everything they need without manually assigning permissions in multiple disparate systems.

 First, always remember that the IDP is a product and that development teams are the customer.

Principles to Follow

Next, consider what principles you need to establish so that the product is successful. For this section, we’re going to focus on three main principles that should guide your IDP.

First, always remember that the IDP is a product and that development teams are the customer. An IDP needs to grow and evolve with the development teams and the product ecosystem.

Second, self-service is key. Without the self-service component, you don’t have a platform. Tickets and requests to other teams slow teams down. Teams must be able to work autonomously as much as possible.

And third, these self-service platforms need security and governance built-in. They should remove the need for manual audits, approvals, and bureaucracy. If auditing needs to be accounted for, it should be a feature of the IDP.

Keeping the components and principles in mind will ensure you’re building the right IDP for your organization.

Summary

An internal developer platform can allow your teams to focus on their product. It ensures that teams aren’t all solving the same infrastructure or CI/CD problems, and consistency exists across the org.

To get started, request a demo with OpsLevel and learn how it can incorporate the tools that support your application lifecycle. See how OpsLevel can provide a portal to centralize your teams’ needs today.

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.