If you are interested in trying out this type of serverless architecture for Slackbots, but don't want to deal with using AWS today, check out: https://hook.io

A few of our users have blogged about building SlackBots with hook.io. It's a great fit!

https://medium.com/bloc-posts/creating-slack-command-with-a-...

https://medium.com/@katyemoe/making-custom-slack-slash-comma...

Full disclosure: I built hook.io.

I don't understand. How does AWS or hook.io make the architecture "server-less." It just ends up that you don't control the server, but there still is one.

hook.io is a 100% open-source project: https://github.com/bigcompany/hook.io

You can run your own hook.io server anywhere. We even have a working Docker image, so it should be almost zero-configuration.

"serverless" refers to the fact that your applications don't each require their own backend servers. You build your applications to depend on the serverless service provided by AWS or hook.io

:-)

So it's basically a running your applications on a VM? I'm still not following the advantage.

If you are looking for portability, you could use docker. If you are looking for abstraction, you could use almost any high level language.

What is the benefit of doing it this way?

(I'm speaking about AWS Lambda because that's the only one I know)

These serverless architectures handle everything for running your app for you, and they go a mile further than application platforms like Heroku. You upload your code, which is only a collection of functions written in JavaScript/Java/Python. These functions have a single purpose: reply to HTTP requests. They can communicate with other services (AWS or not; e.g. databases) and do any kind of processing. Amazon gives you a HTTP endpoint and lets you build REST-like APIs that call these methods. When you get a call, AWS will run your function on one of their servers. Your code only runs when a request comes in, and if there are a lot of them, it just runs on multiple servers. You are billed for the time your functions run and the memory they use. Amazon does everything for you: scaling, cross-datacenter availability, networking, security.

The idea sounds groundbreaking (literally nothing to manage except application code), but in practice I have found Lambda + API Gateway (the product for piping HTTP requests to Lambda functions) both very hard to use, with a very poor UX. Also, one of the downsides of having to load functions before execution is that response times are bad (500ms+). However, if you have enough traffic, you may get reasonable performance when your service has "warmed up", thanks to caching.

I'll take a look at hook.io, but here's their product page: https://aws.amazon.com/lambda/details/ (I'd suggest you look at the pricing page too)

You don't have to manage scaling anymore. All you write is business logic and AWS allows you to run it at whatever load you need, without dealing about configuration, server restart, upgrades, provisioning, all the parts that lean more toward operations than development.

Lambda is more like CGI-in-the-cloud than applications in a VM.

Awesome, Localytics :) You are doing great work and you have also been super helpful in the Serverless Framework community. Thank you!

Yeah, this is "serverless" in the same way a shared php+apache hosting account is serverless. It's just using servers and services that someone else manages.

Lambdas are a bit more "serverless" than most things as they can be spun up anywhere and you're just coding to the entry method signature that passes you some request context.

I think we all understand that it's got to run somewhere, and I too sort of bristle at a marketing driven statement throwing around terms like serverless- but I am finding it to be a mental/verbal shortcut more and more these days.

If you mean to imply that your code will (likely) run with no local configuration state, all your local work will be ephemeral and will need to be pushed out to persistent storage like NAS/SAN, DB, etc, or that you'll need to raise events for others to do more work like sending messages on a queue or an RPC/API call to another end point- then yeah, I'll take that and be okay with it. If that is our shortcut I'm okay with using the term serverless when we all know darn well it's got to run somewhere.

Its just an abstraction though. And it falls apart and becomes full of implementation details when the actual fact that its running on a warmed up or cold server causes issues

It is, but once you agree on the context it provides, it can be a word that is useful when describing how you plan to deploy some section of code.

We use Lambdas for a bunch of different async work tasks like PDF generation and such. Warm or cold doesn't matter at all for us.

If you're trying the super 'serverless' approach of using AWS API services backed by Lambdas, then yeah, warm/cold will definitely matter.

When I think "serverless" I think this: http://unhosted.org/

That describes a model where a web paged is permanently cached in a browser's data. Effectively reducing the server to a binary distribution system.