- We are also focussed on reliability, so setting up and tearing down environments while handling all the AWS rate-limit errors, or other timing related errors. We do this by connecting directly to CloudFormation.
On the alerts, logs, and metrics; the critical difference is that we query directly against your CloudWatch Insights or subscribe to your CloudWatch groups, instead of ingesting all your logs on our side. This allows us to:
Yeah for sure. Previously, we relied on the the Serverless Framework CLI output. But now we directly monitor the CloudFormation events to figure out the root cause of the failure, then decide if we should retry the deployment, and how long to wait to retry.
- The big one is the focus on speed, the incremental deploys at a service and Lambda function level (https://seed.run/blog/speeding-up-serverless-deployments-100...).
- We are also focussed on reliability, so setting up and tearing down environments while handling all the AWS rate-limit errors, or other timing related errors. We do this by connecting directly to CloudFormation.
- We also allow you to configure a deployment order for your services (https://seed.run/docs/configuring-deploy-phases).
On the alerts, logs, and metrics; the critical difference is that we query directly against your CloudWatch Insights or subscribe to your CloudWatch groups, instead of ingesting all your logs on our side. This allows us to:
- Provide real-time Lambda alerts basically for free (https://seed.run/docs/issues-and-alerts)
- And you don't need to configure anything on your side. You connect your AWS credentials and it works out of the box.
As always feel free to reach out if you need further details jay@seed.run