AirQ utilizza tre elementi: cloud, applicazione e sensori. Grazie a queste tre componenti, l’utente puó accedere alla rete di sensori, dati ed informazioni. In questo post, vogliamo condividere lo stato attuale dell’architettura e le scelte che abbiamo preso.
GitHub Actions come CI/CD
Utilizziamo il servizio Actions di GitHub come strumento di CI/CD. Abbiamo dedicato un branch specifico per il Continuos Delivery, mentre il Continuos Integration é svolto in locale, in modo da minimizzare i costi dell’architettura.
Lo stato del servizio é mantenuto nel DB, accessibile solo dal Server, il quale é dotato di permessi specifici per l’aggiornamento delle tabelle, ma non per la creazione e la cancellazione delle stesse. Per questi permessi sfruttiamo il servizio di manutezione fornito dal provider.
Per tutta la durata dello sviluppo, le Actions hanno facilitato la fase di aggiornamento del servizio.
Gateway come punto di accesso
Sia i sensori che l´appllicazione comunicano con un unico punto di accesso. Seguiamo il principio dell’IoT-A, pertanto come DigitalEntities, i sensori e la app parlano allo stesso livello. Inoltre, siccome a volte i sensori vengono installati in posizioni non facilmente raggiungibili, il software deve essere il piú stabile possibile.
Il gateway fornisce un accesso a tutte le richieste, controllate secondo schemi prestabiliti e rigidi.
1 Server, N istanze
Allo stadio attuale, un solo server é sufficiente per fornire la potenza di calcolo necessaria. Tuttavia, per garantire il minor ritardo possibile, abbiamo provveduto a fornire il servizio con due istanze. Stiamo monitorando il traffico ed il carico di lavoro; sino ad ora non abbiamo trovato nessun collo di bottiglia rilevante per il nostro servizio.
Evoluzione?
Siamo sicuri che questa artchitettura é stabile e pressocchè standard. Stiamo tuttavia valutando un possibile aggiornamento che vorremo portare in fase di test entro la fine dell’anno.
Comments