Spring cloud function architecture with multiple functions

Question

I just started a new project where I'm going to use Java, Spring cloud functions and AWS Lambda. It's my first time building a serverless application and I've been looking at different example projects and tutorials on how to get started. However, the projects I've found have been so small that it's hard to understand how to map it to a real project.

As I understand it you build a jar file and upload it to AWS Lambda where you specify which function to run. However, as the project grows, more and more functions that aren't even going to run (unreachable code) will make the jar bigger and bigger and cause each Lambda startup to be slower and slower? I could create separate modules for each Lambda function with its own Application class in order to build separate jars, but it doesn't feel like the intended architecture.

Also, I would like to be able to run all of the functions locally using tomcat in a single application. I guess I could build a separate module specifically designed to run locally, but again it doesn't feel like the intended architecture.

Any suggestions or references to best practices would be greatly appreciated.

Answer 1

TL;DR:

• One JAR per function, not all functions in one JAR.
• Use Maven modules. One module per Lambda function.
• Don't run the Lambda locally, use unit tests with mocks.
• Deploy to AWS to test if the Lambda works as intended.

---

Reading the question I get the feeling that there are a few misconceptions on how AWS Lambda works, that need to be addressed first.

However, as the project grows, more and more functions that aren't even going to run (unreachable code) will make the jar bigger and bigger [...]

You do not deploy a single JAR that contains all your Lambda functions. Every function is deployed as a single JAR. So if you have 20 Lambda functions, you deploy 20 JAR files.

The size of the JAR file is determined by the individual dependencies of the function. A function might use a specific dependency an another might not. So JAR size will differ depending on your dependencies.

One way to improve this is to split your code from the dependencies, by putting the dependencies in Lambda layers. This way, you only deploy a small JAR with your code. The dependency JAR should only be deployed, when the dependencies have been updated. Unfortunately, this will make deployments more complex, but it is doable.

I could create separate modules for each Lambda function with its own Application class in order to build separate jars, but it doesn't feel like the intended architecture.

That's what I'd recommend. And it is more or less the only way. AWS Lambda has a 1 to 1 relationship between the JAR and the function. One Lambda function, per JAR. If you need a second Lambda function, you need to create it and deploy another JAR.

Also, I would like to be able to run all of the functions locally using tomcat in a single application. I guess I could build a separate module specifically designed to run locally, but again it doesn't feel like the intended architecture.

There are tools to run Lambdas locally, like the serverless framework. But running all the Lambdas in a Tomcat is probably going to be hard work.

In general, running Lambdas locally is something I'd not recommend. Write unit tests to run the code locally and deploy to AWS to test the Lambda. There is not really any better way I can think of to do testing efficiently.

Most Lambdas communicate with other services, like DynamoDB, S3 or RDS. So how would you run those locally? There are options, but it just makes everything more and more complicated. And what about services that you can't easily emulate locally (EventBridge, IAM, etc.)? That's why in my experience, running serverless applications locally is unrealistic and will not give you confidence that they'll work once deployed. So why not deploy during development and test the "real" thing?