Vai al contenuto principale
FromNine
Menu

Ingegneria

Ingegneria cloud e di piattaforma che rende i rilasci una routine

Costruiamo fondamenta cloud e piattaforme interne per sviluppatori in cui gli ambienti sono codice, i rilasci sono firmati e ripetibili e ogni euro di spesa ha un responsabile.

Per imprese e PA italiane che devono portare applicazioni nel cloud rispettando la classificazione di dati e servizi, senza perdere il controllo dei costi.

Parliamo del Suo progettoScopra il nostro approccio
Ingegneria cloud e piattaforme: lo stack delle competenzeQuattro livelli sovrapposti in profondità. Dall’alto verso il basso: i carichi di lavoro dei team di prodotto, la piattaforma interna per sviluppatori, le pipeline di rilascio firmate e, alla base, la landing zone con identità, rete e policy.01Carichi di lavoro dei team di prodotto02Piattaforma interna per sviluppatori03Pipeline di rilascio firmate04Landing zone e policy
  1. 01Landing zone con policy as code e residenza dei dati definita per ogni carico di lavoro
  2. 02Golden path che portano un nuovo servizio in produzione in modo ripetibile
  3. 03SLO, ripristino collaudato e costo per prodotto, visibili a chi prende le decisioni

01 Problemi

Segnali che le fondamenta La stanno frenando

  1. 01

    Ogni ambiente è un caso a sé

    Test e produzione differiscono in modi che nessuno ha documentato, e le correzioni fatte a mano dalla console vanno perse alla ricostruzione successiva.

  2. 02

    Un rilascio richiede una riunione

    I deployment sono rari, manuali e pianificati di sera. I team accumulano le modifiche, e così ogni rilascio diventa più rischioso.

  3. 03

    La fattura del cloud sorprende tutti

    I costi sono visibili per sottoscrizione, non per prodotto. La capacità GPU per i carichi di IA la prenota chi la chiede per primo.

  4. 04

    Nessuno sa se il ripristino funziona

    I backup esistono. I ripristini non sono mai stati provati, e tempi di ripristino e soglie di perdita dei dati non sono mai stati concordati con il business.

02 Ambiti di intervento

Che cosa realizziamo

  1. 01 Landing zone e opzioni di sovranità

    Struttura di account e sottoscrizioni, identità, rete e guardrail sui principali hyperscaler e sulle offerte di cloud sovrano europeo, con policy as code e residenza dei dati per ogni carico di lavoro.

    Che cosa facciamo

    • Progettazione di organizzazione, management group e account
    • Rete hub, controllo del traffico in uscita e connettività privata
    • Policy as code per residenza, cifratura e tagging
    • Corrispondenza con le attestazioni richieste dai Suoi clienti, come BSI C5 o SecNumCloud

    Che cosa riceve

    • Landing zone definita interamente come codice
    • Libreria di policy con processo di gestione delle eccezioni
    • Documento sulle opzioni di sovranità per classe di carico di lavoro

  2. 02 Infrastructure as code e piattaforme interne per sviluppatori

    Terraform oppure OpenTofu e Bicep per l’infrastruttura, GitOps per i deployment, Kubernetes o runtime gestiti dove sono adatti e golden path con cui un team avvia un servizio conforme senza aprire ticket.

    Che cosa facciamo

    • Libreria di moduli infrastructure as code
    • GitOps con promozione tra ambienti
    • Piattaforma Kubernetes o alternative gestite
    • Template di servizio e un portale per sviluppatori

    Che cosa riceve

    • Piattaforma interna per sviluppatori con golden path
    • Ambienti in self-service
    • Roadmap della piattaforma gestita da un platform team

  3. 03 Pipeline di rilascio e sicurezza della supply chain

    Pipeline che compilano una sola volta, firmano gli artefatti, registrano la provenienza in linea con SLSA, gestiscono correttamente i segreti e promuovono lo stesso artefatto dal test alla produzione.

    Che cosa facciamo

    • Template di pipeline con controlli di qualità e sicurezza
    • Firma degli artefatti e attestazione della provenienza
    • Gestione dei segreti e rotazione delle chiavi
    • Regole di promozione e registrazione delle modifiche

    Che cosa riceve

    • Template di pipeline riutilizzabili
    • Artefatti firmati con provenienza verificabile
    • Evidenze di rilascio per il change management

  4. 04 Osservabilità e SRE

    Service level objective concordati con il business, error budget che guidano il ritmo dei rilasci, OpenTelemetry su tutto lo stack e un processo di gestione degli incidenti che, dove applicabili, soddisfa anche gli obblighi di notifica di NIS2 e DORA.

    Che cosa facciamo

    • Definizione degli SLO con i responsabili dei servizi
    • Strumentazione OpenTelemetry e dashboard
    • Allarmi sui sintomi, non sulle cause
    • Gestione degli incidenti e analisi post-incidente

    Che cosa riceve

    • Catalogo degli SLO
    • Stack di osservabilità e dashboard
    • Runbook per incidenti e notifiche

  5. 05 FinOps e capacità per l’IA

    Allocazione dei costi per prodotto e per team, metriche di costo unitario come il costo per transazione, pianificazione della capacità GPU e controllo dei costi per i carichi di lavoro di IA.

    Che cosa facciamo

    • Policy di tagging e modello di allocazione
    • Metriche di costo unitario per prodotto
    • Pianificazione di impegni di spesa e istanze riservate
    • Schedulazione GPU, quote e dimensionamento corretto

    Che cosa riceve

    • Dashboard dei costi per ciascun product owner
    • Backlog dei risparmi con responsabili
    • Piano di capacità per l’IA

  6. 06 Ripristino e strategia di uscita

    Backup e disaster recovery con obiettivi espliciti di tempo e punto di ripristino, collaudati a cadenza regolare, e una strategia di uscita che sfrutta i diritti di cambio fornitore previsti dal Data Act europeo.

    Che cosa facciamo

    • RTO e RPO concordati per ciascun servizio
    • Test di ripristino e di failover
    • Mappatura delle dipendenze dei servizi critici
    • Piano di uscita e verifiche di portabilità dei dati

    Che cosa riceve

    • Procedure di ripristino collaudate
    • Report dei test di ripristino
    • Strategia di uscita documentata

