Services / FinOps
FinOpsWe design and operate a cloud-cost rhythm for your services
We design, deploy, and operate a cloud-cost rhythm for your services. We start from the bill and from the services: tags, owners, environments, and where idle sits. Then we stand up showback, rightsizing, and size in Terraform. We keep preview and runner on a TTL. Commitments come after measurement, on a quarterly review.
How it fits together
From tags to rightsizing, code, and commitments
First we understand the services and who owns the bill. On that basis we put together allocation, Kubernetes, Terraform, and pipeline hygiene. Grafana, tags, and a quarterly review are what we use for that work every day.
- For fintech, a saving stays inside control and SLO.
- Cloud commitments after several measurement cycles, after the first weeks of allocation.
We show the bill in product language
Allocation per service, team, environment. A dashboard for engineering and for finance. An anomaly of the day, in the same week as the spike. Without tags there is no owner, so label hygiene comes first.
Tags
Required on the account. Policy blocks a resource without an owner.
Showback
Cost per product. Chargeback when the organization is ready for it.
Anomaly
An alert on a spike. Idle disk, logs without retention, a dead load balancer.
Rhythm
A week of anomalies, a month of rightsizing, a quarter of commitments.
We size requests and the node group to traffic
Excess requests inflate the node pool. Missing limits hurt neighbors. We see idle, burstable, and spot where SLO allows. This is an engineering cost lever, next to the price list.
Rightsize
Pod CPU and RAM vs use. A recommendation from measurement.
Node
Instance type, autoscaler, spot for batch. Production has a separate policy.
Idle
A namespace after a project, a preview without TTL, a dead PVC.
SLO
A saving that breaks p95 comes back as incident cost. We keep the two next to each other.
We keep size and storage class in the module
The registry and your modules hold default instance types, storage lifecycle, backup. A size change goes through plan. Infracost or an equivalent view in the merge request, when the team is ready for it.
Defaults
The module stands up a size fitted to the workload, with a documented default.
Lifecycle
gp disk, archive, log retention. Policy in code.
Commitments
RI and Savings Plans after measurement. A documented horizon.
MR
Plan shows a resource delta. Change cost is part of the review.
We keep preview and runner off the invoice after the job
An environment from a merge request has a TTL. Artifacts and cache have retention. The runner autoscales. GitLab shows which project burns minutes. This is often the simplest lever, and we put it in the rhythm.
TTL
Preview dies after merge or after N days. An alert when it stays.
Artifacts
Images, job logs, cache. Retention and GC.
Minutes
CI showback per team. A shared runner has a cost, assigned to a project.
Production
The pipeline has no right to leave a test stack without a tag and an owner.
How we work
From the client services to a cost rhythm
We start from allocation. Then we close idle and rightsizing. We change storage class and node group from measurement. Commitments come on a quarterly review.
- Allocation We set tags, showback, anomaly, and owners. That gives who spends and on which service.
- Quick wins We close idle, retention, preview TTL, and obvious oversize.
- Architecture We change storage class, node group, and traffic model from measurement.
- Commitments We take RI, SP, or committed use after measurement, with a quarterly review.
Talk
We will discuss allocation, idle, and the cost rhythm
On that basis we will prepare a scope: tags, rightsizing, and commitments.
Contact us