Most Powerful Open Source ERP

Rapid.Space for SaaS Providers

Rapid.Space Hyper Open Cloud platform provides all essential OM features tp launch a SaaS service in less than 3 months.
  • Last Update:2020-10-15
  • Version:008
  • Language:en

Agenda

  • Rapid.Space
  • Current State
  • Rapid.Space Advantage
  • Rapid.Space for SaaS Providers
  • 3-month plan

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

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

Founders

Rapid.Space was founded in 2020 by Nexedi, Amarisoft and a few VIPs of the IT and telecom inudustries.

Nexedi brings its open source stack, in particular its billing platform, its edge-cloud platform and its big data platform, all open source.

Amarisoft brings its purely software defined 4G/5G stack which covers all aspects needed for commercial deployment, including SA, NSA, NBIoT, etc.

Goals

  • Sovereignty, trust and cost control through reversibility
  • A reversible alternative to conventional public clouds
  • A reversible alternative to Palantir platform
  • A reversible Edge platform for I4.0
  • A reversible converged RAN platform (4G/5G)

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.

Reversibility

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.

Sovereignty

  • France servers owned by French
  • Germany servers owned by Germans
  • Netherlands servers owned by Dutch
  • China servers owned by Chinese, etc.
  • Zero knowledge technology (no shared passwords or certificates)

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. 

Current State

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

rapid.space / rapidspace.cn

Rapid.Space has two web sites: https://rapid.space (available worldwide except mainland China) and https://rapidspace.cn (mainland China). This provides a global coverage.

The primary service of Rapid.Space is a high performance virtual private server (VPS) at reasonable cost, combined with a CDN infrastructure for accelerated web content delivery. 

Global Datacenters

Rapid.Space is available in Europe (France, Germany, Sweden, Nertherlands) and in China. It will soon be available in Taiwan and a second DC will open in China.

Global IPv6 Backbone

Rapid.Space IPv6 backbone is based on a hybrid mesh network which relies on hundreds of routers worldwide. Thanks to babel technology (RFC 6126), all sorts of congestions can be avoided. Latency can be minimized. 

Global CDN

Rapid.Space provides HTTPS front-ends (HTTP1, HTTP2, HTTP3) in 10 different locations worldwide. In China, Rapid.Space front-ends are places on all major carriers: CT, CU and CM.

Full Scope

  • IaaS: Small VM, Big VM, networking, etc.
  • PaaS: Web IDE, SQL DB, NoSQL, Data lake, IoT, CDN, PWA, etc.
  • SaaS: make your own

Read online: How does Rapid.Space and SlapOS compare to AWS?

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 Advantage

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".

Fully reversible

Everything in Rapid.Space is open source: software (SlapOS), hardware (OCP) and business procedures. 

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.

Hyper Open

  • Transparent cost structure
  • Contribute your own cloud service (IaaS, PaaS, SaaS)
  • Contribute your own DC
  • Deploy on-premise
  • Build a private infrastructure
  • Interoperable with 3rd party public or private clouds

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.

Guaranteed worldwide delivery

Thanks to its global IPv6 backbone and its CDN front-ends, it is possible to create simple applications that will select automatically the best front-end for each user. Thanks to this technology, users can always access corporate applications (ERP, CRM, etc.) with 100% success rate. This approach is much more suitable for corporate applications than DNS based technologies which only provide 99% success rate. 99% is fine for e-commerce. But if the accountant of a company can not access the ERP of a company (because he or she is the 1% of the 99%), it is not acceptable.

Price

  • 2 to 10 times less than US competition
  • 4 to 20 times less than China competition
  • 30% to 60% less than EU competition

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.

Rapid.Space for SaaS Providers

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

Service Lifecycle Management

Rapid.Space is based on a cloud operation management technology called "SlapOS" which key idea is that "everything is a service".

Instead of considering cloud as a combination of IaaS, PaaS, DRaaS, billing, etc. that are combined to provide SaaS, SlapOS views cloud as an "operation management" problem.

A cloud consists of taking software (code), automating its deployment (devops) and automating with a digital platform the service delivered to customers (operation management). The word "management" is the key concept in this approach. According to certain experts, 90% of problems in cloud computing, and also in radio telecommunication, relate to "operation management". Only 10% relate to mere technology.

Operation Management (OM)

Rapid.Space provides this "operation management" solution, based on SlapOS open source software which itself derives from ERP5 ERP/CRM platform. It has probably no open source equivalent. SlapOS covers: subscription, customer support, resource management (computers, software, etc.), provisioning, orchestration, monitoring, disaster recovery, resource accounting, payment, billing, edge, etc, 

The code itself can be anything: a virtual machine (qemu), a database (mariadb), an ERP (ERP5), etc.

The role of devops scripts - which are as difficult to write as the code itself  - is to automate the how the software is built, provisioned, configured, orchestrated, monitored, etc.

OM + KVM = IaaS

In order to build a IaaS, one only needs to take qemu software and write devops scripts in buildout language. Everything else is already implemented.

OM + JAR = SaaS

In order to build a SaaS, one only needs to take application software (eg. JAR) and database (eg. MariaDB) and write devops scripts in buildout language. Everything else is already implemented.

4G/5G Network = OM + vRAN

Industrial Edge = OM + virtual PLC

3-month plan

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

Overview

  • Month 1: POC (OM, code, devops)
  • Month 3:

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.

Month 1: tasks

  • deploy SlapOS master on dedicated server
    • minimal web site
    • subscription form 
  • deploy SlapOS node on Rapid.Space server
  • write buildout profile of minimalSoftware Release
    • list software components and tests (unit, integration, etc.)
    • collect configuration files
    • rebuild from scratch
    • minimal integration tests
    • minimal deployment tests

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.

Month 1: user demo

  • subscribe to SaaS with email feedback
  • simulate payment and provisioning
  • access and use SaaS
  • access console to list and configure services
  • access monitoring of SaaS
  • post customer support request
  • reply to customer support request
  • generate monthly invoice

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

Month 1: developer demo

  • Software Release profiles
  • WebRunnner development environment
  • (essential!) SaaS testing platform
    • minimal integration test
    • minimal deployment test

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.

Month 2-3: buildout profile MVP

  • extend with additional components
  • extend with DR and/or HA
  • write additional monitoring promises
  • write ressource accounting rules for billing
  • automate instance deployment testing
  • automate full system integration testing
  • cache code and binaries

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.

Month 2-3: SlapOS Master MVP

  • billing rules
  • email feedback messages
  • FAQ
  • HowTo
  • product information
  • company information

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.

Next Steps

  • Extend Software Release
  • Add Software Release
  • Extend OM Platform

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.

Risk Mitigation

  • Lack of Operation Management ✅
  • System built with too many tools ✅
  • Unstable cloud platform ✅
  • Unstable or congested internet ✅
  • Doing too much ⚠

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).

Thank You

  • Rapid.Space International
  • Paris
  • +33629024425 - jp@rapid.space

For more information, please contact Jean-Paul, CEO of Rapid.Space (+33 629 02 44 25 or jp@rapid.space).