03 Architettura

Un’architettura di riferimento illustrativa

Il codice entra da sinistra e i carichi di lavoro in esecuzione escono a destra. Nel mezzo, la pipeline firma ciò che compila, il registry conserva solo artefatti firmati e un controller GitOps li promuove da un ambiente all’altro nel rispetto delle policy.

Alla base c’è la landing zone: struttura organizzativa, identità, rete, chiavi, ripristino e controllo dei costi, definiti una sola volta come codice e condivisi da tutti i team di prodotto.

Livelli del diagramma

Rilascio
Repository, pipeline, artefatti firmati e promozione GitOps.
Piattaforma
La piattaforma per sviluppatori, le policy as code e il runtime su cui i team di prodotto rilasciano.
Landing zone
Organizzazione, identità, rete, chiavi, ripristino e controlli FinOps.
Esercizio
Telemetria, SLO, error budget e risposta agli incidenti su tutto l’insieme.
Esempio illustrativo

  1. Rilascio

    • Repository di codice e IaC
    • Compilare, firmare, attestare
    • Registry di artefatti firmati
    • Promozione GitOps

  2. Piattaforma

    • Piattaforma per sviluppatori e golden path
    • Policy as code
    • Kubernetes e servizi gestiti
    • Carichi di lavoro dei team di prodotto

  3. Landing zone

    • Struttura di gestione
    • Identità e accessi
    • Hub di rete e traffico in uscita
    • Chiavi e segreti
    • Backup e ripristino
    • Allocazione dei costi

  4. Esercizio

    • OpenTelemetry, SLO ed error budget, risposta agli incidenti
Rilascio firmato su una landing zone governata da policy

Architettura illustrativa, non un sistema di un cliente.

Leggere il diagramma in forma testuale

Il percorso principale va dai repository di codice e infrastruttura, attraverso pipeline che compilano, firmano e attestano, a un registry degli artefatti, poi a un controller GitOps e infine agli spoke che ospitano i carichi di lavoro dei team di prodotto.

Una piattaforma interna per sviluppatori mette a disposizione golden path verso le pipeline. Le policy as code vincolano il controller GitOps. Una piattaforma di runtime con Kubernetes e servizi gestiti ospita i carichi di lavoro. Le chiavi gestite dal cliente alimentano il livello delle policy.

