The architecture of Rapid.Space OSS/BSS is inspired by how businesses run and by the idea of encapsulation.
The idea of Service is the equivalent of sales order in business. It defines what the customer (or user) expects to be provided, either for a service or a product, without specifying how this should be technically provided.
The idea of Software Release is equivalent to the idea of model reference of a product (ex. Mercedes Class E) with its blueprints and bill of materials for each possible variation (ex. color, engine) of type (ex. cabriolet, sedan).
The idea of Software Instance is equivalent to the actual car with a serial number (VIN) and a given color, type, engine, etc.
The Compute Node is equivalent to the warehouse or parking area where cars are stored.
The Master is the equivalent of the ERP which manages the complete process of car production and distribution.
In traditional IT systems, the notions of "Service" or "Master" seldom exists explicitely. They are often implemented through management processes implemented by humans. With the recent fashion for containers, the idea of Master has been embodied by the combination of Google Anthos and Kubernetes. However, the notion of "Service" is still not explicit.
What helps understanding why a "Service" differs from a software package or a container image is the idea of service lifecycle encapsulation which combines the software upstream with scripts or tools that automate configuration, monitoring, disaster recovery, billing, etc. of that software.
For example, if we deploy an Amarisoft eNodeB, we would like to ensure that the eNodeB is not shared by too many UEs, that its performance (KPI) is sufficient most of the time. We would also like to automatically monitor the health of the RU it is connected to and sometimes change eNodeB parameters depending on the time of the day, on environment conditions or on alarms for missed KPIs. In case the server which hosts the eNodeB is destroyed, we would like to restore it automatically.
This kind of service requirement is often implemented by adding a wide diversity of scripts and tools around the Amarisoft software. One for monitoring (ex. Zabbix), one for orchestration (ex. Google Kubernetes), one for operation management (ex. Google Anthos), one for billing (ex. SAP), one for backup (ex. Veritas). Implementing a service can require to develop dozens of scripts in five to ten programming languages (ex. PHP, bash, python, yaml, etc.) and 5 to 10 different application environments, all managed independently. It is thus very difficult to get a consistent overview of all facets of a service because the logic is split a so many different locations. It is also very hard to test.
In Rapid.Space OSS/BSS, all facets of a Service are encapsulated in a single place: the Software Release. We use a single language to "glue" all facets: buildout. And everything is managed from a single application: the Master.