Dealing with lambda cold starts in the real-time data pipeline #312

lucylu-coveo · 2024-10-16T20:00:28Z

…-start-blog-post

lucylu-coveo · 2024-10-24T17:20:42Z

The blog post is also available in Google Doc: https://docs.google.com/document/d/1N_3vd_IJpnqAVrtTufF1AiGTbgBEmDxHvbs144nq5lU/edit?tab=t.0

_posts/2024-10-22-dealing-with-lambda-cold-start-in-real-time-data-pipeline.md

jmprovencher · 2024-10-24T18:21:54Z

_posts/2024-10-22-dealing-with-lambda-cold-start-in-real-time-data-pipeline.md

+```
+
+## 2. We kept all the old version of Lambda functions
+Since SnapSart only works with published versions of Lambda, we started publishing versions after enabling SnapStart (before that we had been only using the unpublished $LATEST version). As we didn’t delete old versions (and Lambda doesn’t provide a configurable feature to delete old versions), we ended up with over 50 versions of a single Lambda function. We weren’t aware that all these versions were being re-initialized periodically by Lambda service, until we received a notification about an initialization failure for a very old version. Although this behavior was mentioned in this [documentation](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html#snapstart-pricing) under SnapStart pricing section, we overlooked it after seeing the statement “there's no additional cost for SnapStart”. To mitigate this issue and to reduce costs associated with re-initializations, we created the following bash script to keep only the latest two versions of Lambda function. The previous version is kept in case we need to roll back. This script is triggered automatically after a new version is published.


"This script is triggered automatically after a new version is published."

Improved: "This script is automatically triggered after a new version is published."

Hmmmm I prefer Lucy's version here 🤷🏼 We need a native speaker's input here. CC @mpayne-coveo

The first one sounds more correct to me, but they both sound valid

I won't argue too much, just for fun, that's what chat gpt thinks about this:

`
The improved sentence, “This script is automatically triggered after a new version is published,” is better primarily because of clarity, flow, and emphasis:

Clarity and Readability: When “automatically” is placed directly after “is,” it’s immediately clear that automation is the focus. This placement eliminates any chance of misinterpreting what “automatically” is modifying, making the sentence clearer on first read.

Natural Flow: Placing “automatically” right after “is” aligns with the natural rhythm of English, where adverbs often come directly after auxiliary verbs (like “is,” “was,” “has”). This structure feels more fluid and effortless to read.

Emphasis: Putting “automatically” earlier in the sentence highlights the automation aspect, making it a more prominent detail. Since this is likely an important characteristic, bringing it forward can subtly enhance its importance.

In professional or technical writing, concise, naturally flowing sentences are often preferred as they increase comprehension and readability.
`

_posts/2024-10-22-dealing-with-lambda-cold-start-in-real-time-data-pipeline.md

jmprovencher

a few comments, other amazing post as always

_posts/2024-10-22-dealing-with-lambda-cold-start-in-real-time-data-pipeline.md

rphilippen · 2024-10-25T15:12:22Z

_posts/2024-10-22-dealing-with-lambda-cold-start-in-real-time-data-pipeline.md

+```
+
+## 2. We kept all the old version of Lambda functions
+Since SnapSart only works with published versions of Lambda, we started publishing versions after enabling SnapStart (before that we had been only using the unpublished $LATEST version). As we didn’t delete old versions (and Lambda doesn’t provide a configurable feature to delete old versions), we ended up with over 50 versions of a single Lambda function. We weren’t aware that all these versions were being re-initialized periodically by Lambda service, until we received a notification about an initialization failure for a very old version. Although this behavior was mentioned in this [documentation](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html#snapstart-pricing) under SnapStart pricing section, we overlooked it after seeing the statement “there's no additional cost for SnapStart”. To mitigate this issue and to reduce costs associated with re-initializations, we created the following bash script to keep only the latest two versions of Lambda function. The previous version is kept in case we need to roll back. This script is triggered automatically after a new version is published.


Since SnapSart only works with published versions of Lambda, we started publishing versions after enabling SnapStart (before that we had been only using the unpublished $LATEST version).

I would make the part in parentheses a separate sentence:

Since SnapStart only works with published versions of Lambda, we started publishing versions after enabling SnapStart. (Before that, we had been using only the unpublished $LATEST version).

I also think the placement of the word "only" in that sentence could be better (I moved it in my "suggestion" above). I'm not 100% sure that is actually better; I'm not a native English speaker 😅.

CC @mpayne-coveo

lbourdages

👌🏼

_posts/2024-10-22-dealing-with-lambda-cold-start-in-real-time-data-pipeline.md

lbourdages · 2024-10-25T15:45:48Z

_posts/2024-10-22-dealing-with-lambda-cold-start-in-real-time-data-pipeline.md

+```
+
+## 2. We kept all the old version of Lambda functions
+Since SnapSart only works with published versions of Lambda, we started publishing versions after enabling SnapStart (before that we had been only using the unpublished $LATEST version). As we didn’t delete old versions (and Lambda doesn’t provide a configurable feature to delete old versions), we ended up with over 50 versions of a single Lambda function. We weren’t aware that all these versions were being re-initialized periodically by Lambda service, until we received a notification about an initialization failure for a very old version. Although this behavior was mentioned in this [documentation](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html#snapstart-pricing) under SnapStart pricing section, we overlooked it after seeing the statement “there's no additional cost for SnapStart”. To mitigate this issue and to reduce costs associated with re-initializations, we created the following bash script to keep only the latest two versions of Lambda function. The previous version is kept in case we need to roll back. This script is triggered automatically after a new version is published.


Hmmmm I prefer Lucy's version here 🤷🏼 We need a native speaker's input here. CC @mpayne-coveo

_posts/2024-10-28-dealing-with-lambda-cold-start-in-real-time-data-pipeline.md

lucylu-coveo added 9 commits July 18, 2024 16:14

Add real-time streaming pipeline blog post

9561820

delete unused image

a6027bd

add a blog post about Lambda cold start in real-time data pipeline

72ecfcb

Add real-time streaming pipeline blog post

60d3a00

delete unused image

1c2c4c2

Merge branch 'gh-pages' into feature/UA-9342-dealing-with-lambda-cold…

aa321a3

…-start-blog-post

remove unneeded files

abb19ab

fix image caption format

6c2f951

change post date

cd290f7

lucylu-coveo changed the title ~~Feature/ua 9342 dealing with lambda cold start blog post~~ Dealing with lambda cold starts in the real-time data pipeline Oct 16, 2024

lucylu-coveo marked this pull request as ready for review October 16, 2024 20:48

lucylu-coveo requested review from jmprovencher and amoreauCoveo October 16, 2024 20:53

jmprovencher requested a review from pboucherCoveo October 23, 2024 13:37

lucylu-coveo requested review from mpayne-coveo and lbourdages October 24, 2024 17:19

lucylu-coveo requested review from AdamMartineau-Coveo, aperron-coveo and rphilippen October 24, 2024 17:22

aperron-coveo reviewed Oct 24, 2024

View reviewed changes