SlapOS stands for Simple Language for Accounting and Provisioning Operating System. It is a general purpose operating system usable on distributed POSIX infrastructures (Linux, xBSD) to provide and manage software services without the need for virtualization. SlapOS is published as Free Software under fairly permissive licensing.

SlapOS is useful for anyone requiring to run more than 20 instances of the same application or who needs to operate more than 10 servers. SlapOS is a possible solution for a variety of scenarios such as:

• public or private cloud computing infrastructure (IaaS, PaaS, SaaS, DraaS)
• hyperconverged infrastructure (virtualization of compute, storage and network)
• edge computing infrastructure (CDN, IoT gateway, AI offloading, cache, buffering)
• 4G/5G network management system (eNodeB, locale core network)
• resilient low latency network as a service (IPv4, IPv6, RINA)
• tactical cloud bubble

On a simplified level, SlapOS operates a network of machines. A Master (COMP-ROOT) contains a catalog of software releases which are installed and instantiated on network nodes (COMP-0,1,2,3). The master tracks service consumption and provides means for managing and invoicing the usage of specific services.

Unlike Unix in which "everything is a file", SlapOS can be described as a cloud operating system in which "everything is a process". If one has to manage thousands of servers with thousands of processes, hundreds of different applications in multiple releases or versions, SlapOS is useful by making the whole management process well specified, automated and controllable.

By writing a simple recipe using a software called Buildout, SlapOS can help turn any software application (open source or proprietary) into a solid SaaS or PaaS platform. Besides instance provisioning and monitoring, SlapOS also provides a Dashboard to handle user registration, support requests, invoicing and payments.

The philosophy of SlapOS was created by ViFiB, one of the first providers of "Distributed Cloud Computing".

The first idea of SlapOS is to consider that "everything is a process" and that a system is made up of processes exchanging information through network services based on various protocols (HTTP, memcached, etc).

The second idea of SlapOS is that the best way to create a reliable and efficient cloud computing system is to follow the original principles of the Internet: distribution and simplicity. Rather than trying to build reliable data centers with redundant network, power supply, staff, etc. in order to reach 99.999% availability, SlapOS aggregates unreliable hosting, such as home cloud or low cost dedicated servers and, by combining them, reaches a reliability of 99.999%. SlapOS is in reality much more reliable than traditional approaches to cloud operation because, by selecting independent sources, SlapOS can mitigate the risk of major system outages due to electricity failures, political decisions, etc. Of course, SlapOS is and can also be used to operate traditional data centers more efficiently.

The third idea behind SlapOS is that to ensure redundancy, data replication or energy savings, any intelligent process should be implemented by the application itself rather than by the infrastructure. This is in line with the original ideas behind the Internet: a "stupid" network running clever applications. By taking into account usage or data specificities, optimal policies for redundancy and energy savings can be implemented.

After logging into the SlapOS Dashboard, a user can request new software services using the Services menu in the left hand panel.

The services section displays the list of instantiated services. These can be complete business applications (eg ERP5, Drupal, XWiki), well defined network services (eg. memcached, cloudooo, Frontend) which may be part of a Service Orientated Architecture (SOA), a virtual machine (eg KVM) or an instance of another IAAS provider (eg. Amazon EC2).

To instantiate a new service, click Add in the subheader.

This will load the list of available services products on the software catalog of Vifib. Select the service to be instantiated.

Once a service is selected, a software release (version) must also be selected. SlapOS is capable of providing multiple instances of the same application in multiple versions or releases (eg. users may wish to use MySQL 5.0 or MySQL 5.1, MariaDB or SkySQL).

There is no limitation in SlapOS in terms of number of versions of releases available for each application. This is very important for production systems which often require patching files or changing compilation options of the underlying base software. Here, SlapOS departs from traditional GNU/Linux distributions in the sense that it does not try to define what is a "standard MySQL" or "standard Java" or even a "standard Apache". Experience showed that minor, yet essential changes to any software are eventually required to build a scalable system on the Cloud. GNU/Linux distributions cannot be trusted beyond Linux kernel and core libraries for that purpose.

It was found for example that some GNU/Linux distributions add bugs to packaged software in the process of making it compliant with distribution guidelines. Bugs can sometimes lead to unit tests not passing anymore. Messages in the distribution bug tracker sometime state that there are no plans to fix this bug since there is no way to solve it in a way consistent with the distribution guidelines. This can make sense from the GNU/Linux distribution point of view but may be unacceptable to build a production system.

Before the service is requested and instantiated, a number of software specific configuration parameters can be provided. Manual selection of a network node will override the automatic allocation of the service by the SlapOS Master.

The request is triggered by clicking Proceed. Once the software has been installed in a computer partition of the chosen node and is ready to be used, its connection parameters will be published on a new entry in the Server List previously seen.

Note, that while the Vifib implementation of SlapOS does not use invoicing for software instances or consumption as they are only used internally, these features are trivial to integrate if required.

The SlapOS architecture uses two types of servers: SlapOS Master (COMP-ROOT) and SlapOS nodes (COMP-0,1,2,3) with the COMP-0 node having a special status as it is providing services to both the master node and other nodes on the network.

The SlapOS Master informs each node which software it should install and which instances of which software should be run. Each node tells the SlapOS Master how much resources were consumed by each instance of each software.

