Graal and Truffle, just keeps on impressing me. Their language interoperability is just amazing. Using R, js and Java in one project has become a practical reality instead of an insanity ;)
I was just playing around with FN-project a couple weekends ago to look at self-hosted alternatives to AWS Lambda specifically and to try and wrap my head around serverless architectures in general, lest I go the path of the dinosaur because I don't see the point of the hot new technology.
A few things off the top of my head:
1. I still don't see the point of serverless for anything not completely trivial. The magic attraction here is that you write a function and serverless gives you the web endpoint for free. Okay cool. I guess for a landing page or a signup form or something that you don't really care about a lot, that's great. But in my experience, nothing that actually matters ever stays as simple and uncomplicated as that. If it's got legs, it's going to grow hairs, and you're going to want more from it. So you can keep adding functions piecemeal until you have an unmanageable mess that's worse than if you had a coherent web app, or you can start over and build one, which no team is going to get to do because this already works, so just pile on the debt and make it work.
FN-project docs themselves have an interesting tutorial on building serverless apps in ways that avoid this, and I think that's great that they give some guidance about how to do this in a sane way. Kudos for that team for understanding how unwieldy this can get. But I can't see why I would choose that architecture over traditional web apps. It seems like a lot of conceptual overhead, an enormous amount of redundancy (repeating your entire stack, requirements, etc.) for . . . I'm not sure what the win is here. It is definitely cool stuff to play with.
Some gotchas I found playing with it.
1. It's docker-based, so there are some things to look out for. Docker mangles your ip tables by default. So if you're on some commodity VPS trying this out, you'll have some kind of sane firewalling set up. Like, ufw default deny with port 22 open for SSH (key access only, no root login), and open for traffic on a 10.x.x.x network for VPN access to thinks like . . . docker and fn-project endpoints. So docker binds to 0.0.0.0 by default and also punches through your IP tables rules to expose traffic to the open world unless you tell it not to in the daemon config. So be careful with that.
2. It requires access to a docker registry, which you can host yourself as a docker container. Very convenient. But see above because unless you were expecting it, that registry is now open to the web on port 5000 even though ufw says it's not.
3. If you follow the guide in the docs, it doesn't work because fn-project chokes on docker registry hosts that have a colon in them, so default hosting on 10.x.x.x:5000 fails.
Run your registry on port 80 to get around it. Which means running it as sudo, and now you have additional security problems.
4. Add your private docker registry on your local machine and VPS as a whitelisted registry.
5. Now it works. And in spite of my grousing above, it's pretty goddamn cool.
I did the hello world examples and they worked and it was neat. I left the hello world examples open to the public instead of bound to the VPN iface by accident. This was a huge mistake. I still don't know exactly what happened, but a few days later, I got a bunch of emails from that VPS providers with abuse notices. Logged in to see the processor pegged and a bunch of processes I knew nothing about, and right about then the VPS provider suspended my account. I filed a ticket requesting logs from that VPS so I can track down exactly what happened and how. But at this moment, I'd use caution even exposing the web endpoints to the actual web.
I don't mean to dog on the project as a whole. It's very cool and impressive stuff, and when I get time, I'll try to engage the community about some of these issues and file bugs if appropriate.
Thanks for the interest in Fn! And all great points.. A few comments on your bullets:
Re: the point of serverless, there's more to the "magic attraction" than just an endpoint -- event-driven architectures are pretty common and can be triggered from all sorts of different patterns (iaas state changes, queues, data sources, etc). But you're right, eventually we ask more from our tech stack and we've got to evolve to make it more useful. We're thinking about this a bit with Fn Flow[1] -- how to build more complex serverless apps using future-like code.
Re: registries, thanks for the feedback. We're trying to make this a better experience and have some conversations going already to address[2]. Would love to chat -- hit us up in Slack[3] or tickets[4].
Thanks for the reply. I’m about to go on vacation, but I’ll be looking to get in touch after that. It’s a really cool project, and I’d like to pick the community’s brain for some things when I have time.
