2 ms·
Thank you! They offer something similar but there are a couple of differences. - The big one is the focus on speed, the incremental deploys at a service and La
by jayair 6y ago
Thank you! They offer something similar but there are a couple of differences.
- 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-100x 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 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 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
- jedberg 6y agoAwesome, thanks for the info! Do you have more info on what you mean by "We do this by connecting directly to CloudFormation"?
- jayair 6y agoYeah 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.