Indice dei contenuti dell'articolo:
Se anche tu nella vita fai il sistemista dal 2005, con all’attivo migliaia di server e migliaia di casi uno diverso dall’altro, sarai d’accordo con me che oggi come oggi non se ne può davvero più. Altrimenti potresti credere a tante leggende metropolitane che vengono propinate da commerciali senza scrupoli e senza cognizione di causa alcuna se non quella del mero profitto. Lavorare nel settore IT è diventato demotivante e poco gratificante, dato che ormai il mercato è presidiato ai vertici dal marketing e da vere e proprie leggende metropolitane, divulgate da individui senza titoli né esperienza in ambito sistemistico. Questi commerciali spesso vendono soluzioni miracolose che promettono prestazioni e affidabilità senza pari, senza comprendere le reali esigenze tecniche e operative.
Partiamo dunque ad elencare quelle che sono delle affermazioni opinabili e smentire l’affermazione con ragionamenti logici e relativa documentazione e riferimenti. Il nostro obiettivo è fornire chiarezza e verità in un mare di disinformazione, basandoci su anni di esperienza pratica e conoscenza approfondita del settore. Man mano che avremo nuovi miti da aggiungere e smentire, li pubblicheremo aggiornati in questo post. In questo modo, speriamo di contribuire a una maggiore consapevolezza e competenza tecnica, aiutando i professionisti IT a prendere decisioni informate e a evitare le trappole del marketing ingannevole.
Gli Hosting condivisi sono lenti.
In primis dalla pesantezza del sito da ospitare, da quanti altri siti sono sulla stessa macchina, e dalle risorse che vengono accaparrate dagli altri siti in virtual hosting sulla stessa macchina. È pacifico affermare che condividere un hosting con altri siti non dia garanzie in merito di performance e costanza delle performance, dato che un altro sito ospitato sul nostro stesso server potrebbe monopolizzare le risorse e farne risentire anche al nostro. Tuttavia, un hosting condiviso ottimizzato con Varnish Cache, giuste strategie e politiche di caching, un buon TTFB, protocolli veloci come HTTP/3 o QUIC potrebbero essere molto più veloci e performanti di un server dedicato da 1000€ al mese configurato con Plesk o cPanel sopra senza alcun tuning ed ottimizzazione. La potenza è nulla senza controllo. Quindi, con le giuste ottimizzazioni, un hosting condiviso può offrire prestazioni eccellenti, mentre un server dedicato mal configurato può risultare inefficiente e lento. La chiave è nell’ottimizzazione e nella gestione delle risorse.
Se viene hackerato un hosting sul nostro stesso server, gli attaccanti possono attaccare il nostro sito.
Se viene hackerato un hosting sul nostro stesso server, gli attaccanti possono attaccare il nostro sito. Questo scenario è altamente improbabile. Al giorno d’oggi, eccetto pochi sventurati ed improvvisati, tutti gli Hosting hanno recepito l’importanza della separazione dei privilegi a livello di processi e filesystem. Ad esempio, l’utilizzo di PHP-FPM (FastCGI Process Manager) permette una gestione separata dei processi PHP per ciascun sito, assegnando a ciascun pool di processi PHP un proprio UID (User ID) e GID (Group ID), assicurando che ogni sito web operi con privilegi distinti e isolati. Se oggi bucano il sito ospitato in virtual hosting nel nostro stesso server, l’attaccante non ha il privilegio sufficiente per poter scrivere / leggere i nostri files o il nostro database, poiché i processi PHP-FPM associati al nostro sito funzionano con UID e GID separati e non possono interferire con quelli degli altri siti. Diversa è la situazione in cui l’attaccante buchi il sito ospitato vicino al nostro e poi proceda con exploit improbabili all’elevazione dei privilegi massimi (root), a quel punto può compromettere tutti i siti sullo stesso server. Tuttavia, la corretta configurazione e l’aggiornamento continuo dei sistemi e delle applicazioni riducono notevolmente la possibilità di successo di tali exploit.
Un Hosting con risorse garantite è meglio di un hosting in best effort.
Un Hosting con risorse garantite è meglio di un hosting in best effort. Dipende. Se devi scegliere avere risorse garantite (minime e massime) di 1 core, 1GB di RAM, preferisci sempre un Hosting in best effort. E’ vero che non avrai garanzie sulle risorse minime a te riservate, ma è anche pacificamente vero che per oltre il 90% la soluzione best effort produrrà valori migliori e performance maggiori di una soluzione con risorse dedicate ma insufficienti per far girare correttamente un sito. Nel contesto di un hosting best effort, le risorse sono condivise dinamicamente tra tutti gli utenti del server, permettendo spesso di beneficiare di picchi di performance superiori rispetto a quanto garantito da un hosting con risorse fisse. Questa flessibilità è particolarmente vantaggiosa per siti con carichi di lavoro variabili o con picchi occasionali di traffico, dove il sistema può allocare risorse aggiuntive temporaneamente per mantenere un’alta performance. Inoltre, la gestione delle risorse in un ambiente best effort è ottimizzata per massimizzare l’efficienza complessiva del server, consentendo a siti web meno intensivi di utilizzare risorse in eccesso lasciate da altri, migliorando così l’esperienza utente in termini di velocità e reattività.
Con il Cloud si risparmia perché paghi solo quello che consumi.
Affermazione palesemente falsa almeno nel 90% degli usi reali. È vero che il Cloud ha un modello pay per use piuttosto che un modello Flat (oggi in realtà esistono entrambe le opzioni), ma il costo del cloud è normalmente quattro volte (minimo) rispetto alla stessa soluzione su server dedicato. Per intenderci, dove su Amazon LightSail compri 2vCPU e 4GB di RAM (a cui aggiungere i costi del traffico in uscita), con lo stesso costo puoi acquistare un server dedicato con 12 thread (equivalente di 12vCPU) e 64GB di RAM, con prestazioni a livello di I/O e bus di sistema ovviamente maggiori. Il cloud offre flessibilità, scalabilità e facilità di gestione, ma queste caratteristiche spesso comportano costi aggiuntivi significativi. Inoltre, le risorse cloud sono virtualizzate e condivise, il che può introdurre overhead e limitazioni prestazionali rispetto a un server dedicato con hardware fisico esclusivo. Quindi, per applicazioni ad alte prestazioni e carichi di lavoro costantemente elevati, i Server Dedicati rappresentano una soluzione più economica e performante rispetto ai servizi cloud.
Con il Cloud posso scalare verticalmente da 1 CPU a 128 CPU con un solo click.
Dipende. Normalmente con alcuni fornitori top del mercato come AWS, Google Cloud e Azure, è possibile farlo ovviamente con costi piuttosto proibitivi. Il buon senso dovrebbe sempre regnare sovrano; se compriamo il Cloud senza una reale necessità di scaling verticale (aumentare risorse sulla singola istanza), stiamo facendo una spesa inutile per un evento che non avverrà mai. Ha senso spendere cifre importanti per performance basilari, solo perché forse in futuro avremo la necessità di scalare? La risposta è soggettiva e sta nel buon senso dell’analisi degli eventi particolari (picchi di traffico, effetto slashdotting, black friday) ecc. È importante valutare attentamente le esigenze attuali e future della propria infrastruttura e considerare se il costo aggiuntivo del cloud, con la sua capacità di scalare rapidamente, giustifica l’investimento rispetto a soluzioni più statiche e tradizionali. Inoltre, la scalabilità verticale è solo una parte dell’equazione; spesso è più efficiente e cost-effective considerare anche la scalabilità orizzontale (aggiunta di più istanze) per gestire aumenti di carico.
Il Cloud è più affidabile di un Hosting Condiviso o di un Server dedicato.
Dipende. Quale Cloud? Di quale azienda? Che tecnologie di virtualizzazione? Che tipo e modello di SAN? Che procedure di backup e disaster recovery? Repliche geografiche su region diverse ne fanno? Se non ne fanno di default, le fai tu da sistemista? Il Cloud potrebbe essere infinitamente meno affidabile di un hosting condiviso o di un server dedicato. È vero che le auto hanno 4 ruote, ma non è vero che 4 ruote determinano un’auto. L’affidabilità del cloud dipende da molteplici fattori, tra cui la qualità dell’infrastruttura del provider, la configurazione delle risorse, la gestione del network, e le misure di sicurezza implementate. Ad esempio, i provider top del mercato come AWS, Google Cloud e Azure offrono infrastrutture robuste con elevati standard di ridondanza e disponibilità, ma questi servizi possono avere costi elevati e richiedono una configurazione attenta per sfruttarne appieno i benefici. Al contrario, un hosting condiviso o un server dedicato ben configurato e gestito può offrire un livello di affidabilità comparabile o superiore, soprattutto se supportato da un team di sistemisti esperti che implementano best practices in termini di sicurezza, backup e disaster recovery.
L’accesso SSH va negato perchè espone a rischi di sicurezza.
Dipende. L’accesso SSH con privilegi utente e non root, concesso in un ambiente dove la politica su utenti e gruppi sia corretta, non espone a nessun problema di sicurezza. Tuttavia, per un utente malizioso in un sistema non aggiornato, potrebbe essere una strada prioritaria per procedere all’escalation dei privilegi e tentare la scalata alla root e dunque compromettere la sicurezza dell’intero server. Diciamo che per ovviare all’incompetenza di molti sistemisti, si preferisce non concedere quello che dovrebbe essere un diritto. La sicurezza dell’accesso SSH può essere significativamente migliorata con l’uso di chiavi SSH anziché password, l’implementazione di autenticazione a due fattori, e limitando l’accesso SSH a determinati indirizzi IP. Inoltre, mantenere il sistema e i pacchetti aggiornati, monitorare i log di accesso e applicare regole di firewall adeguate sono misure che possono ulteriormente ridurre i rischi associati all’accesso SSH.
Gli Hosting debbono sempre fornire un pannello di controllo come Plesk / cPanel o simile.
Ti serve veramente? O ti basta accedere ai tuoi file e al tuo database MySQL? Perché cPanel e Plesk sono soluzioni general purpose che si portano dietro importanti problematiche di performance ed ogni tanto anche di sicurezza. Pertanto, su progetti seri, dove gira vero traffico, milioni di pagine viste al mese o milioni di fatturato, si cerca sempre di ottenere la massima resa, e la massima resa non è ottenibile con pannelli come Plesk o cPanel. Se cerchi invece la massima indipendenza magari per installare centinaia di siti vetrina, un pannello di controllo come Plesk o cPanel potrebbe essere la soluzione ai tuoi problemi di indipendenza. L’uso di pannelli di controllo semplifica la gestione per utenti meno esperti, ma introduce overhead e potenziali vulnerabilità che possono compromettere le prestazioni e la sicurezza del sistema. In ambienti ad alte prestazioni, si preferisce una configurazione più snella e personalizzata, gestita direttamente tramite accesso SSH e strumenti specifici per la gestione delle risorse server, per garantire il massimo controllo e efficienza.
Se ho un sito per l’Italia è meglio avere un IP italiano in un datacenter italiano ai fini SEO
Decisamente falso. In che epoca vivi, agli albori del 1996? Questa regola poteva valere fino all’anno 2000, poi è stata ampiamente soppiantata. La maggior parte dei siti di successo italiani oggi si trovano in strutture datacenter in Germania o Francia. Oggi ormai si ragiona non più in termini di paesi, ma bensì di continenti. È corretto, dunque, per un sito italiano avere un datacenter con un buon ping ed una bassa latenza, in Europa. Che sia in Italia, Olanda, Francia, poco importa. Quel che conta è il TTFB (Time To First Byte) e, se è vero che un TTFB in Italia o in Germania può fare la differenza anche di 30ms, si può iniziare a parlare di millisecondi solo quando si è almeno risolti i problemi grossi di velocità e portato il TTFB quanto meno sotto ai 100ms. Oggi come oggi, purtroppo, si tende a scegliere sistemi in Italia non ottimizzati che comunque risultano lenti e con TTFB superiori ai 200ms massimi consigliati da Google. Quindi, è essenziale concentrarsi sulla qualità complessiva dell’infrastruttura e sull’ottimizzazione delle prestazioni piuttosto che sulla semplice localizzazione geografica del datacenter.
CloudFlare e le CDN velocizzano il sito web.
Falso. Almeno nell’idea collettiva che se ne fa dell’uso di CloudFlare e delle CDN. Se hai un sito italiano, con pubblico europeo (ricolleghiamoci alla domanda sopra), CloudFlare non migliorerà nulla, anzi potrebbe peggiorare addirittura la delivery dei contenuti. Se invece ci troviamo di fronte ad un sito internazionale, acceduto anche a livello intercontinentale, CloudFlare può essere sicuramente una soluzione papabile nel diminuire la latenza ed accelerare la consegna dei contenuti. Oltretutto bisogna specificare come viene configurato CloudFlare e la versione del piano acquistato, tenendo conto della funzionalità di CDN e della funzionalità di Full Page Cache che non sono un sinonimo e hanno fini completamente differenti. Una corretta configurazione è essenziale per ottenere i benefici desiderati; ad esempio, l’abilitazione di funzionalità come il caching dinamico, il minifying delle risorse e la compressione può fare una grande differenza. Quindi, mentre le CDN come CloudFlare possono migliorare significativamente le prestazioni di un sito con traffico globale, la loro efficacia dipende dalla configurazione specifica e dal contesto d’uso.
Tuttavia su CloudFlare ne abbiamo dette e scritto molto in questo articolo.
