FRAXSES

TECHNOLOGY

ARCHITECTURE

FRAXSES ARCHITECTURE

MICROSERVICES

MICROSERVICES / EVENTS

Microservices are essentially a design pattern (more often called an architecture) in which small services (components) are responsible for processing a single task or very few tasks. The Fraxses Gateway API is the blanket term for the Fraxses microservices. Each unit of processing by a microservice we typically call an event and the chain of these processing units an event stream (or action). The configuration of these event streams / actions is handled via the events engine within the cluster. The purpose of this architecture is to gain componentization through loosely coupled services. Our philosophy of the microservices architecture essentially equals to the Unix philosophy of:

  • Services are small and fine-grained to perform a single function;
  • Organisation culture should embrace automation of testing and deployment;
  • Eases the burden on management and operations and allows for different development teams to work on independently deployable units of code;
  • Culture and design principles should embrace failure and faults, similar to anti-fragile systems;
  • Each service is elastic, resilient, composable, minimal, and complete.

SECURITY

SECURITY

Advanced data security allows column level security, row level security and masking on data returned through Fraxses. Access to the underlying data objects is restricted by policies assigned to organisations and groups restricted by a low overhead security server that can be accessed with JDBC, ODBC and REST API.

AUDITING

AUDITING

Every microservice in the ecosystem logs error and information messages with accompanying memory profile, environment details and versioning information. It is thus logging everything. This log information is asynchronously passed onto Logstash (via Filebeat) which executes some small pre-processing before persisting the log messages into Elasticsearch (for more information on Filebeat/ Logstash/Elasticsearch please see ELK stack section).

Each request to the Gateway API is assigned a unique request ID which is propagated throughout the service cluster – this can then be used to track all events and log messages associated with that ID, this makes debugging much easier to handle in the decoupled microservices environment.