SlapOS is an open-source management platform designed to automate the operation of large, commercial, distributed IT systems.
SlapOS is useful for:
SlapOS is the only solution on the market for a small team of engineers to deliver within less than a year a commercial cloud, a commercial edge or a commercial vRAN infrastructure. Other solutions will require large teams, a long time or will eventually fail.
SlapOS design is based on minimalism and encapsulation which is unique on the market. It also adopts key design principles that exist in a few other solutions: self-hosting, self-convergence, recursivity, reflexivity, idempotence, zero-knowledge, portability, reproducibility and intelligence at the edge.
Minimalism means that there are fewer components to learn. SlapOS consists of only two components:
A service request can be used to order a virtual machine with a certain memory size, a database cluster with certain storage, a 5G gNodeB on certain frequencies connected to 12 radio units, a virtual programmable logical controller connected to dozens of couplers, etc.
Encapsulation means that the 12 facets of a service request can be implemented in one place. Those facets of a service are:
They are implemented in SlapOS using a single tool: buildout.
Because minimalism and encapsulation bring reproducibility and testability of the complete system on the laptop of every developer.
With SlapOS, a developer can simulate and test on his laptop, in a matter of minutes, all the facets and all the components of a large cloud, edge or vRAN infrastructure. This increases productivity and quality assurance by reducing regressions and accelerating the development cycle.
Most other systems will be based on the adoption of so-called "best of breed" solutions for every facet of a service. Here is a possible example:
Integrating so many solutions can be quite a challenge. Each of Google Kubernetes, Ansible Tower, Zabbix, SAP, Mantis and Jenkins have roughly the complexity of a small to large ERP. Integrating multiple ERPs is a well-known difficult problem that consumes a lot of human resources. Combining so many "best of breed" solutions might require a large team of engineers.
Moreover, achieving end-to-end system testing before a system upgrade requires first installing an infrastructure containing: Packer, Google Kubernetes, Ansible Tower, Zabbix, SAP, Mantis and Jenkins. This is more than 2 GB of software to install.
This will take days or weeks. It will require a lot of hardware resources, even if virtual machines (VMs) are used. The development cycle will be slowed down by the complexity of the environment. Most developers will thus stop trying to run regression tests in a consistent simulated environment. Most system upgrades will not be fully tested. Upgrades will lead to bugs and disasters due to the lack of testing.
With SlapOS, a small software called slapproxy - 3,000 lines of python code - is enough to run end-to-end system testing in a matter of minutes. This makes a huge difference: every developer can simulate and run at any time the whole system on his own laptop. Development cycles are accelerated. System upgrades can be fully tested before the upgrade. The risk of bugs and disaster at system upgrades is reduced.
SlapOS testing framework covers:
We are not aware of any other solution that can cover all those tests which are mandatory to test a cloud, an edge or a vRAN infrastructure.
SlapOS is supported by multiple companies:
24/7 support is thus possible. Global presence with multiple legal entities mitigates the risk of trade or travel restrictions.
SlapOS code tries not to depend and, mostly, does not depend on code owned by a US entity. This reduces the risk of foreign interference through US legislation (CLOUD act, FISA, FCPA, EO 12333).
SlapOS code ownership by a French entity does not pose a risk of foreign interference through French legislation because conditions for possible foreign interference that may exist in French Law require the prior existence of a physical telecommunication link between France and the target system. Unlike US Law, an on-premise system without remote access is out of the scope of French legislation.
SlapOS service provided by a Chinese entity may bear limited risks of foreign interference through Chinese legislation (Cybersecurity Law of the People's Republic of China). But to be practically effective, it is mandatory for Chinese entity or Chinese citizen to have remote access to the system. This risk can be easily mitigated, unlike with US Law, with an on-premise system without remote access and access to Chinese nationals.
Overall, the combination of open source and reduced dependency on US code drastically reduces the risk of foreign legal interference.
Refer to SlapOS newcomer page: https://blog.rapid.space/rapidspace-SlapOS.Introduction.vRAN.Edge.Cloud