-
Notifications
You must be signed in to change notification settings - Fork 305
docs: Serverless Workers - Encyclopedia (4/4) #4415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: feat/serverless-worker-prerelease
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,77 @@ | ||
| --- | ||
| id: serverless-workers | ||
| title: Serverless Workers | ||
| sidebar_label: Serverless Workers | ||
| description: Learn how Serverless Workers work, how Temporal invokes them, and how they differ from traditional long-lived Workers. | ||
| slug: /serverless-workers | ||
| toc_max_heading_level: 4 | ||
| keywords: | ||
| - serverless | ||
| - workers | ||
| - lambda | ||
| - compute provider | ||
| tags: | ||
| - Workers | ||
| - Concepts | ||
| - Serverless | ||
| --- | ||
|
|
||
| This page covers the following: | ||
|
|
||
| - [What is a Serverless Worker?](#serverless-worker) | ||
| - [How Serverless invocation works](#how-invocation-works) | ||
| - [Compute providers](#compute-providers) | ||
|
|
||
| ## What is a Serverless Worker? {#serverless-worker} | ||
|
|
||
| A Serverless Worker is a Temporal Worker that runs on serverless compute instead of a long-lived process. | ||
| There is no always-on infrastructure to provision or scale. | ||
| Temporal invokes the Worker when Tasks arrive on a Task Queue, and the Worker shuts down when the work is done. | ||
|
|
||
| A Serverless Worker uses the same Temporal SDKs as a traditional Worker. | ||
| It registers Workflows and Activities the same way. | ||
| The difference is in the lifecycle: instead of the Worker starting and polling continuously, Temporal triggers the compute environment, the Worker starts, processes available Tasks, and then exits. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same comment as other PR: "triggers the compute environment" >> "triggers the serverless worker" |
||
|
|
||
| Serverless Workers require [Worker Versioning](/worker-versioning). | ||
| Each Serverless Worker must be associated with a [Worker Deployment Version](/worker-versioning#deployment-versions) that has a compute provider configured. | ||
|
|
||
| To deploy a Serverless Worker, see [Deploy a Serverless Worker](/production-deployment/worker-deployments/serverless-workers). | ||
|
|
||
| ## How Serverless invocation works {#how-invocation-works} | ||
|
|
||
| With traditional Workers, you start the Worker process, which connects to Temporal and polls a Task Queue for work. | ||
| Temporal does not need to know anything about the Worker's infrastructure. | ||
|
|
||
| With Serverless Workers, Temporal starts the Worker. | ||
|
|
||
|  | ||
|
|
||
| The invocation flow works as follows: | ||
|
|
||
| 1. A Task arrives on a Task Queue that has a compute provider configured. | ||
| 2. Temporal's internal Worker Controller Instance (WCI) service detects that no Worker is polling the Task Queue. | ||
| 3. Temporal uses the compute provider configuration to invoke the serverless function. For example, calling AWS Lambda's `InvokeFunction` API. | ||
| 4. The serverless function starts, creates a Temporal Client, and begins polling the Task Queue. | ||
| 5. The Worker processes available Tasks until the compute environment's deadline approaches. | ||
| 6. The Worker gracefully drains in-progress work and shuts down. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "shuts down": We use "exits" in prior text. I like "shutdown" / "shuts down" because Durable Lambda Function use this terminology so it might be easier for folks to comprehend: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html |
||
|
|
||
| Each invocation is independent. | ||
| The Worker creates a fresh client connection on every invocation. | ||
| There is no connection reuse or shared state across invocations. | ||
|
|
||
| ## Compute providers {#compute-providers} | ||
|
|
||
| A compute provider is the configuration that tells Temporal how to invoke a Serverless Worker. | ||
| The compute provider is set on a [Worker Deployment Version](/worker-versioning#deployment-versions) and specifies the provider type, the invocation target, and the credentials Temporal needs to trigger the invocation. | ||
|
|
||
| For example, an AWS Lambda compute provider includes the Lambda function ARN and the IAM role that Temporal assumes to invoke the function. | ||
|
|
||
| Compute providers are only needed for Serverless Workers. | ||
| Traditional long-lived Workers do not require a compute provider because the Worker process manages its own lifecycle. | ||
|
|
||
| ### Supported providers | ||
|
|
||
| | Provider | Description | | ||
| |---|---| | ||
| | AWS Lambda | Temporal assumes an IAM role in your AWS account to invoke a Lambda function. | | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -41,7 +41,7 @@ A Worker Program is the static code that defines the constraints of the Worker P | |
| - [How to run a development Worker using the TypeScript SDK](/develop/typescript/workers/run-worker-process#run-a-dev-worker) | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The worker page is going to need a rewrite. With serverless workers, I think we need to update how users should think of this abstraction that we never quite defined well in the docs. Would love some product/engineering input on this question.
We don't answer this question at all right now, and deflect to lower-level abstractions, which isn't very helpful and does not account for serverless workers:
Maybe something like:
|
||
| - [How to run a development Worker using the .NET SDK](/develop/dotnet/workers/run-worker-process) | ||
|
|
||
| - [How to run a Temporal Cloud Worker using the Go SDK](/develop/go/workers/cloud-worker) | ||
| - [How to connect a Go SDK Worker to Temporal Cloud](/develop/go/workers/run-worker-process#connect-to-temporal-cloud) | ||
| - [How to run a Temporal Cloud Worker using the TypeScript SDK](/develop/typescript/workers/run-worker-process#run-a-temporal-cloud-worker) | ||
|
|
||
| ::: | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been using "traditional worker" to refer to long-lived workers when comparing them against serverless. Do we have a preferred name for our normal workers? Standard worker? Long-lived worker? Hosted worker (not great sounds like we host them)? Always-on worker? Or are we happy with traditional
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Long-lived worker is a good name that we also use internally. I am not opposed to a 3-word compound: "traditional Long-lived Worker"