Perché ho creato Flui

Cosa serve oggi per costruire una piattaforma cloud?#

Ho passato buona parte della mia carriera a usufruire dei migliori servizi cloud a disposizione. Ne ho sempre apprezzato la comodità, l’efficienza, la completezza, la potenza, ma soprattutto la user experience. Dietro a quelle poche azioni — configurare uno scaling group, gestire una rete privata o un firewall, creare con un clic un database managed — c’è un grande lavoro che diamo per scontato.

Se a livello professionale ho utilizzato i servizi degli hyperscaler, per varie attività personali e imprenditoriali autofinanziate ho privilegiato VPS oppure server dedicati, seguendo un percorso che molti hanno fatto: deploy con FTP, poi con i container Docker, infine Docker Compose per gestire un’applicazione che iniziava a diventare più complessa. Un database, un backend, un frontend, una cache Redis. A questo livello era già possibile gestire repliche dei componenti API. Anche quando i progetti sono diventati più articolati, con microservizi, diverse tipologie di database e sistemi di gestione delle code, riuscivo ancora a gestirli con Compose.

Il limite è arrivato quando ho dovuto gestire più progetti contemporaneamente su diversi server. Ho sentito l’esigenza di qualcosa di meno macchinoso e mi sono avvicinato a Kubernetes, in particolare alla distribuzione K3s, che includeva già buona parte di quello che mi serviva. Posso dire che è stato un amore a prima vista: era il prodotto giusto nel momento giusto. Per il flusso di lavoro a cui ero abituato mi avrebbe fatto comodo anche una UI, e l’evoluzione naturale è stata Rancher.

A questo punto qualcuno potrebbe dire: ecco, hai raggiunto il picco, hai un’infrastruttura solida per i tuoi casi d’uso. E in effetti era così, tranne per alcuni aspetti. Il provisioning delle macchine virtuali e l’ingresso dei nodi nei cluster, sui provider privi di un’integrazione già disponibile, richiedevano ulteriore automazione. Questo rendeva più macchinoso aggiungere risorse e attivare meccanismi di autoscaling nei momenti di bisogno.

Comunque nulla di ingestibile: questa configurazione mi ha permesso di dare dimora ai vari progetti in una sorta di unica piattaforma.

Nel frattempo una serie di eventi mi ha portato alla convinzione che la scelta del cloud provider non possa più essere soltanto tecnica o economica. A mio parere, è anche una questione di fiducia. Per molte aziende il cloud è diventato parte integrante del funzionamento e custodisce una parte essenziale del loro patrimonio.

Pensiamo ad esempio, a un’impresa che affida al cloud anni di ricerca, progetti e conoscenze. Anche quando tutto funziona, resta questa domanda: quanto è libera di decidere dove conservare quel patrimonio? Se cambiano le condizioni economiche, le esigenze o la fiducia nel fornitore, poter scegliere un’alternativa deve rimanere una possibilità concreta?

La stessa domanda, su una scala diversa, si potrebbe porre anche le persone, le istituzioni e le nazioni. Più le nostre attività dipendono dalle infrastrutture digitali, più conta conservare il controllo sulle scelte che le riguardano.

Fatta questa premessa, sono il primo ad appassionarmi ai servizi cloud di AWS, Azure e Google Cloud; i primi due, in particolare, li ho usati con maggiore intensità. Eppure ho sentito e sento l’esigenza di avere una scelta senza dover compromettere la user experience. Sogno uno scenario in cui, dove ci sono uno o più server collegati in rete, si possa creare una piattaforma cloud degna d’essere chiamata tale.

Molte aziende e molti servizi che utilizziamo attualmente hanno una posizione dominante, costruita con investimenti difficili da eguagliare e un modello basato su enormi data center distribuiti su scala globale.

Il vero punto qui è la ricerca di un’alternativa credibile: è un’esigenza che sento solo io oppure la avverte anche qualcun altro?

