Basic Platform Settings¶
Platform Architecture¶
The platform is built on a microservice architecture that provides modularity, scalability, and flexibility. The key features of the architecture include:
- Microservice Architecture: The system is divided into separate microservices, each of which performs a specific function and operates independently.
- Distributed Processing: Microservices can be distributed across different nodes, providing load balancing and increased system resiliency.
- Containerization and Orchestration: Using Docker to containerize microservices and Kubernetes to orchestrate them makes it easier to deploy, scale, and manage the application.
- Modularity and interoperability of microservices: Modularity is achieved by clearly delineating functions between microservices, and communication between them takes place via specific APIs and interoperability protocols.
The system comes in eleven Docker container images:
| Service | Purpose |
|---|---|
| catalogs | Storage and processing of user data; RLS support |
| data-flow | Processing and storing custom data scripts |
| file-storage | Binary data storage |
| identity | User management and authentication |
| notification | Sending notifications |
| scheduler | Event scheduler in the system; all events are called via the bus |
| template-service | Working with templates |
| view-service | Storage of system metadata; orchestration of metadata update processes |
| workflow | Scripting via the State Machine |
| web-studio | Application development web part |
| web-workplace | Web part for running applications |
Technology Stack¶
- Foundation: The platform is built on Net Core 8.0, a modular open-source software development platform.
- Development Language: C# is used as the primary programming language.
Additional Infrastructure¶
- PostgreSQL (version ≥13.0): Object-relational database management system for primary data storage.
- Redis (version ≥5.0): A non-relational database used for data caching.
- RabbitMQ (version ≥3.0): A software message broker for handling system events and queues.
Web Parts¶
- Uses the Blazor front-end web framework, part of Net Core, to create web components.
- Web Parts are run as a client-side WebAssembly (WASM).
Installation Requirements¶
- Kubernetes: Kubernetes cluster is required for the clustered version of the product to work.
- Minimum Configuration:
- 1 x Master (2 vCPU, 4GB RAM, 20GB SSD) - 3 nodes with the Master role are recommended.
- 1 x Ingress (4 vCPU, 8GB RAM, 20GB SSD)
- 3 x Worker (16 vCPU, 32GB RAM, 60GB SSD)
- Operating System: Ubuntu Server 22.04 LTS
Networking and Ports¶
- All network traffic uses the TCP/IP protocol.
- By default, each microservice (except web-studio) provides two ports:
- 80: Public API (HTTP/1.1).
- 5001: Private API (HTTP/2).
- Web-studio: Provides only port 80 for serving static resources.
- All microservices, with the exception of web-studio, must have access to PostgreSql, Redis, and RabbitMQ.
Protocols Used¶
- HTTP/1.1: For public API.
- GRPC: For private API.
- WebSocket: For the Notification service.
- SIP over WebSocket: Optional, for integration with SIP in a web-workplace.
- RTC/RTCP: Optional, for integration with SIP in a web-workplace.
Storing Data¶
Each microservice manages its own scheme in the database, without overlapping with the others.
| Service | Scheme |
|---|---|
| catalogs | catalogs |
| data-flow | dataflow |
| file-storage | file_storage |
| identity | identity |
| notification | notification |
| scheduler | scheduler |
| template-service | template |
| view-service | view_service, maintenance |
| workflow | workflow, wfc_persistence |
| web-workplace | workplace-host |
Each microservice is responsible for creating and migrating the metadata of its schemes.
The catalogs service, which is responsible for storing user data, creates an additional partition in its scheme for each data type, inherited from the primary table, as well as additional partitions to implement RLS if necessary. When these partitions are formed, all additional indexes and external keys are generated.
The composition of indexes and external keys depends on the configuration of the application you are building in the platform.
Authorization & Permissions Management¶
- Local authorization using JWT tokens.
- Ability to connect external authorization systems (oAuth, OpenId Connect, Windows authorization, SAML).
- RBAC (Role-Based Access Control) for access control.
Collecting metrics and traces¶
All services, except web-studio, provide metrics in the ‘Prometheus’ format. Metrics are available by the relative path /metrics. To check the availability of the service, two paths are provided /hc and /liveness:
- hc - detailed information on all checks;
- liveness - a short response about the availability of the service.
Logs are collected by the system itself, all logs are written to the maintenance scheme, and log viewing is available in the web-studio. The logging level for each service is configured separately through the web-studio, the "Maintenance" section. Two Zipkin or Jaeger systems can be connected to collect traces. Trace collection is configured at the service parameter level. If you want to export traces to Jaeger, you need at least version 1.35.