feat(compute): add Functions serverless enhancement

[scotwells]

Summary

This enhancement introduces Functions, a serverless compute capability that makes it easy for developers to deploy code without managing infrastructure.

Note

I'd recommend reading the rendered view of the markdown document.

What developers get

• Deploy in seconds: Push a container image and your function is live—no network config, instance sizing, or placement decisions
• Pay only for what you use: Functions scale to zero when idle and spin up instantly when traffic arrives
• Fast response times: Sub-50ms cold starts mean users don't wait for your function to wake up
• Use your favorite language: Go, Node.js, Python, and Rust supported out of the box

Common use cases

• API endpoints and webhooks
• Request interception (auth, header modification, URL rewriting)
• Server-side rendering at the edge

Architecture highlights

Functions builds on the existing Workload primitive, so it inherits all the platform's battle-tested compute infrastructure. Private connectivity via Service Connect means traffic between your apps and functions never touches the public internet.

What's included

• Enhancement README with motivation, goals, and design rationale
• Three C4 architecture diagrams showing system context, control plane, and connectivity
• Shared diagram theme for consistent styling

[scotwells]

Refined the Functions enhancement to make it clearer and more complete:

• Architecture diagrams now show how Functions connects to other platform services (Registry, Build, Gateway)
• Developer Experience section added, outlining how developers will deploy and manage functions through Git workflows, the Portal, and CLI
• Future Work section consolidates the roadmap—cron triggers, region selection, canary deploys, and more

[mksinghtx]

Great! From a use-case perspective I have seen functions used for service monitoring, synthetic probes as well.
I imagine we will use them for agent execution as well.
Also do we envision providing protection against unbounded resource usage ?
IS VPC the only level of access control for resource access - what other entities can this function talk to ? Is there finer grain control envisioned for that within a VPC - eg security groups?
I see that access control is planned for future development but for public endpoints access in the first stage what is the access control ? Is user delegation the only envisioned model for building authorization? In that case Can functions register dynamically or use Client-id metadata for authN or authZ or do we have autonomous identities (for agents)?
Capping resource usage - Give users ability to cap usage by function

[scotwells]

@mksinghtx thanks for the feedback! Answers quoted below.

From a use-case perspective I have seen functions used for service monitoring, synthetic probes as well.

Good point. I believe those use-cases would fall under the future work with cron / event based triggers. The current scope is HTTP-only.

Also do we envision providing protection against unbounded resource usage ?

By this, do you mean controlling number of replicas / CPU / Memory usage?

IS VPC the only level of access control for resource access - what other entities can this function talk to ? Is there finer grain control envisioned for that within a VPC - eg security groups?

I'd expect network policies within a VPC to also apply to service connections so you can control what's allowed to access the function. Since the function is actually deployed on infrastructure with the service's control plane in a separate VPC, it won't have any connectivity to the consumer's control plane. I expect our service connect capability would have some method of exposing a consumer's service to the function.

I see that access control is planned for future development but for public endpoints access in the first stage what is the access control ? Is user delegation the only envisioned model for building authorization? In that case Can functions register dynamically or use Client-id metadata for authN or authZ or do we have autonomous identities (for agents)?

Functions will not be routable publicly. Users can reference a function as a route on a Gateway to expose the function to the internet. You'd be able to use all of the existing security features of our gateway to gate access to this route (Basic Auth, OIDC, IP Allow / Deny lists, etc).

[scotwells]

I'm also thinking that we reduce the scope of this to only support Javascript / Python for the MVP.

Golang / Rust will require the platform to compile code into executables before running. That's a more complex pipeline with more things that can go wrong, more error messages to surface clearly, and more edge cases to handle.

[mksinghtx]

@mksinghtx thanks for the feedback! Answers quoted below.

From a use-case perspective I have seen functions used for service monitoring, synthetic probes as well.

Good point. I believe those use-cases would fall under the future work with cron / event based triggers. The current scope is HTTP-only.

Also do we envision providing protection against unbounded resource usage ?

By this, do you mean controlling number of replicas / CPU / Memory usage?

yes, And network resources

IS VPC the only level of access control for resource access - what other entities can this function talk to ? Is there finer grain control envisioned for that within a VPC - eg security groups?

I'd expect network policies within a VPC to also apply to service connections so you can control what's allowed to access the function. Since the function is actually deployed on infrastructure with the service's control plane in a separate VPC, it won't have any connectivity to the consumer's control plane. I expect our service connect capability would have some method of exposing a consumer's service to the function.

By finer-granularity I meant security policy(AWS terminology) rather than network policies. On Service connect it can be modeled like private link with a endpoint service and endpoint(AWS terminology).

I see that access control is planned for future development but for public endpoints access in the first stage what is the access control ? Is user delegation the only envisioned model for building authorization? In that case Can functions register dynamically or use Client-id metadata for authN or authZ or do we have autonomous identities (for agents)?