Le mie origini e il mio presente mi portano a volgere gli occhi sulle necessità di un continente sviluppato e benestante come l’Europa, ma anche dei paesi in via di sviluppo, dove si tocca con mano la sensazione di dipendere da infrastrutture che non si controllano e non si governano fino in fondo.

In Europa, come in altre regioni del mondo, ci sono fior fiore di provider che mettono a disposizione ottime risorse hardware. L’offerta di servizi, però, varia molto: alcuni si concentrano sull’infrastruttura, altri offrono anche servizi gestiti più articolati. Per le mie esigenze, non sempre trovavo sui provider che volevo utilizzare l’esperienza operativa a cui mi avevano abituato gli hyperscaler. Questo mi richiedeva di integrare e gestire direttamente diversi componenti.

Una domanda che mi sono fatto in modo sincero è: serve davvero un altro colosso per offrire un’alternativa? È realmente fattibile? O serve un approccio diverso?

La risposta che mi sono dato è che sia molto più fattibile una piattaforma che possa contare sui provider esistenti. Semplificando molto: una piattaforma cloud che utilizza le risorse dei provider A, B e C.

Un'installazione su più provider. Il control plane gira su server tuoi; object storage, DNS, email e inferenza arrivano dal provider che li offre. Il provider A offre solo server: Flui completa con il proprio firewall e compone con il DNS del provider B.

Chiaramente non sono il primo a essermi posto questa domanda e a essermi dato questa risposta. Stabilire uno standard tecnologico tra soggetti diversi richiede di conciliare visioni e interessi differenti. Per Flui ho scelto di non subordinare il progetto all’adozione di uno standard comune da parte dei fornitori.

Dal mio punto di vista, la piattaforma deve partire dai provider esistenti, dalle loro API e dalle loro capacità. Deve parlare il linguaggio di ciascun provider e fornire un’astrazione comune, senza nascondere le differenze o promettere capacità che un provider non offre.

Ovviamente tra il dire e il fare c’è di mezzo il mare, o in questo caso un sacco di commit e un sacco di componenti open source.

Astrazione delle risorse#

Da tutte queste riflessioni nasce Flui. Il primo problema che ho dovuto affrontare è l’astrazione delle risorse: la piattaforma deve chiedere sempre allo stesso modo una risorsa, a prescindere dal provider, che sia una macchina virtuale, un firewall, una VNET o altro.

Nell’integrazione tra provider gli scenari sono disparati e devono essere gestiti e normalizzati da un modulo dedicato della piattaforma. Alcuni provider possono avere i firewall, altri no; per alcuni la VNET potrebbe essere inclusa, per altri è a pagamento; alcuni hanno la fatturazione oraria, altri no; alcuni utilizzano standard aperti per le API, mentre molti hanno API proprie. Si potrebbero fare molti esempi: scherzando, potremmo dire che sono più le differenze che le similitudini.

In ogni scelta fatta durante lo sviluppo di Flui, mi sono chiesto se ci fosse una soluzione open source da adottare, adeguata a risolvere in modo efficiente il problema che avevo di fronte. In caso affermativo la soluzione veniva adottata; in caso negativo si procedeva allo sviluppo del componente richiesto.

Nel nostro caso, in particolare, ho sperimentato Terraform/OpenTofu e Pulumi. Non erano impossibili da integrare, ma nelle prove che ho fatto ho incontrato alcune difficoltà:

Incapsulare il loro modello di esecuzione dietro azioni comandate dalle API di Flui, seguendone l’avanzamento e fornendo feedback alle interfacce come la dashboard, richiedeva un adattamento che trovavo macchinoso.
La gestione dello state e dei singoli run aggiungeva meccanismi da coordinare, mentre avevo bisogno di un controllo diretto delle operazioni.
Risultati ed errori dovevano essere rimappati nel modello della piattaforma. Usando direttamente le API dei provider, questo passaggio mi risultava più immediato.
Per i provider privi di integrazioni adeguate avrei comunque dovuto implementare il dialogo con le loro API.

