Four Ways to Set Up Developer Self-service in Your Internal Developer Portal

Introduction

‍

Developer self-service actions are what internal developer portals are made for. Through the developer portal, developers can access a product-like user interface that lets them consume software and infrastructure with guardrails and abstractions in place. There is no need for developers to send tickets or deal with complex operations setups.

‍

With Port, developers can provision, terminate and perform day-2 operations on any asset exposed in port’s software catalog. They can provision a development env, request permission for a S3 bucket for limited time or add a secret to a microservice. 

‍

 In general, Port supports three broad types of developer self-service actions:

• Create - by triggering a provisioning process in your infrastructure, creating a new software catalog entity
• Day two operations - updating or modifying an existing software catalog entity
• Delete - triggering delete logic 

‍

How are self-service actions set up?

‍

At the core of Port is the loose coupling of the internal developer portal to the underlying infrastructure. Our belief is that platform engineering is about the creation of reusable elements that enable self-service, and those elements are created with existing tools - from Terraform, through Jenkins, GitHub Workflows and more. The platform team should have the freedom to change platform tooling and configuration, without creating developer confusion, cognitive load or dealing with a need to drive adoption of new tools. As a result, developer self-service actions are set up in the developer portal with a user interface. Once a developer executes an action in the portal, it can be enabled in 4 ways.

‍

4 ways to enable developer self-service actions

‍

Developer self-service actions are defined in the blueprints within the portal. Blueprints are the basic building block in Port and cover all entity types. For instance, in a cloud resource blueprint we can define a self-service action to allow the creation or deletion of such a cloud resource.

‍

When we execute a self-service action, we have 4 options:

‍

1. Webhook: Port triggers webhooks based on a customer provided URL.

‍

In this case, an example flow can be: 

‍

1. A developer self-service action is made: create an ephemeral dev environment with a TTL of 5 days
2. The create action is sent to the defined URL;
3. For example, An AWS Lambda function is triggered;
4. The Lambda function deploys a new ephemeral dev environment;
5. When the Lambda is done, it reports back to Port (by sending a REST API request) and the new environment is reflected in the software catalog. The developer gets a message about the success of the action. 
6. Once the TTL is over, workflow automations remove the ephemeral environment.

‍

You can read more about self-service actions with webhooks here.

‍

2. Kafka self-service actions

Port manages a secure Kafka Topic per customer that publishes the execution run requests. This means that Port doesn’t store any environment credentials and there is no need to open a connection for Port.

‍

You can listen to a Kafka Topic with any code platform you wish to use, and also use it as a trigger for example a serverless function. For example, AWS Lambda. See here.

‍

‍

In this case, an example flow would be:

‍

1. A developer asks to deploy a new developer environment with a TTL of 5 days;
2. The create action is sent to the Kafka topic; 
3. For example, an AWS Lambda function is triggered by this new action message; 
4. The Lambda function deploys a new developer environment;
5. When the Lambda is done, it reports back to Port.
6. When the Lambda is done, it reports back to Port (by sending a REST API request) and the new developer environment is reflected in the software catalog. The developer gets a message about the success of the action. 
7. Once the TTL is over, workflow automations remove the ephemeral environment.

‍

3. Webhook with Port Execution Agent

This option exists as a secure and convenient way to listen and act when Self-Service actions are invoked or in case of changes to the software catalog. In this case the invocation agent pulls the new invocation event from a secure and dedicated Kafka topic. Just as before, this means that no credentials are stored and no connection needs to be open for Port.

‍

‍

4. Github workflow: GitHub Workflow Self-Service Actions

Port’s GitHub application can trigger a GitHub workflow to invoke the required self-service action.

‍

‍

In this case, an example flow can be:

‍

1. A developer asks to deploy a new version of an existing microservice;
2. A message with the developer inputs is sent to the dedicated Kafka topic
3. Port's GitHub application event handler is triggered by this new action message;
4. Port's GitHub application triggers the GitHub workflow that deploys a new version of the service;
5. As part of the workflow, the new microservice Deployment is reported back to Port;
6. When the workflow is done, Port's GitHub application reports back to Port about the status of the action run, according to workflow's conclusion.

‍

Combine GitOps Operations with Port’s self-service cations

In this case, it is possible to have developers execute self-service actions which are then performed with GitOps. The flow works like this:

‍

‍

1. Users make a self-service action which is then stored in a Kafka queue. 
2. Port’s Github app listens to the form submissions and handles Terraform file generation.
3. When the Terraform file is ready it will be committed, resulting in a pull request. 
4. When the pull request is merged, the GitOps workflow triggers the CI that drives Terraform apply. This also ensures that the software catalog is updated with the specific IaC action (here’s a link to the Terraform provider), either apply or destroy. 

‍

The above can also be done with Pulumi and GitLab CI, for example.

‍

{{cta_8}}

‍

Conclusion

The point of Internal Developer Portals is that they are loosely coupled with the underlying platform and that they are both flexible yet allow for an accurate reflection of all things software and infrastructure in the software catalog. To support this loose coupling, Port supports many variations of implementing developer self service actions, including allowing for self-service RBAC, TTL and manual approvals.  We’re working on the ability to trigger more pipelines directly, such as Jenkins and GitLab CI. Would you like to add integrations to Port? Send us a message at info@getport.io