
The stack we choose: Erlang, SmartOS, Clojure - Licenser
https://blog.project-fifo.net/the-stack-we-choose-erlang-smartos-clojure/
======
motiejus
I saw your presentation about project FiFo in Erlang User Conference 2014. I
asked you what does Joyent think about it, you said they're cool with it (gave
you a t-shirt?). At that time, however, Smart Data Center was not open source.

Do you still work on FiFo, even with SDC being open? What are the main its
selling points compared to SDC?

~~~
Licenser
Yes I absolutely still work on fifo, actually 0.7.0 is around the corner right
now and gets polished for release.

To the second question, I'll answer that from a 'out of the box' perspective
so things go not off the rails because 'when doing X/Y then you can also ...'
because as you pointed out both are now open source systems and with enough
effort you can make them do everything. Obviously I am a bit biased here, if
only for the reason that I know a lot more about FiFo then SDC but I'll try to
be as objective as I can. That said I'd really would like to hear what someone
with lots of experience with SDC and a bit of FiFo experience thoughts on this
are.

The first difference to me is the heritage, while today both are open source,
FiFo was born as a open source / community project and has taken this path
from the first day. SDC is an commercial product that was then open sourced,
which as Bryan pointed out in one of his talks is something really really
complicated.

The second point for me, and perhaps the biggest one, is resilience. FiFo is
build on the cloud premises of 'everything will fail', systems are redundant,
it is master less, leverages CRDT's to mitigate the eventual consistent data
model it uses. And that is something that wasn't added to FiFo but was part of
it's design from the start (when you heard my talk on the EUC you might
remember not always successfully ;). SDC uses a more traditional design, it
was build to run on a single server and now Joyent is adding failover and
replication to it. (I won't vouch for the correctness of this since it is hard
to say what the design was like pre open source but it looks like this is the
case from the outside).

The third advantage I see is that with fifo you can start with as little as
3GB as memory in a zone on your system then grow that system as you grow. You
have to chose a sensible number of v-nodes but pretty much going from 1 to 3
to 5 servers isn't a issue and thanks to the great work Basho did on riak_core
as simple as a single command. SDC comes with a own dedicated server as
deployment which makes it rather resource intensive on that front. (I don't
count the COOL images that run in a VM here).

Fourth, FiFo runs on vanilla SmartOS, you can not use it one day, decide you
want to give it a try and it will just pick up on your setup, and then toss it
away the next day and everything keeps running as if nothing ever happened.
SDC has special platform images and at least in the past it wasn't as simple
as not running the head node to get rid of SDC.

Tachyon, which will have it's full premier with 0.7.0 but is already available
as a separate package. Developed together with Lucera it is a monitoring
system for servers. Based on kstat to collect metrics and a special metric
database to handle the load it can handle second level resolutions for decent
installations. So that gives you historic usage and performance metrics on
every server and every zone in your system, which is I think unparalleled at
the moment at least at this resolution.

What we do with backups and in result the option of cold migration of VM's
(kudos to the LeoFS folks at that point) is something new which can be quite
interesting for some people.

Last but not least we have a dog as a mascot, which is just so much better ;).

------
tpg
Can somebody explain what project fifo actually does? Even after spending a
bit of time on their web site, I can't tell what problem it's meant to solve,
or what appropriate use cases might be.

Is it in the same general work-scheduling space as mesos? Kubernetes?

~~~
snw
It's a (pretty great!) cloud orchestration software. Think OpenStack,
CloudStack, SDC or an open-source AWS.

------
rasur
Interesting, but way too short. Could have gone into a little bit more detail.

~~~
Licenser
Anything particular that interests you? There is always room for a followup :)

~~~
rasur
Hmm, not specifically, but if I was being pushed, maybe a little bit more
about how you found the f/e with clojurescript/om.

------
ams6110
If I may just air a pet peeve: Why do projects name subsystems things like
"sniffle", "howl", "jingles" instead of something that gives a freaking clue
about what that system does?

