• Mark Eschbach
Now that I have my plan it’s time to get implementing. Figuring out deployment of the lambdas is important and Terraform might make this easy. Out of curiosity I’m wondering what the
dead letter queue for a function is. I’m assumming this is similar in concept to the DLQ for a message broker too. Ah, for feedback of failures. I’m assuming this is for exceptions and such.
Terraform gives me two options: S3 or a ZIP. I’m not sure I care which one however S3 would be more seamless for updates, or so it seems. Since lambda only has a few choices of execution environments I think I’m going with NodeJS due to team famililarity. I’m not sure why
function_name is required so to the books! Apparently it’s the name to register the function under. I feel like they could have chosen a better name which would have been more expressive. Like
Anyway, theory is easy enough. Next up is getting it to tick-tock. Looks like some others have already figured this out for me! I’ll use a CloudWatch event and setup the Lambda as a target. Sweet.
Just out of curiosity I’m wondering if I was missing something simple. There is an
EcsParameters on the CloudWatch target API however it’s description is vauge. While playing with the CloudWatch console it didn’t give option to execute ECS tasks. So I don’t think there is a simple method to do so.
Next up is dealing with the AWS API to kick the ECS task. I’m hoping it’s as easy as Ruby but we’ll see. In the end it might be easier to use ORC with an SQS message ot run this task. We’ll see though.
Preempted by build issues and deviations from our CD pipeline.