A few of the reasons Internal Developer Platforms (IDPs) are built are to enable self-service for developers and to enable efficient collaboration between developers and other departments. One way to do it is through automation of certain processes which involve people’s communication or just may take an unnecessarily long time to finish. In this article, we will take a look at examples of the routines which developers often face and the ways the developers can interact with the IDP to optimize those routines.

Examples of common processes

Creating a new application or library

Every new application will require CI/CD configuration, local dev configuration, initial boilerplate code, and initial documentation. This can be automated by introducing templates/reference applications with boilerplate logic. There will be different templates for different software kinds, languages, frameworks, etc. This way, when a developer wants to create a new application, they can choose an appropriate template, configure it with a few inputs if necessary and create an application from it with a single click. Instead of taking time to copy-paste configs from an existing application or finding out everything as they go.

Exploring available internal software and finding responsible people

Developers typically want or need to reuse what is already built inside the company. To do so, they need to somehow discover first whether the software they need already exists. This may be done via simple person-to-person communication, but a Developer Portal can ease and centralize the process by providing a Software Catalog. Software Catalog contains the whole collection of software the company built (applications, libraries, ML/DL models) with some useful metadata attached to it: owner team, description, docs link, aggregated info from monitoring/pipeline systems, etc.

Exploring architecture

When a developer is onboarding on a project, they have to learn a lot about the project, including its architecture. They can learn by reading documentation if available, talking to colleagues, and reading code.

Another source of architectural insights can be auto-generated by the IDP diagrams with dependencies between applications/infrastructure resources. The diagrams can be generated from metadata files and kept together with the source code.

Provisioning the infrastructure for an application.

Usually, developers don’t have permission to make infrastructure changes. They have to ask people from other departments for assistance with every infrastructure/deployment change. In some cases, a developer can’t even update environment variables without this process. Sometimes a developer just has to go through a PR process, but it still requires them to go outside the team.

IDPs can remove this barrier by providing standardized mechanisms of configuration management or by use of Platform Orchestrator.

Creating ephemeral environment

In some cases, it’s nice to be able to bootstrap a temporary environment. It may be useful during CI processes to do an integration or NFT testing. Developers also may benefit from it in case they need to test something in isolation without the risk of destroying their shared Dev environments.

This problem can also be solved by using the approaches described above: standardized mechanisms of configuration management or by use of Platform Orchestrator.

Ways of interacting with the IDP

There are different general options and concrete approaches for interacting with the platform.

CLI tooling

A CLI tool may be enough for handling many use cases. It can be necessary to introduce a backend provided by the IDP to perform complex tasks, which would be hard to accomplish locally in each developer environment.

Pros:

• A well-designed CLI can be very useful for automating tasks with scripts or other tooling.
• The developer doesn’t have to go outside his development environment.

Cons:

• Not very intuitive – you have to learn how to use it first. However, a well-designed CLI can ease the learning path.
• Not well suited for reasonably rare tasks. It’s easier to do it using a UI than to learn how to use a CLI.

Internal Developer Portal

An Internal Developer Portal is a single UI, which aggregates information/actions from different tools in one place for developers' convenience. There are several commercial developer portals, but an open-source example is Backstage . Backstage has some built-in functionality (like Software Catalog and templates ), is very extensible and has a lot of ready-to-use plugins.

Pros:

• Intuitive for the use, since it’s UI; should be easy to learn.
• You can aggregate different tools here, such as pipelines, monitoring, alerting, etc.
• You can display visual information here, like graphs, pictures, etc.

Cons:

• Automation is hard.

Platform Orchestrators

The idea is to provide developers with self-service capabilities for managing infrastructure and environments. The platform team can describe each service they provide, by publishing a well-described interface, and how requests for this service are going to be fulfilled. A service can be a database, monitoring configuration, or even provisioning a new environment.

Developers, on the other hand, can request a service, which will be fulfilled automatically, as the platform team described. This way a developer will just declare that for their application to work, it requires a Postgres , for example, and everything else will be configured automatically according to how it was configured by the platform team.

The cool thing is that you can describe everything as a code on both sides.

Kratix and KubeVela are examples of such open-sourced projects. Both of them are built on top of Kubernetes and use Kubernetes CRDs as a contract between developers. The main difference is that KubeVela focuses on describing the application with its dependencies (like database, ingress, etc.) while Kratix focuses on providing an interface for the infrastructure.

Pros:

• Developers don’t have to ask Ops for help with configuring infrastructure and can do it by themselves. Env variables are always under the control of the developer.
• May enable Dynamic Configuration Management, which means that it should be easy to create ephemeral environments (for both, CI and devs/QA).
• Additional guardrails for misconfiguration of the infrastructure. It enforces the creation of and adherence to company standards.
• Since Platform Orchestrator has all the knowledge about applications and infrastructure, it’s possible to visualize it.

Cons:

• Platform teams need to be extra careful while completing their interface designs, eliminating the possibility for developer teams to misconfigure infrastructure by accident (or on purpose).
• It’s harder to control infrastructure costs since infrastructure configuration is not centralized.
• Some developers may be frustrated because of limited access to the infrastructure.

Final words

While these options are not mutually exclusive, and it may sound appealing to provide all of them for your developers to have the best experience, you should keep in mind that it takes effort to develop/deploy such tools, support and adopt them across the organisation.

At CECG we are trying to bring more value with less effort and always think about the developers' experience. Here are a few examples of what we did at CECG:

• Open-sourced Osprey : a CLI tool for providing OIDC access to Kubernetes clusters. It abstracts a roundtrip starting from authenticating at the OIDC provider to acquiring a token and updating a local configuration for kubectl making authentication in Kubernetes simple.
• Crossplanes XRDs for defining high-level components for describing working namespace in Kubernetes and cloud provider, infrastructure components and partial organisation structure.
• Right now we are working on a CLI for our own IDP to provide a simple and intuitive interface for developers, who use it daily.