AWS deployment strategies

[juliocorzo]

Broadly speaking, without mentioning IaC options, this is what a release using open-next probably looks like in AWS infrastructure:

1. Merge master, trigger a new build
2. In the build, run open-next and derive the serverless functions from the source
3. Update current infrastructure with new serverless functions
   1. Image and server lambdas: tag them with the live alias after deploying new versions, so that the Lambda URL points to them.
   2. Middleware: add the new version to the viewer request on the default and the /_next/data/* CloudFront cache behavior, and that of course takes about 5 minutes.

This is roughly what I'm doing currently:

1. Run build and package the new functions for use with CloudFormation
2. Use CloudFormation to deploy new server, image optimization, and middleware functions.
3. Use a pipeline Lambda to update CloudFront cache behaviors for middleware.

Is this correct? Are there easier ways of doing this?

[martg0]

@juliocorzo, I am trying to achieve the same thing using aws-cdk v2. I am new to it, so I am struggling a little bit. As a former user of the serverless-nextjs component, it would be great to make this work.

[devmanbr]

I'm interested in the same subject. it would be nice to hear more about how the community implemented it.

[davidrhoderick]

Just stumbled across this. If you want to figure out how to implement it, the SST NextjsSite construct would be where to take a look. Or you could just use their NextjsSite construct with SST and call it a day...

[juliocorzo]

Follow up: I implemented a fully-working demo with Terraform, but, it's important to understand that Terraform really doesn't like to share infrastructure. I mention this because each new deployment of open-next requires CloudFormation to run to change the Lambdas and S3 assets.

I had to ignore a bunch of stuff on first run, then change a variable in Terraform once the pipeline has run once and the functions exist. I don't think this is sustainable, as new Next.js features will lead to more problems upgrading.

My current point of view is that open-next really shines when using it with SST. Some organizations might not like moving away from Terraform, but I believe that the nature of serverless Next.js requires custom infrastructure be created. It's not as simple as just setting it up on ECS.

This is not the fault of SST or Terraform, but I would encourage anyone that is thinking of using open-next to consider if they actually can at their organization. It's an amazing project, and I'm pushing for adoption, but it's important to know these caveats.