
Serverless Native Java Functions Using GraalVM and Fn Project - fnordsensei
https://medium.com/criciumadev/serverless-native-java-functions-using-graalvm-and-fn-project-c9b10a4a4859
======
jerven
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 ;)

------
ianamartin
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.

~~~
carimura
Hey ianamartin,

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].

[1] [https://github.com/fnproject/flow](https://github.com/fnproject/flow)

[2] [http://slack.fnproject.io](http://slack.fnproject.io)

[3]
[https://github.com/fnproject/fn/issues/995](https://github.com/fnproject/fn/issues/995)

[4] [https://github.com/fnproject/fn](https://github.com/fnproject/fn)

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

------
victor106
It would be awesome if Spring Boot can be made compatible with Graal. and
Truffle

~~~
syjer
There is a subset with spring-fu ([https://github.com/spring-projects/spring-
fu](https://github.com/spring-projects/spring-fu)). They are working to
support the native-image feature of graalvm ([https://github.com/spring-
projects/spring-fu/issues/29](https://github.com/spring-projects/spring-
fu/issues/29)).

