Upgrade to aws-sdk v3

[hugosenari]

Is your feature request related to a problem? Please describe.
Some day aws will release a new version of aws-sdk (aws-sdk v3).

Describe the solution you'd like [optional]
We should be prepared or at least plan the migration.

Additional context

New version features modularized packages it could reduce cold start

[ceilfors]

Great suggestion! There might be a possibility of a breaking change depending on what's being updated. Let's watch closely we need to bump to v2.

[hugosenari]

Update
https://aws.amazon.com/blogs/developer/modular-aws-sdk-for-javascript-is-now-generally-available/

• 3.0.0 (first)
• 3.x.x (current)

[reestolonio]

Node 18 runtime uses only v3 of the sdk. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
Is there update on this?

[ceilfors]

@reestolonio Thanks for bringing this up! Are you stuck because of the version at the moment? I'll be away for 1-2 weeks, we'll appreciate pull requests as well if you can manage it!

[ceilfors]

@Ankcorn Suggested the usage of https://aws-lite.org/ as an alternative to upgrading AWS SDK.

cc: @mpxr @tschoffelen

[hugosenari]

AWS-SDKv2 Issue

I was checking the EOL issue, the problem isn't that v2 will not work anymore, only that will not be shipped with runtime anymore.

Context:
Pre Node 18 runtimes has a provided (note that npm has notion of provided) AWS SDKv2, what some dev does is take advantage of provided package to reduce theirs package size (and cold start), by defining it as dependency and filtering it from the bundle.

Now, Node 18+ runtimes will come with AWS SDKv3.

I didn't test it, but means we could still use v2 until it's EOL, V2 has no EOL defined yet, but users cannot take advantage of this provided trick.

That doesn't mean we don't have to be prepared to EOL or upgrade, only that maybe this EOL issue is less urgent than we think.

AWS-SDKv3 vs AWS-lite

I'm glad to know about AWS-lite, but I don't think (I have no data) that SDK3 is worse than SDK2, in my tests SDKv3 wasn't worth the upgrade effort (no reduced bundle size). But if the problem is that users will not take advantage of the provided trick, it would be the same for AWS-lite.

We have the following installation scenarios:

1. AWS-SDKv3 Provided (I'm not sure but think they provide all submodules)
2. AWS-SDKv3 Bundled * every submodule (ie. only dynamodb, only sqs, sqs + dynamodb)
3. AWS-Lite Bundled * every submodule (ie. only dynamodb, only sqs, sqs + dynamodb)
4. AWS-SDKv3 Provided + AWS-Lite Bundled (ie: laconia uses Lite and dev uses SDK)

And we should measure the following properties at least:

• bundle size
• cold starts
• request overhead (in case Lite has cold start overhead, but requests are faster than with SDK).

We also have to check other pros and cons:

• Effort required to migrate to v3 vs effort required to migrate to AWS-lite.
• Market share of AWS-lite (ie sdk vs sdk/dynamo vs lite/dynamo) and its expectation for future.

[ceilfors]

Thanks, Hugo.

V2 has no EOL defined yet

EOL is not directly for the SDK, but its relationship with AWS Lambda. The EOL is defined here, starting Aug 15, 2024, all Lambdas must be deployed with node18, which no longer ships with AWS-SDKv2.

I agree that the v3 vs lite needs a broader assessment.

[ceilfors]

I briefly looked at aws-lite performance metrics. It's unclear to me, but it seems that the limitation of the assessment is it doesn't compare against "AWS-SDKv3 Provided" scenario i.e. code deployed doesn't include aws-sdk (it's unclear to me what the graph means)

In my head, "AWS-SDKv3 Provided" will provide the best performance, so it could influence people's lack of adoption of aws-lite.

[hugosenari]

doesn't compare against "AWS-SDKv3 Provided" scenario

They call it "Raw", but Provided ("Raw") should not differ from Bundled in run speed (ignoring cold starts), unless they did it in a suboptimal way. IE. they import AWS-SDK for every request.

[hugosenari]

After that, I'm not sure if they did the benchmark correctly, but as I can see:

	cold start
aws-sdk3 provided P90	145ms
aws-sdk3 bundled P90	160ms
aws-lite bundled P90	189ms
aws (sdk2+sdk3+lite) P90¹	??

	time to respond	sdk init	DyDB R	DyDB W	memory
aws-sdk3 P90	481ms	20ms	157ms	32	98
aws-lite P90	251ms	23ms	135ms	58	83

¹ high market share of sdk2 means most users would use sdk2 bundled, have sdk3 provided and if we use, also lite bundled

EOL is not directly for the SDK, but its relationship with AWS Lambda. The EOL is defined here, starting Aug 15, 2024, all Lambdas must be deployed with node18, which no longer ships with AWS-SDKv2.

Unless AWS-SDKv2 stopped working in Node 18+ or we cannot have the provided aws-sdk3 (not in use) and bundled aws-sdk2 (in use), that relationship only matters for provided, not for bundled.

If the last statement is true (it is??), there is a palliative option til we migrate to sdk3 or adopt lite: Have two sdk versions. Isn't good, but less catastrophic than say it won't work after Aug 15, 2024.

[ceilfors]

Wow, thanks for doing all the analysis, Hugo!

