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 sensa 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 ne esperienza in ambito sistemistico.
Partiamo dunque ad elencare quelle che sono delle affermazioni opinabili e smentire l’affermazione con ragionamenti logici e relativa documentazione e riferimenti.
Man mano che avremmo nuovi miti da aggiungere e smentire li pubblicheremo aggiornati in questo post.
Gli Hosting condivisi sono lenti.
Dipende. 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.
Se viene hackerato un hosting sul nostro stesso server, gli attaccanti possono attaccare il nostro sito.
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. 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.
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.
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.
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 LightSails compri 2vCPU e 4GB di RAM (a cui aggiungere i costi del traffico in uscita), ci compri con lo stesso costo 1 Server Dedicato con 12 thread (equivalente di 12vCPU) e con 64GB RAM, con prestazioni a livello di I/O e bus di sistema ovviamente maggiori.
Con il Cloud posso scalare verticalmente da 1 CPU a 128 CPU con un solo click.
Dipende. Normalmente con alcuni fornitori top del mercato AWS, Google Cloud, 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 avremmo 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.
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 shared o di un server dedicato. È vero che le auto hanno 4 ruote, ma non è vero che 4 ruote determinano un’auto.
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 siano corretti 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.
Gli Hosting debbono sempre fornire un pannello di controllo come Plesk / cPanel o simile.
Dipende. 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 importantissime 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.
Se ho un sito per l’Italia è meglio avere un IP italiano in un datacenter italiano ai fini SEO
Falso. 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 Francesi. 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.
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.
Tuttavia su CloudFlare ne abbiamo dette e scritto molto in questo articolo.
