"Dev" mode

[mnapoli]

A topic we wanted to cover from the start was helping users deploy applications with:

• production-optimized settings (this is Lift's default right now)
• development-optimized settings (not implemented yet)

That "dev" mode is mostly about reducing costs.

For example, when deploying a database with a VPC, we don't want the same kind of instances, storage space and redundancy in prod and in dev.

Let's discuss some ideas here, as so far we haven't identified an ideal solution.

Since GitHub discussions allows response threads, let's open 1 response thread per idea. That way we can discuss each idea.

[mnapoli]

One idea is to be able to override specific settings explicitly:

service: app-backend
provider:
    name: aws
lift:
    vpc:
        az: 3
constructs:
    # ...
    db:
        type: database/sql
        instanceType: t3.xlarge
        storage: 3000

# Map each stage to a "dev/prod mode"
stageMapping:
    prod: prod
    staging: prod
    default: dev
# Override specific settings for "dev mode" only
dev:
    lift:
        vpc:
            az: 1
            nat:
                type: instance
    constructs:
        db:
            instanceType: t3.micro
            storage: 20

I don't like this option, it's confusing and complex. But I thought it was worth mentioning 🤷

[mnapoli]

Another idea is to simply not support the feature.

Users would be able to solve that problem by having 2 config files with different settings:

# prod deployment
serverless deploy

# serverless.yml
service: app-backend
provider:
    name: aws
lift:
    vpc:
        az: 3
constructs:
    # ...
    db:
        type: database/sql
        instanceType: t3.xlarge
        storage: 3000

# dev deployment
serverless deploy -c serverless.dev.yml --stage=...

# serverless.dev.yml
service: app-backend
provider:
    name: aws
lift:
    vpc:
        az: 1
        nat:
            type: instance
constructs:
    # ...
    db:
        type: database/sql

That solution is simple to implement (because there's nothing to do), and simple to understand for users.

However it can involve a lot of duplicated config over those 2 files…

[mnapoli]

Iterating on the previous idea (duplicating everything), we could have an extend mechanism:

# prod deployment
serverless deploy

# serverless.yml
service: app-backend
provider:
    name: aws
lift:
    vpc:
        az: 3
constructs:
    # ...
    db:
        type: database/sql
        instanceType: t3.xlarge
        storage: 3000

# dev deployment
serverless deploy -c serverless.dev.yml --stage=...

# serverless.dev.yml
extends: serverless.yml
lift:
    vpc:
        az: 1
        nat:
            type: instance
constructs:
    db:
        instanceType: t3.micro
        storage: 20

Using the extends keyword, we avoid duplication: the serverless.dev.yml file would only override specific properties.

I expect that solution to be harder to implement (maybe it would make sense to actually do that in the Serverless Framework itself). But past the initial complexity to implement, it seems easy to understand for users.

[esimonetti]

Yeah, I think this approach upstream in serverless would make sense. jekyll does something similar, just need to pass multiple configs one after the other on build/serve and it will override anything that is passed to the outermost configs jekyll build --config _config.yml,_config.dev.yml

Someone could probably do it this way as well? https://medium.com/@HussainAliAkbar/serverless-reusing-common-configurations-across-functions-e17ee10e0645
Chunking the files in section and having a section for each stage