6 ms·

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 a

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?

skywhopper 9y ago
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.
- methehack 9y ago
  Why?
  - skywhopper 9y ago
    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.
    - icholy 9y ago
      > Scaling is completely invisible and outside of your control isn't that the point?
    - munns 9y ago
      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_Studies 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
o_____________o 9y ago
I think you're raising more topographical/philosophical problems, but https://github.com/serverless/serverless https://github.com/serverless/serverless has allayed a lot of my gripes with lambda.
cle 9y ago
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.
mssnlayam 9y ago
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.
wenc 9y ago
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.
unkoman 9y ago
We use it for all production workloads together with API Gateway in the frontend, AWS Batch and RDS in the backend.

skywhopper 9y ago

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.

methehack 9y ago
Why?
- skywhopper 9y ago
  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.
  - icholy 9y ago
    > Scaling is completely invisible and outside of your control isn't that the point?
  - munns 9y ago
    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_Studies 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

o_____________o 9y ago

I think you're raising more topographical/philosophical problems, but https://github.com/serverless/serverless https://github.com/serverless/serverless has allayed a lot of my gripes with lambda.

cle 9y ago

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.

mssnlayam 9y ago

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.

wenc 9y ago

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.

unkoman 9y ago

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