Based on the start dates and stop dates which represent the time series of execution frames of each application, and based on the resource usage of each application, the SlapOS Master can produce invoices for every user of SlapOS based on his personal usage.

The current architecture of SlapOS based on a single redundant Master node is designed to manage thousands of servers. Future versions of SlapOS may however rely on a distributed implementation of the SlapOS Master, too.

SlapOS nodes run a small kernel called the "SlapOS Kernel". This kernel consists of a minimal GNU/Linux distribution, the SlapGrid daemon, a Buildout environment for bootstrapping applications and supervisord to control running processes.

This current implementation of "SlapOS Kernel" was created using OpenSuSE and the SuSE Studio service and is small enough to fit on an USB key.

The SlapOS Master is also just a standard SlapOS node with ERP5 installed.

This ERP5 "Cloud Engine" is an extension of ERP5 open source ERP which provides, in addition to invoicing and financials, all the standard business processes required to operate an IaaS, SaaS or PaaS company. ERP5 Cloud Engine can be used standalone or in combination with other business applications.

The core scope of ERP5 Cloud Engine is to keep track of all available SlapOS nodes, to list all software products and releases which can be requested and define how they can be installed, to define which release of which application may be installed on which SlapOS node, to specify how a given application can be instantiated and to keep track of which instance is being run on which SlapOS node. The core scope of ERP5 Cloud Engine is also sometimes called "SlapGRID Cloud Engine".

The ERP5 Cloud Engine also implements the subscription process for users to register to SaaS, PaaS or IaaS, an e-commerce portal for users to order and access instances through the Web, a CRM interface to handle support requests as well as a complete financial system.

The ERP5 Cloud Engine can be interfaced to existing systems using standard interfaces based on standard protocols such as SyncML, REST, SOAP, XML-RPC, LDAP or MySQL. ERP5 Cloud Engine supports most SSO implementations, too.

After a SlapOS node is initially installed, a user may request an instance of a given (and available) software to be instantiated. This is done using so-called "recipes" and "Software Releases".

SlapOS already provides default recipes for many common softwares (MySQL, Apache, memcached, et al.). However, it is recommended for users to always create their own recipes with their own compilation options and specific build configuration. As an example, a recipe can be created for specific version of MediaWiki and another one for OS Commerce. Each recipe may embed its own version of Apache, MySQL, etc. with its own custom compilation options. This way, a recipe is self-contained and under the control of the recipe author.

A Software Release is defined as the url and revision number of a git repository which contains a collection of recipes required to build a complete software application. This repository is called buildout directory. Software Releases also define a signature in order to make sure that buildout directories which are downloaded contain the same files as those which are expected.

The process of installing the Software Release relies on two components of the SlapOS Kernel: SlapGRID and Buildout. SlapGRID requests the list of software which should be installed on a SlapOS node from the SlapOS Master, who returns the respective Software Releases to install. SLAPgrid downloads the buildout directory of the Software Release and runs the buildout command. The buildout command downloads all source code and dependencies required to compile the software application defined in the recipes, compiles all source code (using cache to accelerate compilation) and installs software application binaries, files and libraries in a subdirectory of /opt.

Once the requested applications are installed on a SlapOS node, it is possible to create so-called "Software Instances".

The concept of "Software Instance" refers to the idea that modern servers can easily run multiple independent processes of the same software. With IPv6, it is also quite trivial to associate hundreds of independent IP adresses to every server, for example one for each instance of each application. And because all applications share the same shared libraries, memory footprint overhead to run yet another instance of the same software is minimal, unlike what happens with virtual machines.

It is thus possible to run on a single SlapOS node more than 200 instances of the same software. In the case of the TioLive service (discontinued), 200 ERP5 open source ERP instances were run on a standard dual CPU server.

The easiest way to install SlapOS is the single line installer. The steps for setting up a SlapOS Master are described in installing the COMP-ROOT.

The first required network node COMP-0 can be setup using installing the COMP-0, with installing COMP-123 outlining the steps for "regular" network nodes which are not required for the minimum setup.

Creating recipes for SlapOS is also quite straightforward. In the above example, a memcached server is instantiated. In order to start this service, it is simpy required to generate a startup script, which uses the connection informations returned by the SlapOS Master.

The SLAP protocol itself if very easy to invoke using the SLAP library. In the above example, a new connection to the SlapOS Master is initialized and an existing computer partition object is instantiated. Then, a memcached server instance is requested and, once instantiated, can be accessed and used.

SlapOS also provides Slap console, an iPython notebook shell which allows to supply software and request instances through the terminal. In the above example an instance of a Frontend (Apache) Slave is requested.

SlapOS has been designed for maximum compatibility. The SlapOS default distribution already contains recipes for many NoSQL technologies, databases, runtimes and application servers. Recipes that do not exist are easy to derive from the thousands of existing community created buildout recipes.

Making your own contribution simply means copying ideas from others and adapting them to your needs. For example, creating a high performance LAMP recipe for SlapOS consists of reusing a couple of existing recipes for Apache, MySQL, Varnish, ha-proxy and combining them so that the PHP application can be distributed across multiple servers sharing two MySQL databases configured in redundant mode. Then increasing from 1 to 2 to 3 and then to 100 the number of Apache nodes which are instanciated on the SlapOS cloud is just a matter of changing a parameter of the recipe. SlapOS takes care of the rest.