Ho quindi scelto di gestire l’integrazione dentro moduli dedicati, che condividono la stessa interfaccia di astrazione ma hanno la propria implementazione. Flui mantiene il ruolo di decidere quando serve una risorsa; questi moduli permettono di governarla attraverso le API del provider o un’interfaccia comune come OpenStack.

Questo permette di integrare un nuovo provider senza modifiche al core di Flui, quando le sue capacità rientrano nel contratto e nelle logiche esistenti, o con modifiche circoscritte quando è necessario estenderli.

La scelta delle API dirette comporta anche il compito di gestire attese, errori e operazioni parzialmente completate. Al momento è l’approccio che ho trovato più adatto; se domani troverò un modello migliore, potrò rivedere questa scelta.

Un altro principio emerso durante lo sviluppo, legato all’astrazione delle risorse, è il completamento da parte della piattaforma e, quando necessario, la composizione.

Facciamo un esempio concreto: la gestione dei firewall è un tassello fondamentale, ma ci possono essere provider sprovvisti di un firewall da creare via API. In questi casi l’approccio di Flui è quello del completamento: un firewall messo a disposizione dalla piattaforma, basato su nftables, mantenendo l’astrazione. La piattaforma espone quindi lo stesso modello di regole nelle interfacce come dashboard e CLI. Cambia però il punto in cui vengono applicate: sul perimetro del provider oppure sul singolo host. L’astrazione mantiene comune la gestione, mentre le caratteristiche di protezione dipendono dal meccanismo sottostante.

Una sola policy, due punti in cui applicarla: il firewall del provider intorno alle macchine, oppure il firewall di Flui dentro ciascuna.

Ci sono altre casistiche in cui entra in gioco la composizione: per servizi come DNS ed email, dove l’approccio del completamento risulta controproducente, si utilizza la funzionalità di un altro provider. Ecco uno scenario: il provider A offre solo server, il firewall lo mette a disposizione Flui e per il DNS viene usato il provider B. In questo modo Flui riesce a comporre il meglio di due provider.

Modello API key e SSH#

Durante lo sviluppo del progetto sono state previste due tipologie di installazione: una in cui Flui crea e configura i server tramite le API del provider e una in cui l’utente fornisce server già disponibili, sui quali Flui installa la piattaforma via SSH.

Come premesso sopra, la piattaforma si adatta ai provider, ma per automatizzare il provisioning richiede API documentate che permettano di gestire le risorse. Per abilitare il provisioning elastico automatico ho inoltre posto un requisito economico: la fatturazione oraria, così che aggiungere una macchina per un’esigenza temporanea non comporti il costo di un intero mese.

In assenza di queste condizioni, Flui continua a funzionare, ma cambia il modello di provisioning delle risorse: servono le credenziali SSH di una macchina creata manualmente, sulla quale Flui installa la piattaforma. In questa modalità anche il ridimensionamento dei nodi passa per un’operazione manuale.

Da server a piattaforma#

Nel momento in cui Flui provvisiona un server, inizia la fase di preparazione: configura il firewall e la rete privata, installa K3s e predispone i componenti di sistema necessari al ruolo del cluster. Quelli dedicati alla gestione della piattaforma e quelli destinati a eseguire le applicazioni hanno esigenze diverse, come vedremo tra poco. Qui non verrà esposto l’elenco completo dei componenti: il concetto che voglio trasmettere è che Flui automatizza i passaggi necessari per passare da singoli server a una piattaforma cloud.

Dai singoli server a una piattaforma: i passaggi che Flui automatizza, con componenti di sistema diversi a seconda del ruolo del cluster.

La gestione comprende il ciclo di vita dell’infrastruttura: provisioning dei server, reti private, firewall e configurazione dei nodi vengono coordinati per costruire e mantenere i cluster. Kubernetes distribuisce i workload sui nodi disponibili, mentre Flui ne gestisce la capacità, aggiungendo o rimuovendo server secondo le esigenze dei carichi e le policy stabilite dall’utente.

