Guidelines for CRaC in Cloud Environments
AWS
AWS Lambda
AWS Lambda provides the SnapStart functionality, which is an implementation of CRaC. Each time you upload a new version of your Lambda function, it gets executed automatically, and a checkpoint is created. This checkpoint is then used for each new instance of the function, to provide fast startup.
For more information, check Improving startup performance with Lambda SnapStart.
AWS EC2, EKS, ECS,…
When you run your application as a regular or Dockerized app on one of the Amazon services, follow the general guidelines as described on Running an Application With CRaC.
Microsoft Azure
Quarkus
Quarkus can be restored in Azure, when your app is configured correctly:
-
The container for the checkpoint must be identical to the cloud service’s container you use to restore your app.
For example, an Azure Java 17 Web App logs contains the following container name:
mcr.microsoft.com/azure-app-service/java:17-java17_221014210614. That same container must be used to create the checkpoint. -
The app directory structure on checkpoint must be identical to the directory structure used by the cloud service for your app on restore. You need to check how your runtime archive gets deployed on the cloud service.
-
File permissions on checkpoint must be the same as on restore in a cloud service.
For example, in Azure all the deployed files have
777permissions, which can’t be changed. As a result,777permissions must be set to the files which are used for the restore. -
Network ports used by your app must be allowed by the cloud service.
For example, Azure only allows to use ports 80 and/or 443. Your app must use one of these ports when the checkpoint is created, otherwise Azure can’t ping your app after restore, and shuts it down.
Google Cloud
Micronaut
If you use the Micronaut framework, check the documentation provided by the Micronaut project: Deploy CRaC Docker Image to Google Cloud Run.