Show HN: Fair CPU scheduling to run unlimited apps on one plan | Hacker News Reader

Show HN: Fair CPU scheduling to run unlimited apps on one plan

miget.com

1 pointktaraszk3 comments

Most cloud PaaS cost isn’t the CPU you actually use - it’s the CPU you reserve and then sits idle 90% of the time.

Traditional platforms still charge per app, even if each app barely touches the CPU.

We redesigned scheduling: CPU is dynamically shared across your workloads based on real demand. You pay once for the resource, rather than multiple times for idle capacity.

I'm happy to discuss technical details, scheduler design, and the challenges we encountered along the way.

Open articleView on HN

A quick example of why this matters for devs & startups: imagine you’ve got 5 small apps each using 0.3 CPU most of the time. In most PaaS you’d pay for 5 separate instances. On Miget you pay for one resource plan and those apps share the CPU dynamically - result: ~75% cost reduction.

If you’re curious about how this stacks up against platforms like Heroku, Render or Railway, I can post a cost-comparison table.

A couple of questions I expect here (based on similar discussions in other channels):

1) What about memory - is it shared too? CPU is shared dynamically. Memory is still hard allocated as a guaranteed limit per workload. This was intentional because, unlike CPUs, memory oversubscription risk is significantly harder to mitigate safely at PaaS scale without introducing latency unpredictability and OOM risk. So: CPU = elastic, RAM = guaranteed / stable.

2) Is isolation compromised by this approach? No - apps don’t run on the same container host. Every app runs on its own Kubernetes node (physical or VM). The Fair Scheduler coordinates CPU fairness across nodes under a single user resource plan. This eliminates noisy neighbors and preserves app-level blast radius reduction.

Here’s a bit more detail on how the scheduler works under the hood: 1. Each application still runs on its own Kubernetes node to guarantee isolation (so noisy-neighbor issues are eliminated).

2. We track CPU usage in real-time across all workloads and maintain a global usage map.

3. Idle CPU from any app/node becomes available for re-purchase by other workloads in the same resource plan.

4. CPU limits can be adjusted on the fly without restarts, enabling real-time response to changing load.

If anyone wants to dive into topics like threshold algorithms, node assignment heuristics, or Kubernetes API interactions - I'm happy to dig into that.

Reply on news.ycombinator.com