3 ms·
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
by _Marak_ 11y ago
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-hook-io-fe4d2bb7ffd2#.nw2vu7a9i https://medium.com/bloc-posts/creating-slack-command-with-a-...
https://medium.com/@katyemoe/making-custom-slack-slash-commands-with-hook-io-93ba70daf681#.d8v40byi7 https://medium.com/@katyemoe/making-custom-slack-slash-comma...
Full disclosure: I built hook.io.
- gravypod 11y agoI 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_ 11y agohook.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 11y agoSo 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 11y ago(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)
- rakoo 11y agoYou 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.