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.
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.
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.
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.
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.
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.
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.
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 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".
Everything in Rapid.Space is open source: software (SlapOS), hardware (OCP) and business procedures.
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.
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.
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.
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.
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.
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.
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.
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:
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).
For more information, please contact Jean-Paul, CEO of Rapid.Space (+33 629 02 44 25 or email@example.com).