Cost Optimization in Cloud Foundry Through Economies of Scale
summary
Migration to larger Diego VMs (migrated Diego VMs to 128 then 256 GB) plus a controlled memory overcommit raises real memory utilization on cells, reducing VM count; raising the container limit from 250 to 350 by switching IP prefix to /23, making max-containers configurable and bumping tmpfs to 50 MB enables denser packing; BBS changes—parallel stop requests, rep sync interval from 30s to 70s, a routing-info endpoint that omits security groups, and increasing BBS timeout to 20s—remove the need for expensive network-optimized VMs and save seven-figure operational costs per year.
AI-written summary · about
chapters (9)
- 0:00Introduction to economies of scale
- 1:50Key concepts in economies of scale
- 2:33Migrating Diego CVMs to larger sizes
- 3:57Memory overcommit implementation
- 5:04Increasing containers per cell
- 6:50Optimizing BBS network traffic
- 8:13Reducing BBS sync load
- 9:16Adjusting BBS request timeouts
- 9:58Cost savings and summary
related talks
33mNot Only for Giants: The Minimal Reasonable Size of a Cloud Foundry Implementation
37mCloud Foundry Diego Overview
35mResource Management Ecosystem and Cloud Foundry - A Review of the State of the Art
29mCloud Foundry Growing Pains: Lessons Learned Keeping the Largest CF Environment Alive and Kicking
32mCloud Foundry Diego Update
29mLessons Learnt Operating Multiple Cloud Foundry on OpenStack Deployments
14mCut Costs, Not Performance: Implement Kubernetes Cost Optimization Strategies
41mA cloud cost savings spectacular
