Announcing Port Timer: TTL for ephemeral cloud environments, permissions and more
Some things need to self-destroy and not live forever, but they stay alive
People always fret about orphaned cloud resources, developer environments, and other on demand resources that are reported to live forever in the shadows, making cloud costs uncontrollable and environments messy. And don’t forget temporary permissions that stay on forever.
A common practice among engineering organizations is to resolve this issue through a dedicated database that stores the timestamp of the resource, which is then followed by an automatic cleanup script. Other engineering organizations use on-call for clean-up once a week: in that case, temporary resources or permissions are deleted with a shaking hand, risking the ire of the developer that still needed them.
Developers need to provision short-lived cloud environments/resources, on-demand. They need temporary permissions too. All this needs to happen without expending too much energy, rummaging around in cloud management tools etc. It’s also important to keep developer experience in mind: developers need easy access to be able to consume devops resources, and devops also need to be able to work seamlessly with permissions.
We believe that developer self-service actions are of key importance in the software catalog, not less important than the software catalog and the developer and devops KPIs. And a key part of developer self-service is having a built in timer that allows for TTL. This is a classic example of creating guardrails for developers and easier lives for devops.
TTL for ephemeral cloud environments
In this case, we require developers to choose a TTL when performing a self-service action to spin-up an ephemeral environment. If they want more time than was pre-set in the self-service interface of the developer portal they can request manual approval. This means that the developer will find it easy to spin-up an ephemeral cloud env, update and use it, and then have it self-destruct when the time is up.
When developers ask for permissions to cloud resources, production environments and any other type of resource, a time limit needs to be set, after which permissions revert back. This is important for many compliance and security reasons, as well as general good order. Similarly, in the developer self-service action UI, this can be pre-defined and manual approvals required for longer time permissions.
Port’s Timer Feature
This is exactly what the Port Timer feature does. It allows the provisioning of a temporary anything through developer self-service actions:
- Temporary integration environments
- Temporary cloud or environment permissions
- Temporary cloud resources and more
Once the time is up, there is an automatic shut-down. In case the developer needs more time, a manual approval process can be set up, requiring devops approval.
Practically speaking, the Timer feature is defined in Port Blueprints. A Blueprint is the basic building block in Port. It represents assets that can be managed in Port, such as Microservice, Environments, Packages, Clusters, Databases, and many more. Blueprints are completely customizable and can support Timers.
Timer properties allow you to define expiration date & time that can trigger internal workflows, such as triggering a workflow that destroys an ephemeral on-demand environment when the time comes.
With TTL, you can kick back and relax while developers roam freely.
To see Port for yourself, request a demo.
Book a demo right now to check out Port's developer portal yourself
It's a Trap - Jenkins as Self service UI
How do GitOps affect developer experience?
It's a Trap - Jenkins as Self service UI. Click her to download the eBook
Learning from CyberArk - building an internal developer platform in-house
Example JSON block
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Scaffold a new microservice
Deploy (canary or blue-green)
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Add / Remove / Update Column to table
Run Airflow DAG
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
A/B testing traffic route
Spin up remote Jupyter notebook
Containers & Serverless
Software and more