Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

131–140 of 670 posts

Re: The Serverless Revolution Has Stalled

#132
post #67

You mean the permanent AWS lock-in revolution?

yes and no, the web app I'm working on at sqwok.im uses a proxy to point to a backend api that's built to be portable should the need ever arise (which I doubt would until it's in the status of "good problems to have").

it's true I would need to port the other bits outside the api that use native aws services.

how often do people change their infrastructure once things are working and they move onto building out a platform? I definitely have gone back and forth on the lock-in thing, but I feel like we're always locked into _something_ at the end of the day and it's more important to get something that works and prove it out on the business end.

Re: The Serverless Revolution Has Stalled

#133

An interesting rant to be sure, but what the author misses (in my opinion of course) that serverless isn't new, it just isn't recognized by a lot of programmers for what it is. Serverless computing is exactly mainframe computing. And by exactly I mean exactly. You see when I was taking CS classes for my degree students bought something called "kilocoreseconds" (kCs) and they are exactly what they sound like, they are…

A beautiful summary, compressing decades of experience into a pithy "Big Picture". Thank you for writing this, Chuck!

Re: The Serverless Revolution Has Stalled

#134

I am still on the serverless high, and I don't see it going away any time soon. For the large corporation that I work for, things like soc2, patching, server maintenance, etc. are a giant pain every single month. The quicker we switch as many things as possible to serverless the better. One of the services I converted over went a year and a half with absolutely no attention from our engineers. It was great seeing how…

How does moving to 'serverless' change the need for patching and other security maintenance? You've just moved it to a server owned by someone else. Sounds more like passing the buck rather than ensuring security.

Re: The Serverless Revolution Has Stalled

#135
post #96

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.

multiple seconds??

what platform?

Re: The Serverless Revolution Has Stalled

#136
I love how we're going back to PHP's original model (effectively stateless "functions") and giving it a hot new name. People have tried to convince me (unsuccessfully) that this is entirely different. Somehow.

If you really want serverless, install apache with mod_php and call it a day.

Re: The Serverless Revolution Has Stalled

#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...

Re: The Serverless Revolution Has Stalled

#138

Earlier quoted context omitted.

Developer experience for serverless is such a pain point, spot on. AWS SAM has tackled some of the IaC modeling problem (on top of CloudFormation which is a mature choice) and they've had a crack at the local iteration (invoke Lambda function or API Gateway locally with connectivity to cloud services). It's a little incomplete, missing some of the AWS IAM automation that makes local development smooth, environment ma…

Stackery is great. Doing serverless without an extensive toolset is impossible, which is sad.

Thanks! We like you too. <3 Stackery.

Re: The Serverless Revolution Has Stalled

#139

I love how we're going back to PHP's original model (effectively stateless "functions") and giving it a hot new name. People have tried to convince me (unsuccessfully) that this is entirely different. Somehow. If you really want serverless, install apache with mod_php and call it a day.

Ok, but do I have to update this host? Do I have to pay for it when it's not being used? How quickly can I quadruple my capacity?

Re: The Serverless Revolution Has Stalled

#140
post #80

Earlier quoted context omitted.

To be honest, the serverless environments I dealt with had worse deploy experience than plain servers. There's a bit of a ritual around deploying a lambda for example and it requires a specific packaging process. I can't easily use poetry for python projects there. I guess if we count fargate as serverless, it's much better for this use case.

While I am not that big fan of serverless projects (I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it) you can use poetry with lambda. I'm sure there are other ways of doing it, but the way I do it is using serverless framework (is a nodejs app) together with serverless-python-requirements plugin. The plugin understand poetry (make sure you do…

>(I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it)

I've created a whole photo sharing website in AWS Lambda, including a complete user accounts system (register, login, forgot password, email verification, profile photos, etc), social aspects, as well as other things like youtube video search and transcoding in the same system.

I also had to create my own Lambda build system because what was out there wasn't what I wanted. I wanted to be able to hit save on a file and have it repackage my Lambda on AWS (using a Lambda to create the lambda) including shared code in 'Layers'. Kind of a "live-reload" for Lambda. It's all working very efficiently.

This was a lot of effort though, but now that I've got a basic system I can extend it to any kind of website.

My photo sharing site for friends costs me about $0.25 every few months, and that is mostly/all the cost of storing gigabytes of photos on S3. No, it doesn't see a lot of traffic, and that's exactly why I chose Lambda to build this site on, because I don't have to run an EC2 instance for my photo sharing site 24/7 if nobody is using it. It's worked out exactly how I wanted, costs me practically nothing to run every year.

And, if I did build a system with a ton of active users, Lambda handles the scaling of that. Another reason I spent the time to create this build system and write all the code to handle user accounts, etc.

Post reply on HN