Functions - Concepts
AutoscalingLink to this anchor
Autoscaling refers to the ability of Serverless Functions to automatically adjust the number of instances without manual intervention. Scaling mechanisms ensure that resources are provisioned dynamically to handle incoming requests efficiently while minimizing idle capacity and cost.
Autoscaling parameters are min-scale and max-scale. Available scaling policies are:
- Concurrent requests: requests incoming to the resource at the same time. Default value suitable for most use cases.
- CPU usage: to scale based on CPU percentage, suitable for intensive CPU workloads.
- RAM usage to scale based on RAM percentage, suitable for memory intensive workloads.
Build stepLink to this anchor
Before deploying Serverless Functions, they have to be built. This step occurs during deployment.
Once the Function is built into an image, it will be pushed to Container Registry
Cold StartLink to this anchor
Cold Start is the time a function takes to handle a request when it is called for the first time.
Startup process steps are:
- Downloading the container image (which contains the built Function) to our infrastructure
- Starting the container and the runtime
- Waiting for the container to be ready.
Container RegistryLink to this anchor
Container Registry is the place where your images of your Serverless Functions are stored before being deployed.
CRON triggerLink to this anchor
A CRON trigger is a mechanism used to automatically invoke a Serverless Function at a specific time on a recurring schedule. It works similarly to a traditional Linux cron job, using the * * * * * format, and uses the UTC time zone. Refer to our cron schedules reference for more information.
Custom domainLink to this anchor
By default, a generated endpoint is assigned to your Serverless resource. Custom domains allows you to use your own domain - see our custom domain documentation for full details.
EndpointLink to this anchor
An endpoint is the URL generated to access your resource. It can be customized with custom domains.
Environment variablesLink to this anchor
Environment variables are key/value pairs injected in your container. They are useful for sharing information such as configurations with your container. Some names are reserved. See details on reserved names.
GB-sLink to this anchor
Unit used to measure the resource consumption of a Serverless Function. It reflects the amount of memory consumed over time.
JWT TokenLink to this anchor
JWT (JSON Web Token) is an access token you can create from the console or API to enable an application to access your private container. Find out how to secure a Function.
HandlerLink to this anchor
A handler is a routine/function/method that processes specific events. Upon invoking your function, the handler is executed and returns an output. Refer to our dedicated documentation for more information on the structure of a handler.
InstanceLink to this anchor
A Serverless Function instance handles incoming requests based on factors like the request volume, min scale, and max scale parameters.
Load balancingLink to this anchor
The Serverless infrastructure manages incoming request traffic. In scenarios like sudden traffic spikes or load testing, resources are automatically scaled based on the max scale parameter to handle the load.
LoggingLink to this anchor
Serverless offers a built-in logging system based on Scaleway Cockpit to track the activity of your resources: see monitoring Serverless Functions.
Max scaleLink to this anchor
This parameter sets the maximum number of function instances. You should adjust it based on your function’s traffic spikes, keeping in mind that you may wish to limit the max scale to manage costs effectively.
MetricsLink to this anchor
Performance metrics for your Serverless resources are natively available: see monitoring Serverless Functions).
Min scaleLink to this anchor
Customizing the minimum scale for Serverless can help ensure that an instance remains pre-allocated and ready to handle requests, reducing delays associated with cold starts. However, this setting also impacts the costs of your Serverless Function.
NamespaceLink to this anchor
A namespace is a project that allows you to group your functions.
Functions in the same namespace can share environment variables and access tokens, defined at the namespace level.
NATS triggerLink to this anchor
A NATS trigger is a mechanism that connects a function to a NATS subject and invokes the function automatically whenever a message is published to the subject.
For each message that is sent to a NATS subject, the NATS trigger reads the message and invokes the associated function with the message as the input parameter. The function can then process the message and perform any required actions, such as updating a database or sending a notification.
Privacy policyLink to this anchor
A function’s privacy policy defines whether a function may be executed anonymously (public) or only via an authentication mechanism provided by the Scaleway API (private).
Private Networks compatibilityLink to this anchor
Refer to the dedicated FAQ for more information on Serverless Functions compatibility with Private Networks and Virtual Private Cloud (VPC).
Queue triggerLink to this anchor
A queue trigger is a mechanism that connects a function to a queue created with Scaleway Queues, and invokes the function automatically whenever a message is added to the queue.
For each message that is sent to a queue, the trigger reads the message and invokes the associated function with the message as the input parameter. The function can then process the message and perform any required actions, such as updating a database or sending a notification.
Request timeoutLink to this anchor
Request timeout is the maximum amount of time a request to a Serverless Function is allowed to run before the request is terminated. Purpose of this parameter is to ensure long-running requests do not hang indefinitely, which could impact ressource usage and scalability.
Use cases:
- Shorter timeouts: Ideal for use cases with quick, predictable response times, such as HTTP APIs or real-time applications.
- Longer timeouts: Useful for tasks requiring extended processing times, like data processing, report generation, or integration with slower external services.
Rolling updateLink to this anchor
When deploying a new version of a Serverless Function, a rolling update is applied by default. This means that the new version of the service is gradually rolled out to your users without downtime. Here is how it works:
- When a new version of your function is deployed, the platform automatically starts routing traffic to the new version incrementally, while still serving requests from the old version until the new one is fully deployed.
- Once the new version is successfully running, we gradually shift all traffic to it, ensuring zero downtime.
- The old version is decommissioned once the new version is fully serving traffic.
This process ensures a seamless update experience, minimizing user disruption during deployments. If needed, you can also manage traffic splitting between versions during the update process, allowing you to test new versions with a subset of traffic before fully migrating to them.
RuntimeLink to this anchor
The runtime is the execution environment of your function. Regarding Serverless Function, it consists of the languages in which your code is written.
SandboxLink to this anchor
A sandbox is an isolation area for your function. Serverless Functions offer two sandboxing environments:
- v2 - Recommended for faster cold starts.
- v1 - Legacy sandboxing with slower cold start, but fully supports Linux system call interface.
Scale to zeroLink to this anchor
One of the advantages of Serverless Functions is that when your function is not triggered, it does not consume any resources, which allows for significant savings.
SecretsLink to this anchor
Secrets are an extra-secure type of environment variable. They are environment variables that are injected into your function and stored securely, but not displayed in the console after initial validation.
ServerlessLink to this anchor
Serverless allows you to deploy your Functions (FaaS) and Containerized Applications (CaaS) in a managed infrastructure. Scaleway ensures the deployment, availability, and scalability of all your projects.
Serverless FrameworkLink to this anchor
Serverless.com (Serverless Framework) is a tool that enables the deployment of serverless applications without having to manage Serverless Function’s API call. Just write your configuration in a YAML and deploy, it handles everything.
Serverless ContainersLink to this anchor
Serverless Containers is a fully managed service that enables you to run containerized applications in a scalable and serverless environment.
It automatically handles infrastructure management, scaling, and load balancing, allowing you to focus on writing code without worrying about servers or clusters. Serverless Containers supports any language, framework, or binary that can run in a container, and it integrates seamlessly with other Scaleway services, making it ideal for deploying modern, event-driven, and API-based applications.
Serverless FunctionsLink to this anchor
Serverless Functions are fully managed compute services that allow you to run small, stateless code snippets or functions in response to HTTP requests or events.
These functions automatically scale based on demand and are designed to be lightweight, event-driven, and easily deployable, eliminating the need to worry about infrastructure management. Functions is built on top of Serverless Containers, meaning you can run your functions packaged in containers and have them scale efficiently.
Serverless JobsLink to this anchor
Serverless Jobs are similar to Serverless Containers but are better suited for running longer workloads. See the comparison between Serverless products for more information.
StatelessLink to this anchor
Refers to a system or application that does not maintain any persistent state between executions. In a stateless environment, each request or operation is independent, and no information is retained from previous interactions.
This means that each request is treated as a new and isolated event, and there is no need for the system to remember previous states or data once a task is completed. Statelessness is commonly used in serverless architectures where each function execution is independent of others.
To store data you can use Scaleway Object Storage, Scaleway Managed Databases, and Scaleway Serverless Databases.
StatusLink to this anchor
A Serverless Function can have the following statuses:
- Ready: your Serverless Function is operational to serve requests.
- Pending: your resource is under deployment.
- Error: something went wrong during the deployment process or build of the source code to image. Check our troubleshooting documentation to solve the issue.
TriggerLink to this anchor
In a serverless architecture, a function is not running constantly, but is rather triggered by an event.
A trigger is a mechanism that connects the function to an event source and enables the function to execute automatically in response to specific events.
Triggers can take many forms, such as HTTP requests, messages from a queue or a stream, CRON schedules, etc.
vCPU-sLink to this anchor
Unit used to measure the resource consumption of a container. It reflects the amount of vCPU used over time.