This presentation has four parts.

First, we introduce Rapid.Space, its founders and goals.

Second, we introduce the current state of Rapid.Space in terms infrastructure and scope.

We then explain the advantage of Rapid.Space compared to other cloud solutions.

In a fourth part, we introduce how Rapid.Space can help software developers to create a SaaS platform.

We propose in conclusion a 3-month plan to build a SaaS platform from existing software.

Rapid.Space may be a new name for you. We are going to present here who we are and what is our goals.

The goal of Rapid.Space is to provide sovereignty and trust through full reversibility. You may consider this goal as providing the kind of thing that companies such as Huawei, Palantir or AWS are not able to provide due a combination IP and legal policies.

This goal applies to every business which Rapid.Space is targetting.

Rapid.Space already provides a reversible cloud platform that can be used for public or private clouds. All components of this platform are open source, including the hardware, meaning that any customer can "clone" this platform on-premise or have it operated by a third party at no license cost.

Rapid.Space intends to provide a reversible big data platform with a scope similar to Palantir.  All components of this platform are open source, including the hardware, meaning that any customer can "clone" this platform on-premise or have it operated by a third party  at no license cost.

Rapid.Space intends to provide a reversible Edge computing platform which includes everything needed for Industry 4.0, including PLC, sensors, actuators. Again, all components are open source.

Rapid.Space intends to provide a reversible RAN platform which supports 4G/5G and can be used for both private and public networks. Most components are open source. Some components may be licensed source, meaning that any customer can "clone" this platform on-premise and audit its source code at some license cost.

Everything except VRAN in Rapid.Space is open source: software (SlapOS), hardware (OCP) and business procedures. VRAN is based on a licensed source stack which may eventually become open source at some point.

The Rapid.Space Handbook explains every aspect to build a Rapid.Space node and operate it, either as a public cloud or as a private cloud. This is a major difference with any other cloud provider which usually keep their operating process secret.

Rapid.Space is sovereign-by-design.

Servers of Rapid.Space are owned by national companies with no capital relation.

It is therefore impossible for one company owning Rapid.Space servers to "spy" another company's Rapid.Space servers. Only governments are allowed to "spy" servers in certain countries, whenever local legislation defines such possibility. However, governement in country A can not spy servers in country B in the case of Rapid.Space because there is no way for companies with no capital relation to instruct eachother anything.

The Rapid.Space company which orchestrates all servers worldwide does not have access to passwords or certificates which act as credential to servers. This approach is sometimes called "Zero-Knowledge". Whenever it is used, it is impossible for Rapid.Space centralised management platform to access servers in other countries or user information. 

Rapid.Space infrastructure is growing. It is now deployed in Europe and Asia. It will soon be deployed in USA.

Based on an early assessment, 85% of cloud services provided by Amazon AWS could actually be implemented with Rapid.Space low cost, high performance cloud and the vairous open source stacks such as SlapOS (75% services) and a few third party Free Software (10% services).

Rapid.Space is cheaper, ensures global delivery of services (including in China), is fully reversible (customers can quit Rapid.Space easily) and is open to all sorts of contribuions or adoptions of its open source technology. This is the advantage of being "Hyper Open".

All costs of Rapid.Space are public and described in "Business Model of a Low Cost Cloud Operator". The price of Rapid.Space is based on electricity, real estate, hardware amortisation, networking, operation management costs (software, human), hardware maintenance, financial costs. A 20% margin is added to cover all other risks related to the operation of a cloud service.

Anyone can contribute to Rapid.Space their own service in addition to the 70+ existing ones.

Anyone can contribute servers and datacenter to extend the worldwide coverage of Rapid.Space, as long as Rapid.Space procedures are respected.

Rapid.Space can be deployed on-premise too in a way that is typical of hybrid cloud.

It is also possible for one to operate a completely private infrastructure based, as Teralab does.

It is even possible to deploy Rapid.Space services on third-party public or private clouds (AWS, OVH, Azure, Alicloud, Hertzner, Huawei, VMWare, etc.) and benefit from all Rapid.Space services including its IPv6 backbone, CDN, IaaS, PaaS, etc. 