Flui è una piattaforma cloud che usa K3s come runtime. Ho scelto K3s per la sua semplicità, il footprint contenuto e i componenti già inclusi. I concetti e i comportamenti della piattaforma sono definiti da Flui API: applicazioni, ambienti, servizi, deployment e molte operazioni sull’infrastruttura.

È qui che prende forma la visione opinionata di Flui: le scelte su come distribuire un’applicazione, esporla, proteggerla e osservarla diventano comportamenti della piattaforma, accessibili attraverso dashboard, CLI e MCP. L’utente descrive ciò di cui ha bisogno; Flui traduce quelle richieste nelle operazioni sui provider e nelle risorse Kubernetes necessarie. Per usare la piattaforma non serve conoscere Kubernetes.

Separare gestione e applicazioni#

Un cluster è un insieme di server che lavorano come un unico ambiente per eseguire carichi come applicazioni e job in background. Kubernetes coordina questi server, distribuisce i carichi di lavoro e mantiene le applicazioni nello stato desiderato. In Flui, ogni cluster comprende anche la rete, lo storage, il provisioning dei nodi, uno scaling group, la gestione DNS e i servizi di base necessari al suo funzionamento, e può partire da un solo server.

In Flui i cluster hanno due ruoli: il control cluster ospita la piattaforma stessa, mentre i workload cluster ospitano le applicazioni dell’utente. Un unico control cluster può gestire più workload cluster, anche su provider diversi.

Nonostante sia possibile avere un unico cluster in cui eseguire sia i componenti di piattaforma sia i workload degli utenti, in ambiente di produzione è consigliato separare il cluster di controllo dai cluster di workload.

Il cluster di controllo coordina la gestione dell’installazione, ma non si trova nel percorso ordinario delle richieste verso le applicazioni. Un suo malfunzionamento temporaneo rende indisponibili dashboard, API e osservabilità centrale e interrompe le operazioni che dipendono da esso. I workload cluster continuano a eseguire le applicazioni, purché queste non dipendano da servizi ospitati sul cluster di controllo.

Topologia e networking cross provider#

Ci sono ottime ragioni per rimanere all’interno di un provider e ottime ragioni per lavorare tra provider diversi. Una delle sfide tecnologiche che Flui cerca di risolvere riguarda proprio la rete privata. I provider che mettono a disposizione una VNET permettono di collegare privatamente i server, senza far transitare quel traffico su Internet. Alcune reti si estendono tra regioni diverse, altre sono limitate alla stessa regione. L’isolamento della rete e le prestazioni sono motivi per affidarsi a questa possibilità dove disponibile.

Per i cluster creati tramite le integrazioni con i provider, Flui mantiene i nodi di ciascun cluster sullo stesso provider e utilizza la sua rete privata per il traffico Kubernetes tra i nodi. Quando manca una rete privata, Flui collega i nodi attraverso Flui network, una rete virtuale privata basata su WireGuard. Questo permette di gestire anche server forniti dall’utente senza una rete privata preesistente.

Flui permette anche una topologia cross provider: una singola installazione, con un control cluster che gestisce workload cluster distribuiti su provider diversi. Le ragioni possono essere varie:

Costi e disponibilità: scegliere il provider più adatto a ciascun workload per prezzi, caratteristiche delle macchine e capacità disponibile.
Vicinanza geografica: eseguire le applicazioni vicino agli utenti, anche dove il provider iniziale non è presente.
Policy e vincoli sui dati: collocare i workload presso fornitori e territori compatibili con le esigenze dell’organizzazione.
Resilienza: limitare l’impatto di un problema presso un singolo provider, predisponendo dove necessario strategie di recupero o failover.
Migrazione graduale: affiancare un nuovo provider e trasferire progressivamente applicazioni e dati, mantenendo un unico modello di gestione.

