Nexedi clients are mainly large companies and governments looking for scalable enterprise solutions such as ERP, CRM, DMS, data lake, big data cloud, etc.
https://beta.rapid.space/ is a high performance, low cost cloud infrastructure that provides:
It is available in China in addition to Europe. It is based on SlapOS and Open Compute Project (OCP) hardware, the same as the one used by Facebook.
re6st was created to fix problems of current Internet through an IPv6 overlay network.
The probability of connectivity fault is about 1% in Europe/USA and 10% inside China - too much for industrial applications.
Without re6st, SlapOS (or any distributed container system) can not work. If one has to deploy 100 orchestrated services over a network of edge nodes with a 1% probability of faulty routes, the overall probability of failure quickly becomes too close to 100%. There is therefore no way to deploy edge without fixing the Internet first.
re6st routing provides one solution to that. re6st is available in China (license: 中华人民共和国增值电信业务经营许可证：沪A1-20140091). Nexedi has the right to provide global low latency high resiliency IPv6 network for IoT (http://www.grandnet.cn/).
In addition to re6st, we use buffering to that we do not lose data sent by edge nodes (gateways or sensors) in case of application server failure for example fluentd.
Both re6st and fluentd are used in all IoT deployments done by Nexedi and based on SlapOS.
So, we used buildout (http://docs.buildout.org/en/latest/) as the base for our service descriptor language and ERP5 to keep track of "service lifecycle" after we found out that any edge or cloud system can be made of two components: a devops and an ERP (see "SlapOS: SlapOS: A Multi-Purpose Distributed Cloud Operating System Based on an ERP Billing Model" https://ieeexplore.ieee.org/document/6009348).
For resiliency, we based all our design on the idea that resiliency must be implemented with software and should rely on redundant infrastructure on redundant sites with redundant suppliers. However each site or hardware does not need to be redundant.
This approach was quite successful. By sticking to a very simple and minimal architecture, we could achieve with a small budget what huge community projects such as OpenStack still fail to achieve after 10 years. And we could do much more, because our architecture was more generic.