Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Deploying .zip files is one of my favorite features of Lambda, particularly when writing Go apps.

Docker always felt wrong with Go to me.

Why do I need a local VM, a Linux build service, an image registry and servers with container orchestration to deploy Go software? I understand how all this helps with "legacy" Rails or Java apps, but why can't I just throw a Go binary somewhere to run it?

Lambda is exactly this. I upload a cross-compiled .zip to S3 and everything else is taken care of. This was a big breakthrough for me, seeing a much simpler solution for deploys than all the container stuff.

I've been building a boilerplate app that demonstrates just how little "stuff" is needed to run a Go service on Lambda:

https://github.com/nzoschke/gofaas

More thoughts about how .zip files make our lives easier is here: https://github.com/nzoschke/gofaas/blob/master/docs/dev-pack...



It actually wouldn't be too hard to build a MacOS tool for building scratch Docker containers with a cross-compiled Go binary. The docker image format roughly just a tar file containing a manifest json file and a tar file containing the root filesystem. *

Sure Lambda is pretty simple (just upload a zip!) and is very similar to what Google AppEngine has been doing since 2008 (AppEngine also uses zip). But you are signing up for complete lock-in...

Also, it's depressing to note that MacOS is now the only major operating system that does not have support for native Linux containers without the use of a VM. * *

* https://github.com/moby/moby/blob/master/image/spec/v1.md

* * https://www.hanselman.com/blog/DockerAndLinuxContainersOnWin...


You don't need all of that shit, though. You absolutely can just throw a golang binary into a super minimal alpine image and run it wherever you've got a Docker daemon installed. You literally don't need any of the things you listed! Plus, it is simply untrue that "everything else is taken care of" in Lambda. There is plenty of one-off configuration to do ("toil").


If you're just working with a golang binary, you shouldn't be using an Alpine container, you should be putting the binary in an empty, from-scratch container. Go binaries are typically static and don't need distro or the libs it provides in their container.


Sure, I'm just saying that none of that stuff he says is necessary is needed at all.


Your go containers don't need anything more than your static binary, root certs, and tzinfo files. Everything else is extra.


Plus a base image, Docker build system, image registry service and Docker runtime.

Not to mention the load balancer and container orchestration to run the containers.

It's not all bad. Container tools and services are ubiquitous, pleasant to use, and support literally any workload you may have.

But throwing a zip in S3 and having API gateway send it requests is far less moving parts (at least that we have to worry about).


I can take my (docker) containers and VMs, move to an entirely different cloud provider, simply update DNS to point to the new IP and everything is up and running within 5 minutes of the host booting.

On AWS Lambda, I can't just rip out my entire infrastructure and move elsewhere. I'm stuck with AWS Lambda until I rewrite my functions to not rely on AWS Lambda and AWS Services.

If my hoster decides they don't like me anymore, I can move my business elsewhere within the hour. Can you move AWS Lambda to another provider within the hour?




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: