Comment by kstrauser | Hacker News Reader

Comment by kstrauser | Hacker News Reader

Parent Full thread

An example of where serverless is lovely for us:

We run on AWS. We log lots of stuff to CloudWatch. CloudWatch allows you to scan for regexps (more or less) and send matching lines to a destination of your choosing. There are about 5-10 such matching events per day that we care about, and when they happen, we want an alert in a Slack channel (or email or text or PagerDuty or...).

Option A:

Stand up a server. Deploy a web service on it that accepts POSTs from CloudWatch and acts on them. Update the box as OS vulnerabilities come along. Pay 24/7 for a server that accepts 10 incoming requests per day.

Option B:

Write a plain Python function that takes the contents of a POST that's already been processed and has no other idea that it's living behind a web server. Drop it in Lambda. Pay for 1000ms of processing time per day.

I wouldn't want to run our entire stack on Lambda and friends, but for certain specific situations it's brilliant and I wouldn't want to give it up.

If you have spare capacity on a server you can probably squeeze in such functionality at no extra cost.

It's almost never about server capacity. It's usually about who's maintaining them, who controls the updates and versions of software on there, and which dept the server's billed to. All stuff that's reasonable for things of a certain size, but unreasonable for things too small or big to fit the process will.

Ah so it's serverless as a tool to work around corporate red tape, then ;)

I would love to see a study of how much IT spending in general is just for tools to work around corporate bureaucracy. I suspect the figure would be staggering.

A market that will never die!

But that makes operational expenses go up. For instance, now you have to tweak the Nginx config to support the service that normally lives on that machine and the new system. And you still have to write and maintain the web service driving it (which may not be hard, like a Flask app with a single route, but still more than zero). And you still have to maintain the server itself, which should involve regular OS updates and any work you have to do to automate deployment of the web service, unless you really like doing all that stuff by hand.

Or you can upload a single function definition to Lambda and let it do everything else.

Again, I wouldn't use Lambda for everything, but I'll gladly let it handle the stuff I won't want to bother with.

>But that makes operational expenses go up

On the other hand, you're probably all set up to do that already. It's no big deal. Introducing a new tech requires training, new deployment procedures, new documentation, etc., and now you probably have a one off component out there. There's a line somewhere, but if I were just adding a webhook for log events I'd throw it on a server I already have.

> ...at no extra cost

Complexity and dependency are costs too, and I would argue often more significant costs than the $30/month to run a server.

Reply on news.ycombinator.com