Using Aws Java Sdk It Takes Time To Upload A File Which Is 30 Mb Why?

AWS Lambda layer in Java

What are lambda layers?

AWS introduced Lambda Layers back in 2018 as a way to share lawmaking and data between functions within and across different accounts.

Lambda layers allow us to share common lawmaking and dependencies between multiple lambda functions.

Using lambda layers to manage and govern lambda function will result in a flexible, scalable and solid base for your lambda based architecture.

Why employ lambda layers?

The chief benefits of using lambda layers are:

Small resulting JAR — Each function deployed will exist small and contains merely the lawmaking related to the action it intended to do.
Single packaging for shared dependencies — No need to package shared dependencies or code with each function.
Flexible code updates — Updating a code or a dependency will happen but in one place instead of each role.

In short, lambda layers are hither to help united states develop higher scale and complex lambda functions using flexible, scalable and unproblematic management tools.

When to use lambda layers?

The use of lambda layers can, sometimes, create more problems than solutions. Especially when coding in a static language like Java, which requires all the code and dependencies during the compilation process.

In my betoken of view the use of lambda layers should be done in the following cases:

Large dependencies that frequently updated.
Custom lambda runtimes.
Lambda function custom wrapper.

Lambda layers in Java:

As we sympathize so far, having your lambda layers written in Coffee can be a real pain. I would not recommend this at all. Using Python or NodeJS will be much easier and faster.

Just, in some cases. The cost of migrating existing services, written in Java, into lambda functions, in a unlike linguistic communication, will exist fifty-fifty more painful than wrapping yourself around this tutorial and deploying lambda layers in Java.

Lambda Basic Wrapper:

The start affair that we will do is to create the function trigger handler, This trigger handler will utilise us as the starting time and most basic lambda layer for our functions. We will be using MAVEN and openjdk8.

And then, our initial pom.xml should contain the following dependencies:

And also the shade plugin:

Notice the dependencies section for a transformer to log4j2 logging framework. In case y'all want to use log4j logger in your app besides, delight add together too the following dependencies:

Right now we are coding our showtime functional layer, with some functionality and not just dependencies. I would recommend keeping this layer every bit minimal every bit possible. Any other dependencies required by your implementation are welcome. But acquit in heed, this layer should be generic and calorie-free.

On top of information technology, depends on the version of aws SDK you are using, some version conflicts heighten and should exist dealt with. Please brand sure to follow the AWS documentation to complete your pom.xml

The Lambda handler class:

The side by side step is to create the handler that volition be triggered by AWS Lambda when needed.

This can be done using the RequestHandler interface<I, O> that volition require us to implement the handleRequest method.

In my case, I chose to implement this interface using an abstract course, this will allow me the create a solid infrastructure betwixt all of my lambda functions, and the AWS Lambda interface.

My example describes an abstruse SQS message lambda trigger.

Please notice the comments inside the class for further explanations

Local installation and use:

Now, for us to use our new lambda layer, nosotros will need to install it and import it.

Layer installation:
This is a very uncomplicated task, we will employ MAVEN to create our fat JAR using the shade plugin: mvn clean install The result will exist a new jar installed in our local repository .m2. Nosotros volition use this JAR as part of our layer deployment (volition be explained afterward on). Simply, also every bit a basic layer for lambda functions.
Layer import:
Before going into the technical part, let'southward understand what exactly we want to practise and why this is not that fiddling.
Nosotros wish to create, eventually, a JAR that will compile properly by MAVEN using our description in the pom.xml but we don't want to package this JAR's dependencies with information technology.
Why?
well, doing that will make the use of layers pointless, we don't want to bundle every office with all of its dependencies. Nosotros desire to be able to compile just the lawmaking that we need and to use dependencies at runtime for a unlike repository.
How?
For us to get this weird setup to piece of work, we will need all the dependencies bachelor on our local .m2 repository. We volition need to physically import the dependencies into our local environment. Nosotros need this for compile-time so we volition be able to admission our lawmaking. Now, to marking MAVEN non to parcel those dependencies alongside our code, we will use the provided scope in the dependency definition.

Add the provided scope for each dependency you lot want to extract from a lambda layer at runtime. Just make sure that the versions and JAR names will match.

Now all that's left for you is to create a class extending the LambdaAbstractWrapper class you created in the basic layer, set the return type of the function and implement the processMessage abstruse method.

Layer packaging for runtime:

As we mentioned earlier, our lambda layer is added to the lambda function runtime environs once the part is invoked. And then, how tin we tell the lambda runtime which layers we want? and where they are located so our app will be able to utilize them?

First, let us create a lambda layer:

ZIP all desired JAR files into ane zipped file — LambdaLayer.nada
Upload this Nix file into the desired S3 bucket.
aws s3 cp LambdaLayer.zip s3://<BUCKET_NAME>
Create a new lambda layer using aws CLI and salvage the response.
aws lambda publish-layer-version --layer-name <LAYER_NAME>\ --compatible-runtimes java8\ --content S3Bucker=<BUCKET_NAME>,S3Key=LambdaLayer.zip\ >> LambdaLayerResult.json

By now, you should have a lambda layer compatible with Java lambda functions. You tin verify it by logging into your AWS account, navigate to lambda and click on "Layers" on the left side menu. The consequence of the CLI call was saved into a file called LambdaLayerResult.json. From this file have the LayerArn. When we will define the lambda office we will need it to attach the layer to the function.

Create and deploy the Lambda function:

Now, we will create our lambda execution function, deploy our Java lambda part and attach it to the lambda layer we created in the last part.

Create a lambda execution role example, salve the new role ARN for later use.
Edifice our lambda function JAR using MAVEN — mvn clean install
Uploading the lambda function using aws CLI:

aws lambda create-fucntion --function-proper noun <FUNCTION_NAME>\ --runtime java8 --role <ROLE_ARN> --handler <PATH_TO_HANDLER_CLASS>\ --retentiveness-size <MEMORY_SIZE_IN_MB> --region <REGION> --layers <LAYER_ARN>\ --zip-file fileb://<PATH_TO_JAR> --publish

Now, we take created the lambda execution role, the lambda function and attached the lambda layer to it. You can verify information technology by logging into your aws account, navigate to lambda and search for your new function nether Functions.

That's it!

Lambda functions, in general, are a powerful tool in a serverless architecture. The power to manage lambda layers in Java will allow you to maintain a simple, stiff and flexible serverless surround.