L’ostacolo più grande in questo contesto è la comunicazione sicura tra control cluster e workload cluster. Anche per questa esigenza viene utilizzata Flui network. Per i collegamenti tra cluster, la topologia è a stella: ogni workload cluster comunica con il control cluster per le operazioni di gestione e l’invio di log e metriche. Flui network non inoltra traffico tra workload cluster.

Il control cluster resta sul provider A e gestisce workload cluster anche sul provider B e su server tuoi. Il cluster sul provider A è raggiunto tramite la rete privata del provider, gli altri due tramite la Flui network. Tra i workload cluster non passa traffico.

Questa topologia, insieme alle funzionalità di gestione delle applicazioni e dei dati, rende possibili diversi scenari:

Separare la collocazione della gestione da quella delle applicazioni: il control cluster può restare sul provider A mentre i workload vengono distribuiti dove conviene, senza duplicare la piattaforma.
Combinare cloud e server propri: gestire nella stessa installazione cluster presso provider diversi e macchine on-premises, anche senza una rete privata preesistente tra loro.
Mantenere privati i flussi di gestione e telemetria: operazioni sui cluster, log e metriche attraversano connessioni cifrate, senza dover esporre pubblicamente gli endpoint di raccolta della telemetria.
Separare produzione e backup: mantenere un’applicazione sul provider A e conservarne i backup sul provider B.
Preparare una migrazione: mantenere l’applicazione attiva sul provider A fino al passaggio al provider B, senza cambiare strumenti e modello di gestione.

Autoscaling come decisione operativa ed economica#

Dal mio punto di vista, una caratteristica fondamentale di una piattaforma cloud è l’elasticità: poter aumentare e ridurre la capacità disponibile in funzione della domanda. In Flui volevo che fosse la piattaforma stessa ad adattare la capacità dei cluster alle esigenze dei workload, entro i limiti e con le autorizzazioni stabilite dall’utente.

Questo richiede un’osservazione continua dello stato dei cluster e dei carichi di lavoro. Come vedremo nel prossimo capitolo, raccogliere queste informazioni è una delle fondamenta della piattaforma: permette di riconoscere quando serve capacità aggiuntiva e quando è possibile rilasciarla.

Il modello parte dagli scaling group: numero minimo, target e massimo di nodi, condizioni per intervenire e criteri per scegliere le macchine da acquistare. A questi elementi si aggiungono alcune scelte:

Separazione della decisione dall’azione. Flui può rilevare la necessità di un nodo senza che questa si trasformi in un acquisto immediato. Se il provisioning automatico è abilitato e il provider lo permette, si procede entro i limiti stabiliti. In modalità manuale, invece, Flui segnala la necessità all’operatore. Con server forniti via SSH, l’operatore deve procurare e collegare la nuova macchina.
Limite anche alla spesa. Un massimo di nodi non basta a definire il costo: macchine diverse hanno prezzi diversi. Per questo il provisioning automatico richiede anche un tetto mensile al costo stimato dei nodi gestiti dallo scaling group. Questo limite riguarda la capacità di calcolo gestita dal gruppo, non l’intera fattura del provider, che può comprendere storage, traffico e altri servizi.
Gestione della disponibilità delle macchine. Un determinato taglio può essere temporaneamente esaurito. Nelle situazioni in cui la configurazione lo permette, Flui attende che la macchina torni disponibile per procedere con l’acquisto.

Uno scaling group tiene la flotta tra un minimo e un massimo, entro un limite di spesa. L'urgenza acquista dentro questi limiti; l'opportunità restituisce capacità quando non serve più.

Osservabilità come parte fondante della piattaforma#

Il comando di installazione del cluster di controllo, subito dopo aver installato K3s, procede all’installazione dello stack di osservabilità. Volevo che una nuova installazione fosse in grado di mostrare cosa stava succedendo, sia nei componenti di sistema sia nelle applicazioni, senza che questo fosse demandato a una fase successiva.

Anche qui ho integrato componenti open source: VictoriaMetrics per le metriche, Loki per i log, vmagent per la raccolta delle metriche e vmalert per la valutazione delle regole di alert.