OpenStack does the same thing with "cinder" and "nova" and "horizon" and
"neutron"

I guess it's trendy but what's with names that have no relation to function?
It really adds to the learning curve or ability for someone on the outside to
have a conversation about the system and understand in broad strokes what is
going on.

~~~
Licenser
Multiple reasons

1) It gets really complicated if every single server is named 'api-server',
even with this names we ran into name conflicts and had to re-name our
packages to fifo-...

2) Mnemonics, since all the names have a link to their task (jingles is an
exception here for historical reasons and will be deprecated with the next
release). FiFo's naming scheme is dog themed, howl is the service handling
API/HTTP and communications - a dog howling, communicating with others. Snarl
is the rights management server, think a guard dog snarling at new person.
Sniffle is the business logic server, 'sniffing' all things out and
understanding them.

3) As a developper I am spending hours a day in the code, and some of them can
be really frustrating, having to deal with snarl doing something wired is a
lot more pleasant then dealing with generic-aaa-server doing something wired,
at least reading the name makes me smile every time.

------
aerovistae
Can anyone tell me what libzdoor is? They list it among other C libraries in
this article, but googling it I couldn't find any information about it. Even
the github repo has no README. Very unusual not to be able to find info about
a library, don't think it's ever happened to me before!

~~~
Licenser
libzdoor is an extension of libdoor[1] done by Joyent. It is focusing on using
doors to bridge the barrier between none global zone and global zone. Handling
zone events such as boot, shutdown, deletion. It is used in a the sshd plugin
that allows a process in the global zone to manage ssh keys (and ssh key
access) into zones.

[1]
[http://docs.oracle.com/cd/E23824_01/html/821-1464/libdoor-3l...](http://docs.oracle.com/cd/E23824_01/html/821-1464/libdoor-3lib.html)

~~~
aerovistae
Ah, thanks!

------
prdonahue
"After some rather unpleasant experiences with angular.js we ended up
rewriting the entire UI in ClojureScript / Om."

What specifically did you not like about AngularJS? And which version did you
use?

~~~
Licenser
The version was: Angular 1.2.4

The problems in no particular order and what improved:

* need to mess with gulp, and npm and their interaction vs. simply having to deal with lein * Dependency injection is a freaking mess to debug, and it lead to an incredible spaghetti code, clojure is quite clear about where which functions come from * The split between service, view, controller, scripts, styles, filters, directives is adding to the nice noodle feeling of it, Om/cljs does not force a layout so it's possible to arrange things as works for you * The dependency tree from npm was HUGE and included a bunch of unnecessary dependences which made it impossible to build the UI on our build servers so we had to include the 'compiled'/distribution results of it in the git repository. Lein projects split between development deps and production deps, so everything complies nicely and only what is needed for a release is included in it. * The split between HTML/JS/in-html-code/in-js-html is a mess. With CLJS/Om we have all code and layout in s-expressions. * 'Everything is a callback' is in my opinion a bad programming model, still some callbacks in CLJS but a lot less and the functional model of clojure makes it easier to deal with. * Mutable state is a pain to deal with. While not entirely gone this is a lot less of a issue to deal with since it's exceptionally clear of what is mutable and what not, in most cases you only have to worry about function parameters that's it.

------
nailer
> We use vanilla SmartOS, so that there is no dependency on FiFo for your
> running VM’s. You could just switch FiFo off and all your VM’s would
> continue to just work.

Please, just 'VMs'. There's no need for the apostrophe.

------
lectrick
> Some people find the syntax to be odd,

Perhaps he hasn't heard of Elixir and its fluid interop with Erlang libs?

~~~
eggy
Considering they are also using Clojure, LFE, or Lisp Flavored Erlang, might
be a better fit than Elixr with two Lisp languages. It too has seamless
interop with Erlang.

~~~
lectrick
That's a good point, and it does look like a cool project

