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.

‍

Temporary Permissions

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.