La landing zone sottostante comprende struttura di gestione, identità e accessi, un hub di rete, chiavi, backup e ripristino e controlli FinOps. L’osservabilità con SLO e risposta agli incidenti copre l’intera piattaforma.

04 Considerazioni e limiti

Scelte progettuali e limiti

  • La sovranità è uno spettro

    Come lo affrontiamo

    Classifichiamo i carichi di lavoro per sensibilità e associamo a ogni classe un’opzione: region UE di un hyperscaler, un’offerta di cloud sovrano o un’infrastruttura privata. I compromessi in termini di funzionalità, costi ed esercizio vengono messi per iscritto.

    Limiti e dipendenze

    Le offerte sovrane sono spesso in ritardo sui servizi gestiti, compresi quelli di IA. Alcuni carichi di lavoro costeranno di più o faranno meno, ed è una scelta di business.

  • Una piattaforma ha bisogno di un product owner

    Come lo affrontiamo

    Trattiamo la piattaforma interna come un prodotto, con utenti, roadmap e cicli di feedback, e La aiutiamo a costituire il team che la gestisce.

    Limiti e dipendenze

    Una piattaforma senza team diventa un collo di bottiglia. Se non può assegnarle un team, Le consiglieremo servizi gestiti e meno livelli di astrazione.

  • Le norme plasmano l’esercizio

    Come lo affrontiamo

    Dove NIS2 o DORA La riguardano, classificazione degli incidenti, tempi di notifica e raccolta delle evidenze sono integrati nel processo di gestione degli incidenti.

    Limiti e dipendenze

    Stabilire se la Sua organizzazione rientra nel perimetro e come si applica il recepimento nazionale resta compito dei Suoi team legali e di compliance.

  • Il controllo dei costi è condiviso

    Come lo affrontiamo

    Rendiamo i costi visibili per prodotto e aggiungiamo guardrail come budget, quote e spegnimento programmato degli ambienti inattivi.

    Limiti e dipendenze

    I risparmi maggiori derivano di solito dalle scelte di architettura e di utilizzo dei product owner, non dalla sola piattaforma.

05 Come lavoriamo

Come lavoriamo

Prima le fondamenta, poi un team sul golden path, poi tutti gli altri.

  1. 01

    Analizzare e classificare

    Carichi di lavoro, sensibilità dei dati, costi attuali e controlli attesi dai Suoi auditor.

    RisultatoClassificazione dei carichi di lavoro e opzioni di destinazione

  2. 02

    Costruire la landing zone

    Tutto come codice, rivisto con la sicurezza, con un processo per le eccezioni.

    RisultatoLanding zone in produzione

  3. 03

    Accompagnare un team pilota

    Un team di prodotto passa al golden path; le difficoltà che incontra danno forma alla piattaforma.

    RisultatoPrimo servizio sulla piattaforma

  4. 04

    Estendere e passare le consegne

    Altri team adottano la piattaforma, il platform team ne assume la responsabilità e il ripristino viene collaudato a cadenza regolare.

    RisultatoRoadmap della piattaforma e report dei test di ripristino

06 Controllo umano

Dove il controllo resta alle persone

L’automazione gestisce la piattaforma. Le decisioni che comportano rischi o costi restano alle persone.

  • Le modifiche in produzione sono tracciabili

    Ogni modifica in produzione nasce da un commit revisionato, quindi chi ha cambiato che cosa e chi l’ha approvato risulta agli atti.

  • L’accesso di emergenza è raro e registrato

    L’accesso break-glass è limitato nel tempo, va motivato ed è sottoposto a verifica successiva.

  • Le eccezioni alle policy hanno un responsabile

    Quando un carico di lavoro richiede un’eccezione a un guardrail, la approva un responsabile del rischio designato, con una data di scadenza.

  • Gli obiettivi li fissano i responsabili dei servizi

    Obiettivi di ripristino e livelli di servizio vengono concordati con il responsabile di business di ciascun servizio, non fissati dal solo platform team.

07 Tecnologie

Tecnologie con cui lavoriamo

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Offerte di cloud sovrano europeo
Infrastruttura e rilascio
  • Terraform e OpenTofu
  • Bicep
  • Argo CD e Flux
  • GitHub Actions, GitLab CI e Azure DevOps
