Autoscaling refers to the ability of Serverless Containers 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.
Cold start is the time a Container takes to handle a request when it is called for the first time.
The startup process steps are:
Downloading the container image to our infrastructure
Starting the container. Optimize your container startup speed to minimize this step (e.g., avoid waiting for slow connections or downloading large objects at startup)
Waiting for the container to listen on the configured port.
Serverless Containers allows you to customize the command and args instructions of your container image directly from the Scaleway console and from the Scaleway API.
The command instruction defines the command, process, or script executed when your container starts.
The args instruction defines the arguments passed to the command instruction. Arguments can be passed as environment variables, as shown in the example below.
Concurrency defines the number of simultaneous requests a single instance of your container can handle at the same time. Once the number of incoming requests exceeds this value, your container scales according to your parameters.
A container is a package of software that includes all dependencies: code, runtime, configuration, and system libraries so that it can run on any host system. Scaleway provides custom Docker images that are entirely handled for you in the cloud.
Container Registry is the place where your images are stored before being deployed. We recommend using Scaleway Container Registry for optimal integration. See the migration guide for full details.
A CRON trigger is a mechanism used to automatically invoke a Serverless Container 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.
By default, a generated endpoint is assigned to your Serverless resource. Custom domains allow you to use your own domain - see our custom domain documentation for full details.
Some parameter changes require a new deployment of the container to take effect. The deployment happens without causing downtime, as traffic is switched to the newest version.
Environment variables are key/value pairs injected into your container. They are useful to share information such as configurations with your container. Environment variables defined at the container level override the ones defined at the namespace level if they have the same name.
In addition to vCPU and RAM, Serverless Containers also provide a storage volume for the duration of the task. This storage space allows you to hold the data retrieved by the job, and disappears once the execution is complete.
The maximum size of the ephemeral storage is tied to the allocated memory.
To determine the status of a container, the default health check automatically checks if basic requirements are met, to define the status as ready. You can customize the following elements to better fit your use case:
The probe type defines the type of check to perform to define if your container is ready:
The TCP probe will check if the TCP connection of your Serverless Container is opened on the specified port
The HTTP probe allows you to define a custom path to your Serverless Container to get the readiness status. It can be useful to check if all requirements are met, such as the connection to the database, etc.
The failure threshold corresponds to the maximum number of checks that can fail before declaring the Serverless Container in error. Defaults to 30.
The interval corresponds to the duration in seconds between every check. Defaults to 10 seconds.
The path (HTTP probe type only) corresponds to the endpoint to call you Serverless Container (example: /health).
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 container.
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.
Serverless Containers offers a built-in logging system based on Cockpit to track the activity of your resources. Refer to monitoring Serverless Containers for more information.
This parameter sets the maximum number of container instances. You should adjust it based on your container’s traffic spikes, keeping in mind that you may wish to limit the maximum scale to manage costs effectively.
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 Container.
A NATS trigger is a mechanism that connects a container to a NATS subject and invokes the container 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 container with the message as the input parameter.
The container can then process the message and perform any required actions, such as updating a database or sending a notification.
A container’s privacy policy defines whether a container may be invoked anonymously (public) or only via an authentication mechanism provided by the Scaleway API (private).
Scaleway Serverless Containers support Private Networks.
Private Networks let you connect Scaleway resources across multiple AZs within the same region. Attached resources can then communicate between themselves in an isolated and secure layer 2 network, away from the public internet.
Dynamic Host Configuration Protocol (DHCP) is built into each Private Network, making it easy to manage the private IP addresses of your resources on the network.
Previously, Private Networks at Scaleway were zoned. Only resources from within one defined AZ could be attached to each network. Now, all Private Networks are regional, and resources from any AZ within that network’s region can be attached. “Old” zoned Private Networks have all been automatically migrated to become regional.
While DHCP is built into all new Private Networks, it may not be automatically activated for older Private Networks. Check our migration documentation for more information.
A queue trigger is a mechanism that connects a container to a queue created with Scaleway Queues, and invokes the container 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 container with the message as the input parameter.
The container can then process the message, and perform any required actions, such as updating a database or sending a notification.
Request timeout is the maximum amount of time a request to a Serverless Container is allowed to run before the request is terminated. The purpose of this parameter is to ensure long-running requests do not hang indefinitely, which could impact resource 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.
When deploying a new version of a Serverless Container, a rolling update is applied by default. The new version of the service is gradually rolled out to your users without downtime, as follows:
When a new version of your container is deployed, the platform automatically starts routing traffic to it incrementally, while still serving requests from the old version until the new one is fully deployed.
Once the new version is successfully running, the platform gradually shifts 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 it.
When provisioned with a minimum scale of 0, Serverless Containers scale down to zero active instances as long as they are not triggered. While idling, they do not consume any resources, which allows to reduce the cost of your infrastructure.
Secrets are an extra-secure type of environment variable. They are environment variables that are injected into your container and stored securely, but not displayed in the console after initial validation. Secrets defined at the container level override the ones defined at the namespace level if they have the same name.
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.com (Serverless Framework) is a tool that allows you to deploy serverless applications without having to manage Serverless Container’s API call. Write and deploy a YAML configuration file, everything else is handled automatically, even the image building.
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 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 Jobs are similar to Serverless Containers but are better suited for running longer workloads. See the comparison between Serverless products for more information.
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.
vCPU is the abbreviation for virtual Centralized Processing Unit. A vCPU represents a portion or share of the underlying physical CPU assigned to a particular container.
The performance of a vCPU is determined by the percentage of time spent on the physical processor’s core. It is possible to allocate different resource allowances on specific vCPUs for specific containers or virtual machines.
Serverless Containers supports http1 (default) and http2 (h2c). Use HTTP/2 if your container application is configured to listen for HTTP/2 requests, such as a gRPC service or a web server that uses HTTP/2 features like multiplexing, otherwise, HTTP/1 is recommended.
Thank you for the feedback!
Your opinion helps us make a better documentation.