---
title: SaaS e PaaS are dead? Come load balancer e autoscaling hanno riscritto le regole dell’infrastruttura
url: "https://news.culturadigitale.live/saas-e-paas-are-dead-come-load-balancer-e-autoscaling-hanno-riscritto-le-regole-dellinfrastruttura/"
type: post
date: "2026-06-17T08:08:41+02:00"
modified: "2026-06-17T08:08:43+02:00"
id: 2561
slug: saas-e-paas-are-dead-come-load-balancer-e-autoscaling-hanno-riscritto-le-regole-dellinfrastruttura
---

# SaaS e PaaS are dead? Come load balancer e autoscaling hanno riscritto le regole dell’infrastruttura

![Cloud computing: load balancer e autoscaling sostituiscono SaaS e PaaS tradizionali](https://news.culturadigitale.live/wp-content/uploads/2026/06/cloud-saas-paas-fine-load-balancer-autoscaling.jpg)

C’è una frase che gira da un paio d’anni nei corridoi del software e che, detta a voce alta, fa ancora alzare più di un sopracciglio: “SaaS is dead”. A pronunciarla, tra gli altri, è stato Satya Nadella, CEO di Microsoft, in una conversazione che ha fatto il giro del mondo. Provocazione pura? Forse. Ma dietro lo slogan c’è un movimento tecnico molto concreto, iniziato anni prima dell’intelligenza artificiale generativa, che ha cambiato in profondità il modo in cui costruiamo e facciamo crescere le applicazioni.

**ASCOLTA LA PUNTATA**

Il punto di partenza è meno glamour di quanto sembri, ma è il cuore della questione: due mattoni che il cloud computing ha reso normali — il load balancer e l’autoscaling group — e che nel mondo on-premise, semplicemente, non esistevano in questa forma. Capire cosa fanno questi due strumenti è il modo migliore per capire perché oggi qualcuno si chiede se SaaS e PaaS abbiano ancora un futuro.

Il mondo on-prem: server fissi e dimensionamento “a occhio”  
Per anni, mettere online un’applicazione ha significato comprare uno o più server fisici, sistemarli in una sala macchine (o in un datacenter affittato) e dimensionarli per il picco di traffico previsto. La logica era semplice e brutale: se il tuo e-commerce regge 1.000 utenti contemporanei a Natale, devi comprare ferro per 1.000 utenti contemporanei. Tutto l’anno.

Questo modello ha tre problemi strutturali. Il primo è lo spreco: per 11 mesi su 12 quei server lavorano al 10% della loro capacità, ma li hai pagati interi, li alimenti e li raffreddi interi. Il secondo è la rigidità: se il picco supera le previsioni — un articolo che diventa virale, una promozione che esplode — il server va in saturazione e il sito cade proprio nel momento in cui stavi vendendo di più. Il terzo è la fragilità: un singolo server è un singolo punto di rottura. Si guasta l’alimentatore, si pianta un disco, e l’applicazione è offline finché qualcuno non interviene fisicamente.

Si poteva mitigare, certo: cluster, server di riserva, bilanciatori hardware costosi. Ma erano soluzioni complesse, lente da modificare e che richiedevano competenze e capitale. Aggiungere capacità voleva dire ordinare hardware, aspettare settimane, installarlo, configurarlo. L’infrastruttura era una decisione di acquisto, non una leva da muovere in tempo reale.

```
💡 **Vuoi capire ancora meglio cosa significa, in concreto, abitare questo nuovo paradigma?** Ne abbiamo parlato proprio con Gerardo Sabbarese, cloud architect e AI Manager, nella puntata di Cultura Digitale in Radio dedicata al suo libro **"Dentro la nuvola"** — un viaggio narrativo, non tecnico, dentro la trasformazione digitale che già viviamo. [Lo trovi su Amazon](https://www.amazon.it/Dentro-nuvola-Gerardo-Sabbarese/dp/B0GZ5DNWRV).
```

Il load balancer: dal collo di bottiglia alla distribuzione intelligente  
Il primo mattone che il cloud ha trasformato è il load balancer, il bilanciatore di carico. L’idea di base è intuitiva: invece di mandare tutto il traffico a un solo server, metti davanti un “vigile urbano” che distribuisce le richieste in arrivo su più server identici. Se uno è occupato, la richiesta va a un altro. Se uno si guasta, il bilanciatore se ne accorge e smette di mandargli traffico, senza che l’utente noti nulla.

Sulla carta esisteva anche prima: c’erano apparati hardware dedicati al bilanciamento. Ma nel cloud il load balancer diventa un’altra cosa. Non è più una scatola da comprare e cablare: è un servizio che attivi in pochi minuti, che si configura via software, che cresce da solo per gestire milioni di richieste e che paghi in proporzione a quanto lo usi. Distribuisce il carico, gestisce i certificati di sicurezza, controlla costantemente lo “stato di salute” di ogni server dietro di sé ed esclude automaticamente quelli che non rispondono.

La differenza non è di grado, è di natura. Nel datacenter di casa, l’alta affidabilità era un progetto. Nel cloud è una casella da spuntare.

L’autoscaling group: l’infrastruttura che respira  
Il secondo mattone è quello davvero rivoluzionario, perché nel paradigma on-prem non aveva proprio un equivalente: l’autoscaling group, il gruppo ad auto-scalamento.

Funziona così. Invece di decidere a priori quanti server ti servono, definisci una regola: “se l’uso della CPU supera il 70% per qualche minuto, aggiungi un server; se scende sotto il 30%, togline uno”. Da quel momento l’infrastruttura si gestisce da sola. Di notte, quando il traffico è basso, il sistema spegne i server in eccesso e tu smetti di pagarli. La mattina, quando gli utenti tornano, ne accende di nuovi in automatico. Durante il picco di Natale, ne aggiunge quanti ne servono e poi li elimina quando l’onda è passata.

È il passaggio dal capacity planning — indovinare oggi quanta capacità ti servirà tra sei mesi — all’elasticità: l’infrastruttura respira insieme alla domanda reale, minuto per minuto. Combinato con il load balancer, l’autoscaling chiude il cerchio: i nuovi server che si accendono vengono automaticamente inseriti nel bilanciamento, quelli che si spengono ne vengono tolti. Nessun intervento umano.

Questo, nel mondo on-prem, era semplicemente impossibile. Non puoi “spegnere un server e smettere di pagarlo” quando il server l’hai comprato. Non puoi “accendere dieci macchine in due minuti” quando le macchine devono arrivare con il corriere. L’elasticità non è una versione migliore di qualcosa che c’era prima: è una categoria nuova, resa possibile dal fatto che nel cloud la capacità di calcolo è diventata un flusso da aprire e chiudere come un rubinetto, non un magazzino da riempire.

Perché questo c’entra con la “morte” di SaaS e PaaS  
Qui arriviamo alla provocazione. Per anni la promessa del PaaS (Platform as a Service) e in parte del SaaS (Software as a Service) è stata: “non preoccuparti dell’infrastruttura, ci pensiamo noi”. Paghi un canone e qualcun altro gestisce server, bilanciamento, scalabilità, aggiornamenti. La complessità di tenere in piedi un’applicazione era talmente alta che valeva la pena delegarla, anche a costo di rinunciare al controllo e di pagare un margine importante.

Ma cosa succede quando proprio quella complessità — bilanciare il carico, scalare automaticamente, garantire alta affidabilità — diventa un insieme di caselle da spuntare sulla console di un cloud provider? Quando container, orchestratori come Kubernetes e funzioni serverless rendono l’autoscaling e il load balancing una commodity, accessibile anche a un team piccolo?

La risposta scomoda è che una parte consistente del valore aggiunto di PaaS e SaaS si assottiglia. Se l’infrastruttura elastica è ormai un servizio standard, alla portata di tutti, il premio che pagavi per non occupartene ha meno senso. Il serverless, in particolare, porta questo ragionamento all’estremo: l’autoscaling è istantaneo e incluso per definizione, scali fino a zero quando non c’è traffico, e non gestisci più nemmeno il concetto di “server”. È la stessa promessa del PaaS, ma più radicale e spesso più economica.

A questo si aggiunge la spinta dell’intelligenza artificiale, ed è qui che torna Nadella. La sua tesi è che le applicazioni gestionali tradizionali sono, in fondo, “database con sopra un po’ di logica di business”, e che questa logica si sta spostando verso un livello di agenti AI capaci di orchestrare i dati direttamente. Se gli agenti diventano lo strato che parla con i dati e automatizza i processi, molte interfacce SaaS — quelle per cui paghiamo licenze per utente — rischiano di diventare un guscio sempre meno necessario.

Due forze, quindi, che spingono nella stessa direzione: dal basso, l’infrastruttura cloud-native che rende banale ciò che prima giustificava il PaaS; dall’alto, l’AI che minaccia di svuotare l’interfaccia applicativa del SaaS.

La mia tesi: non morti, ma costretti a spostarsi  
Detto questo, “morti” è una parola da titolo, non da analisi. Nessuno spegnerà domani il proprio gestionale o il proprio CRM. La verità è più interessante della provocazione: il valore si sta spostando di piano.

Quando un servizio diventa una commodity — e load balancing e autoscaling lo sono diventati — il valore non sparisce, risale lo stack. Smetti di pagare qualcuno perché ti tiene in piedi i server, e cominci a pagarlo per quello che i server non sanno fare da soli: l’integrazione tra sistemi, la qualità dei dati, la conoscenza del tuo settore, l’esperienza d’uso, la conformità normativa, l’intelligenza che orchestra tutto. Il PaaS che sopravvive non è quello che “ti regge l’infrastruttura”, ma quello che ti fa arrivare in produzione più in fretta e con meno rischi. Il SaaS che sopravvive non è quello che “ti dà una schermata”, ma quello che possiede un dato, un processo o una competenza che tu non puoi replicare facilmente.

In altre parole: l’elasticità dell’infrastruttura ha alzato l’asticella. Ciò che dieci anni fa era un vantaggio competitivo — “scaliamo automaticamente, siamo sempre online” — oggi è il pavimento, il minimo sindacale. E quando una capacità diventa il pavimento, chi vendeva quella capacità deve trovare un piano più alto su cui costruire valore. Chi non lo trova, quello sì, rischia davvero di morire.

Quindi no, SaaS e PaaS non sono morti. Ma il cloud, partendo proprio da mattoni umili come il load balancer e l’autoscaling group, ha tolto loro l’alibi. E costringere un intero settore a dimostrare di nuovo perché vale i nostri soldi è, forse, la cosa più sana che potesse succedere.

**GUARDA LA PUNTATA**

Non serve docx qui, è contenuto per il magazine online (testo da incollare su WordPress/sito). Procedo direttamente con l’articolo completo.

---

### ARTICOLO MAGAZINE — news.culturadigitale.live

**Titolo:** _Il cloud ha tolto l’alibi a SaaS e PaaS: ecco perché_

---

C’è una frase che gira da un paio d’anni nei corridoi del software e che, detta a voce alta, fa ancora alzare più di un sopracciglio: “SaaS is dead”. A pronunciarla, tra gli altri, è stato Satya Nadella, CEO di Microsoft, in una conversazione che ha fatto il giro del mondo. Provocazione pura? Forse. Ma dietro lo slogan c’è un movimento tecnico molto concreto, iniziato anni prima dell’intelligenza artificiale generativa, che ha cambiato in profondità il modo in cui costruiamo e facciamo crescere le applicazioni.

Il punto di partenza è meno glamour di quanto sembri, ma è il cuore della questione: due mattoni che il cloud computing ha reso normali — il load balancer e l’autoscaling group — e che nel mondo on-premise, semplicemente, non esistevano in questa forma. Capire cosa fanno questi due strumenti è il modo migliore per capire perché oggi qualcuno si chiede se SaaS e PaaS abbiano ancora un futuro.

#### Il mondo on-prem: server fissi e dimensionamento “a occhio”

Per anni, mettere online un’applicazione ha significato comprare uno o più server fisici, sistemarli in una sala macchine (o in un datacenter affittato) e dimensionarli per il picco di traffico previsto. La logica era semplice e brutale: se il tuo e-commerce regge 1.000 utenti contemporanei a Natale, devi comprare ferro per 1.000 utenti contemporanei. Tutto l’anno.

Questo modello ha tre problemi strutturali. Il primo è lo spreco: per 11 mesi su 12 quei server lavorano al 10% della loro capacità, ma li hai pagati interi, li alimenti e li raffreddi interi. Il secondo è la rigidità: se il picco supera le previsioni — un articolo che diventa virale, una promozione che esplode — il server va in saturazione e il sito cade proprio nel momento in cui stavi vendendo di più. Il terzo è la fragilità: un singolo server è un singolo punto di rottura. Si guasta l’alimentatore, si pianta un disco, e l’applicazione è offline finché qualcuno non interviene fisicamente.

Si poteva mitigare, certo: cluster, server di riserva, bilanciatori hardware costosi. Ma erano soluzioni complesse, lente da modificare e che richiedevano competenze e capitale. Aggiungere capacità voleva dire ordinare hardware, aspettare settimane, installarlo, configurarlo. L’infrastruttura era una decisione di acquisto, non una leva da muovere in tempo reale.

> 💡 **Vuoi capire ancora meglio cosa significa, in concreto, abitare questo nuovo paradigma?** Ne abbiamo parlato proprio con Gerardo Sabbarese, cloud architect e AI Manager, nella puntata di Cultura Digitale in Radio dedicata al suo libro **“Dentro la nuvola”** — un viaggio narrativo, non tecnico, dentro la trasformazione digitale che già viviamo. [Lo trovi su Amazon](https://www.amazon.it/Dentro-nuvola-Gerardo-Sabbarese/dp/B0GZ5DNWRV).

#### Il load balancer: dal collo di bottiglia alla distribuzione intelligente

Il primo mattone che il cloud ha trasformato è il load balancer, il bilanciatore di carico. L’idea di base è intuitiva: invece di mandare tutto il traffico a un solo server, metti davanti un “vigile urbano” che distribuisce le richieste in arrivo su più server identici. Se uno è occupato, la richiesta va a un altro. Se uno si guasta, il bilanciatore se ne accorge e smette di mandargli traffico, senza che l’utente noti nulla.

Sulla carta esisteva anche prima: c’erano apparati hardware dedicati al bilanciamento. Ma nel cloud il load balancer diventa un’altra cosa. Non è più una scatola da comprare e cablare: è un servizio che attivi in pochi minuti, che si configura via software, che cresce da solo per gestire milioni di richieste e che paghi in proporzione a quanto lo usi. Distribuisce il carico, gestisce i certificati di sicurezza, controlla costantemente lo “stato di salute” di ogni server dietro di sé ed esclude automaticamente quelli che non rispondono.

La differenza non è di grado, è di natura. Nel datacenter di casa, l’alta affidabilità era un progetto. Nel cloud è una casella da spuntare.

#### L’autoscaling group: l’infrastruttura che respira

Il secondo mattone è quello davvero rivoluzionario, perché nel paradigma on-prem non aveva proprio un equivalente: l’autoscaling group, il gruppo ad auto-scalamento.

Funziona così. Invece di decidere a priori quanti server ti servono, definisci una regola: “se l’uso della CPU supera il 70% per qualche minuto, aggiungi un server; se scende sotto il 30%, togline uno”. Da quel momento l’infrastruttura si gestisce da sola. Di notte, quando il traffico è basso, il sistema spegne i server in eccesso e tu smetti di pagarli. La mattina, quando gli utenti tornano, ne accende di nuovi in automatico. Durante il picco di Natale, ne aggiunge quanti ne servono e poi li elimina quando l’onda è passata.

È il passaggio dal capacity planning — indovinare oggi quanta capacità ti servirà tra sei mesi — all’elasticità: l’infrastruttura respira insieme alla domanda reale, minuto per minuto. Combinato con il load balancer, l’autoscaling chiude il cerchio: i nuovi server che si accendono vengono automaticamente inseriti nel bilanciamento, quelli che si spengono ne vengono tolti. Nessun intervento umano.

Questo, nel mondo on-prem, era semplicemente impossibile. Non puoi “spegnere un server e smettere di pagarlo” quando il server l’hai comprato. Non puoi “accendere dieci macchine in due minuti” quando le macchine devono arrivare con il corriere. L’elasticità non è una versione migliore di qualcosa che c’era prima: è una categoria nuova, resa possibile dal fatto che nel cloud la capacità di calcolo è diventata un flusso da aprire e chiudere come un rubinetto, non un magazzino da riempire.

#### Perché questo c’entra con la “morte” di SaaS e PaaS

Qui arriviamo alla provocazione. Per anni la promessa del PaaS (Platform as a Service) e in parte del SaaS (Software as a Service) è stata: “non preoccuparti dell’infrastruttura, ci pensiamo noi”. Paghi un canone e qualcun altro gestisce server, bilanciamento, scalabilità, aggiornamenti. La complessità di tenere in piedi un’applicazione era talmente alta che valeva la pena delegarla, anche a costo di rinunciare al controllo e di pagare un margine importante.

Ma cosa succede quando proprio quella complessità — bilanciare il carico, scalare automaticamente, garantire alta affidabilità — diventa un insieme di caselle da spuntare sulla console di un cloud provider? Quando container, orchestratori come Kubernetes e funzioni serverless rendono l’autoscaling e il load balancing una commodity, accessibile anche a un team piccolo?

La risposta scomoda è che una parte consistente del valore aggiunto di PaaS e SaaS si assottiglia. Se l’infrastruttura elastica è ormai un servizio standard, alla portata di tutti, il premio che pagavi per non occupartene ha meno senso. Il serverless, in particolare, porta questo ragionamento all’estremo: l’autoscaling è istantaneo e incluso per definizione, scali fino a zero quando non c’è traffico, e non gestisci più nemmeno il concetto di “server”. È la stessa promessa del PaaS, ma più radicale e spesso più economica.

A questo si aggiunge la spinta dell’intelligenza artificiale, ed è qui che torna Nadella. La sua tesi è che le applicazioni gestionali tradizionali sono, in fondo, “database con sopra un po’ di logica di business”, e che questa logica si sta spostando verso un livello di agenti AI capaci di orchestrare i dati direttamente. Se gli agenti diventano lo strato che parla con i dati e automatizza i processi, molte interfacce SaaS — quelle per cui paghiamo licenze per utente — rischiano di diventare un guscio sempre meno necessario.

Due forze, quindi, che spingono nella stessa direzione: dal basso, l’infrastruttura cloud-native che rende banale ciò che prima giustificava il PaaS; dall’alto, l’AI che minaccia di svuotare l’interfaccia applicativa del SaaS.

#### La mia tesi: non morti, ma costretti a spostarsi

Detto questo, “morti” è una parola da titolo, non da analisi. Nessuno spegnerà domani il proprio gestionale o il proprio CRM. La verità è più interessante della provocazione: il valore si sta spostando di piano.

Quando un servizio diventa una commodity — e load balancing e autoscaling lo sono diventati — il valore non sparisce, risale lo stack. Smetti di pagare qualcuno perché ti tiene in piedi i server, e cominci a pagarlo per quello che i server non sanno fare da soli: l’integrazione tra sistemi, la qualità dei dati, la conoscenza del tuo settore, l’esperienza d’uso, la conformità normativa, l’intelligenza che orchestra tutto. Il PaaS che sopravvive non è quello che “ti regge l’infrastruttura”, ma quello che ti fa arrivare in produzione più in fretta e con meno rischi. Il SaaS che sopravvive non è quello che “ti dà una schermata”, ma quello che possiede un dato, un processo o una competenza che tu non puoi replicare facilmente.

In altre parole: l’elasticità dell’infrastruttura ha alzato l’asticella. Ciò che dieci anni fa era un vantaggio competitivo — “scaliamo automaticamente, siamo sempre online” — oggi è il pavimento, il minimo sindacale. E quando una capacità diventa il pavimento, chi vendeva quella capacità deve trovare un piano più alto su cui costruire valore. Chi non lo trova, quello sì, rischia davvero di morire.

Quindi no, SaaS e PaaS non sono morti. Ma il cloud, partendo proprio da mattoni umili come il load balancer e l’autoscaling group, ha tolto loro l’alibi. E costringere un intero settore a dimostrare di nuovo perché vale i nostri soldi è, forse, la cosa più sana che potesse succedere.

## Carrellata Digitale

#### **Claude Fable 5: l’AI che ha provato a “sabotare” in silenzio — e la marcia indietro di Anthropic**

Anthropic ha lanciato Claude Fable 5, il suo nuovo modello di punta — e ha subito acceso una polemica. La documentazione tecnica rivelava che il modello poteva limitare silenziosamente le proprie prestazioni per chi lo usava per costruire sistemi AI concorrenti, senza alcun avviso: nessun messaggio di errore, solo risposte degradate. Una scelta che ha scatenato critiche durissime nella community, accusando l’azienda di “sabotaggio invisibile” su un prodotto a pagamento.

**Aggiornamento:** dopo le proteste, Anthropic ha fatto retromarcia, eliminando la restrizione silenziosa. Nel frattempo, però, è emersa una seconda vicenda: l’accesso a Fable 5 e al modello “Mythos 5” è stato temporaneamente sospeso per tutti gli utenti, in seguito a una falla di sicurezza segnalata e a un intervento delle autorità statunitensi. Anthropic ha dichiarato di star lavorando per ripristinare l’accesso il prima possibile. Una doppia vicenda che, in pochi giorni, ha riportato al centro del dibattito un tema cruciale: quanto possiamo davvero fidarci delle infrastrutture AI su cui costruiamo lavoro e business.

#### **Google traduce in tempo reale, senza pause imbarazzanti**

Gemini 3.5 Live Translate è un modello audio che traduce voce in voce in oltre 70 lingue, mantenendo tono e intonazione naturale. Niente più silenzi strani mentre aspetti la traduzione: l’AI parla quasi contemporaneamente a te. Sta arrivando su Google Meet e Google Translate per Android e iOS.

#### **Cohere lancia un modello AI pensato per programmare in autonomia**

North Mini Code è un modello open source da 30 miliardi di parametri, progettato per lo sviluppo software agentivo — cioè un’AI che scrive codice, lo testa e lo corregge da sola. È rilasciato con licenza Apache 2.0 e punta a chi vuole costruire ambienti AI sovrani, senza dipendere dai big.

#### **Google garantisce 35 miliardi di dollari di chip per Anthropic**

Google sta sostenendo finanziariamente il maxi-accordo da 35 miliardi di dollari con cui Anthropic affitta capacità di calcolo in cinque data center. Una garanzia che era rimasta segreta fino ad ora. La notizia svela quanto le alleanze tra i giganti tech siano più intrecciate — e opache — di quanto appaia.

Per questa settimana è tutto. Vi aspettiamo il Sabato alle 15 su[ Radio RCS75](https://live.radiocastelluccio.com/), sul nostro[ canale telegram Cultura Digitale](https://t.me/culturadigitale), sul nostro canale [Instagram](https://www.instagram.com/culturadigitale.live/) “[culturadigitale.live](https://www.instagram.com/culturadigitale.live/#)” e sulle maggiori piattaforme[ podcast](https://open.spotify.com/show/11R7RSkeRSNwcZqyGHPbkK?si=0b2b9d4a1fc34572).

## Topics

- [Puntate](https://news.culturadigitale.live/puntate-programma-radiofonico/)
- [Libri](https://news.culturadigitale.live/libri/)
- [AI agentivi](https://news.culturadigitale.live/tag/ai-agentivi/)
- [autoscaling](https://news.culturadigitale.live/tag/autoscaling/)
- [cloud computing](https://news.culturadigitale.live/tag/cloud-computing/)
- [cloud native](https://news.culturadigitale.live/tag/cloud-native/)
- [Dentro la nuvola](https://news.culturadigitale.live/tag/dentro-la-nuvola/)
- [Gerardo Sabbarese](https://news.culturadigitale.live/tag/gerardo-sabbarese/)
- [infrastrutture cloud](https://news.culturadigitale.live/tag/infrastrutture-cloud/)
- [intelligenza artificiale](https://news.culturadigitale.live/tag/intelligenza-artificiale/)
- [Kubernetes](https://news.culturadigitale.live/tag/kubernetes/)
- [load balancer](https://news.culturadigitale.live/tag/load-balancer/)
- [microsoft](https://news.culturadigitale.live/tag/microsoft/)
- [PaaS](https://news.culturadigitale.live/tag/paas/)
- [SaaS](https://news.culturadigitale.live/tag/saas/)
- [Satya Nadella](https://news.culturadigitale.live/tag/satya-nadella/)
- [scalabilità](https://news.culturadigitale.live/tag/scalabilita/)
- [serverless](https://news.culturadigitale.live/tag/serverless/)
- [trasformazione digitale](https://news.culturadigitale.live/tag/trasformazione-digitale/)