Functions will not be routable publicly. Users can reference a function as a route on a Gateway to expose the function to the internet. You'd be able to use all of the existing security features of our gateway to gate access to this route (Basic Auth, OIDC, IP Allow / Deny lists, etc).

So ok assume that only references will be allowed. In that case I was thinking more like whether in addition to users who can reference functions - if applications then will user delegation for an app be allowed and then in that case will app registration be static - with a secret or more like Client metadata based registration or DCR. The more interesting case is where an autonomous agent references this route where static registration does not really work! More an auth question I guess as we build those enhancements

[scotwells]

Also do we envision providing protection against unbounded resource usage ?

By this, do you mean controlling number of replicas / CPU / Memory usage?

yes, And network resources

Internally we'd set resource caps on CPU / Memory / Network that can be consumed per function. I don't think we'd give users too much control over this with functions because the idea with functions is providing an abstracted infrastructure interface. Users who need more control over CPU / Memory / Network would just create workloads directly with their resource requirements.

IS VPC the only level of access control for resource access - what other entities can this function talk to ? Is there finer grain control envisioned for that within a VPC - eg security groups?

I'd expect network policies within a VPC to also apply to service connections so you can control what's allowed to access the function. Since the function is actually deployed on infrastructure with the service's control plane in a separate VPC, it won't have any connectivity to the consumer's control plane. I expect our service connect capability would have some method of exposing a consumer's service to the function.

By finer-granularity I meant security policy(AWS terminology) rather than network policies. On Service connect it can be modeled like private link with an endpoint service and endpoint(AWS terminology).

Service connect will be similar to AWS Private Link, GCP's Private Service Connect, and Azure's Private Link concepts. Our network policies will have similar behavior to security groups where you can configure tag-based / identity rules rather than just IP-based.

I see that access control is planned for future development but for public endpoints access in the first stage what is the access control ? Is user delegation the only envisioned model for building authorization? In that case Can functions register dynamically or use Client-id metadata for authN or authZ or do we have autonomous identities (for agents)?

Functions will not be routable publicly. Users can reference a function as a route on a Gateway to expose the function to the internet. You'd be able to use all of the existing security features of our gateway to gate access to this route (Basic Auth, OIDC, IP Allow / Deny lists, etc).

So ok assume that only references will be allowed. In that case I was thinking more like whether in addition to users who can reference functions - if applications then will user delegation for an app be allowed and then in that case will app registration be static - with a secret or more like Client metadata based registration or DCR. The more interesting case is where an autonomous agent references this route where static registration does not really work! More an auth question I guess as we build those enhancements

This is a great forward-looking question. The current scope assumes Gateway handles auth for public access, but you're right that static secrets don't fit well for dynamic agents or app-to-function calls. This feels like it belongs in the Auth/IAM enhancement space—things like workload identity, dynamic client registration, or token exchange for service-to-service auth. I'll flag this as a dependency to consider as those capabilities develop.

[jacobsmith928]

LGTM, thanks for your deep dive on this @scotwells

[jacobsmith928]

I meant to approve on my last review

[drewr]

Thanks for this @scotwells. I didn't see anything that stood out to me as a concern at this stage. I like the control plane separation. Looking forward to diving more into how auth will work.

[scotwells]

@drewr @jacobsmith928 did you see my comment on reducing initial scope to just JavaScript / python? Looking to get feedback there.

[jacobsmith928]

@scotwells yes that seems like a good place to start vis a vis:
https://developers.cloudflare.com/workers/languages/

[drewr]

just JavaScript / python

I saw it. Hard to judge yet without seeing the effort required to add support per language.

I am curious how Rust or Go complicates things. I know they're compiled but all languages will require some kind of build, whether that's cargo build, go build, npm install, or pip install. It feels like an image pops out the other end regardless.

Languages aside, I'm envisioning something like how a GitHub Action creates a GitHub Pages deployment (something we'd love to have for datum-cloud/cloudvalid.com#9, eg). Deploying a static site should be easy with this. We may want to specify it in the user stories?

[scotwells]

Hard to judge yet without seeing the effort required to add support per language.

I am curious how Rust or Go complicates things. I know they're compiled but all languages will require some kind of build, whether that's cargo build, go build, npm install, or pip install. It feels like an image pops out the other end regardless.

The biggest friction point is it requires you to compile an image and push it to a registry. Since Javascript / Python are interpreted languages you can just load the files into the runtime and execute the script.

For an MVP, I'd target commonly used dependencies be automatically included in the JS / Python runtime to make it possible for people to easily manage functions via the UI. If they want custom dependencies for more advanced use-cases, I think that's a secondary phase where we have a build process.

Mainly trying to avoid having to create a build a pipeline for the first phase.

Languages aside, I'm envisioning something like how a GitHub Action creates a GitHub Pages deployment (something we'd love to have for datum-cloud/cloudvalid.com#9, eg). Deploying a static site should be easy with this. We may want to specify it in the user stories?

This seems like something separate than functions to me. I'd dump the rendered HTML / CSS / JS assets into an S3 bucket and use it as the origin.