First AWS Lambda (I tried to see what kind of environment it works in)

It was AWS architect training for 3 days from Monday. I was surprised when I first came into contact with Lambda. It is my own summary (for those who know it, I preach to Buddha).

What is Lambda?

I'm ashamed to say that when I heard the word "serverless," it didn't quite come to me. But this is literally right. It doesn't matter what environment the program runs in. It doesn't matter what the OS is, what the middleware is, how much memory is, how much the CPU is, what the NW is, what the topology is, etc. (Actually, you can specify the memory size and respond accordingly. CPU capacity will be allocated). Anyway, the code (program) moves with the "trigger" called "trigger" as a trigger. With Java, the JVM will start up and the uploaded jar will be executed. "Trigger" is highly integrated with AWS services, for example

• Files have been uploaded to S3, a file storage service (although it's no longer just storage)
• The message was put on the queue
• Request came to API Gateway
• EC2 instance launched
• It's 3 o'clock
• I'm hungry (I told Amazon echo)
• e.t.c.

Is it TDB (Trigger Driven Bean) instead of MDB? It doesn't have to be a bean, so it may be better to call it TDC (Trigger Driven Code).

Try to move

During the training, I had plenty of time for practical training, so I wrote a simple code in Eclipse that was in the training terminal and tried it. Tests can be kicked from the AWS Console, so it's easy to try if you just want to run it without defining a "trigger".

Manners

Basically any Java program will work if you include the necessary libraries, but there seems to be a promise in the method to call. It's an argument. Get ʻObject as the first argument and Contextas the second argument. The method name can be anything. The type can be anything (however, both the first argument and the return type must beSeriarizable`, primitive types are OK).

Specifically, the information from the "trigger" is entered in the first argument. If the trigger is that the message is puted to the queue, you can pass the message itself. If the return value is a synchronous call, it should be almost the same. All you have to do is Serialize and return it according to your interface requirements.

The second argument, Context, is not javax.naming.Context, but com.amazonaws.services.lambda.runtime.Context. So you need to add the AWS-provided jar file (https://mvnrepository.com/artifact/com.amazonaws/aws-lambda-java-core/1.1.0) to your build path. [^ 1] [^ 1]: Eclipse has a AWS toolkit plugin There is, so you can just set up this environment.

create

I don't have the skills or ideas to write meaningful code yet, so I decided to see what kind of environment (system properties, environment variables, passed Context objects) works like an infrastructure shop.

SystemInfo.class

package net.mognet.aws.lambda;

import java.util.Map;
import java.util.Properties;

import com.amazonaws.services.lambda.runtime.Context;

public class SystemInfo {

    public static String printSystemInfo(int i, Context context) {
    		StringBuilder sb = new StringBuilder();
    		//Add header
    		sb.append("name,value\n");
    		
    		//Get system properties
    		Properties prop = System.getProperties();
    		for(Object key : prop.keySet()) {
    			String name = (String) key;
    			String value  = prop.getProperty(name);
    			sb.append(name + "," + value + "\n");
    		}
    		//Get environment variables
    		Map<String, String> env = System.getenv();
    		for(String key : env.keySet()) {
    			String value = env.get(key);
    			sb.append(key + "," + value + "\n");
    		}
    		//Get Context information
    		sb.append("context" + "," + context.toString());
    		return sb.toString();
    }
    
    public static void main(String[] args) {
    		System.out.println(printSystemInfo(1, null));
    }
}

main is for testing. The first argument is supposed to be important, but this time we will not do anything.

Put on

Open the AWS console and create a Lambda function (it works in units called functions. There seems to be a service that orchestrate multiple functions (details not yet investigated)). Select an appropriate name and runtime (Java8 this time) and press "Create Function". Since the standard output flows to CloudWatch Logs, create a role with Write permission to CloudWatch Logs in advance and attach it here if necessary. Normally, you would select a trigger here, but I just want to test it, so I'll just put in the conditions around that. In the function code, upload the jar file from" Upload ", and the important thing is to enter the method to be executed here in the" Handler ". The format is fixed, and it is the method name with "." Notation and "::" after the full path of the class. This time it will be " net.mognet.aws.lambda.SystemInfo :: printSystemInfo ". I also added environment variables. Once you "save", the file will actually be uploaded. Next is the preparation for the test. This is a test case (input setting = first argument setting). Select "Test Event Settings" at the top of the screen. Since the first argument of the method to be executed public static String printSystemInfo is ʻint`, write only 1 to finish. Press "Save" at the bottom. Now you are ready to test.

Let's do it!

Press "Test" as a matter of course. It worked. Since there is no log output (standard output) this time, I do not see the log, but the start and end messages were displayed. Since the String type method was executed, the return character string is displayed on the screen as it is (I wanted the line feed code to start a new line, but this is the correct way for the execution result display console).

appendix

The execution result is listed in the appendix.

Information such as the access key was also included in the environment variables, so I masked it. It may be necessary to understand that it is such a specification. Is it possible to call the AWS API using the keys around here? Also, the environment variables that have been set properly are also shown (obviously). It looks like it's running on OpenJDK on Amazon Linux. I don't know what will happen to this when it actually goes live. It's just that this was the case when this test was run. After all, it's serverless, so again, the execution environment (HW, OS, MW, etc.) doesn't matter. Rather, I realized that Lambda-like usage is to write the code on the assumption that it doesn't matter.

reference

Lambda Function Handler (Java) --AWS Lambda