101 AWS Lambda tutorial for Go developers | Hacker News Reader

101 AWS Lambda tutorial for Go developers

blog.mantil.com

66 pointskkordi20 comments

For the amount of money that AWS is making it's amazing on the lack of documentation beyond the simple lambda hello world.

I've been using C# and looking up how to handle DI and have been trying to piece together things from old articles and SO posts that I have no idea hold true today or not. Why they simply can't provide up to date best practices for various scenarios is beyond frustrating. I guess they're big enough they don't need to care that much.

Their enterprise sales team is another story entirely.

I paid for Linux Academy, pre and post merger with acloud guru. It made such a huge difference in brining me up to speed. AWS docs and tutorials are just never enough sadly.

I had the same issue a few weeks back. My solution was a variation of a SO answer. It was frustrating to not find an official answer.

After writing lambdas for node, python, go and java/kotlin, my advice is use a deterministic, compile-time or generated DI (in Java world, something like Dagger) or simply write the setup script that wires the components together.

If you don't do this, your runtime DI will become one of the most expensive parts of your lambda stack. It will dramatically affect performance and your requirements for memory in ways it simply wouldn't for long running container services.

I have north of 400 (c#) lambdas for step functions.

There’s absolutely 0 need for DI.

I totally agree here. We have used Dagger in a couple of translated Java/Kotlin lambdas but for the most part, controlling your setup scripts tightly matters which is the opposite of DI.

I'm just going through this journey myself (migrating some Go event handling stuff to Lambda), will definitely have a blog post up in a few months. Lots of pain, but also lots of gain.

Some advice:

Don't use zip files. There's no reason to use them. The OCI image approach let's you use much larger images (which with Go binary sizes might occasionally be important - 10GB vs 50MB) and only sounds scary. It's as easy as using zip files, if not easier, cause you just end up with a 10 line multistage docker image which does everything you need to produce your final artifact.

Also important, though that part is actually fairly well documented in the runtime reference, the runtime of your Lambda will be hibernated between invocations (a warm lambda, I don't mean cold starts). That means, if you have asynchronous goroutines which are periodically doing IO, you might end up with loads of timeouts and broken TCP connections there, as you'll often get hibernated mid-IO-operation.

The last point is extra painful because it causes errors that are difficult to reproduce locally (even when using runtime interface emulator)

Sometimes it feels like I'm the only person using profiles. All those access and secret keys flying around everywhere. AWS_PROFILE FTW.

You and I both, though they are a blessing and a curse. Profiles used to be my biggest issue with local and remote cred resolution, and then we layered AWS SSO on top of profile management, which doubled my problems. It’s all technically more secure and ultimately cleaner to work with when you know what to do, but trying to figure out how to transparently pass role based IAM creds into a running Fargate container to the AWS SDK was a lesson in pain (not to mention designing that to work locally). Lambda can fall through to an SSO/managed profile env fine if running w/o the container wrapper, and SAM plugins are pretty magic for making it work if you use their container, but otherwise I have been strongly avoiding custom OCI containers w/o SAM because the dev SDLC is going to require all kinds of env tweaking and cred directory mounts.

AWS documentation in this topic is lacking.

I purchased programming-aws-lambda from here https://learning.oreilly.com/library/view/programming-aws-la...

Highly recommend.

I'm curious, maybe I missed it, but why Terraform instead of AWS SAM? I find AWS SAM and CloudFormation very easy to work with and the TF is filled with AWS specific clauses so vendor lock-in is the same.

But I'm sure Terraform has some points for it too. I'm curious what people's thoughts are.

Does AWS SAM handle alias and weighted invocations well? My main complaint with Terraform is that it really starts to break down when trying to provision canary deployments with aliases and weights.

I haven't tried myself. But this example is using AWS SAM https://aws.amazon.com/blogs/compute/performing-canary-deplo...

But it does seem to require human input in the Console. I'm not sure if that is a requirement or they just did it that way for the tutorial.

(Author here) I have a great experience with Hashicorp tools and great respect for both the company and the founders. I was using Consul, Nomad, Packer, and Terraform for years in previous projects. So I chose Terraform in this serverless world also mostly because of my experience and trust in the tool.

AWS SAM, Serverless, AWS CDK, ... are all valid tools. Just don't use AWS Console for changing infrastructure; your clicks are hard to share ;).

Here in Mantil we are using mostly Terraform but also the CloudFormation and AWS SDK for operations where they fit better.

In the article I was trying to highlight the difference between two approaches; one imperative (build infrastructure line by line) the other declarative (describe desired end state).

Thanks for the thoughtful reply.

I greatly prefer declarative vs imperative. But since SAM is also declarative, I was just curious why TerraForm.

Use what you know and what you already have in you stack!

Nice write up, defining a serverless function is half the battle.

Pipedream also just launched Go support for workflow serverless steps, so you can write and execute Go serverless functions without managing deployments to Lambda. It's all through a Web UI.

I'm not sure if its DDG, but the tech company Pipedream should consider rebranding or improving their SEO. A quick Internet search did not yield the results I expected...

This is great. I’ve been looking for documentation of using the new al2 runtime with go and this fits the bill. Thanks for the excellent article.

Reply on news.ycombinator.com