IoT e web: cosa ho imparato lavorando in entrambi i mondi

Ho passato gli ultimi anni come Lead Software Engineer a Elemental Machines, costruendo software per sistemi IoT — sensori, pipeline di dati, dashboard real-time, gestione dei dispositivi. Prima e in parallelo, ho continuato a sviluppare app web e mobile: questo sito, Barba Studio, lavoro per clienti attraverso Honeyside.

Muoversi continuamente tra questi due mondi mi ha dato una prospettiva che lavorare in uno solo di essi non mi avrebbe mai dato. In apparenza sembrano discipline completamente diverse. Non lo sono.

Il web dà per scontata l'abbondanza. L'IoT no.

La prima cosa che l'IoT ti insegna è che il web ti stava viziando.

Sul web si assume una connessione veloce e affidabile. Si assume che il server sia sempre disponibile. Si assume che se qualcosa va storto, l'utente può semplicemente ricaricare la pagina. Queste assunzioni sono così profondamente radicate nel modo in cui costruiamo app web che non le notiamo finché non smettono di essere vere.

Nell'IoT, nulla è affidabile per default. Un sensore potrebbe essere su una connessione cellulare in un seminterrato. Potrebbe andare offline per sei ore e tornare su. Potrebbe inviare 200 letture al secondo o tacere per un giorno senza preavviso. Il tuo software deve assumere che il fallimento sia normale — non un caso limite da gestire con grazia, ma la condizione operativa attesa.

Questo cambia il modo in cui pensi all'ingestione dei dati, alla gestione degli errori e allo stato. E una volta cambiato, non riesci più a non vederlo anche sul lato web. Ora penso in modo diverso agli stati offline, alla logica di retry e all'optimistic UI nelle app web, perché ho dovuto pensarci seriamente in sistemi dove sbagliare significa perdere dati di sensori in modo permanente.

Il real-time è più difficile di quanto sembri

Entrambi i mondi si preoccupano dei dati in tempo reale, ma i problemi sono diversi.

Sul web, il real-time di solito significa WebSocket o Server-Sent Events che inviano aggiornamenti al browser. La parte difficile è la UI — mantenere lo stato coerente, evitare re-render inutili, far sembrare l'esperienza live senza sovraccaricare il client.

Nell'IoT, il real-time significa ingerire migliaia di letture al secondo da centinaia di dispositivi, instradarle verso i consumer giusti e archiviarle in modo efficiente. Il settore si è assestato su strumenti come MQTT, code di messaggi e database time-series. La parte difficile è l'infrastruttura — throughput, garanzie di ordinamento, backpressure.

L'intuizione che si trasferisce: entrambi i problemi riguardano fondamentalmente l'architettura event-driven. I pattern — producer, consumer, code, subscription — sono gli stessi. La scala e il substrato differiscono. Imparare a pensare per eventi sul lato IoT mi ha reso un architetto molto migliore sul lato web, e viceversa.

Il deploy è un problema completamente diverso

Sul web, fare il deploy di una fix significa fare push di un commit. La CI gira, il CDN si aggiorna, ogni utente riceve la nuova versione al prossimo caricamento della pagina. È così veloce e privo di frizioni che a volte facciamo push più volte al giorno senza pensarci.

Nell'IoT, il dispositivo è fisico. Potrebbe trovarsi in un laboratorio a cui non hai accesso, montato all'interno di un macchinario, o installato in una struttura dall'altra parte del paese. Un aggiornamento firmware over-the-air che va storto può rendere un dispositivo inutilizzabile. Il rollback non è sempre possibile. Il riflesso del "mando su una fix veloce" che lo sviluppo web costruisce in te diventa genuinamente pericoloso.

Questo mi ha reso più deliberato nei deploy ovunque. Feature flag, rollout graduali, la disciplina di chiedersi "com'è un deploy fallito e come recuperiamo" — sul web sembrano opzionali finché non lavori da qualche parte in cui non lo sono.

La mentalità della resilienza

L'hardware si rompe in modi che il software non ti prepara ad affrontare. Un sensore deriva fuori dalla calibrazione. Uno switch di rete scarta pacchetti in modo asimmetrico. L'orologio di un dispositivo si desincronizza e inizia a timestampare le letture nel passato. Questi non sono bug che puoi correggere con una modifica al codice. Sono proprietà dei sistemi fisici che il tuo software deve saper gestire.

La mentalità che si costruisce: architettura difensiva per default. Non fidarti dei dati. Valida a ogni confine. Progetta pensando che il sistema possa essere parzialmente degradato in qualsiasi momento e produca comunque un output utile.

Ho portato questo approccio nello sviluppo web. Le API mentono. I servizi di terze parti si bloccano. Gli utenti fanno cose che non avevi previsto. L'istinto IoT di trattare ogni input come potenzialmente sbagliato finché non è dimostrato il contrario ha intercettato più bug nel mio codice web di quanti vorrei ammettere.

Cosa ciascun mondo sbaglia dell'altro

Gli sviluppatori web che si avvicinano all'IoT tendono a sottovalutare l'hardware. Costruiscono dashboard bellissime e UI real-time, ma progettano le pipeline di dati come se stessero costruendo una REST API — sincrona, stateless, ottimistica. La prima volta che un dispositivo sommerge l'endpoint di ingestione o va offline nel mezzo di una sessione, le assunzioni crollano.

Gli ingegneri IoT che si avvicinano al web tendono a sovra-ingegnerizzare la resilienza. Aggiungono code di retry per operazioni che dovrebbero semplicemente fallire velocemente. Trattano il browser come un client embedded inaffidabile e costruiscono di conseguenza. Il risultato è software robusto ma lento da sviluppare e difficile da modificare.

Il punto di equilibrio è da qualche parte nel mezzo: la velocità di iterazione e il focus sull'utente del web, la disciplina dell'IoT sui failure mode e l'integrità dei dati. Arrivarci richiede di aver lavorato seriamente in entrambi.

La competenza che si trasferisce meglio

Se dovessi nominare una sola competenza che si trasferisce perfettamente tra i due mondi, è questa: sapere dove si trovano i confini del tuo sistema e rispettarli.

Nell'IoT, il confine è tra il tuo software e il mondo fisico. A quel confine, nessuna assunzione regge.

Nello sviluppo web, il confine è tra il tuo codice e tutto ciò che è esterno — input dell'utente, API esterne, la rete, il browser. A quel confine, vale lo stesso principio.

Tutto ciò che si trova dentro il confine lo puoi ragionare e controllare. Tutto ciò che si trova fuori, puoi solo difenderti. Gli ingegneri che capiscono questo — indipendentemente da quale dominio l'ha insegnato loro — costruiscono sistemi migliori.

---

Le opinioni espresse qui sono opinioni personali. I contenuti pubblicati non sono monitorati né approvati da Elemental Machines prima della pubblicazione e non rappresentano necessariamente le opinioni di Elemental Machines.