[ITA] Scaling smart energy: building a cloud-native platform for renewable communities

Le reti elettriche europee stanno affrontando una crisi silenziosa: la domanda di energia cresce rapidamente, spinta dall'adozione di veicoli elettrici, pompe di calore ed elettrificazione industriale, mentre le fonti rinnovabili immettono energia in modi per cui la rete non è stata progettata. Il risultato è un sistema sotto pressione da entrambi i lati. Adeguare l'infrastruttura costerebbe miliardi. L'alternativa più intelligente è software che rende l'infrastruttura esistente più flessibile, ed è esattamente quello che fa SPARklE.

SPARklE è una piattaforma cloud-native a microservizi (Java/Spring Boot per i servizi core, Python per algoritmi di forecasting e ottimizzazione) che gestisce Comunità Energetiche Rinnovabili (CER) e partecipa ai mercati della flessibilità energetica per conto dei Distribution System Operator. In questo talk partiremo dal problema di dominio che ha guidato le nostre scelte architetturali, per poi entrare nel dettaglio delle decisioni tecniche che hanno reso il sistema funzionante in produzione.

Approfondiremo tre aree:

- multitenancy: perché abbiamo scartato l'approccio con clausole WHERE e implementato PostgreSQL Row-Level Security con propagazione di variabili di sessione attraverso un connection pool — inclusi i problemi sottili che abbiamo incontrato lungo la strada.
- dati time-series su larga scala: come le hypertable e le retention policy di TimescaleDB hanno gestito l'ingestione ad alta frequenza da smart meter e sistemi di accumulo su più comunità.
- ottimizzazioni delle immagini docker dei microservizi SpringBoot: come ridurre dimensione e startup time con jdeps, jlink e AOT Cache
- GitOps in un progetto che coinvolge più aziende: come FluxCD su Kubernetes ha portato ordine nei deployment quando il sistema integra moduli e componenti di proprietà di partner esterni.

Un talk sui trade-off reali di un team piccolo che costruisce infrastruttura che impatta direttamente il flusso di energia rinnovabile nella rete. Include live demo.

Video of presentation at JUG Milano - 2026/06/18 : https://www.youtube.com/watch?v=sNWVQHHGc6w&t=316s

Transcript

