Hi Chris, Thanks for your post about Go Lambda, but... should we be worried? Did something happen to Jeff Barr? Is it time to move to a different cloud provider?
Your post about Go on Lambda is certainly helpful, but feels like it's aimed towards at a difference audience than Jeff (Barr, not Bezos).
Hi fragmede! Jeff Barr is a busy man and his blog these days is mostly focused on new products or super major features for existing ones. Lambda releasing Go support definitely toes the line (at least in my mind) but we made the decision to go with a post on this blog which has a focus in this space. Jeff is quite fine though and I talk to him almost daily!
Don't know if this is sarcasm, but AWS has a large team of evangelists. I'm sure they'd want to avoid a single point of failure in developer relations as well.
Anybody dissected yet how they're invoking the handler?
Given that you have to compile the binary before pushing it up, it seems weird to announce "golang support" and not "support for any binary that talks $insert_serialization_scheme" over stdin/stdout or a network socket or some such, unless they're doing fancier magic.
It looks like the compiled binary just gets exec'd by the Lambda function and listens on a TCP port (specified by the environment variable _LAMBDA_SERVER_PORT) which accepts RPC calls to execute the handler using net/rpc.
TL;DR: Discusses how Google engineers replaced the download server written in C++ with one written in Go, and analyzes the reasons why. It's pretty cool.
My understanding is that it's not that significant in terms of lines of code in the codebase, but it is significant in terms of its official support and its rate of growth.
Hrm. That is stretching the definition of scripting quite a bit. No REPL and clearly lower level than shell, Perl, Python, Ruby, no dynamic typing, etc. Not knocking golang at all, but "scripting"?
I would agree that some problems solved by scripting could/should be replaced with something more precise. But golang wouldn't be a great fill in for true scripting needs.
Wishing for Rust support too. At the moment we are doing some batch processing stuff on AWS Lambda using Rust. We are wrapping the Rust binary in a Python script, which is fiddly and annoying.
if it's a "json" like data that is sent to you (i.e a structure made out of only primitive types and list/dict) it may be not that hard, but I think it will be a work with very few value outside of this very specific use case.
Go might be a better language to use as a shim executor than Javascript. Unless Lambda is doing something tricky to make NodeJS perform much better than normal when it comes to loading code
Curious if you can comment, but is it in the roadmap to define a standardized language agnostic gateway interface for Lambda so a binary written in any language could be deployed by simply implementing the interface?
Had anyone had resounding success with serverless technologies?
The CLI tools work, but they're frequently more of an annoyance then running a single process app. The logical layout and composition falls entirely on the team. Composing related functions seems to be more troublesome than it's worth.
Is Go on lambdas exciting because people use Go for cross cutting devops operations? Is there demand for writing serverless Go?
I see containers and the single process model as much easier to test, lay out and run. Honestly, I probably just do "get" serverless. What am I missing?
I'm excited for Go on Lambda because the only other viable statically-typed language supported by Lambda has been Java, which suffers from crippling cold start problems. This will let me have Python-speed cold starts, faster-than-Java sustained throughput, and static typing, in a relatively simple and easy language.
There are some narrow use cases where yes, stuff like Lambda works well. Mainly for infrastructure glue and pasting over holes in AWS functionality. I do not recommend it for any direct production usage.
I am on the go so I can’t type much, but basically lack of control and insight into your service—why it’s firing or not, what is backing things up, unexpected errors can fail near silently, there’s a lot of tooling we take for granted on servers we control that you start to miss on lambda. Logging is a lot more work. Scaling is completely invisible and outside of your control. Weird OS or runtime bugs can surprise you. I don’t have a bullet list with documentation of each downside, but from experience running at a large-ish scale, it can be a lot more frustrating than you expect and the benefits in cost are not necessarily there. But again it depends on the workload and the use case. I’m not interested in making blanket statements about serverless tech. It has a promising future but the tools are just not there yet, at least not with Lambda. I don’t have experience with the competing services.
This is all fair feedback and this is still early days for what Lambda and the "serverless" application space will bring. From the AWS's side we've seen a lot of customer success in various areas from companies moving from more monolithic or 2/3 tier web apps to single page apps (SPA) + serverless backend, moving to near real-time streaming with Kinesis+Lambda, processing records/documents/images/video/etc with S3+Lambda. Alexa Skills are often powered by it, etc. Bunch of customer stories here: https://aws.amazon.com/lambda/resources/#Customer_Case_Studi... and yes lots of work (such as this release) to keep making this be the default compute platform of choice for the future.
Disclaimer: AWS Serverless Developer Advocate
We use AWS Lambda for running our Django application. We chose it because we did not want to manage servers and everything else that comes with it. We have had only a few minor issues, nothing we could not handle.
Initially it was a bit disconcerting that I could not ssh into a machine and inspect anything. However, our mindset changed after a while. Instead of thinking of Lambda as a server, view a Lambda application as equivalent to a Gunicorn process in a production server. No one is going to ssh into the process or set breakpoints.
Only after Microsoft had a better Android emulator experience and C++ support for Android development on VS, did they care to actually improve their own tools.