Basically, there is no blocker, no secret, no anti-competitive practice of any sort in Rapid.Space.

Currently, EU has the cheapest prices for cloud. Rapid.Space is only 30% to 60% cheaper compared to EU brands.

US and China have the most expensive prices. Rapid.Space is 2 to 20 times cheaper compared to US or China brands.

Let us now discuss how Rapid.Space can help someone become a SaaS provider.

We will now explain how to convert existing software into SaaS with a 3-month plan.

The firth month consists of creating a POC combining OM (SlapOS master) and devops (buildout). This first month ends with a demo.

Based on the demo, a follow-up plan is defined to reach a minimal viable product (MVP) in 2 months. 

One team finalises devops scripts. Another team finalises a dedicated OM platform.

The goal of the POC is to demonstrate the full system in the shortest possible time. This means that the shortest route will be considered and the full system will be simplified.

A standard SlapOS master will be deployed and configured with a sample home page, sample subscription form. A sample SlapOS node will be deployed on Rapid.Space.

The hard word is to write a first Software Release (SR) using buildout language. Anything not strictly required will be eliminated: load balancer, high availability, etc. The goal here is to create a "monolithic" version of the SR that can provision automatically "all-in-one" systems.

At the end of POC, it is possible to demonstrate the complete order and operation workflow: subscription, payment, provisionning, access, console, monitoring, support, invoicing.

Developers are then introduced with the buildout language and the WebRunner environment. We explain how the buildout profile was written and how we test it daily: integration test, deployment test.

A key concept in SlapOS is encapsulation: the same profile defines how to build, deploy, provision, monitor, account... and test.

Based on the results of POC1, we define a 2-month extension to reach a minimal viable product (MVP). Most of the work consists of extensing the SR with extra components, implement disaster recovery, high availability, improve monitoring, implement resource accounting that are the base of billing, extend deployment tests, encapsulate integration tests and ensure all code (source and binaries) are well cached.

All this can take from 2 month to 1 year depending on how much automation is expected and how difficult it is. This is why we suggest to focus on a 2-month plan and on MVP. Else, it may never end.

On the SlapOS Master side (OM), we only need to finish the web site (FAQ, HowTo, company information, product informaion), implement billing rules and ensure that email messages are clear enough for users.

Once the MVP is finished, it is possible to consider the next steps. The existing buildout profiles will have to be extended for sure, because proper monitoring depends on actual experience of commercial deployment. New buildout profiles will be created for new services. And the OM platform will probably receive extra features in relation to marketing or to user support automation.

Many companies that try to build SaaS fail for multiple reasons:

• they forget the primary role of the OM platform and are unable to automate operations;
• they use too many "best-of-breed" tools and are unable to stabilise integration;
• they use an unstable cloud platform such as...;
• lack of resilient networking to resolve internet congestions;
• they try to do too much.

Rapid.Space can help mitigate most risks except the last one. If one tries to do too much, project will fail.

Among the most difficults problems are: resiliency (automated disaster recovery) and high availability. Rather than trying to solve them all and at once, it is better to move step by step, with stable solutions that might be imperfect initialy, then extend them towards perfection.

First, ensure that there is a proven backup and restoration test, daily.

Then, implement initial features for high availability. In most modern systems, high availability is implemented at application level, not at system level. It can be implemented with a replicated database (SQL or NoSQL), by deploying the same service multiple times on different nodes, with a load-balancer, etc.

Always keep in mind that perfection in the field will always hit the imperfections of the Linux kernel, and the possible need to interrupt servers and services each time Linux kernel is upgraded.

One of the goals of the 3-month plan is to lower ambitions for the first MVP and ensure that a stable service can be commercialised as SaaS within that time frame. The purpose of the POC is to review the current state of software and define where to go next withing 2 months. 2 months are usually enough. However, if some software is extremely complex, more time may be needed either to simplify that software first (best solution) or to write very complex devops scripts (highest risk).