Controlling and Monitoring Cloud Spend

Since your organization will be using your cloud account (AWS, GCP or Azure) for development environments, you will now incur costs for each dev environment you spin up. We find that these costs are minimal for the most part and that the investment pays for itself with increased productivity and a reduction in annoying work.

That said, there are ways to monitor and control the DevZero environments your team can create to keep costs aligned with your goals.

screenshot of the DevZero Policy Based Resource Management Dashboard

Our Policy Based Resource Management Dashboard gives admins of the DevZero account easy, yet granular parameters to control. This applies to all your virtual machines and kubernetes development environment deployments.

For VMS we've identified six areas that we consider key to managing cloud costs:

Retention Period

To prevent loss of work, we retain backup volumes. You can dial in this value to balance cost and the risk of losing work stored on those volumes.

Suspend After

We already have smart logic around stopping machines so that they aren't incurring costs while your engineers are sleeping, but we also give you control over this to further control costs if possible. Reducing the time will stop machines sooner after an inactivity period, but that trade-off could come at the cost of your developers waiting for machines to come back online.

Total VMs

Again, our systems are pretty smart about how many VMs to create, but if you notice a consistent surplus, it might be good to lower the limit of total VMs that can be generated. The risk here is running out of VMs and not having any available for a developer.

Pool Size

We get cloud development environments into your developers' hands quickly by having a pool of prebuilt environments ready. While these prebuilt environments incur very low cost, we still offer the ability to dial this parameter in.

User Limit

Cap the total number of users to place a hard limit and prevent new users onboarding. This is a radical change, but may suit your organizations needs.

Compute Limit

The more vCPUs you use in an environment the more cost you will incur. If you want to be assured that no one specifies provisioning compute over a specific amount you can set this parameter as well. It's wise to allow some high compute for templates that may need that power to help speed up development. But if you know the upper bound of how much compute you'll ever need, it's good to have this set.

Projected Spend

As you adjust these parameters, we will use the API of your cloud provider to project costs based on what is changed. We rely on AWS, GCP and Azure for these projections.

Kubernetes

We offer similar capabilities for Kubernetes.

Policy Based Resource Management Dashboard for Kubernetes

Pods per Developer

Since your developers can deploy as many pods as they want to their namespace it may help cost control goals to set a hard upper limit on this.

Number of Namespaces

Adjusting this parameter will limit how many namespaces your organization can create in your cluster. Lowering the number too much could make your team less flexible, but setting a limit can ensure that the number of namespaces doesn't get out of control.

Number of Hosts

Similar to above, limiting this number could reduce flexibility if your team needs to expand the number of hosts you use, but obviously that could come with a high cost. Setting a hard limit though will ensure some certainty around costs.

Compute per Host

Just as with setting the compute allowed in a VM, our DevPods can also have variable compute. Optimize speed and cost by dialing this in to meet your team's needs.

Projected Spend

Just as with VMs, we'll use your cloud provider's API to calculate projected costs.