Capabilities
Scopes can be configured to have specific hardware (e.g., CPU or GPU, storage) and configurations (e.g., healthcheck URL, log throttling).
We encourage you to provide as few scope specs and constraints as possible since this allows greater flexibility towards automated runtime optimization and cost savings. For example, if you establish a specific instance type, we won't be able to swap your instance type for a more suitable one that better suits your workload.
How to set capabilities
Capabilities can be set at creation or while the scope is active through the "Advanced" section at the bottom of the new/edit scope page.
Use the /capability endpoint to list the available capabilities and the /scope/:id endpoint to check the current
configuration (under the capabilities field). Capabilities are defined using JSON Schema.
Capability lists
Language and runtime (Serverless only)
Here you specify the language runtime that will run your serverless applications.
Concurrency (Serverless only)
Define how AWS Lambda handles concurrent executions for your serverless function.
Processor (server-based only)
Here you can choose between traditional CPU instances or CPU + GPU, which are handy for example to serve machine-learned models. In case you really know what you're doing, you ultimately have the ability to specify the exact instance type that this scope will require.
Scaling (server-based only)
Here you configure the minimum and maximum number of instances that will serve your application in this scope. We recommend never going below 2 and being careful about the maximum value since it can compete account-wide quotas.
You can also define scaling behavior based on resource usage:
- Scale based on average CPU usage across instances.
- Scale based on memory usage by setting a target memory threshold.
Spot instances (server-based only)
When you enable spot instances, you have the chance to use lower-priced resources by taking the risk of being evicted from those instances. To properly manage this tradeoff you can choose which percentage of your scope will be targeted to run on spot instances.
Function Handler (serverless only)
Specifies which function is being exported for the runtime to invoke upon a call.
Storage
In the case of server-based applications, this capability is controlling the amount of storage that will be available on the mounted filesystem.
Timeout (serverless only)
Determines how many seconds your serverless function can run before being considered "failed."
Continuous Delivery
When you turn on this capability, you have to specify which branches will be automatically deployed into this scope. Whenever there's a new build coming from any of these branches we will generate an automatic release and run an all-in deployment into this scope.
Turning on continuous delivery in production scopes can be dangerous as this is an all-in deployment without a progressive traffic switching step. Use with care.
You can use this capability to automatically deploy to this scope every time a new build is created from those branches.
Logs (server-based only)
Here you can select the log service provider and set up scope-specific policies such as log throttling.
Metrics (server-based only)
In this section you can turn on / off the functionalities that extract metrics from your instance to deliver them to Cloud Watch.
Metrics and logs are embedded in nullplatform's product, and turning them off will impact your experience and harm your troubleshooting capabilities.