The stack we choose: Erlang, SmartOS, Clojure
blog.project-fifo.net
blog.project-fifo.net
Do you still work on FiFo, even with SDC being open? What are the main its selling points compared to SDC?
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 ;).
Is it in the same general work-scheduling space as mesos? Kubernetes?
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.
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.
[1] http://docs.oracle.com/cd/E23824_01/html/821-1464/libdoor-3l...
What specifically did you not like about AngularJS? And which version did you use?
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.
Please, just 'VMs'. There's no need for the apostrophe.
Perhaps he hasn't heard of Elixir and its fluid interop with Erlang libs?