
IncludeOS roadmap: tiny Node.js-style web services in highly efficient C++ - ingve
https://github.com/hioa-cs/IncludeOS/wiki/Roadmap
======
kator
I love watching the pendulum swing back and forth in tech.

From mainframes to pc's ... to thin clients ... to server rendered HTML ... to
client side frameworks ... to microservices

I'm sure I could come up with more examples. I was just thinking of re-
architecting a heavy apache web head app into unikernel super light micro
services. It just makes me chuckle as we swing back and forth and try to find
the right balance. Each generation sort of saying "Hey wait there's a CPU over
here on this side of the diagram and it could do X/Y/Z".

Recently I've been working on Raspberry Pi's so much that when I logged into a
nice medium sized EC2 instance I was "shocked at how responsive these are".
LOL. I started on machines with 4k of memory and built systems that consume TB
of ram across many nodes and data centers. It's fun to go back to my roots
trying to cram something into an ESP8266 nodemcu device and thinking about how
long I can run it on a LiPo battery. I think this back and forth is good for
us, but I encourage everyone to spend time on micro devices to remember just
how simple you can solve a problem when confronted with the reality of 20k of
ram and 4M of flash storage.

------
Gladdyu
I wrote something similar a while ago, combining the easy-to-use asynchronous
programming model of Node.js with the speed of C++.

