Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

291–300 of 670 posts

Re: The Serverless Revolution Has Stalled

#291
post #187
post #25

Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…

Couldn’t agree more, the dev experience was awful. You basically have to develop against public AWS services, my dev machine became a glorified terminal. They do seem to be iterating on the tooling quickly, but I wouldn’t use it again if I had a choice. Edit: CloudFormation was also painful for me, the docs were sparse and there were very few examples that helped me out.

> the docs were sparse

Over 5000 pages of documentation

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

> very few examples that helped me out

AWS provide an example for most common services, plus there are thousands of other community supplied examples out there.

https://github.com/awslabs/aws-cloudformation-templates

Re: The Serverless Revolution Has Stalled

#292
post #171

Earlier quoted context omitted.

I'm not really interested in having the 1,000th discussion about the definition of "serverless". The parent was wondering what the value of the paradigm is, so I provided a list of specific features that many companies consider valuable with serverless offerings.

I hope this "risk aversion" mindset starts to apply to code as well. Can't wait for codeless, zero code, nocode, whatever name it gets called... something where normal people can build their own ideas without having meaningless discussion about tdd, frameworks and etc, nor the need to maintain codebases, ci/cd and all the jazz

[deleted]

Re: The Serverless Revolution Has Stalled

#293
post #137

Earlier quoted context omitted.

But you forgot that always-on server it lives on. The idea behind serverless includes the fact that you don't pay for what you don't use. So if no requests are served, you owe nothing. Your FCGI solution shuts down idle copies, but keeps the server running...

I don't really understand serverless, but if it's running a process in response to a request, then of course there's still a server, because something received that request. FCGI has a server running. And serverless has a server running, as long as its listening for requests.

Serverless architectures rely on some sort of gateway run by their cloud provider as their always on listener which spins up a process for your function when needed.

Essentially it’s a collective pooling which is cheap enough that it can be offered for “free” to the entity creating a serverless workflow.

Re: The Serverless Revolution Has Stalled

#294

Earlier quoted context omitted.

Yes, this exactly. The fact that I can guarantee that my code is running, and have entire massive teams at Amazon whose literal job title is to keep my code running, it is such a freeing feeling. I might be able to delete rows from Dynamo from my code messing up, but Dynamo will never go offline.

This is so naive. Unless you’re just creating utilities all day long, at some point you’ll actually have a production service that people are using that needs to be monitored, even if it is build out of lambda functions. And unless you’ve run AWS vs colo at scale, you have no concept of the orders of magnitude cost savings on bandwidth (at 95th percentile billing vs per gig) and compute.

Nobody’s saying serverless makes monitoring unnecessary. But a serverless architecture gets rid of an entire category of bureaucracy and issues that can arise from dedicated servers.

Re: The Serverless Revolution Has Stalled

#295

Earlier quoted context omitted.

Yes, this exactly. The fact that I can guarantee that my code is running, and have entire massive teams at Amazon whose literal job title is to keep my code running, it is such a freeing feeling. I might be able to delete rows from Dynamo from my code messing up, but Dynamo will never go offline.

This is so naive. Unless you’re just creating utilities all day long, at some point you’ll actually have a production service that people are using that needs to be monitored, even if it is build out of lambda functions. And unless you’ve run AWS vs colo at scale, you have no concept of the orders of magnitude cost savings on bandwidth (at 95th percentile billing vs per gig) and compute.

I have run AWS vs colo at scale. For the cost of precisely 1 engineer fully loaded, I can have 500TB of bandwidth per month, every month. Guess what, it isn't going to take just 1 engineer to maintain your homegrown worldwide CDN.

Does it make sense for FAANG to run their own datacenters? Yes of course. Does it make sense for you? No. This is what I don't get about arguments for running a bunch of VPSs-- for literally any environment that isn't thousands of engineers, it is more cost effective to let someone manage your underlying infrastructure for you, and any workload at that scale, you aren't contracting with some random bare metal hosting shop.

Re: The Serverless Revolution Has Stalled

#296
post #137
post #72

Serverless computing refers to an architecture in which applications (or parts of applications) run on-demand within execution environments that are typically hosted remotely. Like CGI or FCGI programs! But with YAML! FCGI really is a "serverless" environment. Launches an application when called for. Starts more copies of the application if there are enough requests. Shuts down idle copies when not needed. Starts a f…

But you forgot that always-on server it lives on. The idea behind serverless includes the fact that you don't pay for what you don't use. So if no requests are served, you owe nothing. Your FCGI solution shuts down idle copies, but keeps the server running...

> But you forgot that always-on server it lives on.

A better comparison would be "Serverless" is "FCGI in shared environment"... if such a thing exists...

Re: The Serverless Revolution Has Stalled

#298

Earlier quoted context omitted.

I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to mak…

As a systems developer, comments like yours make me amazed at the state of web development. From the outside looking in, it seems like 10% code and 90% monkeying around with tooling and frameworks and stacks.

[deleted]

Re: The Serverless Revolution Has Stalled

#299

Earlier quoted context omitted.

I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to mak…

As a systems developer, comments like yours make me amazed at the state of web development. From the outside looking in, it seems like 10% code and 90% monkeying around with tooling and frameworks and stacks.

It’s still a very young ecosystem. Serverless hasn’t had its Rails moment (yet).

I don’t think it’s as bad as people make it out to be.

Re: The Serverless Revolution Has Stalled

#300

As someone on a two-man-team who runs a lot of little "utility" functions in AWS Lambda with the Serverless Framework[1] to support our DevOps / Build processes, it's been one of the most productive tools in my toolkit (after the initial learning curve, of course). It allows me to stand up a practically maintenance-free endpoint in a matter of hours (usually to glue separate services together): * Want to run a quick…

I totally agree with this. My only real complaint is managing these one off items. Team member 1 puts one on a VPC the other doesn’t, another team member ties one to RDS and doesn’t automate auth...etc.

It’s great but you have to put management of usage in place first.

Post reply on HN