Aree di competenza / Fondamenta e piattaforma / 2.2
Cloud Computing & Platform Engineering
Elasticità, senza perdere sovranità.
Il cloud ha mantenuto molte promesse: elasticità, rapidità, meno infrastruttura da gestire. Ma ha cambiato la natura della dipendenza. Oggi le domande difficili non sono tecniche: chi può accedere ai dati, sotto quale legge, con quale preavviso possono cambiare le condizioni, quanto costa andarsene.
Davanti a queste domande il mercato tende a schierarsi, per entusiasmo o per rifiuto. Noi preferiamo una mappa: quale servizio può stare dove, quale dato non deve uscire, quale carico deve restare attivo anche se il fornitore cambia idea. Costruiamo piattaforme aperte, private o ibride, descritte interamente come codice, così che si possano ricostruire altrove. E proviamo la strategia di uscita invece di limitarci a scriverla. Sappiamo portare anche il governo dei costi, perché l’elasticità senza misura diventa presto una sorpresa in fattura.
Un ente pubblico può partire dalla residenza dei dati; un ente di ricerca da uno stack interamente aperto; un’azienda da un cloud privato che assorba i picchi senza vincolarla. L’elasticità resta, la sovranità pure: è questo che intendiamo per cloud.
Quattro gruppi di competenza
Ogni gruppo ha un dettaglio tecnico per chi lo vuole.
- 2.2.a
Cloud privato e ibrido
Un cloud che resta vostro.
Realizziamo cloud privati su piattaforme aperte e li integriamo con risorse esterne per i picchi. Elasticità e self-service, senza cedere il controllo dell’infrastruttura.
Dettaglio tecnico
Il gruppo comprende le piattaforme cloud private e ibride. In produzione: cloud privato OpenStack con Ironic per il bare metal e Heat per l’orchestrazione, landing zone e disegno dei tenant, autoscaling, cloud ibrido e bursting verso risorse esterne. In progetto: FinOps per il governo dei costi e architetture serverless.
- 2.2.b
Container, orchestrazione e osservabilità
Portabilità e visibilità, insieme.
Eseguiamo applicazioni su Kubernetes, portabili tra data center, cloud ed edge. E le rendiamo osservabili con strumenti aperti, per sapere sempre che cosa sta succedendo.
Dettaglio tecnico
Il gruppo comprende container, orchestrazione e osservabilità. In produzione: Kubernetes, runtime containerd e Podman, Helm e Kustomize, API gateway e ingress, osservabilità con Prometheus, Grafana, Loki e Tempo. In progetto: OpenShift, service mesh Istio e Linkerd, OpenTelemetry. Le internal developer platform sono seguite come sviluppo.
- 2.2.c
Infrastruttura come codice e GitOps
L’infrastruttura scritta come software.
Descriviamo l’infrastruttura come codice versionato, così che ogni ambiente si possa ricostruire e ogni modifica lasci traccia. È ciò che rende possibile cambiare piattaforma.
Dettaglio tecnico
Il gruppo comprende l’infrastruttura descritta e applicata come codice. In produzione: OpenTofu per il provisioning, Ansible per la configurazione, rilascio GitOps con ArgoCD e Flux. In progetto: policy as code con OPA e Kyverno e Terraform dove già adottato dal cliente.
- 2.2.d
Sovranità e reversibilità
Sapere dove sono i dati, e come si esce.
Decidiamo con voi dove possono stare i dati e sotto quale legge, e proviamo come si porterebbero altrove. L’indipendenza da un fornitore si dimostra, non si dichiara.
Dettaglio tecnico
Il gruppo comprende la dimensione giuridica e strategica del cloud. In produzione: residenza del dato e vincoli giuridici come requisiti di progetto, disaster recovery cloud cross-region, strategia di uscita documentata e provata. La qualificazione ACN dei servizi cloud e il confidential computing sono seguiti come sviluppi del contesto.
Per il lettore tecnico
Il cloud ha risolto un problema reale, la rigidità di infrastrutture dimensionate sul picco, e ne ha introdotto uno di natura diversa: la dipendenza contrattuale e giuridica dal fornitore. Chi può accedere ai dati, sotto quale ordinamento, con quale preavviso cambiano le condizioni, quanto costa andarsene: sono domande che non si risolvono con una configurazione. Il dominio progetta piattaforme elastiche in cui queste domande hanno una risposta scritta.
Il dominio lavora su quattro gruppi. Il cloud privato e ibrido comprende in produzione OpenStack con Ironic e Heat, landing zone e disegno dei tenant, autoscaling, cloud ibrido e bursting, e in progetto FinOps e architetture serverless. I container e l’osservabilità comprendono in produzione Kubernetes, runtime containerd e Podman, Helm e Kustomize, API gateway e ingress, osservabilità con Prometheus, Grafana, Loki e Tempo, e in progetto OpenShift, service mesh e OpenTelemetry. L’infrastruttura come codice comprende in produzione OpenTofu, Ansible e rilascio GitOps con ArgoCD e Flux, e in progetto policy as code e Terraform. La sovranità e la reversibilità comprendono in produzione la residenza del dato come vincolo di progetto, il disaster recovery cross-region e la strategia di uscita documentata e provata; la qualificazione ACN e il confidential computing sono seguiti come sviluppi del contesto.
Il principio progettuale è che l’indipendenza si misura sulla possibilità concreta di spostare i carichi: una strategia di uscita esiste solo se è stata provata. Per questo si preferiscono piattaforme aperte e un’infrastruttura interamente descritta come codice.
Il dominio poggia sull’infrastruttura del dominio 2.1 e sulla catena di rilascio del dominio 2.3; riceve dal dominio 1.1 la connettività satellitare con terminazione privata; l’uscita diretta verso le region cloud è in progetto. Residenza del dato e vincoli di conformità si definiscono con il dominio 4.2.
Parliamo del vostro sistema
Raccontateci il requisito di servizio: che cosa deve funzionare, entro quanto, e che cosa succede quando qualcosa si rompe. La tecnologia la scegliamo dopo.