Go Is a Great Fit for Lambda
brandur.org
brandur.org
The Go 1.x runtime will happily execute any binary, go, rust, c++. Events are sent over a TCP stream. That stream uses Go's net/rpc which encodes objects using Go's special [gobs] binary format.
If they had chosen a more common exchange format it would be much easier to support new runtimes. I haven't found any implementation of gobs outside of go. If you write one for a language you could use that language to write a native Lambdas.
Worst case, you can implement this interface yourself now easier than ever. Since golang is statically linked and has super fast startup times, you can build an interface where Lambda launches your golang process, and that process binds to a port and spawns a sub-process that implements the actual Lambda function. The golang process would implement the "socket" based interface for you.
People have been doing the above already, but all the existing runtimes, including Node.js, Java, Python, and .NET, have non-trivial startup times and memory usage compared to a golang binary, which should be able to start up in 10s of milliseconds and use less than 1 MB of memory while acting as a proxy.
Man, the JSON specification must be annoying/complicated - because the first part of what you said, binding to port X and responding to HTTP, is like.. 1 line in Go. So the first part of what you said is extremely trivial, so the difficulty must lie in the second part?
I wonder what makes the JSON specification so difficult? From your wording, I assume the HTTP response is being sent to AWS, not the actual HTTP requester. Regardless, it must be damn clumsy to justify calling a simple HTTP response too complicated for developers.
Clearly I've never used Lambda though.
Tell me in Java, without looking up any online resource, how to set up a FastCGI web application. Can you? Probably not. Now tell me how to write a static method in Java. If you have at least the equivalent Java experience of a freshman undergrad, you can do the latter but not the former.
If you think Lambda should use FastCGI as its common interface, then by all means create a project on github that deploys a Go-based FastCGI bridge to Lambda and makes it easy for you to bundle up your FastCGI application into a Lambda function. Problem solved! Now you just have to get people to use it.
But the average developer isn't going to do that, and won't need to. Within a week there would be more than one framework up on github to do the binding in their favourite language for them. Look at how many web frameworks there are.
That's annoying, and something I hate about Javascript. There's no standard way to do it, so everyone has a different way of doing it.
I prefer that Lambda has sane, solid standard ways of doing things so if I have to move between projects I know what the heck is going on, rather than having to figure out which of the many homegrown ways of doing things people decided to use.
// main.go
package main
import (
"github.com/aws/aws-lambda-go/lambda"
)
func hello() (string, error) {
return "Hello ƛ!", nil
}
func main() {
// Make the handler available for Remote Procedure Call by AWS Lambda
lambda.Start(hello)
}
[Edit: this is a joke. I think the person to whom I'm replying has a valid point.]
The industry has way too many frameworks that should have been protocols.
That's half a dozen (-ish); I'll let someone else complete it.
Anyone can implement their own 'aws-lambda-go' library in what ever language they want, but the choice to use net/rpc and it's gobs format makes it more difficult than it could be. json is implemented in practically every language. there are binary formats with libraries is most languages if your want to be efficient.
Choosing a protocol other than net/rpc would 1. make it easier for AWS to support more runtimes 2. make it easier for the community to support custom runtimes. 3. be as easy to integrate with as aws-lambda-go is.
CGI only works if you’re willing to take the hit of launching an entire process (good luck using any interpreted language, and even go needs some runtime initialization at startup) for every single web request.
The magic of TCP or domain sockets is that calling accept() gives you a unique file descriptor that corresponds with a single client.
Just using stdout doesn't work that way, unless your entire process was launched to handle one request, hence CGI being very inefficient.
I wish lambda would do more to support more executable contexts instead of blessing individual languages.
You can argue that fast compilation IS a feature and that new language options should be evaluated, but it's unfair to say it's "not a priority" even for languages like Scala.
This. Compiling C++ would be a lot faster if you made the developer manually expand all the templates into tedious boilerplate before starting the compiler, but it's not a good tradeoff to make.
Before releasing Go support, it felt like they're simply creating arbitrary friction to keep people on their platform. By expecting your code to export a handler, rather than listen on a port, that has a specific signature, you end up coupling yourself more to the AWS platform. But it also causes a ton of friction for adoption, since testing is more difficult than it should be.
Now with the release of Go, it feels even more that they're putting up these arbitrary gates without a rhyme or reason. How come Go can listen on a port, but other runtimes need to export a handler function? Why did they choose to rely on a Go-specific protocol instead of a common one?
It's frustrating, because I really want to use it (from an ops perspective), but I think my team is going to ditch the proof of concepts we've done because of the friction we've experienced. I'm sure there are valid engineering reasons for these choices, I just don't see them.
Rather than offer what amounts to nothing more than an ad hominem, perhaps you’d care to explain why whatever you’re using is superior.
Your preference may be containers or bytecode bundles, but you’d be hard pressed to justify a major advantage and add a lot of complexity overhead for the privilege of using them.
Is this ad hominem? Why?
We can both agree to this and agree that Go's compile speed makes very large code bases possible (and that its cross-compile story is very compelling when your entire world revolves around writing on OSX machines and running in a linux docker container.
Lots of languages can deliver big static binaries. Hell, once upon a time this was considered a disadvantage and languages like Common Lisp and Smalltalk were totally raked over the coals for having an image & executable model!
> but you’d be hard pressed to justify a major advantage and add a lot of complexity overhead for the privilege of using them.
Why then is Go given this?
Because I could name 3 languages equally deserving right off the bat and one of them would be way less work: Kotlin, Swift and Haskell.
The special case of glibc, is the exception of majority of C compilers.
It's a very odd state of affairs. In an age of docker, nix uberjars, ever more sophisticated user and system space filesystems it's really questionable what value they bring.
People say, "Simplicity" then they bling out their docker containers with multiple layers of processes and initialization anyways.
Go's tooling would have been great in a pre-Docker era. Now... I don't see the appeal.
There's a packaging challenge, but Go is also easier to install than most languages (unzip the linux build and set GOROOT correctly).
Then running `go lint && go vet && go build && go test` inside Lambda is fast and cheap compared to other options. No more time spent in a queue, downloading Docker images, initializing containers, etc.
I made a GitHub app if anyone wants to quickly try out building their Golang project on every build in a Lambda function.
I struggle to think of a language where that hasn't been true..
If you're ok extending that to "language + stdlib": Node.
https://news.ycombinator.com/item?id=16169803
The short version is that I don't think it's fair to compare Go's stability to that of a "barebones" language with an infinitesimal stdlib (e.g., C), because that's where most of the change is likely to happen. Go's already proven to be far more stable than most "batteries included" languages: think Python 2 vs. 3, Ruby's fairly considerable churn over the years, PHP 4 to 5, etc.
Obviously my designation on Go here is subjective, but it seems to me that it compares favorable to any other platform that comes to mind.
Of course, C++98 was 20 years ago so that's probably okay!
One obvious concrete benefit of serverless is not managing infrastructure.
At the free tier your options include, on a monthly basis:
* a single EC2 t2.nano box with 0.5gb memory and 1vcpu
* 1,000,000 requests (or 40,000 gb-seconds worth of requests) to your lambdas
Assuming you're taking in less than 1m requests monthly the lambdas will handle traffic spikes much more gracefully than the small VM will; as well, since it's not an either-or proposition this also means you still have a free VM you can do something with.
Where I think Lambda is interesting is in areas of high variability.
The sort of canonical example is image resizing. While you certainly can do that on the same machine as your web server it makes a lot more sense to put the images to a S3 bucket (keeps them off the server, out of versioning, etc.)
You can tie a Lambda to a S3 create file event. So when the file hits the bucket it automatically gets resized into all the appropriate sizes needed elsewhere on the site. This setup sidesteps a ton of potential issues, makes your app much more robust and is pretty easy to get going.
If you’ve got 100s of services or handle huge load spikes, why spend extra rev cycles on concerns like “do I have enough machines” or “are these things patched?” or even “how do I make sure my service stays up?”
I use it for creating image derivatives on a project which doesn’t have dedicated servers for that task. Every S3 upload triggers a conversion task which saves the result to another bucket. The long-term average number of servers is close to zero since the content is released in batches but when a new batch arrives it’s reliably done in 5 minutes no matter how large it is, and I don’t have to manage autoscaling policies, server builds, etc. – just write a couple dozen lines of Python.
For a sufficiently large amount of work the cost tradeoff might go the other way but in my experience there are a LOT of tasks which are below the threshold where the savings in server time is greater than the savings in sysadmin time.
If what you actually want to do is relatively simple, eg, read a JSON message from an AWS service, like a Cloudwatch Alert, an autoscaling action, or an API call logged in Cloudtrail, you can easily wire those events up to Lambda functions for which you only need to code the bit that parses the JSON and does something in response. So then if the event happens once a day, once a month, or 50 times a second, you don't have to actually worry about calculating scale, except for cost purposes. But if it's a rare event, then Lambda comes in way cheaper than a $20/month server you have to maintain somehow.
Of course, you can build apps directly on Lambda, but there's a lot of tools you'll miss when you get around to going full scale production. But for simple glue to wire up actions to events, it's actually a pretty slick service.
Need to keep a security group in sync with the IPs some 3rd party service publishes? cloudwatch cron + lambda function.
Need to do some weird scattering in response to s3 object created events? lambda function.
want to roll some of your own automation to manage and respond to health events with services you host? some event stream + stepfunctions + lambda functions.
Thanks to Lambda's generous free tier, I've paid literally nothing for these services. I could handle 100x the current load and still pay nothing.
It has taken some time for Google to support new versions of Go on App Engine, though they're promising to get better at it.
Do we need to open a new connection to the DB on every call?
TL;DR don't use a connection pool in Lambda
> Now I see that you mentioned in one of the github posts: "The Lambda does seem to use the pool, but if I make maybe 3 / 4 quick requests to the lambda, new connections are opened up despite there being all of those connections already."
> 3/4 quick requests would mean concurrent invocations, and concurrent invocations will execute in new containers. Containers are not aware of each other and cannot share state information so if an execution occurs in new container, it will open a new connection if there are none in this new container, despite there being existing connections from different containers. This can also cause your RDS instance to have too many open connections, because another container may have all the connections saturated, and if a new container is required to handle the load it may not be able to create the new RDS connection it needs to do it's work.
- https://github.com/sequelize/sequelize/issues/4938#issuecomm...
In that light, it might make sense to use a pool size of 1, if your application already does pooling. If you've written code to run multiple database queries simultaneously, you may want to adjust accordingly, but only allocate the number of connections you expect to use in that single request.
If you're connection constrained, you might want to look at pgBouncer, whether or not you're using Lambda. It increases your connection usage efficiency to the max irrespective of whether the connections are being used by lambda or a regular server.
- has a very low base cost - scales quickly to thousands of req/s
Operating this on lambda has some significant downsides:
- no request multiplexing - warm up overhead (lambda itself, our service, connections)
As we are operating at large scale we can invest in building infrastructure that supports this with more traditional AWS primitives.
In broad terms our approach is to:
- operate a t2.micro for each tenant - use burst capacity to bridge scale up periods - switch to c5 instances when a cluster reaches higher load.
This is a lot of operational overhead, but because we operate thousands of clusters we can fully automate this.
As a user of Prisma you can consume your database via a GraphQL API over http. This is a great benefit when developing serverless functions as Prisma essentially moves db connection pooling outside your serverless functions.
Go 1.0 was released 28 Mar 28 2012.
Go is on a six-month release cycle[1]. Focusing on the number of minor versions is not only the wrong thing to do (because different languages release updates at different rates) but it's also factually incorrect, because by schedule, 2 minor releases happen in a year.
Anyway, I like Go too and agree it's very stable and while it's not as formal as C++ (ISO standards) it's been very stable. Give it 10 years to know for certain.
> But for a fair comparison you'd need to include a lot of C libraries to match Go's standard library. How much have those libraries changed over the years?
Yes, exactly. Something like C isn't a fair comparison because there's so little included in the core language. Think about everything that you get with Go's standard library: concurrency, HTTP (even HTTP2), TLS, JSON, XML, Zip encoding, Regexp, etc., and then consider C's APIs along with all the APIs of all the libraries you'd need in C to accomplish those tasks — all of that together would be a more fair comparison.
That might seem like apples and oranges, but for most real-world programs, people generally need a considerable subset of that functionality. C's stability is nothing to scoff at, but it's nowhere near as impressive of an achievement.
There are arguments on this thread that they should have supported arbitrary binaries by using a generic RPC format, instead of th Go specific RPC format.
There is ongoing work on CoreRT, the UNIX version of .NET Native.
You can easily compile or run, any .NET 1.1 on .NET 4.7.1, that is 16 years of stability.