Hacker News Reader

Comment by electricEmu | Hacker News Reader

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?

View on HN

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.

Why?

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.

> Scaling is completely invisible and outside of your control

isn't that the point?

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

I think you're raising more topographical/philosophical problems, but

https://github.com/serverless/serverless

has allayed a lot of my gripes with lambda.

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.

Feel free to disagree with me:

In my mind, serverless functions are akin to database triggers: they do one thing and one thing only, in response to an event.

If one tries to make a serverless function do too much, it tends to get somewhat difficult to debug.

If one stays within complexity boundaries analogous to that of a database trigger, things may be more manageable.

Just as you would not abuse a database trigger to do wacky things, it may be a good idea to not overextend serverless functions.

We use it for all production workloads together with API Gateway in the frontend, AWS Batch and RDS in the backend.

Reply on news.ycombinator.com