SlapOS is an open-source management platform designed to automate the operation of large, commercial, distributed IT systems.
SlapOS is useful for:
- cloud infrastructure (IaaS, PaaS, SaaS);
- edge infrastructure (cloud resiliency, autonomous drones, industrial automation);
- vRAN infrastructure (public radio networks, plug-and-play private radio networks).
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.
Why...
Minimalism and encapsulation
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:
- the SlapOS Master which is essentially a shrunk-down ERP which keeps track of infrastructure resources and service requests;
- the SlapOS Node which is essentially a devops agent which automates the instantiation of service requests.
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:
- build (the binary code that will be executed)
- allocate (resources in the infrastructure)
- instantiate (a service with sufficient resources)
- configure (a service based on parameters provided by the user)
- orchestrate (a service by connecting it automatically to another service)
- monitor (the health of a service through an extensible list of counters and alarms)
- self-repair (a service by optimising its configuration or re-allocating it)
- recover from disaster (a service by restoring a backup on another infrastructure node)
- account (the resources used by a service that can not be allocated to another service)
- bill (the resources used by a service that must be charged to someone)
- track issues (of a service and how they were resolved)
- test (that new versions of a service satisfy all requirements before upgrading the infrastructure)
They are implemented in SlapOS using a single tool: buildout.
Why is it better?
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.
Why is it so different?
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:
- build: Packer
- allocate: Google Kubernetes
- instantiate: Google Kubernetes
- configure: Ansible Tower
- orchestrate: Google Kubernetes
- monitor: Zabbix
- self-repair: a collection of proprietary python scripts
- recover from disaster: a collection of proprietary python scripts
- account: a collection of proprietary python scripts
- bill: SAP
- track issues: Mantis
- test: Jenkins
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.
What is being tested?
SlapOS testing framework covers:
- build tests on different targets and OS
- unit tests
- integration tests
- deployment tests
- alarms tests
- scalability tests
- naming convention tests
- end-to-end system tests
- live tests
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.
Commercial aspects
SlapOS is supported by multiple companies:
- Nexedi SA (France) with offices in France, Brazil, Argentina and Bulgaria
- Nexedi KK (Japan)
- Nexedi GmbH (Germany)
- Nayu Technologies (China)
- Rapid.Space (France)
- Xunkongjian (China) with an office in Russia
24/7 support is thus possible. Global presence with multiple legal entities mitigates the risk of trade or travel restrictions.
Legal aspects
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.
References
Refer to SlapOS newcomer page: https://blog.rapid.space/rapidspace-SlapOS.Introduction.vRAN.Edge.Cloud