A better way of deploying Go services with Serverless Framework

Maciej WinnickiMaciej Winnicki · November 25, 2019 · 3 minutes read

Go is a great language. I really like it. It’s super simple, statically typed, with a huge ecosystem. It makes you productive. Do you know what’s better than Go? An AWS Lambda function written in Go and deployed with Serverless Framework.

The experience of building Go services with Serverless Framework is not the best, though. Well, that’s pretty obvious because the framework is language-agnostic. Let me list some of the issues:

  • Go is a compiled language, so you cannot simply run serverless deploy or serverless deploy function after each code change because you need to compile it. It requires an intermediate step making the dev experience a bit disturbed.
  • Developers that are new to Go don’t know all the secrets of go build command. They tend to compile Go code without using addition flags causing the output file being larger than possible, which in turn causes the deployment process to take longer.
  • When you define the function in serverless.yaml, handler property has to point to the compiled file, rather than to the source file. Again, not big of an issue, but it might be tricky for people starting with Go or/and Serverless Framework.

Usually, the solution is to have a Makefile or some Bash script that will automate the compiling and deploying process. But there is a better way.

The Plugin

I really care about the developer experience, feedback loop, and about using well-tailored tools that make our work easier. That’s why I would like to introduce you to ⚡️ Serverless Framework Go Plugin!

The plugin solves all the aforementioned issues (and more!) and makes the development process seamless. Let see how it works.

Here is the minimal Go service:

service: example-service

  - serverless-go-plugin

  name: aws
  runtime: go1.x

    handler: ./functions/example/main.go
    memorySize: 128

Now, let’s see how it works:

To sum up:

  • no reference to the compiled file because the plugin compiles the handler on-the-fly (concurrently on all CPU cores)
  • no need to set package configuration excluding all unnecessary files from the zipped payload. The plugin does that for you.

The plugin also supports serverless deploy function and serverless invoke local!

Go check it out! If you have any questions let me know in GitHub issues or here in the comments.