Not affiliated, other than by being based in the same town. I also chatted with one of the founders a year or so ago.
ben509 comment about our name makes sense. The network functions still using the state, we just decoupled it into a separate location to achieve elasticity and high resiliency. We just liked the name since its short and made us unique to some degree.
Our platform developed way beyond what you see in the paper. It is developed now into a microservice architecture using zookeeper and masos to handle state decoupling and other aspects in a much scalable and robust fashion.
As for RAMCloud, it is very interesting but the challenge that it is not robust enough so we had to hack into its code to make it more stable. But yea it is so fast.
If you are interested to learn more, please free to keep asking questions or contact us through our website www.beStateless.com
NFSv3 added TCP (and brought minimal network state) into the protocol.
NFSv4 rolled all the external stateful services (stat, mount, idmap) into the main protocol.
Bearing in mind this progression, are stateless services difficult to maintain in production, and will there be a strong tendency to reintroduce state?
You can't run NAT without tracking what device and port the return ports map to. So what they're doing is working out how to distribute that. And, naturally, mapping port numbers to devices is highly amenable to circular hashing.
They've also identified some algorithms that require only very transient state or whose "state" can be determined dynamically.
Load balancers, for instance, are inherently tolerant of errors, and they load balancing is well understood to perform better when you don't track load closely. If you send work randomly, it will pile up on some nodes, but if you ping two nodes at random to see who is less busy, that additional information is enough to balance the work.
I think the difference between these and NFS is that for NFS to do its job, it has to be fully implemented on the client to work. I would definitely anticipate people wanting to add additional features, but if those can be factored out as separate components, you limit the issue. And, further, if they can manage their state in a distributed fashion, the network components themselves would remain decoupled, and you still get the elasticity.