Chapter 2: Basic Categories and Technologies
The term System will hereafter abstractly refer to the deployed platform "Incoplax", or a product based on it, without making any distinction.
Platform Stack
The stack is understood as a certain set of tools and principles that can be used to conveniently create products. The platform stack includes the platform itself (software product), some ready-made applications to manage it, as well as the principles of creating and customizing products based on it and the automated process of product assembly and testing. The platform lays down in the stack the basic architectural principles that
-
ensure that non-functional requirements and quality attributes are met in the order of importance presented,
-
cover a number of functional requirements of communication orientation,
-
define approaches to the realization of other functional requirements,
-
form opportunities for integration and incorporation into other products, including through decoration.
The platform itself in its pure form is not a ready-to-deliver product - there is no proper product user documentation, no names, logos, organized support processes. Nevertheless, the platform distribution can be built, and products based on it are built according to the same principles. Moreover, only the platform has a build process, and products inherit it directly and customize it if necessary.
A few basic categories
The architecture of the platform defines the architecture of the entire stack. The base categories are introduced by analyzing several input requirements mentioned at the beginning of the paper.
-
The system has to be scalable. That means it is multi-server. The concept of server.
-
The system should be distributed, ensuring full functioning of individual parts in case of network unavailability. A dedicated group of servers at each site. The concept of site, process ETL.
-
The system must support separation into multiple independent companies with independent data management. The concept of domain and entities in a domain.
-
Key quality attributes are accessibility and modifiability. Focus on mini-applications - with a clearly delineated purpose and functionality - role. The concept of applications and roles .
-
Each server runs one or more microservices. The absence of parasitic mutual resource dependency would be useful in achieving reliability. The concept of node.
Thus the key to understanding is the three layers of consideration of the system:
-
Infrastructure layer. Sites, servers, nodes.
-
Data Layer. Domains, entities.
-
Layer of logic. Roles (microservices), applications.
-
Product layer. Industry packages: data model, applications, microservices.
| Notion | Layer | Determination |
|---|---|---|
|
|
A group of servers of high availability to each other, providing full system functionality within a quorum (50% + 1). The quorum ensures data integrity in case of loss of communication between site servers, since functionality is supported only in one of the groups, and only if there is a majority. The case of an even number of servers is solved with the involvement of an arbitrator - an external server. Read more in xref:achitecture: Each site is independent and can exchange information with other sites. Including, it is possible to connect to any sites, authorize, register and work with data of any domains. Each site must maintain at least one domain, using a site without a domain is pointless and impossible. Defined by a text name that begins with a lowercase Latin letter and may consist of Latin letters and numbers. |
|
|
A platform that allows you to run software applications. Typically a single physical or virtual machine with a unique IP address. Each server must belong to one site only, it is not possible to use a server without being attached to a site. Defined by a text name that begins with a lowercase Latin letter and may consist of Latin letters and numbers. |
|
|
An operating system process. It runs an instance of Erlang runtime system, which has a unique name. Multiple nodes can be active on a single physical or virtual server (address). Nodes are distributed to servers automatically based on the configured configuration. |
|
|
An entity that defines the boundaries of a group of system objects that provide access to system functionality. The system logic uses domains and objects belonging to them when implementing functionality and defining access for individual users. All data within a domain is closed by default. Refers to the data layer. Each domain is served on a specific site, uses its own data stores. |
|
|
Any object in the domain created by an administrator and used by the system in any running processes. |
|
|
A conditionally independent component of the software part of the platform, which has a fixed responsibility and a defined interface. Platform roles are implemented as application level applications or aggregations of them. Version builds build higher-level applications, where the platform itself acts as the application. |
|
|
A category of microservice that implements some isolated functionality of the system. An integral part of the platform logic. The instance runs as an application in one of the nodes on one of the servers and has a unique name throughout the system. The name begins with a lower case Latin letter and may consist of Latin letters and numbers. |
|
|
A structure that connects the infrastructure, logic, and data layers to each other. Which server belongs to which site, what addresses the servers have, which microservices are executed on which servers, which domain zones are served on which sites, and other data. The configuration is defined by the configuration file, and is the same for all servers in the system. Each node on each server draws in configuration information about which servers are part of the infrastructure, discovers itself, determines which microservices should be activated, and which servers host other microservices. |
|
|
A platform subsystem that allows industry-specific application packages to be created, and executed. The package is loaded into a specific domain, creates a data model, client and server microservices, user access roles, and applications there. The data handling uses a change subscription model. Operates in the following categories: enumerations, classes and collections, Rest API, controls (Editors), visual tools (Controls), user roles, user applications, actions (Actions), microservices, handlers, scenarios, packages. |
On all servers where the program is deployed, the program directory structure looks the same. Launching the program on all servers is also done in the same way.
Technologies used
Erlang OTP
To ensure quality attributes when writing the platform’s business logic layer, a tool is required to allow for high-speed of deep changes and debugging while maintaining full source code control and developer understanding of all algorithms. Any third-party off-the-shelf solution (application) that is accepted for use must be available as a open-source.
The "Incoplax" communication platform is selected as such a tool for the development of the communication platform Erlang OTP (A framework containing a set of libraries and design patterns for building scalable applications in a programming language Erlang). Proven by decades of trouble-free operation in telecom solutions, the reliability of the Erlang virtual machine eliminates the risks associated with the tool’s immaturity. Possibilities of dynamic debugging and hot-swapping of code at runtime have been known since the early 1990s and are extremely useful when implementing services with large requirements to continuity and availability. An event-driven architecture with extreme process lightweighting allows the event-driven platform under development to be spared its own deep layer of solutions, providing and facilitating asynchronous operations - it becomes the driver of the platform architecture. Erlang is used in such well-known solutions as Yandex.Disk server, game messenger-communicator Discord, message broker RabbitMQ and others. It is not a mass tool in software development, and with this comes the difficulty of finding ready developers. However, technology studies have found that the new developer onboarding time is 1 to 4 weeks, which virtually removes the problem.
C++
The media processor requires the highest performance because the main time of all processors in the communication platform is spent processing traffic - audio and video. audio and video, especially when using transcoding (repackaging of traffic from one codec to another by the media server). The media processor is singled out for separate consideration due to a completely different prioritization of non-functional requirements. It is being developed in C++. Thus, the achieved performance - 150-200 simultaneous voice conversations per one processor core (the specific value depends on the codecs used), can’t be achieved by any other available tool.
PostgreSQL
A relational database is used to store configuration data PostgreSQL. Its use is also temporarily extended to event history storage databases and pre-aggregated logs. It is possible to use it as a project database through connection string registration in the domain.
Apache.Kafka
Distributed fault-tolerant streaming platform, message broker. It is used to receive event streams from the communication platform for further redirection to storage and reporting systems.
Yandex.ClickHouse
Introduced to the community in 2016 as a high-performance columnar database with the ability to build multi-server fault-tolerant clusters for BigData storage and analytical work with data. Yandex.Metric is powered by ClickHouse, deployed on more than 300 servers and storing more than 20 PB of information. Compact data storage, high speed of building analytical queries, independence from the storage size allows to use ClickHouse as an alternative tool for storing the history of events communication platform "Incoplax" with the ability to build analytical reports directly without preliminary aggregation.
JS/TS + React + Node.JS
Approved the concept of writing independent web client applications for each user role. Great attention is paid to the speed of development, priority is given to small applications with clear and useful "here and now" functionality. Dynamic tweaking of solutions requires great flexibility, accordingly building bulky applications does not reflect this need. Nevertheless, it remains possible to dock the platform via APIs with arbitrary applications. The principle of separation of interfaces (see SOLID) predetermined this approach in the construction of APIs and the web applications that use them.
Server modules/applications can be loaded into the platform via APIs and executed and maintained by the system. Proprietary "back-end" applications of this class are also developed on the JS/TS + React. They act as product microservices, with links to specific subject areas. Executed in nodejs under platform supervision.
TS is used in builder, and packages built with it. Microservices for industry packages are created on TS, compiled by builder, uploaded to the server when the package is activated, and executed by nodejs under platform supervision.
Docker
Operational unified installation of the system on arbitrary servers is provided due to Docker. Updates and distributions are delivered in a Docker container. Orchestrators are not used for Docker because the platform manages inter-server communications on its own, including updates.
-
Next chapter: Cases for a deep dive into architecture
-
Previous chapter: Entries