Runtime
  • Kubernetes e varianti gestite
  • Piattaforme serverless e a container
  • Service mesh dove conviene
  • Node pool GPU per i carichi di lavoro di IA
Esercizio
  • OpenTelemetry
  • Prometheus e Grafana
  • Monitoraggio cloud-native
  • Policy engine come OPA

La citazione di una tecnologia descrive la nostra esperienza di ingegneria. Non implica una partnership con il relativo fornitore né la sua approvazione.

08 Esempio

Un esempio illustrativo

Esempio illustrativo

Un comune che porta i propri servizi nel cloud qualificato

01Situazione
Un comune capoluogo gestisce tributi, servizi demografici e protocollo su server in un locale tecnico che nessuno vuole più mantenere, e deve completare la migrazione avviata con i fondi del PNRR.
02Che cosa realizzeremmo
Una classificazione di dati e servizi, una landing zone in codice su servizi cloud qualificati ACN per il livello richiesto e un piano di migrazione per ondate, con prove di ripristino.
03Dove decidono le persone
Il responsabile per la transizione al digitale approva classificazione e ondate; ogni eccezione alle policy di sicurezza richiede il suo via libera.
04Che cosa misureremmo
Servizi migrati per ondata, tempi di ripristino verificati, costi di esercizio rispetto alla situazione precedente.

09 Settori

Nel Suo settore

  • Pubblica Amministrazione

    Opzioni di sovranità per classe di dati, attestazioni nazionali di sicurezza e piani di uscita che reggono anche alla gara successiva.

  • Servizi finanziari

    Resilienza operativa secondo DORA: ripristino collaudato, supervisione dei fornitori terzi di servizi ICT e notifica degli incidenti integrata nell’esercizio.

Italia

Cloud per la PA e NIS2 in Italia

La Strategia Cloud Italia chiede alle amministrazioni di classificare dati e servizi come ordinari, critici o strategici e di migrarli verso infrastrutture e servizi cloud qualificati dall’ACN, con il Polo Strategico Nazionale per i casi più delicati. Per i soggetti essenziali e importanti, pubblici e privati, il D.Lgs. 138/2024 recepisce la NIS2: registrazione presso l’ACN, misure di sicurezza e notifica degli incidenti al CSIRT Italia.

Progettiamo landing zone in cui residenza dei dati, registri e classificazione degli incidenti sono policy nel codice, e verifichiamo che i servizi scelti abbiano la qualificazione richiesta.

Domande su ingegneria cloud e piattaforme

Quale cloud provider ci consigliate?

Quello adatto ai Suoi carichi di lavoro, ai contratti in essere e ai Suoi requisiti di sovranità. Lavoriamo con i principali hyperscaler e con le offerte sovrane europee, e documentiamo i compromessi perché la scelta possa essere difesa in sede di gara e riconsiderata in seguito.

Ci serve Kubernetes?

Non sempre. Kubernetes ripaga quando si gestiscono molti servizi e c’è un team in grado di far funzionare la piattaforma. Per pochi servizi, le piattaforme gestite a container o serverless sono spesso più semplici ed economiche da gestire.

Come affrontate la sicurezza?

La sicurezza è integrata nella landing zone e nelle pipeline: identità a privilegio minimo, policy as code, artefatti firmati e segreti mai presenti nel codice. FromNine stessa è certificata ISO/IEC 27001 per la gestione della sicurezza delle informazioni.

Potete ridurre i nostri costi cloud?

Di solito sì, ma non promettiamo una percentuale prima di aver visto i dati. Partiamo dal rendere visibili i costi per prodotto, poi lavoriamo su un backlog di risparmi con i responsabili in grado di agire.

Come evitiamo il lock-in?

Scegliendo con consapevolezza dove dipendere da servizi specifici di un provider, mantenendo l’infrastruttura come codice e disponendo di un piano di uscita documentato e collaudato. Il Data Act europeo rafforza i Suoi diritti di cambio fornitore; un piano di uscita li rende esercitabili.

Ci mostri i prossimi tre rilasci

Le diremo che cosa li renderebbe una routine e quanto costerebbe costruire e gestire quella piattaforma, partendo da una prima valutazione con il Suo team IT.

Parliamo del Suo progettoScoprire il nostro approccio