1. 1 18 Giugno 2026 - Scaling smart energy: building a cloud-native platform for renewable communities Michele Giacobazzi
2. ๏ Gestione dell’energia ๏ Cos’è SPARklE? ๏ Demo ๏ TimescaleDB ๏ Multitenancy ๏ DevOps / FluxCD Today’s goals: AGENDA_ 2
3. GESTIONE INTELLIGENTE DELL’ENERGIA Dal problema alla soluzione 3
5. SFIDE DI DISTRIBUZIONE_ 5 Source: Areti SpA – Relazione Tecnica Progetto RomeFlex Picco di domanda ๏ 2022: 2,000 MW ๏ 2032: 3,300 MW ๏ > 2,500 MW per 750h
6. Possibili approcci SFIDE DI DISTRIBUZIONE_ ๏ Gestione picco 3300 MW ๏ Investimento di circa 1000 mln€ Adeguamento infrastruttura 6
7. Possibili approcci SFIDE DI DISTRIBUZIONE_ ๏ Gestione picco 3300 MW ๏ Investimento di circa 1000 mln€ ๏ Intervenire su richiesta per ridurre il picco ๏ Potenziare infrastruttura per gestire 2500 MW ๏ Investimento totale di circa 500 mln€ Adeguamento infrastruttura Flessibilità e gestione energia 7 Source: Areti SpA – Relazione Tecnica Progetto RomeFlex
8. Come fare?
9. Cosa sono? COMUNITÀ ENERGETICHE RINNOVABILI_ 9 ๏ Associazione di utenti ๏ Generazione da fonti rinnovabili ๏ Condivisione virtuale dell’energia ๏ Incentivi per autoconsumo
11. COMUNITÀ ENERGETICHE RINNOVABILI_ 11 I vantaggi ๏ Incentivo energie rinnovabili ๏ Impatto sulla rete più costante e prevedibile
12. Come funziona? FLESSIBILITÀ ENERGETICA_ 12
13. Come funziona? FLESSIBILITÀ ENERGETICA_ 13 PREVISIONI CONGESTIONI SULLA RETE IL DISTRIBUTORE FORMALIZZA LE RICHIESTE UTENTI POSSONO PARTECIPARE PER UNA QUOTA PAGAMENTO IN BASE AI RISULTATI
14. Dall’efficienza alla flessibilità energetica 14
16. 16 I PARTNER DI PROGETTO_
17. Gestione completa di una CER SPARKLE_ 17 Algoritmi avanzati (efficientamento CER) IoT (integrazione facile con dispositivi) Comunità (Gestione CER come comunità di utenti) Calcolo incentivi
18. Gestione della flessibilità SPARKLE_ 18 Simulazione scenari flessibilità Applicazione richieste schedulate
19. Variabili in gioco SPARKLE_ 19 ๏ Prezzo dell’energia ๏ Andamento storico ๏ Previsioni del tempo ๏ Capacità di accumulo ๏ Incentivi autoconsumo ๏ Incentivi flessibilità
20. MONITORAGGIO E ANALISI ENERGETICA_ SPARKLE_ 20
21. Gli utenti tipo SPARKLE_ 21 Energy manager Service Provider Utente
22. Demo Time 22
23. Challenges SPARKLE_ 23 Problema ๏ Lettura e accumulo di molti dati, da apparati differenti ๏ Collaborazione tra 4 aziende ๏ Tecnologie diverse e modelli per previsione ed efficientamento
24. Architettura SPARKLE_ 24
25. Gestione Misure e Setpoint SPARKLE_ 25
26. Data management SPARKLE_ 26 TimescaleDB ๏ Alte performance su inserimento ๏ Ottimizzazione per query temporali ๏ Retention policy ๏ Funzioni temporali integrate ๏ Estensione di PostgreSQL
27. Mole di dati SPARKLE_ 27 TimescaleDB
28. Multitenancy SPARKLE_ 28 Problema ๏ Gestione di più CER ๏ Separazione completa dei dati per gli utenti finali ๏ Accesso a tutti i dati per statistiche e verifiche ๏ Evitare la clausola WHERE
29. Keycloak MULTITENANCY_ 29 ๏ CER come realm ๏ TenantId come custom field
30. Service - auth MULTITENANCY_ 30 ๏ Recupero tenantID con auth filter ๏ Uso di variabile ThreadLocal
31. DB access MULTITENANCY_ 31 ๏ Aggiunta della variabile tenant ID a ogni connessione DB acquisita
32. Multitenancy - row level policy MULTITENANCY_ 32
33. MULTITENANCY_ 33
34. Automate all the things DEVOPS_ 34 ๏ Monorepo con pipeline in comune ๏ Build automatica immagini docker ๏ Multi stage build e ottimizzazione ๏ GitOps: declarative infrastructure and application
35. Spring Boot Dockerfile DEVOPS_ 35 Ridurre: ๏ Dimensione immagine ๏ Startup Time ๏ Memory footprint
36. 36 DEVOPS_
37. Spring Boot Dockerfile DEVOPS_ 37 ๏ jdeps trova i moduli usati ๏ aggiunta manuale dei riferimenti dinamici ๏ jlink crea JRE su misura ๏ Dimensione docker image da 450MB a 170MB ๏ Sicurezza: l’immagine contiene solo il necessario
38. 38 DEVOPS_
39. What else? DEVOPS_ 39 • Dimensione ridotta, ma tempi di avvio lenti • A ogni startup, per ogni classe: ◦ Load: parse Bytecode, generazione metadata ◦ Link: Verify Prepare Resolve Come migliorare?
40. 40 Class Data Sharing DEVOPS_
41. CDS: i benefici 41 −20% startup con CDS, a ogni budget CPU 1 CPU 5 CPU senza CDS 38.8 s 18.5 s con CDS 31.1 s 15.0 s risparmio −20% −19% mediane di 20 run per configurazione · 3 nodi GKE· stessa finestra temporale DEVOPS_
42. 42 AOT Cache DEVOPS_ CDS: Load - AOT Aggiunge: • Linking (Verify - Prepare - Resolve) • Registrazione dei profili per JIT Project Leyden · JEP 483 / 515 · JDK 25
43. Modernizzare la JVM 43 −32% JDK 25 + CDS + AOT cache Solo cambio JDK: −8% AOT: −14% sopra il CDS mediane · stesso nodo GKE · 1 CPU · n=22 DEVOPS_
44. Verifica incrociata 44 mediane · stesso nodo GKE · n=22 (1 CPU) / 9 (3 CPU) · shuffle-interleaved DEVOPS_ 1 CPU 3 CPU JDK 21 base JDK 25 + CDS + AOT 34.1s 13.3s 23.2s 9.2s software −32% CPU −60% dal peggiore al migliore: 34.1s → 9.2s −73%
45. 3 CPU: il guadagno regge su entrambi i nodi DEVOPS_ 45 mediane · 3 CPU · cambiano i tempi assoluti, guadagno consistente
46. GITOPS_ 46
47. Here comes FluxCD GITOPS_ 47
48. Roadmap SPARKLE_ 48 Settembre 2025 Progetto Pilota Dicembre 2025 Conclusione progetto con Università La Sapienza, Roma Settembre 2026 Lancio SPARklE come prodotto Marzo 2026 Onboarding prima CER
49. Feature list SPARKLE_ 49 CER ๏ Algoritmo ottimizzazione ๏ Onboarding utenti ๏ Gestione di CER con configurazioni multiple Monitoraggio ๏ Dashboard di analisi ๏ Grafici avanzati
51. 51 Contatti SIETE I BENVENUTI_ Via Campagna 13, CH-6982 - Agno info@welld.ch www.welld.ch Via Pastrengo 14, 20154 - Milano https://sparkle.energy