
Serverless Slackbots Powered by AWS - kddeisz
http://eng.localytics.com/serverless-slackbots-powered-by-aws/
======
_Marak_
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](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/bloc-posts/creating-slack-command-with-a-hook-
io-fe4d2bb7ffd2#.nw2vu7a9i)

[https://medium.com/@katyemoe/making-custom-slack-slash-
comma...](https://medium.com/@katyemoe/making-custom-slack-slash-commands-
with-hook-io-93ba70daf681#.d8v40byi7)

Full disclosure: I built hook.io.

~~~
gravypod
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.

~~~
_Marak_
hook.io is a 100% open-source project:
[https://github.com/bigcompany/hook.io](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

:-)

~~~
gravypod
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?

~~~
Artemis2
(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/](https://aws.amazon.com/lambda/details/)
(I'd suggest you look at the pricing page too)

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

------
frik
Reading "serverless" and "powered by AWS" in the same sentence. Click bait
headline. Amazon Lambda is a managed service, but not serverless:
[https://en.wikipedia.org/wiki/Amazon_Lambda](https://en.wikipedia.org/wiki/Amazon_Lambda)

~~~
Tiksi
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.

~~~
manyxcxi
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.

~~~
goldenkey
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

~~~
manyxcxi
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.

~~~
gravypod
When I think "serverless" I think this:
[http://unhosted.org/](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.

