Overview
FuncWarm explores a control plane that sends warmup requests to services running on Cloud Run. The goal is to understand request behavior in a controlled, limited experiment.
The problem
Serverless instance lifecycles can make request latency unpredictable. Warmup requests may help in a particular configuration, but do not guarantee that a platform will keep an instance alive.
The architecture
Illustrative system boundary. No proprietary infrastructure is represented.
Read the architecture as text
Separate the warmup controller from the target service so each can be observed independently. Observe individual HTTP attempts rather than infer a production latency guarantee from a small sample.
My contribution
Designed and implemented periodic request scheduling and monitoring for the prototype, as described in the supplied resume. The underlying source code has not been independently reviewed.
Decisions & trade-offs
- Separate the warmup controller from the target service so each can be observed independently.
- Observe individual HTTP attempts rather than infer a production latency guarantee from a small sample.
Periodic requests add cost and operational work. They also cannot override platform scheduling or replace appropriate minimum-instance settings. The observed latency alone does not isolate every source of cold-start behavior.
What the evidence says
- Successful attempts
- 20 / 20
- Mean request latency
- 103 ms
- Maximum observed
- 283 ms
In the supplied experiment: 20 of 20 attempts succeeded; mean observed request latency was 103 ms and the maximum was 283 ms. No cold attempts were observed. This small sample is not a production benchmark, SLA, or guarantee.
The takeaway
Keep the observation separate from the claim. A broader evaluation needs a reproducible workload, configuration details, a baseline, and longer observation windows.