Accanto alla possibilità di utilizzare Grafana, Flui integra la consultazione di questi dati nelle sezioni della dashboard a cui si riferiscono: stato di salute di un’applicazione, metriche di un cluster, log oppure traffico in ingresso verso un’applicazione. Dashboard, CLI e MCP accedono agli stessi dati.

Lo stack di monitoraggio risiede nel control cluster; i workload cluster hanno il minimo indispensabile per raccogliere e inviare metriche e log.

Ogni cluster invia metriche e log al control cluster, che riceve e non interroga mai. CLI, dashboard e agente leggono gli stessi dati.

L’applicazione descrive i propri bisogni con flui.yaml#

In un’architettura che vuole essere portabile by design, l’applicazione ha un ruolo centrale. I container offrono un ottimo punto di partenza: permettono di confezionare il software e le sue dipendenze in un formato riutilizzabile. Per eseguire un’applicazione, però, servono anche informazioni che l’immagine da sola non descrive: requisiti di CPU e memoria, configurazioni, storage persistente, modalità di accesso alla rete e condizioni di scaling.

Fondamentalmente mi serviva un modo per dichiarare queste esigenze insieme al codice, senza legarle al provider o alle risorse Kubernetes necessarie a realizzarle. Da queste esigenze nasce flui.yaml: un manifest che descrive come eseguire l’applicazione, quali risorse richiede, come viene raggiunta e di quali servizi ha bisogno.

Per esempio, il manifest di un’applicazione Next.js preso dagli esempi della specifica:

apiVersion: flui.cloud/v1beta1
kind: Application
metadata:
  name: marketing-site
build:
  strategy: dockerfile
  dockerfile: ./Dockerfile
  context: .
deploy:
  port: 3000
  exposure: public
  healthcheck:
    path: /api/health
  resources:
    profile: small
  scaling:
    min: 1
    max: 3
  domain:
    auto: true
    tls: true
    certificateProvider: lets-encrypt
  env:
    NODE_ENV: production
    SESSION_SECRET:
      valueFrom:
        generate: secret
        length: 48
        format: base64url

La specifica vive inoltre in un progetto separato, con schema e versionamento propri. Flui la implementa, ma altri strumenti possono implementarla a loro volta. La descrizione dell’applicazione rimane un file dell’utente, conservabile, verificabile e versionabile insieme al codice.

Database e catalogo gestiti dalla piattaforma#

Il catalogo di Flui è una raccolta di applicazioni pronte per essere installate sulla piattaforma. Ogni voce associa una o più immagini container già disponibili a un manifest flui.yaml, che descrive come eseguirle e quali configurazioni, risorse e volumi richiedono. È questo insieme a rendere il software deployabile attraverso Flui.

Gli elementi del catalogo possono essere applicazioni standalone, pronte per essere utilizzate, oppure building block come database, cache e code, pensati per essere utilizzati da altre applicazioni. Il catalogo può inoltre includere stack composti da più componenti.

Per i building block, questa integrazione ha un valore che va oltre la comodità di avere qualcosa di pronto da installare: permette di estendere i principi di portabilità di Flui anche ai servizi da cui dipendono le applicazioni.

Sui database, in particolare, il valore è più percepibile. Ho iniziato a integrare funzionalità come:

Backup, dump e restore e, per i motori già supportati, point-in-time recovery.
Migrazione tra cluster, anche su provider diversi, per i motori supportati, con meccanismi di replica e una fase di blocco delle scritture per coordinare il passaggio.
Connection pooler, console SQL, monitoraggio delle sessioni attive e collegamento automatico alle applicazioni.

La possibilità di trasferire e recuperare un database contribuisce alla portabilità dei dati, ma non equivale, da sola, a un sistema di replica geografica o failover automatico.

