Skip to main content
  1. Posts/

Using Go in AWS Lambda

··596 words·3 mins
Author
Hairizuan Noorazman
Software engineering experiments, implementation notes, and lessons learned.

Disclaimer: There are definitely better ways of doing this; this is more of a lazy man’s way of doing it. This is just to explore the possibility of getting a golang application into AWS Lambda and successfully running it.

Although Golang support is coming to AWS Lambda, (I’m totally excited for this - hopefully it will come out this year!) we can still try a few things on our own end to somehow get lambda to run our Go Applications. One common way would be to just write Golang applications as usual but instead of just running the command:

go build main.go

We would instead use a nice feature that Golang have; cross compilation and build it for the AWS Lambda runtime.

env GOOS=linux GOARCH=amd64 go build main.go

There would generate an executable that can run on the machine that built it but it should on linux machines just fine.

In python, we would just wrap that executable and call it accordingly. To put it simply; since AWS didn’t really support Golang runtime then, we could create the binary that was compatible with the AWS OS that is used to host AWS Lambda and then have the python code in the available python runtime run it. Essentially, any language that produces a binary that can be executed on a machine can be put here as long as the right values are being put in.

from __future__ import print_function

import json
import subprocess

def lambda_handler(event, context):
  value = subprocess.check_output("./main", shell=True)
  print(value)

  response = {
    "statusCode": 200,
    "headers": {
      "Content-Type": "*/*"
    }
  }
  return response

We would try to run this very simple go code example (The helloworld example)

package main

import "fmt"

function main() {
  fmt.Println("Hello World")
}

The deploy.sh file below:

# Create the distribution folder
rm -rf dist
rm -f dist.zip
mkdir dist

# Build the go application
env GOOS=linux GOARCH=amd64 go build main.go

# Copy lambda files in
cp lambda_function.py ./dist/lambda_function.py
cp main ./dist/main

# Generate the distribution zip
cd dist
zip -r dist.zip .
cd ..
cp dist/dist.zip dist.zip

To view the full code for this example: https://github.com/hairizuanbinnoorazman/demonstration/tree/master/trying_aws_lambda/raw/go_example

I can only think of very few reasons to want to do this; due to the nature of AWS Lambda where code might take a while to start running (e.g. cold start problem), there is no point having extremely efficient code. Unless you are doing extremely heavy compute stuff and python or any other language supported by AWS Lambda that can help resolve the issue, would this go kind of help a little. Other than that, it might be better to just play along with what AWS Lambda provides us.

If you would prefer an explanation and an example of this, you might want to watch this clip.

However, with the upcoming support provided by AWS, it is probably uncessary to do all these weird hackaround. We can upload the Go Code straight into AWS Lambda and then have it execute accordingly.

Even with all that simplicity, it would ideal to actually rely on serverless framework to actually help do the administrative portions of the serverless functions. There are many things to consider when writing serverless functions, one of which is to set up the required security roles. If the functions are dependent on queues etc, it would requiring work to administrate all that additional functionality.

Naturally, as programmers, we would have all those work automated away, which could mean writing ansible scripts or even cloud formation scripts (specific AWS). However, one can just rely on the serverless framework to do all that heavy work.

Related

Serverless Applications with Cloud Run with Serverless MySQL from PlanetScale

··806 words·4 mins
Serverless computing, as seen in platforms like Cloud Run or AWS Lambda, allows developers to run code without managing the underlying infrastructure. This is achieved by automatically scaling the resources based on the incoming requests, and users are billed based on the actual execution time and resources consumed during each function or container invocation.

Trying out Google Cloud Workflows

··1675 words·8 mins
Over the recent weekends, I’ve decided to take a gander and try another “serverless” tool called Google Cloud Workflows. The tool’s appeal is to be able coordinate a bunch of services in order to achieve a particular goal. The coordination effort (or workflow) can easily get pretty complex -> one way would be to script but if we want to have the capability to have the button to run the entire workflow from start to end with logging in place as well as capability to run the workflow based on particular triggers.

Trying out skaffold

··497 words·3 mins
When developing application that are meant to be deployed to the Kubernetes platform, it involves a bunch of steps on top of your usual local development work: Writing a Dockerfile to package the application (Multi stage applications are optional here - useful for compiled based languages) Build and tagging the docker image of the application with the target repository Either use kubectl commands or use kubernetes config resource files to define the resources required for deploying the applications. Use those commands/configurations to define the resources on the staging/production application Repeat the process for each update of the application (Repeat second point onwards) As you see from above, it starts to be pain to do so after each iteration of the application development. The building of the docker containers process as well as the applying of the new images to each cluster, (sometimes with slightly changed configuration files) - the kubernetes secret and config files can change across different environments.