[Deployments]: AWS Lambdas

[jonaro00]

Deploy AWS Lambdas using Shuttle

---

_{This issue is a part of the Product Feature Poll (all issues). React with 👍 if you want this feature. Comment if you have suggestions related to this feature.}

[3tilley]

Pulling out a summary of this idea from a Discord discussion.

The proposal would be to accept user code and execute it on the Shuttle runtime in a Function-as-a-Service manner - made famous by AWS Lambda.

Benefits to the user

• Worry less about configuring a webserver - choosing between Axum / Rocket etc and maintaining that
• Guaranteed successful execution of each call, since the contract with users is that it might be a cold start, but it will eventually complete. Currently infrequently used services fail more often (is my understanding)
• Potentially able to write very simple code with a very short time to market - no wrestling with endpoints
• Huge advantages over AWS Lambda like the Shuttle deployment system, configuration as code

Benefits to Shuttle

• More homegeneous user code is easier to support / less proliferation of webservers / versions
• Potentially more economical execution of user code - this needs to be validated
• Potentially simpler pricing model / free tier - minutes of execution per month

Below is an example of what user code to register a Shuttle FaaS might look like:

#[derive(serde::Serialize)]
pub struct CalculationResult {
    z: f64,
}

#[derive(serde::Deserialize)]
pub struct CalculationInput {
    x: f64,
    y: f64,
}

pub enum Error {
    InternalError,
}

// More hands-on way of exposing a lambda-like endpoint
#[shuttle_runtime::faas_post("/mutliply")]
pub async fn multiply(input: CalculationInput) -> Result<CalculationResult, Error> {
    Ok(CalculationResult {
        z: input.x * input.y,
    })
}

// Could it be simplified such that someone would only need to do the below? Shuttle
// would then generate the JSON types
#[shuttle_runtime::faas_post("/multiply_simple")]
pub async fn multiply_simple(x: f64, y: f64) -> f64 {
    x * y
}

Things to think about:

• Auth
• Sync vs async? Could async benefits be realised inside a sandboxed container?
• How to handle errors?
• Allow all HTTP methods / accept-headers etc?
• Allow any form of HTTP result? E.g. would it just be a ShuttleFaas result object?
• Are the imagined efficiencies there?

[shaaza]

Adding some more benefits that a FaaS model might bring to both users and the platform, largely due to the request-scoped nature of FaaS:

• Idling and scale-up concurrent project deployments based on request load
• Shuttle can own the availability and scalability of the user by applying resiliency and scalability patterns using request-level success metrics (retries, timeouts, redundancy etc.)
• Enable on-demand pricing models that can scale to zero when project not in use
• More granular per-request monitoring capabilities for the app out of the box: e.g. per-project availability, latency and breakdown, errors, dependency failures etc.
• Event-driven triggers for requests to projects instead of just REST APIs
• Continuous security patching of OS and OS deps,