AWS offers a dazzling array of services for similar things. Dazzling is a great synonym for “confusing”. Feels like “Speed of Innovation”, “Range of Services” and “Coherence of Offerings” is a “pick 2 of 3” situation…
An often asked question on the AWS communities I hang out on is “can we use a Lambda for that?”
People asking this are often primed with some of the problems of serverless compute, and jump to the advanced features to mitigate them:
- “I’m worried about cold starts, do I need to pay for provisioned concurrency?”
- “I’m accessing a database, do I need to add an RDS Proxy?”
- “I worry about response time, do I need to enable API Gateway caching?”
- “I worry about out-of-order”, do I need First-In First-Out queues1
These are valid questions, with valid solutions, but paraphrasing a global sportswear brand: Just Try It.
Deploy your code, and see how it performs/responds. Then apply the tricks to make it better.
Starting with the dirtiest hack of all: Make it bigger.
Lambda CPU is only controllable by memory, and I’ve been in multiple situations where there was a step-change in performance jumping from 64 to 128 megabytes. There’s tooling that can help you find the right size for your application.
It’s lazy, brute force, but takes literally seconds to change the memory and re-test.
I’m a big proponent of ‘innovation as Business as Usual’: you shouldn’t need the excuse of an innovation day to try the new things. That only works if you start simple.
But I’m an even bigger proponent of not stressing yourself/teams unnecessarily: If you don’t have time to test in your current project, do what you know works. Hit your shipping dates, have an easier sprint.
Hopefully you can have a play in the future and add something else list of what “works”, it’s nice to expand that list, but only when you’ve enough headroom to do so.
In conclusion, while sometimes I can tell you that something is unlikely to work, most of the time you’re just going to have to try it.
Sorry.
- I understand FIFO messaging has its place, but I work in content, not transactions. Including a ‘reliable’ timestamp in the event (e.g. the time an article was published, not the time the message was sent) is cheaper and allows consumers to identify if they should process an event, allowing easier recovery if databases have to be re-crawled. ↩︎