Coffee, Cookies and Architecture

AirQ uses three elements: cloud, application and sensors. Thanks to these three components, users can access the sensors network, data and information. In this short post, we want to share the current state of the AirQ architecture and the decisions we made.

GitHub Actions for CI/CD

We use the Actions service from GitHub as a tool for CI/CD: we dedicated a specific branch to Continuous Delivery, whereas Continuous Integration is done locally so that we can minimize the costs of the architecture.

The status of the service is maintained in the DB, which is accessible only from the Server. The Server has specific permissions for updating the tables but not for creating or removing them. For such permissions, we leverage the maintenance service offered by the provider.

For the entire duration of the development, the Actions helped us facilitate the update phase of the service.

Gateway as an access point

Both the sensors and the application communicate to a single point of access. We follow the IoT-A principle, therefore as DigitalEntities the sensors and the application talk to the same level. Additionally, since sometimes the sensors are installed in locations that are not easily accessible, the software has to be as stable as possible.

The gateway provides access to all requests, which are managed by rigid and predefined schemes.

1 Server, N instances

In the current state, one server is enough to provide the necessary computational power. However, in order to guarantee as little latency as possible, we provide the service with two instances. We constantly monitor traffic and workload; so far we have not identified any bottleneck that is relevant to our service.

Evolution?

We know that this architecture is standard and stable but we are already evaluating a potential update that we intend to bring to a testing phase by the end of this year.