Generated CoudFormation templates & deploy stagger

Jets
1

I’ve noticed when using the following options that the generated child stacks do not all have DependsOn set.

  config.deploy.stagger.enabled = true
  config.deploy.stagger.batch_size = 1

DependsOn is not set on the following child stacks

  • shared resource stacks
  • authorizer stacks

Is this intentional ?

We are experiencing frequent rate limits on CloudFormation

Rate exceeded (Aws::CloudFormation::Errors::Throttling)
2

Yes. DependsOn is only set on “app” stacks, mainly because it was simple to implement at that time. Will consider PRs. No sweat either way of course. :+1:

Also, wondering how big your shared resources and authorizer stacks are. Wondering what the limits currently are.

3

@tung

We have

  • 5 authorizers
  • 1 function
  • 10 jobs & growing
  • and a handful of shared resources

We currently have > 150 lambdas deployed total. It would be a nice option, if all actions (GET, PUT, etc) on a given resource (/foo/bar) could be deployed to a single lambda rather than a separate lambda for every action.

CloudFormation Stack instance operations per administrator account is set to 3500. I’m not 100% sure this is the rate limit we are hitting, but AWS refused to increase it for us.

We tried upgrading to 3.0.17 which helps with the rate limit errors, but causes a significant cost increase in our lambdas. Lambda durations increase dramatically in 3.0.17. Does Jets use the AWS SDK during controller execution ?

4

Bummer. Yup. AWS has limits like any other cloud provider.

As you mentioned, Jets 3.0.17 has rate-limiting improvements. Actually ran into rate-limit issues issue enough with a BoltOps client that has over 200 lambda functions. Fixed it as a part of that work. They haven’t seen or reported any more rate limit issues since then. So believe address most of the rate-limit issues for large apps.

RE: It would be a nice option, if all actions (GET, PUT, etc) on a given resource (/foo/bar) could be deployed to a single lambda rather than a separate lambda for every action.

No current way to do that with a framework setting. Would consider PRs but unsure how that would work right now.

If you want to combine things into a fewer or single lambda function, here are some approaches:

  • One away is to each of the controllers to catchall controller action routes and then within the controller delegate to private methods or other classes or some pattern that makes sense for your app.
  • Another way is to have an AllController that handles the catch-all route. That can then delegate to other ruby classes to handle your needs. This will only generate 1 lambda function and you are delegating to the rest of your app logic.
  • Another possible way is to have a rack compatible app and mount it: https://rubyonjets.com/docs/rails/mount/

There will be some rework to your app structure, but those are some approaches.

RE: significant cost increase in our lambdas

Sadly, unsure what’s going with that. Debugging it a bit and couldn’t reproduce it: UPDATE_FAILED AWS::CloudFormation::Stack JetsPreheatJob Embedded stack