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:
- A developer self-service action is made: create an ephemeral dev environment with a TTL of 5 days
- The create action is sent to the defined URL;
- For example, An AWS Lambda function is triggered;
- The Lambda function deploys a new ephemeral dev environment;
- 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.
- 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:
- A developer asks to deploy a new developer environment with a TTL of 5 days;
- The create action is sent to the Kafka topic;
- For example, an AWS Lambda function is triggered by this new action message;
- The Lambda function deploys a new developer environment;
- When the Lambda is done, it reports back to Port.
- 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.
- 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:
- A developer asks to deploy a new version of an existing microservice;
- A message with the developer inputs is sent to the dedicated Kafka topic
- Port's GitHub application event handler is triggered by this new action message;
- Port's GitHub application triggers the GitHub workflow that deploys a new version of the service;
- As part of the workflow, the new microservice Deployment is reported back to Port;
- 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:
- Users make a self-service action which is then stored in a Kafka queue.
- Port’s Github app listens to the form submissions and handles Terraform file generation.
- When the Terraform file is ready it will be committed, resulting in a pull request.
- 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
Check out Port's pre-populated demo and see what it's all about.
No email required
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Check out Port's pre-populated demo and see what it's all about.
(no email required)
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Book a demo right now to check out Port's developer portal yourself
Apply to join the Beta for Port's new Backstage plugin
It's a Trap - Jenkins as Self service UI
Further reading:
Example JSON block
Order Domain
Cart System
Products System
Cart Resource
Cart API
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Component Blueprint
Resource Blueprint
API Blueprint
Domain Blueprint
System Blueprint
Microservices SDLC
Scaffold a new microservice
Deploy (canary or blue-green)
Feature flagging
Revert
Lock deployments
Add Secret
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Development environments
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Cloud resources
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
SRE actions
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Data Engineering
Add / Remove / Update Column to table
Run Airflow DAG
Duplicate table
Backoffice
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
Train model
Pre-process dataset
Deploy
A/B testing traffic route
Revert
Spin up remote Jupyter notebook
Engineering tools
Observability
Tasks management
CI/CD
On-Call management
Troubleshooting tools
DevSecOps
Runbooks
Infrastructure
Cloud Resources
K8S
Containers & Serverless
IaC
Databases
Environments
Regions
Software and more
Microservices
Docker Images
Docs
APIs
3rd parties
Runbooks
Cron jobs