aws (sdk2+sdk3+lite) P90¹
high market share of sdk2 means most users would use sdk2 bundled, have sdk3 provided and if we use, also lite bundled

If users are using sdk2 bundled, they will not be importing sdk3. This means there's no performance impact of AWS providing sdk3.

They call it "Raw", but Provided ("Raw")

I have just confirmed with Brian that Raw means provided by the Lambda runtime.

should not differ from Bundled in run speed (ignoring cold starts)

I just got this revelation too that this is not necessarily true. Think about why we bundle js files for browser libraries i.e. there could be a good amount of useless code that's involved in the I/O when things are raw.

there is a palliative option til we migrate to sdk3 or adopt lite: Have two sdk versions

Yes! This is a valid option. Companies who want to still deploy via Node18+SDKV2 can bundle in SDKv2 on their own. AWS Lambda Layer is also an option.

Scenarios:

1. Existing users that are generally stuck with SDKv2: They will find this matter less urgent
   • In this scenario they stick with v2.
2. Existing users that are only blocked by Laconia.js: They will still find this very frustrating i.e. they have to implement a workaround.
   • In this scenario they have upgraded their own code to SDKv3.
3. New users: Users who are already on node20, and using awssdkv3 won't benefit from Laconia.js.

---

I'm beginning to think that aws-lite should be considered differently for Laconia.js i.e. we support it if there are a good enough requests to support it, because:

• Scenario 1: Users are on aws-sdkv3, Laconia.js on aws-sdkv3: Laconia.js does not impact performance
  • Most likely to happen, so safest option is to support v3 first
• Scenario 2: Users are on aws-sdkv3, Laconia.js on aws-lite: Laconia.js has a performance impact
  • We'll unnecessarily impact users performance, not great
• Scenario 3: Users are on aws-lite: Laconia.js on aws-sdkv3: Laconia.js has a performance impact
  • We'll unnecessarily impact users performance, not great but this scenario should be unlikely? We can optionally support it in the future as a different feature.

[hugosenari]

I just got this revelation too that this is not necessarily true. Think about why we bundle js files for browser libraries i.e. there could be a good amount of useless code that's involved in the I/O when things are raw.

That because I'm not correctly using the term "bundle". I'm using it as user provided (SDK in the user package), the opposite of aws provided (referred only as provided because of Maven analogy).
Then for bundle (user provided), user has two options:

• Packed: dynamic linked, run time imports;
• Compiled: static linked, build time imports.

Most people refer to "bundle" as "compiled".
I used to do more "packed" and in layers for lambda, because I think we have 3 phases:

1. AWS download and unpack our code (only for cold start);
2. AWS import our code (only for cold start);
3. AWS call our functions (all requests).

Maybe because of speed difference between network I/O and disk I/O, 1 has more impact in cold starts than 2.
So, not adding SDK to user package would be more impactful than adding it but compiled because V2 tree shaking wasn't effectful, that's why I was hoping v3 to be better. Turns out that v3 isn't, reason I'm glad to know about Lite.

Code \ Runtime	AWS Node 16 (SDK2 Provided)	AWS Node 18+ (SDK3 Provided)
No SDK	SDK2 Provided +0 Network I/O +0 Disk I/O	SDK3 Provided +0 Network I/O +0 Disk I/O
SDK2 Provided	SDK2 Provided +0 Network I/O +3 Disk I/O	FAIL
SDK2 Packed	SDK2 Provided + SDK2 Packed +9 or +0¹ Network I/O +3 Disk I/O	SDK3 Provided + SDK2 Packed +9 or +0¹ Network I/O +3 Disk I/O
SDK2 Compiled	SDK2 Provided + SDK2 Compiled +9 Network I/O +1 Disk I/O	SDK3 Provided + SDK2 Compiled +9 Network I/O +3 Disk I/O
SDK3 Provided	FAIL	SDK3 Provided +0 Network I/O +3 Disk I/O
SDK3 Packed	SDK2 Provided + SDK3 Packed +9 or +0¹ Network I/O +3 Disk I/O	SDK3 Provided + SDK3 Packed +9 or +0¹ Network I/O +3 Disk I/O
SDK3 Compiled	SDK2 Provided + SDK3 Compiled +9 Network I/O +1 Disk I/O	SDK3 Provided + SDK3 Compiled +9 Network I/O +1 Disk I/O
Lite Packed	SDK2 Provided + Lite Packed +6 or +0¹ Network I/O +2 Disk I/O	SDK3 Provided + Lite Packed +6 or +0¹ Network I/O +2 Disk I/O
Lite Compiled	SDK2 Provided + Lite Compiled +3² Network I/O +1 Disk I/O	SDK3 Provided + Lite Compiled +3² Network I/O +1 Disk I/O
	0¹ with luck in layers	3² how effective is tree shaking Lite

If users are using sdk2 bundled, they will not be importing sdk3. This means there's no performance impact of AWS providing sdk3.

I'm expecting that by actual market share of v2, how powerful are demons from dependency hell and how accurate is Murphy, user import both. I just don't know if it will work.

I'm beginning to think that aws-lite should be considered differently for Laconia.js i.e. we support it if there are a good enough requests to support it

Agree, since user can always use only core, #539