The Serverless Revolution Has Stalled

Post by raverbashing » Tue, Oct 13, 2020, 2:10 AM UTC

nickjj wrote: 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…

Post by crehn » Tue, Oct 13, 2020, 2:11 AM UTC

mark242 wrote: post #247

crehn wrote: post #241

Earlier quoted context omitted.

And I’d argue the mere possibility of the server breaking at any time contributes to non-negligible amounts of sustained psychological stress.

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.

Post by lmm » Tue, Oct 13, 2020, 2:12 AM UTC

Aeolun wrote: post #96

superfrank wrote: post #47

Earlier quoted context omitted.

I'd add on top of that, that it provides even more value when volume is usually low and sparse, but unpredictable. If you have a server that can handle up to 100 requests at a time, but you're only getting one or two a day, you could probably save money by switching to serverless. On the flip side though, you're also a bit screwed if 1000 requests all come in at once, since, even if you have some autoscaling solution…

> Serverless provides a solution for that case as well, since you have almost unlimited resources. Not really, since it takes a few seconds to spin up all the serverless instances, so your app response becomes really erratic. Then you need some magic to deal with database connections from 1000 lambda functions. All of them use their own since they cannot pool.

Post by lovehashbrowns » Tue, Oct 13, 2020, 2:12 AM UTC

annoyingnoob wrote: post #253

lovehashbrowns wrote: post #156

Earlier quoted context omitted.

soc2 compliance for Lambdas happens through AWS https://aws.amazon.com/compliance/services-in-scope/ not through our team's engineers. So for example, if we have a service deployed in an EC2 instance, we have to update the instance(s) every month by a certain date. Sometimes, we have to update early if there is a severe security issue. We also have to manage things like security software that has to run on every inst…

I guess in places where I've worked we've had Ops folks that handled things like access controls, managing secrets, servers, network, etc. Usually in space rented in a commercial datacenter, where the datacenter handles power, cooling, physical security, and where the building has a diversity of internet providers. Its a team effort. In my opinion, software developers shouldn't be responsible for OS level patches, OS…

Post by tuananh » Tue, Oct 13, 2020, 2:13 AM UTC

k__ wrote: post #2

"Limited Programming Languages" AWS Lambda can run all programming languages via layers. Cloudflare Workers can run all programming languages that compile to WebAssembly. "Vendor Lock" True, but being locked into Kubetnetes isn't a cakewalk either. "Performance" Cold-starts aren't a thing for Cloudflare Workers and can be mitigated for AWS Lambda. AppSync and API Gateway don't even have them if you directly integrate…