Ask HN: What are some practical uses for serverless?

> Setting up sidekiq + rails is basically a 10 minute operation.

Standing up a toy sidekiq + rails environment for experiments and for tiny projects is a 10 minute operation. Standing one up for large projects, taking care of deployment without breaks, restarting sidekiq without losing jobs, scaling the environment in reaction to traffic, etc. is a lot more work.

Also standing up sidekiq requires managing your backend storage. If you have time and skills for that, great. Otherwise, a managed service may be better.

On top of that, you need to actually deal with system maintenance for all of those components normally. Any managed solution (whether that's serverless, or effectively-close-to-serverless like heroku) may be a good idea.

Software engineering daily just had a pretty nice discussion on this topic on their last podcast

API/backend services, event-based processing (e.g. emails with csv files attached kicking off a workflow), integration (serverless shims for horrible third party APIs), etc.

especially for workflows, lambdas and step functions are very interesting.

I prefer to think of serverless as: events triggering backend processes without needing a user interface.

A very simple example would be receiving emails to a helpdesk address, extracting pertinent information, looking up the user's priority and their system's details, reformatting the information and posting to a helpdesk system's queue.

You have to remember that the term "serverless" is a misnomer, you are using the provider's servers and infrastructure on a pay-as-you-go basis -- with a significant markup. Of course, that markup is the value of you not having to configure, administer, allocate servers, processes, etc on your own.

Serverless, like most IT, is well suited to some use-cases and not to others. It takes skill and experience to design the optimal solution for any given requirement.

Django you say?

Check out Zappa. If your mind isn't blown after you start to grok what it can do, comment here and we can go through it together. It's very cool.

I also thought I'd never use it. At some point I realized that Amazon's free tier allows me to execute some minor periodic tasks (like hourly site monitoring, verification that backups have been performed, an easy way to send notifications to myself).

This way, the deployment issue of an application and its maintenance kind of goes away. It's also free, meaning I don't have to spend any more money or pack the code in another server.

As I like to joke, I am a simple liberal arts major...with about 24 years on/off Wall Street. Have been an intermediate user of R seemingly forever. While I find node.js painful, early days still, the capabilities that I have and will have in the near future to improve my Shanghai based professional services business speaks to the power of the technology/framework, whatever you want to call it. Working on a Hugo website and then will move to microservices offerings to clients both as lead generators and new service offerings. I am psyched.

Queuing works great when you have mostly constant load. Take image resizing, if you size a queue system to handle resizing 10k/images a day it will fall over on the day you get a million. If you use serverless it might cost a few extra bucks but you will not have a capacity problem.

The million at once thing happens more often then you think, take the case where a website gets a new logo. Now you have to redo the watermark on all the images. Or maybe you want to convert your jpg to webp.

You can also use lambdas to process your images on-the-fly as clients request them. We use both pre-process and on-the-fly depending on if we need hashes ahead of time.

Apex Ping is a great example.

It's not there yet (so, admittedly not a particularly practical answer to your question) but what I envision it to be in the future is an expansion of the "functions as a service" paradigm: Deploying functions and building blocks without having to worry about plumbing, infrastructure and cross-cutting concerns such as security or logging.

Serverless is a misnomer; what’s important is that it’s provisionless.

That means you won’t have to preallocate (and pay for) resources that will go unused during non-peak load. It enables automatic scaling.

There are plenty of “serverless” offerings for computation, but very few for databases. Without the later, I don’t think it has much value.