FaaS: event-driven functions, governed like everything else
Run functions triggered by HTTP requests, queues, schedules and platform events on your own infrastructure, with the observability and security you already apply to services.
What is FaaS?
DevOpsArk FaaS is the functions-as-a-service module that runs short-lived, event-driven code on your infrastructure in response to HTTP requests, queue messages, schedules and platform events.
What FaaS is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- Small pieces of automation end up as cron jobs on a server nobody maintains.
- Vendor function platforms are convenient until the code has to run in a specific network or region.
- Functions escape governance: no scanning, no cost attribution, no ownership.
- Debugging a function means reading provider logs in a separate console.
- A function that fails silently is discovered weeks later.
FaaS packages a function into a container automatically and runs it on managed capacity in your own environment, so network placement and data residency stay within your control. Triggers include HTTP endpoints, queue and topic messages, schedules, and DevOpsArk platform events, which lets a function respond to a deployment, an alert or a policy violation without extra wiring. Because functions are containers underneath, the ordinary platform machinery applies: image scanning, secret injection, log and metric collection, cost attribution and ownership. Failed invocations are retried according to policy and then sent to a dead-letter destination, and a rising failure rate raises an alert like any other signal rather than staying invisible.
What FaaS does
The 6 capabilities that make up FaaS.
Multiple trigger types
HTTP, queue and topic messages, schedules, and DevOpsArk platform events such as deployments and alerts.
Automatic packaging
Source is packaged into a container by ArkBuilder, so a function is governed like any other image.
Runs in your environment
Functions execute on your infrastructure, so network placement and data residency remain yours.
Retries and dead-lettering
Failed invocations retry to policy and then land in a dead-letter destination rather than disappearing.
Invocation observability
Duration, cold start, error rate and per-invocation logs collected into the same plane as everything else.
Cost attribution
Execution cost attributed to the function and its owning team rather than absorbed into a shared total.
How FaaS fits together
Outcomes
- Small automation gets a managed home instead of a forgotten cron job.
- Functions stay inside your network and residency boundaries.
- Function failures are alerted rather than silent.
- Functions carry the same scanning, ownership and cost visibility as services.
- Reacting to a platform event needs no bespoke integration.
Using FaaS, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Write the function
Provide source in a supported runtime, or a container image.
- 2Choose triggers
HTTP, queue, schedule or platform event.
- 3Package and scan
ArkBuilder produces the image and it is scanned like any other.
- 4Deploy and scale
Concurrency scales with load, within the limits you set.
- 5Observe
Duration, errors, cold starts and logs appear in the platform.
Where teams apply FaaS
React to platform events
Run a function when a deployment completes, an alert fires or a policy violation is detected.
Handle a webhook
Expose an HTTP-triggered function without provisioning a service and an ingress by hand.
Process queue messages
Scale consumers with queue depth and dead-letter what cannot be processed.
Replace cron jobs on a snowflake host
Move scheduled scripts onto managed capacity with logs, alerts and ownership.
What FaaS works with
Named integrations link to their own page. The rest are supported runtimes and formats.
FaaS: frequently asked questions
The 6 questions teams ask most often before adopting FaaS.
Functions as a service is a model where you deploy individual functions rather than long-running services, and the platform runs them in response to events, scaling from zero and charging for execution rather than for reserved capacity.
It runs on your own infrastructure, so network placement and data residency stay under your control, and functions are governed by the same scanning, secrets, observability and cost attribution as the rest of your estate.
HTTP requests, queue and topic messages, schedules, and DevOpsArk platform events such as a completed deployment, a fired alert or a detected policy violation.
It is retried according to the policy you set, and if it continues to fail the invocation is sent to a dead-letter destination. A rising failure rate raises an alert rather than remaining invisible.
Node.js, Python and Go are packaged directly from source; any other runtime can be supplied as a container image.
Cold start duration is measured and reported per function. Minimum warm instances can be configured for latency-sensitive functions, trading a small standing cost for predictable response time.
See FaaS against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.