DPS Architecture

Servitly is a distributed system composed of many interconnected elements. The DPS system applications are configured and running on the architecture described below.

Frontend

The DPS main interface is provided through the Frontend, which is a Web application allowing users to access and view machine data, events, and insights. The frontend is a single-page HTML5-based application that makes use of the Bootstrap, Angular, and Angular Material frameworks to build the user interface. The DPS application comes with a predefined set of pages (eg. Customers, Products, Alerts, etc.), but it is possible to change them or add new pages.

The content of the pages is based on templates whose visualization is defined through a library of predefined graphical components, which can display data in various formats (e.g., a temperature, a power, a counter), or display charts and graphs (by using the amChart built-in library).

Once the user has authenticated, the frontend's components can start invoking the backend APIs by sending the user's JWT token.

Certain widgets can also subscribe to metric or property updates in order to keep the page updated without refreshing it.

Third Party App

These are all the external applications that can be integrated with the DPS. By default, Servitly provides a set of built-in plugins that can be easily configured in order to integrate major CRM applications, FSM, and other software solutions normally used by OEMs.

In addition, it is possible to leverage the Servitly REST API to integrate any other kind of legacy software.

DNS and API Gateway

API requests are intercepted by a DNS (Amazon Route53) that redirects them to the right API Gateway, which is responsible for verifying the identity and context of the client and decoupling access to the private micro-services.

The API Gateway itself is replicated in a way that redistributes the request load.

All incoming communication must be made through HTTPS and must include a JWT token, and if performed from a third-party application, also an API KEY which defines the constraints and permissions.

This is the list of public IPs.

Note that, in the future, new IP addresses may be changed or added.

IoT Connectors

Products can communicate with the DPS by using the IoT Connectors and the relative protocols (e.g. MQTT, HTTP).

Servitly includes these built-in connectors MQTT Connector, HTTP Connector, CoAP Connector, but it is possible also to use other connectors based on third-party services, for instance: AWS IoT Core, MS Service Bus, Everyware Device Cloud, Alleantia, Lemonbeat, and more.

Any communication to the IoT Connector is protected through a certificate, and other information used to uniquely identify the connected product (e.g. username, asset-id).

Micro Services

Within the Servitly VPN, there are a set of deployed micro-services, each of which is called upon to perform a specific task by the API Gateway or by the IoT Connector. The micro-services communicate with each other in a balanced way. For example, at the receipt of metric data in addition to being saved, data is processed by a series of secondary services in order to compute derived values, calculate insights, evaluate events, notify users, and perform automation.

Data Storage

All the data managed by Servitly, including customer data, user data, product data, and metric data, are stored in a set of isolated and replicated databases.

In addition to databases, there are other support services:

• queues used to absorb peak loads;

• cache services which are used to reduce the response time in retrieving frequently requested information;

• cloud file archives to store secondary resources.

All databases store data in a replicated manner, using different availability zones. Typically, each date is stored in at least two different availability zones.

Database querying is allowed only through API requests addressed to the API Gateway, any other communication to the databases and support services is forbidden.

Scalability

Any incoming IoT request or data is forwarded to the designated internal micro-service. Micro-services are replicated, and the number of instances of each one depends on the architecture load, which may be affected by:

• the number of connected products;

• the complexity of each product definition;

• the frequency reaching remote product publishes data;

• the number of API calls made by the frontend or by other external services.

In the event that a micro-service becomes unreachable, it is disposed and immediately a new instance of it is allocated, and the load is automatically redistributed.
Scaling of the micro-services is done automatically by Servitly to keep availability and reliability at a maximum at all times.