Queste funzionalità portano nella piattaforma alcune delle capacità dei servizi database managed, la cui configurazione autonoma richiede una certa complessità. Il supporto è ancora in evoluzione e varia tra i motori: l’obiettivo è mantenere procedure di gestione comuni anche quando cambia il provider sottostante.

Un’esperienza comune attraverso dashboard, CLI e MCP#

Dashboard, CLI e MCP sono le interfacce attraverso cui si interagisce con Flui. Si appoggiano alla stessa API e allo stesso modello di risorse, con le dovute distinzioni e gli adeguamenti per le autorizzazioni.

Alcune operazioni specifiche appartengono solo alla dashboard o alla CLI, ma la gestione ordinaria segue lo stesso modello a prescindere dall’interfaccia.

L’accesso degli agenti richiede un controllo più preciso delle credenziali. È possibile emettere token dedicati, limitandone l’accesso per area funzionale, per cluster o per singola applicazione, e distinguendo le operazioni di lettura da quelle di modifica. Un agente può così ricevere soltanto l’accesso necessario a svolgere un compito specifico, con uno scope limitato.

La piattaforma permette inoltre di individuare azioni soggette a un ciclo di approvazione: l’agente deve ottenere il consenso esplicito dell’utente oppure disporre di una precedente autorizzazione applicabile a quell’azione. Il controllo viene applicato nell’API, insieme ai normali controlli di accesso.

La scrittura di un agente diventa una richiesta; una persona risponde; l'agente ripete la stessa chiamata.

Nell’installazione avviata dalla CLI, la workstation dell’utente ha un ruolo nel sistema: conserva i riferimenti e le credenziali necessari a operare sul control plane. Questo comportamento è voluto: il centro di gestione è il control plane della propria installazione, senza richiedere un servizio centrale esterno operato da Flui per governare l’infrastruttura. Le informazioni sensibili conservate localmente, come le API key dei provider, sono protette da un vault cifrato con una chiave master sotto il controllo dell’utente. La CLI è quindi sia l’interfaccia che avvia l’installazione sia uno degli strumenti con cui viene gestita.

Scegliere, e scegliere ancora#

All’inizio cercavo un modo per ritrovare sui miei server la comodità dei servizi cloud che utilizzavo professionalmente. Costruendo Flui, quella ricerca è diventata qualcosa di più: poter comporre le capacità di provider diversi senza dover adottare l’intero ecosistema di uno solo.

Scegliere un cloud provider non dovrebbe essere una promessa fatta all’altare. Un fornitore può essere la scelta giusta oggi e non esserlo più domani. Oppure può essere ottimo per una parte della nostra architettura, mentre un altro risponde meglio ad altre esigenze.

Il cloud è la dimora dei nostri segreti più intimi e dei nostri asset più importanti. Custodisce ciò che sappiamo fare, ciò che stiamo costruendo, le nostre forze e le nostre debolezze. Tutto questo si traduce in una scelta di fiducia, mentre le esigenze delle persone, delle imprese e delle nazioni cambiano nel tempo. Ci sono paesi in piena crescita che contribuiranno sempre di più a questa economia del cloud, con necessità e priorità proprie. Non credo che un modello concentrato nelle mani di pochissimi provider sia l’unica strada possibile per rispondere a queste esigenze.

Sto lavorando affinché la libertà di scelta sia concreta: valorizzare le infrastrutture esistenti, combinare servizi, spostare applicazioni e dati, rivedere una decisione senza dover ripensare tutto ciò che ci abbiamo costruito sopra. Cambiare infrastruttura comporterà sempre del lavoro. L’obiettivo di Flui è fare in modo che quel lavoro non diventi il motivo per cui siamo costretti a restare.

Flui è ancora in evoluzione, ma è questa la direzione in cui voglio continuare a costruirlo: una piattaforma che permetta di scegliere, e di scegliere ancora.

Flui è su flui.cloud e il codice è su GitHub, con licenza AGPL-3.0. La documentazione, con tutti i concetti di questo articolo approfonditi, è su docs.flui.cloud.