This looks cool. But speaking from an architecture POV, does it make sense to use Java in Lamda? Isn't the start-up time much bigger than say Javascript based Lambda even with the snapstart?
It's a really interesting question, and does depend entirely on the skillset of your team. Retraining an org to use JavaScript is a much heavier lift than Java + SnapStart+ Lambda. And then you could step out to AppRunner or Fargate if needed. Personally, I've had success with Java and .NET on Lambda. Under a steady state load you'll likely see a relatively small % of cold starts, and SnapStart does negate it. A pattern I've used before combines things like SpringBoot on Lambda for the majority of API endpoints, then maybe you pull out on or 2 endpoints that need better performance and compile them with GraalVM.
This looks cool.
But speaking from an architecture POV, does it make sense to use Java in Lamda? Isn't the start-up time much bigger than say Javascript based Lambda even with the snapstart?
It's a really interesting question, and does depend entirely on the skillset of your team. Retraining an org to use JavaScript is a much heavier lift than Java + SnapStart+ Lambda. And then you could step out to AppRunner or Fargate if needed.
Personally, I've had success with Java and .NET on Lambda. Under a steady state load you'll likely see a relatively small % of cold starts, and SnapStart does negate it.
A pattern I've used before combines things like SpringBoot on Lambda for the majority of API endpoints, then maybe you pull out on or 2 endpoints that need better performance and compile them with GraalVM.