Most cloud services could be built by combining an open source / Free Software (eg. MariaDB) together with a service lifecycle automation (SLM) platform (eg. SlapOS). With one notable exception, this goal has not yet been reached by the Open Source / Free Software community because most projects are still focusing on some kind of virtualisation (eg. virtual machines, containers) or orchestration (eg. Kuberneres) which only represent 10% to 20% of what is necessary to implement a public cloud service.

This may leave SlapOS as the only open source / Free Software project that could possibly match leading public cloud services (AWS, Azure, Alicloud), as the following comparison table highlights:

Nexedi stack: less is more

Nexedi develops and operates complex, scalable applications with less than 15 software: the Nexedi Freee Software stack.

Out of those 15 software, developers actually focus on four of them:

• ERP5 for enterprise records management (including CRM, MRP, MES)
• OfficeJS for Progressive Web Application (PWA) development;
• SlapOS for IT infrastructure automation (on the cloud, at the edge or in the workshop);
• Wendelin for data collection and processing (including AI and conversion).

Since both SlapOS, Wendelin and OfficeJS are just variations of ERP5, Nexedi developers actually only need to learn a single framework (ERP5) and a single language (python). By relying on less tools, Nexedi developers have more time to learn ERP5 in depth. They can reuse their ERP5 knowledge with SlapOS and Wendelin. And thanks to the huge size of python library, most problems that are not already covered by ERP5, SlapOS, Wendelin or OfficeJS can be solved quickly.

AWS vs. Rapid.Space

Amazon AWS provides more than 200 cloud services.

The table below provides a comparison between Amazon AWS cloud services and technologies of the Nexedi Free Software stack which can be used to build simlar services deployed with SlapOS on Rapid.Space high performance, low cost cloud platform. For each AWS category and product,  we provide a possible alternative in Nexedi Free Software stack either as a SlapOS profile (server based) or as Progressive Web App (browser based). We also provide open source / Free Software alternatives we are aware of. 

Missing services

45 features out of the 209 AWS services are not yet covered by the combination of Nexedi stack and Rapid.Space. About 75% of AWS services are thus already covered by Nexedi stack and Rapid.Space, as long as developers accept to adopt Nexedi's tools:

• python on the backend (incl. C/C++/FORTRAN based libraries);
• buildout for cloud automation scripting;
• javascript on the HTML5 frontend;

Out of the 45 missing services, Nexedi does not intend to cover 3 of them:

• blockchain (2): because it has no practical use and can not scale (due to CAP theorem);
• quantum computing (1): because efficient qubit I/O can not exist with the levels of energy available on earth (due Maxwell's demon throught experiment).

12 features are actually already covered through existing Free Software that has not yet been integrated into SlapOS appstore.

Overall, only 30 services (less than 15%) are missing, mainly in relation to:

• Threat detection;
• AI models powered by private or secret datasets;
• Windows/VMWare compatibility.

Based on this analysis, future SlapOS R&D should consider how to encapsulate threat detection into the core of SlapOS design in a cost efficient manner.

Key differences

Nexedi stack focuses on reliability and simplicity. Traditional vendors may prefer to focus on ease of sales, ease of adoption (which often relates to fashion) and complexity (which some executives analyse as completeness). In the context of the previous comparison with AWS stack, one should keep in mind that Nexedi may rely on quite different approaches:

• SlapOS nano-containers instead of Linux name-space based containers;
• content-centric APIs instead of event-centric APIs;
• libraries rather than APIs;
• less is more rather than more and more.

Even though the end-result may be the same, the way it is achieved may be different.

For example, Nexedi considers that Linux name-space based containers are not stable enough for production and are not portable among different hosts with different distribution due to the kernel ABI mismatch problem [RD]. This is why we use SlapOS nano-containers which simply consist of running processes on a POSIX system with an unpriviledged user rather than with the root user. In terms of isolation, it makes no difference. In terms of security, it brings one benefit: some bad code which implies running a process as superuser has to be fixed. In terms of portability, it is superior: the same approach can be applied to FreeBSD or even possibly to embedded OS such as NuttX. It is also more reliable (no ABI mismatch risk) and simpler (no need to add the namespace layer). Yet, the current fashion in 2019 is to use containers, even though reliability problems are now acknowledged [RD] and fashion is fading away [RD].

We prefer in Nexedi to have a single SDK called JIO [RD] and develop all our code based on this SDK and its minimalist API. This API creates a unified abstraction of the world as a repository of contents. Each content has a precise schema, usually a JSON schema. Interacting with services is thus achieved with JIO in the same way as one would interact with a database or a filesystem but with some asynchronism and a wider range of possible operations or data types. Through JIO, we have eliminated most uses of event-based programming. We also stopped defining yet another API for each new problem that needs to be solved. Instead, we rather focus on defining yet another JSON content schema for each new problem that needs to be solved. We also made our code backend-independent and thus portable from one cloud to another in this way.

The difference between a content-based approach and an event-based approach is idempotence, that is the ability for a system to self-recover by repeating a process. Content-based approaches are idempotent by default whereas event-based approaches require extra processes which developers often forget to code. This is similar to the difference between declarative programming and imperative programming. In a distributed infrastructure with thousands of interconnected device, the risk of events is that they are sometimes lost. The advantage of content is that in case it was not accessed at some point, it can always be recovered later, which results in a much more resilient system. The idea of content-centric APIs is not new. It was deployed in military and aerospace in the 1990s with the Data Distribution Service (DDS) protocol [RD]. It can also be found in the OPC-UA PubSub protocol which release lead to an accelerated adoption of OPC-UA standard for Industry 4.0 [RD]. The importance of a concent-centric approach has been well understood in the industry for quite a long time (ex. process control of Japanese chemical factories in the 1990s based on a whiteboard architecture) and in telecommunication research with CCNx [RD]. This is why nearly all software in Nexedi are either content-centric or moving in that direction.

Nexedi also prefers to use a single integrated service (eg. Wendelin) with a single API and different libraries (eg. scikit-learn, scikit-image) to solve different problems (eg. machine learning, image analysis), rather than create multiple independent services with multiple APIs. Nexedi's direction is thus to base modularity on libraries rather than on services or APIs. We consider in particular that the approach called "serverless" can only lead to technical disasters if the meaning of "serverless" is to host on a cloud service hundreds of "single function code" which mutually interact by calling eachother asynchronously through the cloud service infrastructure. That form of "severless" approach can be close to impossible to debug, especially if one starts with a function, adds another which calls the first one and so forth until hundreds of functions are hosted and mutually call eachother asynchronously with no clear structure. It can also lead to latency issues if connection pooling has not be designed into the "serverless" infrastructure. Yet, if "serverless" means hosting code on the cloud and editing code through the Web on a system which is managed by the cloud provider, this is something that Nexedi has been doing since 2001. It has many advantages, especially in terms of efficiency and quality assurance.

Nexedi services which are equivalent to AWS are based on a much smaller list of base services (Wendelin, ERP5, etc.) yet cover a similar scope. It looks like less impressive to an executive than a list of more and more services. It has however the advantage of reducing the learning curve and simplifying integration. One developer can learn a single technology and use it for many different purpose. Less things to learn, more applications.

References

• Free Software and Open Hardware for Industrial Automation
• Top 10 Best Network Inventory Software for Linux
• Top 30 most popular AWS products (thanks to S. Fermigier)