Come lavoriamo in modo sostenibile — e come lo misuriamo

1. Efficiente per architettura

Il core di PeakSpitz gira come codice nativo compilato, non come stack applicativo interpretato. Questo conta sul piano energetico perché il lavoro che il processore compie per servire una richiesta è il lavoro che viene contabilizzato — ed emesso.

• • Base indipendente: studi peer-reviewed che classificano i linguaggi di programmazione in base al consumo energetico collocano costantemente i linguaggi compilati tra i più efficienti dal punto di vista energetico e quelli interpretati tra i meno efficienti — spesso con un ordine di grandezza di differenza su compiti equivalenti. Lo citiamo come base di categoria per la nostra scelta progettuale. Non ne ricaviamo un moltiplicatore specifico per PeakSpitz.
• ✓ Ciò che affermiamo: il motore di PeakSpitz appartiene per costruzione alla classe di software efficiente dal punto di vista energetico.
• ✗ Ciò che non affermiamo: un dato numerico del tipo “X% di energia in meno rispetto al concorrente Y.”

2. Tenancy dimensionata sul giusto

Ogni cliente dispone di un deployment isolato per tenant, configurato su quella specifica azienda — non un monolite condiviso e multiuso con ogni modulo residente in memoria.

Le funzionalità inutilizzate non restano accese. La nostra architettura è guidata dalla configurazione anziché duplicata per settore, quindi la superficie in esecuzione di un tenant è limitata a ciò che usa davvero. Il risultato: non spende potenza di calcolo — né denaro — per tenere in funzione funzionalità che non usa.

3. Infrastruttura verde e scelta della regione

PeakSpitz può funzionare su substrati e regioni multipli. Dove geograficamente disponibile, il cliente può scegliere un deployment più verde. La base fattuale sono i dati pubblicati dai provider stessi:

• • Efficienza del datacenter (PUE): gli operatori che utilizziamo pubblicano i valori di Power Usage Effectiveness. Alcuni operatori europei su cui possiamo lavorare si distinguono per un PUE basso, ottenuto con tecniche come il raffreddamento a liquido proprietario. Rimandiamo ai valori attualmente pubblicati dall'operatore invece di riportare un numero che può diventare obsoleto.
• • Intensità di carbonio della rete ed energia carbon-free: le regioni differiscono molto per quanto è pulita la loro rete elettrica. Dove operiamo su un grande cloud pubblico, quel fornitore pubblica le percentuali di energia carbon-free per regione e i dati sul carbonio della rete; li usiamo per capire quali regioni si possano considerare “più verdi.”
• • Residenza dei dati nell'UE: tra le opzioni con regioni più verdi ci sono i deployment con dati residenti nell'UE.

Colleghiamo intenzionalmente ai dati aggiornati dei fornitori invece di riportare qui valori fissi di PUE/CFE: citare un numero congelato è il modo in cui le pagine di metodologia diventano silenziosamente inesatte. Ci chieda le cifre attuali per una regione specifica. Manteniamo sempre la cautela: “dove geograficamente disponibile.”

Il fulcro della nostra roadmap è l'efficienza controllata dal cliente:

• • Finestre Eco: il cliente potrà definire finestre a basso consumo su una pianificazione a risoluzione giornaliera. Durante quelle finestre l'istanza funziona in modalità a potenza ridotta, abbassando il consumo di calcolo — e quindi il costo di calcolo del cliente.
• • Recupero del pool condiviso: la capacità liberata durante una finestra a basso consumo torna a un pool condiviso invece di restare inattiva, così può svolgere lavoro utile altrove. La logica di sostenibilità è a livello di flotta: capacità riutilizzata significa che l'intero parco alloca e alimenta meno hardware totale a parità di lavoro aggregato.

Stato e onestà: finché questa funzione non sarà rilasciata e non potremo descriverne l'esatto meccanismo di recupero, la presentiamo come un impegno dichiarato, non come una funzionalità attiva. Aggiorneremo questa sezione — con il meccanismo reale ed eventuali misurazioni — quando sarà disponibile.

5. Come misuriamo

Siamo espliciti sull'attuale maturità delle nostre misurazioni, invece di lasciar intendere più di quanto abbiamo:

• • Oggi: ragioniamo a partire da fatti strutturali (classe del motore, modello di tenancy) e dai dati infrastrutturali pubblicati dai provider (PUE, CFE, intensità della rete elettrica).
• • Stiamo costruendo: visibilità per tenant su calcolo ed energia, così che il cliente possa vedere l'impronta del proprio utilizzo — e il risparmio delle Finestre Eco — con risoluzione giornaliera, la stessa granularità su cui opera la pianificazione.
• • Gli standard a cui guardiamo: la rendicontazione PUE/WUE dei datacenter, la metodologia sull'energia carbon-free dei cloud provider e il pensiero riconosciuto sull'intensità di carbonio del software. Ci allineiamo a questi invece di inventare un punteggio nostro.

6. Ciò che non affermiamo (ancora)

Non diremo nessuna delle cose seguenti finché ciascuna non sarà misurata e il metodo pubblicato:

Quando una di queste diventerà dimostrabile, comparirà qui con il suo metodo, e solo allora sulla nostra pagina dedicata alla sostenibilità.

Registro delle modifiche

• • 23 giugno 2026 — Pagina creata (impostazione di posizionamento; baseline metodologica). Eco Windows e recupero indicati come roadmap.