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 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). In addition, the custom components can be defined.

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 API to integrate any other kind of 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 to verify the identity and context of the client and decoupling access to the private microservices.
The API Gateway itself is replicated in a way that redistributes the request load.

This is the list of public IP addresses:

Note that, IP addresses may be subject to change, so you should avoid encoding them in your software (e.g. firmware, app, third party).

Microservices

Within the Servitly VPC, there is a set of deployed microservices, each of which is called upon to perform a specific task by the API Gateway, by the IoT Connector, or any other internal service.
These microservices 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.

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: Direct MQTT Connector, Direct HTTP Connector.
In the alternative you can use a third party connector. For more details refer to the Third Party Connectors article.

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. Each data 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 microservice.

The allocated number of instances of each microservice depends on the load, which may be affected by several factors:

• the number of connected products;

• the complexity of each product definition;

• the data publishing rate;

• the rate of API requests made by the frontend or by third party services.

Thanks to a real-time monitoring system of microservices and allocated resources, servers scale to maintain maximum availability and reliability at all times.

Availability