Fantastic post! Ever since Lambda@Edge was released, I never understood why I would use but your example did it.
The trick of using the parameter store to avoid cyclic dependencies is an insight for me as well.
About #6: well, I wished there was an open source library for custom resources! :) 7…
Absolutely. I recorded a video to explain my thoughts on it but in my own way. I didn’t like how people interpreted the term nowadays (to get attention due to the buzzword maybe?)
absolutely. human error may not be because “we’re human”. It’s rather that we are dealing with sub-optimal systems under not-so-ideal conditions (e.g stress)
before you write your next post about it, I invite you to read “The Field Guide to Understanding Human Error” by Sidney Dekker. It changed my thinking on human error.
Hey Rafat, I was looking for the “condition” configuration but the docs says that it’s no longer supported since compose 3.
They suggest these alternatives instead:
do you use cloudformation at all? does the following not suit your needs?
I think that what we’re looking at is the early release. Lambda supported only Node.JS, functions had maximum 30-second timeouts and heck, even integration with api gateway was missing at launch. Give AWS some time, I’m sure they can and will do better :)
I get your point but I’m still sceptical on this.
I wonder how that will work at scale of hundreds of functions. How much ops overhead that will incur? What if you have to fix permissions in several in one go?
How have you dealt with it?
Wow before I read this, I was only thinking about SNS. That’s a smart way of using dynamodb streams, thanks!
I just found that Eric Hammond has written about another approach using Kinesis streams. I didn’t think about that either and it seems to be a smart solution as well. An example of what it allows you to do is: