Hosting condiviso: perché ho tolto tutti i miei clienti da lì

Un anno fa ho passato una mattinata a cercare un pulsante che non esisteva.

Dovevo mettere un reverse proxy davanti al sito di un cliente. Operazione da mezz’ora, se hai accesso alla macchina. Su quell’hosting condiviso non c’era niente da fare: nessun pannello di controllo del server, nessun virtual host, nessuna riga di configurazione raggiungibile. Il piano costava pochi euro al mese e funzionava benissimo, per quello che sapeva fare. Il problema è che avevamo appena iniziato a lavorarci sopra.

Quella mattina ho capito una cosa che oggi dico a tutti i clienti nuovi: l’hosting condiviso non è un cattivo prodotto. È un prodotto pensato per siti che devono esistere, non per siti su cui bisogna lavorare.

L’hosting condiviso va benissimo, finché non tocchi niente

Voglio essere onesto, perché la retorica del “l’hosting economico ti rovina” è quasi sempre venduta da chi ha un hosting costoso da piazzare.

Se hai un sito vetrina di cinque pagine, che aggiorni due volte l’anno e che non deve fare nient’altro che aprirsi, l’hosting condiviso è la scelta razionale. Costa poco, non richiede competenze, ha un centro assistenza che risponde. Non c’è niente da migliorare.

Il soffitto arriva nel momento esatto in cui qualcuno inizia a intervenire sul sito. E quel momento, di solito, coincide con il momento in cui il sito inizia a contare qualcosa per il fatturato.

Le cose che non ho potuto fare, in ordine di frustrazione

Nessun livello davanti al sito. Tutto il mio lavoro di migrazione progressiva da WordPress a uno stack moderno si regge su un server Node che sta davanti all’applicazione originale e intercetta le richieste. Su hosting condiviso quel livello non esiste e non può esistere: i piani condivisi di Aruba, per dirne uno, escludono esplicitamente Node dalle tecnologie supportate, insieme ad Angular e Vue. Non è una configurazione da chiedere all’assistenza, è una porta murata.

Nessun modo serio di lavorare. Niente deploy da un repository, niente ambiente di staging, niente possibilità di tornare indietro. Il sito in produzione è l’unica copia esistente e si modifica lì, in diretta, sperando bene. Il backup c’è, sta nel pannello, e nessuno l’ha mai provato a ripristinare.

Nessuna cache persistente e un pannello di amministrazione lentissimo. Su questo mi soffermo un attimo, perché è il punto che i clienti sentono ogni giorno senza saperlo nominare. Le pagine pubbliche sono in cache, quindi al visitatore il sito sembra decente. Il pannello di amministrazione no: quello ti dice quanta CPU hai davvero. Se chi scrive i contenuti aspetta sei secondi a ogni salvataggio, i contenuti si smettono di scrivere. È un problema di marketing travestito da problema tecnico.

Il giorno in cui la differenza è diventata evidente

Il 13 agosto uno dei siti che gestisco è stato attaccato. L’ho raccontato per intero in Sito WordPress attaccato: come l’ho reso sicuro e più veloce in poche ore.

La parte che qui conta è una sola. Davanti a un sito compromesso, su un hosting condiviso hai una mossa disponibile: ripulire e sperare che l’ingresso fosse quello che hai chiuso. Io ne avevo un’altra, cioè spegnere WordPress come applicazione viva, generare una build statica e ripuntare il proxy sulla nuova origine. Stessi URL, nessun database, nessun PHP in esecuzione, sito più veloce di prima.

Quella mossa non è più intelligente della prima. È solo disponibile, e lo è perché la macchina è in mano a qualcuno che ci può entrare.

È questo il vantaggio vero dell’hosting gestito da un tecnico, e non c’entra con la potenza del server: quando succede qualcosa, il ventaglio di risposte è più largo.

Cosa si perde, perché qualcosa si perde

Chi ti vende una soluzione senza controindicazioni sta vendendo, non spiegando. Quindi lo dico chiaramente.

Su un hosting condiviso il cliente compra un’infrastruttura con un centro operativo attivo ventiquattro ore su ventiquattro e contratti di servizio scritti. Con me compra me. Se sparisco io, non c’è un turno di notte che mi sostituisce. È un baratto reale e va messo sul tavolo prima della firma, non dopo.

Costa anche di più di un piano condiviso, ovviamente. La domanda giusta non è quanto costa l’hosting, ma quanto vale poter intervenire. Per un sito che porta contatti e fatturato la risposta viene da sola. Per un sito vetrina che nessuno tocca, la risposta è che non ne vale la pena, e te lo dico io.

In sintesi

L’hosting condiviso è un piano di parcheggio, e i parcheggi funzionano. Ma se il sito è il canale da cui arrivano i tuoi clienti, prima o poi qualcuno dovrà metterci le mani: per renderlo più veloce, per rimediare a un attacco, per spostarne un pezzo su una tecnologia migliore. In quel momento la domanda non sarà quanto paghi al mese. Sarà se chi ti sta aiutando può entrare o deve aprire un ticket.

Parliamone

Se il tuo sito inizia a contare qualcosa e ti stai chiedendo se l’infrastruttura sotto regge, raccontami il tuo progetto.