[http://gladdy.github.io/c++/2015/07/26/NodeDemystified-
pt1.h...](http://gladdy.github.io/c++/2015/07/26/NodeDemystified-pt1.html)

source code:
[https://github.com/Gladdy/Mininode](https://github.com/Gladdy/Mininode)

~~~
nickpsecurity
The example looks really clean. Amazing how far modern C++ has gotten in that
area.

~~~
pcwalton
Losing memory safety is a pretty big deal though.

In particular, the capturing semantics with [&] are going to result in a big
surprise (use after free) if you try to close over and capture variables like
you do with node.js.

~~~
nickpsecurity
Got no expertise there. I always assume it with C or anything derived from it.
But C++ commenters here keep telling me modern C++ and its libraries have all
kinds of ways to prevent common issues with memory. They've demonstrated a
few. So, I'd be curious to see a comparison of what happened in practice
between the two.

That said, typical C++ applications might be easier to get right than
Javascript runtimes, JIT's, or whatever. A lot of eyes go into the JS
foundations but so do a lot of complexity and problems.

~~~
pjmlp
To add my input to pcwalton.

It is true that modern C++ with the proper tools can mitigate many of the
issues that come from C heritage.

The sad reality is that despite the tools that C++ offers for memory safety,
the majority of enterprise developers don't buy into them and the code looks
more like C with classes than anything else.

If you look at CppCon 2015 when Herb was presenting the Core Guidelines and
the new VSC++ static analyzers, only 1% of the audience said they ever used
one.

~~~
seren
From what I have seen, the issue is that in big risk-adverse entreprise, the
mentality of "don't change anything if it works" goes a bit too far.

I feel a bit ashamed, but to give you some rough idea of the age of the
toolchain, the c++ compiler we are using does not even support namespace. We
are slowly fazing out old platforms but this is really a long drawn struggle.
Basically you have to wait that the underlying HW is not produced anymore for
10 years, before maybe thinking the SW side should be upgraded.

I would be very eager to use some nice feature of Cpp11 but it won't be in
this company...

~~~
pjmlp
No reason to be ashamed, I have seen many companies that only use platform
SDKs (e.g. aC++ on HP-UX) and IT has the last word over what tools are allowed
on dev machines.

However the situation is no different in other languages.

I am aware of some companies still using Java 5 on production, just to cite
one example.

~~~
nickpsecurity
I know one major retailer whose terminals are all a DOS variant whose sales
ended in 1999 and whose inventory is hard-tied to SCO UNIX. Got future-proof
written all over those. ;)

Note: Many key operations, including the backend, are on AS/400 and mainframe.
Much wiser choices. Needless to say, the employees tell me _that part_ never
goes down.

------
hanez
Sounds a little bit crazy to me at first but when thinking about it, it is a
nice idea.

May you should take a look at Rump Kernels and build your stuff on top. Then
you do not need to implement the OS stuff - It's done already. May I am wrong
but it seems to be a similiar idea but the following project is currently at
the OS level only but some applications like ngnix are working already. I was
very confused when I first read about Rump Kernels and after reading a while
and watching some conference talks a lot of stuff made sense to me even if I
do not understand in detail what they are doing.

[http://rumpkernel.org/](http://rumpkernel.org/)

[https://github.com/rumpkernel](https://github.com/rumpkernel)

~~~
semisight
This seems more like MirageOS/Ling than a rumpkernel. From what I remember,
rumpkernels are more general, at the cost of being less "unikernel-y" (i.e.
lean and fast). I agree that it would be easier and faster to use a rumpkernel
if the intention is use in production _soon_.

I can't tell if this is a research project, or intended to be production
quality at some point.

~~~
vive-la-liberte
>I can't tell if this is a research project, or intended to be production
quality at some point.

Found this on their website [1]:

>IncludeOS is the result of a research project at Oslo and Akershus University
College of Applied Science (hioa.no)

>IncludeOS is not production ready - but we're working hard to become so.

[1]: [http://www.includeos.org/](http://www.includeos.org/)

~~~
semisight
Thanks, I didn't catch that. I'll have to make some time to play with this,
especially once it gets further along.

------
std_throwaway
At first it seemed strange that a Node.js-replacement needs a full IP stack
including DHCP.

As far as I understood this, they are building a whole operating system to be
run in a VM like QEMU which then acts like a Node.js-instance - except that
it's programmed in C++ and linked as one whole exeutable which also is a
complete OS.

I wonder how this compares to Docker or Sandstorm where the existing kernel
API is used in a virtualized container instead of emulating a whole machine.

~~~
kentonv
> I wonder how this compares to Docker or Sandstorm where the existing kernel
> API is used in a virtualized container instead of emulating a whole machine.

Short answer is probably: Better at security, but less efficient.

Xen bugs notwithstanding, the VM boundary has a better security record than
the kernel API boundary. (Though Sandstorm -- my project -- has been pretty
successful at dodging kernel bugs through aggressive attack surface
reduction.)

The problem with VMs is that they're heavy-weight. The hardware interfaces
were never intended to be a clean abstraction boundary between software. For
example, it's tricky to reclaim unused RAM back from a VM, because within the
VM the guest would by default assume it has a fixed amount of RAM that is
exclusive to it. Communication probably has to happen in the form of network
packets, requiring setting up and traversing a whole IP network stack in the
guest, which is a lot more expensive (in both CPU time and memory use) than
pipes, unix sockets, or shared memory would be.

However, if you're designing a kernel specifically for use in a VM, you can
probably do better on these things, e.g. you can define some virtual hardware
interface by which the kernel marks RAM pages unused so that the host can take
them back, or you can define a cleaner communication interface. But as you
define these interfaces, your "virtual hardware API" ends up looking more and
more like a kernel API -- and has greater risk of security bugs.

So one way (containers) you start out with a wide interface and high
efficiency but a large attack surface, and you try to narrow the interface to
improve security. The other way (VMs) you start with a narrow but inefficient
interface which you try to widen to improve performance.

Eventually they will probably converge.

------
alfanick
I never been fun of Node.js (neither the hype of writting server-side in awful
JS), so sometime ago I've written [https://github.com/alfanick/rest-
cpp](https://github.com/alfanick/rest-cpp) \- "tiny Rails-style web services
in highly efficient C++" ;) Code has not been updating for some time, but it
is near production-ready.

------
kentonv
I like this idea, but I don't understand describing it as "node.js-style". I
guess they think of Node as being a particularly ideal platform for
implementing "microservices", but honestly I don't think there's any
particular property of Node.js itself that makes it microservice-friendly. To
me "Node.js" simply means "server-side Javascript", which obviously this isn't
(it's C++).

~~~
rileymat1
ASP has had server-side "Javascript" for years. The magic sauce in Node.js is
the combination of async, JS, and package management.

------
smithclay
If you're interested in IncludeOS, runtime.js is also worth checking out:
[http://runtimejs.org/](http://runtimejs.org/)

------
ilaksh
I thought web assembly was going to be the main part of Node++.

Anyway I would look into Nim or Go if you want a more efficient webserver.

------
jdc
Anyone know how this compares to OSv?

------
BrainInAJar
So... back to CGI programming then. Cool.

------
TheRubyist
Just use Rust....

