Provider on Melabit

Da melabit a melabit: fare da sé?

Tue, 18 Jun 2019 06:00:00 +0000

Non avrei mai immaginato che sarebbe passato un anno intero prima di riuscire a scrivere ancora di trasferimento del blog, hosting e così via. Nel mezzo c’è stata una transizione lavorativa improvvisa e quasi inaspettata oltre che vari impegni familiari improrogabili e non sono riuscito a fare di più. Ma abbiamo già perso troppo tempo, quindi meglio venire subito al dunque.

Fare da soli

Abbiamo già visto come scegliere il servizio di hosting, cioè l’azienda (o provider) che gestisce l’infrastruttura hardware e software su cui si basa il nostro sito web e che lo rende raggiungibile attraverso la rete. Un provider ha un certo costo, che per un blog personale o un sito web di un professionista o di una piccola azienda può andare da un minimo di 20-30 euro a qualche centinaia di euro all’anno, a seconda del provider, dei servizi scelti e del livello di supporto desiderato. A fronte di questa spesa assolutamente ragionevole, utilizzare un provider permette di delegare la gestione di tutta l’infrastruttura hardware, l’aggiornamento del sistema operativo e del software su cui si basa il sito, la sicurezza, il backup e così via, a degli esperti professionisti (si spera!), lasciando a noi solo il compito di gestire i contenuti veri e propri del sito.

Ma… e se volessimo lo stesso fare da soli? Magari perché vogliamo imparare a gestire un server. Oppure perché vogliamo provare diverse soluzioni prima di decidere come realizzare definitivamente il nostro sito. Perché siamo restii a far gestire il nostro sito da un provider che domani potrebbe scomparire. Per semplice curiosità o perfino perché vogliamo riutilizzare come server web un vecchio computer lasciato a marcire in cantina.

Cominciamo dalla fine. Se sperate di poter fare quello che era così comune agli albori del web, prendere un computer ormai vecchio e poco performante e fargli gestire il vostro piccolo sito web, mi dispiace ma dovete ricredervi. Il web di oggi è molto diverso da quello di 15-20 anni fa, è infarcito di JavaScript, di contenuti dinamici, di CSS, di decine di altre tecnologie completamente sconosciute anche solo cinque o sei anni fa. Un computer vecchio, con un processore obsoleto, poca RAM, con un hard-disk lento come una lumaca, non ce la fa più a gestire in modo efficiente il web odierno, a meno di non ostinarsi a realizzare un sito vecchio (anzi, vecchissimo) stile, con le pagine scritte in HTML puro e collegate manualmente l’una all’altra. Un sito come quelli di GeoCities o giù di lì.

Raspberry Pi

Per fortuna per un sito web non serve nemmeno una workstation superpotente con processore Xeon e decine di gigabyte di RAM, è sufficiente un computer moderno anche se a basso costo.

E fra i computer a basso (o meglio, bassissimo) costo disponibili sul mercato, il più interessante è senza alcun dubbio il Raspberry Pi, il microcomputer grande poco più di un pacchetto di sigarette (si può dire ancora?) che ha prodotto una vera e propria rivoluzione fra i cosiddetti maker, che lo usano per i progetti più svariati e a volte incredibili, dai semplici sistemi domestici di videosorveglianza o intrattenimento a progetti avanzati di monitoraggio ambientale, robotica o intelligenza artificiale.

Se il Raspberry Pi va bene per queste applicazioni, a maggior ragione può essere usato per implementare un NAS, un servizio cloud personale o un server web casalingo (dove con questo termine intendo indicare in generale un blog personale o un sito di un professionista o di una piccola azienda).

Io ho provato a trasferire questo blog sul mio Raspberry Pi 3 B e ha funzionano tutto perfettamente, molto meglio di quanto mi sarei potuto aspettare. Per farlo, ho installato Raspbian (la versione di Debian GNU/Linux specifica per il Raspberry Pi) scegliendo la versione Lite senza interfaccia grafica,¹ ho installato e configurato Wordpress seguendo queste istruzioni stringate ma molto chiare e infine ho trasferito tutto il contenuto del blog usando il plugin di esportazione installato di default in Wordpress. Più o meno due ore di lavoro, andando piano e controllando bene quello che stavo facendo.

I risultati sono andati oltre le più rosee aspettative: la velocità di accesso al blog era indistinguibile da quella garantita dall’hosting attuale su Wordpress.com e anche l’utilizzo del backend, cioè del sistema di gestione di Wordpress (articoli, file allegati, plugin, utenti e così via), non faceva assolutamente rimpiangere quello a cui sono abituato ormai da tanti anni.

A chi volesse provarci a sua volta e non ha già un Raspberry Pi a disposizione, consiglio di acquistare il modello più recente, il Raspberry Pi 3 B+ (costa 32 euro su Amazon, qualcosa di più su PiHut), e una scheda micro SD veloce da almeno 16-32 GB, tenendo conto che la velocità della scheda è molto più importante della capienza.

Pro e contro

Il Raspberry Pi è perfetto per imparare a gestire un server web e il sistema Linux associato oppure per fare delle prove con diversi CMS o generatori di siti statici prima di scegliere quello che vogliamo usare per il nostro sito.

Il Raspberry Pi non ha nemmeno bisogno di essere collegato ad un monitor e ad una tastiera e mouse, ma può essere gestito senza problemi da remoto tramite l’interfaccia ssh (naturalmente bisogna avere dei rudimenti di conoscenza del Terminale, cosa comunque necessaria per chiunque voglia imparare a gestire Linux e un sistema server). In più è molto piccolo, messo in un case come questo o questo fa la sua figura e può essere tenuto tranquillamente in bella vista sulla scrivania o accanto al router.

Ma anche se, come io stesso ho potuto verificare, funziona molto bene con Wordpress e probabilmente anche con qualunque altro CMS o sistema statico che ci possa venire in mente di installare, usare un Raspberry Pi come sistema definitivo sul quale ospitare un server web (ma anche un NAS o un cloud casalingo) richiede di curare attentamente una serie di dettagli niente affatto trascurabili. È importante tenere presente che, anche se l’articolo è focalizzato sull’uso del Raspberry Pi, le considerazioni che seguono valgono in parte per qualunque computer che possiamo voler usare come server web.

Il processore del Raspberry Pi genera poco calore e non ha bisogno di un dissipatore o di una ventola. Ma il microcomputer è progettato per essere usato per qualche ora e poi spento, cosa succede se lo teniamo acceso 24 ore su 24? Ci sarà bisogno di montare un dissipatore metallico o una ventola, oppure di usare un case metallico adatto a dissipare il calore prodotto dal processore (io ho fatto così).

Le schede SD utilizzate dal Raspberry Pi come memoria di massa sono notoriamente fragili e poco adatte ad un uso prolungato. Ci sono soluzioni che permettono di utilizzare un disco esterno meccanico o SSD (o anche due) al posto della scheda SD, sono molto interessanti ma richiedono un minimo di manualità e di esperienza per installare e configurare il tutto.
Alimentare un server con un alimentatore da parete e il suo fragile connettorino microUSB ha un livello di affidabilità decisamente scarso. Se poi aggiungiamo un disco esterno, è facile che la potenza fornita dall’alimentatore USB diventi insufficiente. Molto meglio usare un alimentatore ad hoc, magari insieme ad un case adatto ad ospitare tutti i componenti come questo (si veda anche la figura qui sotto). Purtroppo, mettere insieme una cosa del genere richiede un livello di manualità e di esperienza ancora più elevato.

– Fonte: The Stuff We Build, Raspberry Pi Web Server.

Sempre in tema di alimentazione elettrica, per usare il Raspberry Pi come server è indispensabile aggiungere una batteria tampone, adatta a tenere il Raspberry Pi alimentato anche in assenza di corrente elettrica, meglio se associata ad un piccolo UPS per il router (se va via la corrente di casa e il router si spegne, tenere alimentato il Raspberry Pi non serve comunque). Il solo UPS può anche andare bene per alimentare i due dispositivi, bisogna solo controllare che abbia una potenza sufficiente ad alimentare il router ed il Raspberry Pi per diverse ore.
Un server web ha bisogno di un nome di dominio e di un indirizzo IP associato. Per il nome di dominio c’è poco da fare, va richiesto necessariamente ad una azienda intermediaria (registrar) come Register.it, GoDaddy, Cloudflare, Google Domains e costa circa 10-15 euro all’anno (spesso molto meno il primo anno). Al nome di dominio bisogna associare l’indirizzo IP del nostro sito, che in genere è gestito direttamente dal provider del servizio di hosting. Se vogliamo fare da soli dobbiamo riuscire ad ottenere in qualche modo un indirizzo IP personale. Purtroppo i normali provider telefonici che usiamo per accedere ad internet da casa o dall’ufficio, Wind/Infostrada, Vodafone o simili, ci assegnano degli IP dinamici, che possono cambiare nel tempo, mentre a noi serve un IP statico, da associare una volta per tutte al nome di dominio. Scordatevi i servizi di DNS dinamico come DynDNS, OpenDNS o NoIP e simili, questi possono andar bene per accedere di tanto in tanto alla videosorveglianza o ai dispositivi IoT di casa, non certo per un server web. L’unico provider che conosca che fornisce facilmente un IP statico ai clienti è Fastweb, basta chiederlo ed è anche gratuito.
Da non dimenticare la questione dell’aggiornamento e della messa in sicurezza del sistema operativo e dei pacchetti software che utilizziamo per realizzare il sito web. Linux è intrinsecamente un sistema operativo sicuro, ma ciò non toglie che bisogna preoccuparsi di aggiornarlo frequentemente, nonché di aggiornare tutti i pacchetti software di contorno, in particolare quelli utilizzati per il sito web, in modo da evitare non solo che il sito finisca sotto il controllo di qualche script kiddie che non ha di meglio da fare, ma soprattutto che il nostro microcomputer diventi una base di partenza per i malintenzionati della rete per effettuare attacchi mirati a più vasta scala.

Conclusioni

Come è facile notare le mie perplessità sull’uso del Raspberry Pi come server web casalingo (così come di qualunque altro computer usato per questo scopo) sono soprattutto di natura hardware, e in fondo riflettono il fatto che questo microcomputer nasce come sistema sperimentale o di sviluppo, non come sistema affidabile da tenere in funzione 24 ore su 24.

Anche dal punto di vista puramente economico non mi sembra una grande idea: fra Raspberry Pi, UPS, case e accessori vari si rischia di superare facilmente il costo di un servizio di hosting pluriennale, con in più i tanti grattacapi descritti.

Il Raspberry Pi invece è imbattibile come sistema didattico ed è di sicuro uno dei migliori acquisti che si possano fare in questo momento, una specie di ritorno ai tempi eroici degli anni ‘80 quando chi comprava un computer come il Commodore 64, lo Spectrum o, per i più fortunati, l’Apple II doveva rimboccarsi le maniche e imparare i rudimenti della programmazione e magari anche dell’elettronica per usarlo al meglio. È una vera fortuna che quei tempi siano tornati, oggi.

Da melabit a melabit, la serie completa degli articoli

La versione ideale per un server web al quale, dopo la configurazione iniziale, si accede quasi esclusivamente tramite l’interfaccia web. ↩︎

Da melabit a melabit: la scelta del dominio

Tue, 05 Jun 2018 06:00:00 +0000

Se la scelta del servizio di hosting più adatto alle nostre esigenze è difficile, ancora più complicata è la scelta del nome di dominio (o solo dominio), cioè del nome univoco assegnato ad un sito web, che lo caratterizza e lo rende facile da ricordare, come ad esempio www.google.com, www.debian.org oppure www.nomesito.it.

Breve lezioncina preliminare (sono noioso, ma bisogna pure capirsi). Un dominio è composto da tre parti separate da punti: la prima parte è il noto acronimo www (cioè world wide web), una specie di marchio di riconoscimento del web (come la @ per la posta elettronica) che ormai viene usato sempre più di rado.¹

La parte finale è detta dominio di primo livello (o TLD, Top Level Domain) e serve ad identificare la tipologia del sito web (.com per i siti commerciali, .org per quelli senza scopo di lucro) oppure la nazione dove opera il sito (.it). Però, dopo la liberalizzazione dei TLD, queste definizioni sono diventate sempre meno significative.

Infine la parte di mezzo è il nome dell’host (google, debian oppure nomesito negli esempi di sopra), la parte del nome di dominio che caratterizza veramente il sito.

Aggiungendo il metodo di accesso, http:// o ormai quasi sempre la versione sicura https://, si ottiene l’URL, cioè la stringa univoca https://www.nomesito.it, che permette al browser di accedere al sito web desiderato.

Finita la lezione, veniamo alla parte più significativa dell’articolo: come si fa a scegliere il nome di dominio più adatto per il nostro sito? Le regole di base sono già tutte in questo articolo, inutile ripeterle un’altra volta.

Per una volta voglio usare un approccio più pratico e raccontare come e perché ho scelto proprio melabit come nome di dominio per questo sito, applicando senza nemmeno saperlo alcune delle regole contenute nell’articolo appena citato. Tre regole in particolare: volevo un nome di dominio che fosse breve e facile da scrivere, e che una volta letto non sembrasse qualcosa di diverso e imprevisto. Perché la ragione conta, ma il caso ha sempre il suo bel daffare a metterci i bastoni fra le ruote.

La primissima idea di tenere un blog personale non è mia, ma dell’amico Lucio Bragagnolo, che molto gentilmente mi aveva invitato ad aprirne uno su Macworld Italia. Si doveva chiamare “iLife of Brian”, un bel gioco di parole con il nickname che uso più o meno sempre su internet (con qualche variazione).² Ho ancora il testo del post di presentazione, che non ho mai pubblicato perché intanto Macworld ha chiuso su due piedi.

Ci ho pensato e ripensato e alla fine ho deciso di fare da solo. Ma senza più l’ombrello protettivo di Macworld ho escluso immediatamente di chiamarlo “iLife of Brian”, i motori di ricerca non l’avrebbero mai trovato. Provate a cercare “iLife of Brian” su Google (ma anche su Bing, su DuckDuckGo, su quello che vi pare), vi verrà fuori solo e sempre qualcosa dei monumentali Monty Python. Il confronto era improponibile.

Allora ho preso il fidato nvALT, che uso molto più di Notes per buttare giù degli appunti veloci, e ho cominciato a buttare giù una serie di nomi per il blog. Poi li ho messi in ordine (si può fare a mano, ma sapere usare un po’ il Terminale può essere utile anche per queste cose) e mi sono messo a cercare su internet se erano disponibili o no.

C’è voluto un po’ di tempo e di pazienza, e alla fine è venuta fuori questa lista. Nella colonna di sinistra sono finiti tutti quelli già utilizzati, un vero peccato perché alcuni erano veramente carini. Rimanevano quelli della colonna di destra.

A questo punto ho cominciato a tagliare. Alcuni nomi erano troppo lunghi e complicati (mactechbit, openappletech), spesso troppo anglosassoni per un blog destinato volutamente ad un pubblico italiano (openmactools, toolsformac). Poi c’erano i nomi troppo caratterizzati verso aspetti molto particolari del mondo Mac (melaprog, scientificmac) mentre io volevo mantenere la possibilità di di scrivere di tutto quello che mi piaceva (e mi interessava). Tagliati anche loro senza pietà.

Alla fine mi ero deciso per melaperta. Poi quasi per caso, mentre lo ripetevo mentalmente, mi sono accorto che poteva essere scambiato per un sito per adulti (provate anche voi e ditemi). Avrebbe fatto molto bene alle statistiche di accesso, lo so, ma ho tagliato anche melaperta senza pietà.

Il nome immediatamente successivo era l’unico che non aveva controindicazioni, ed è così che è nato melabit.

Per approfondire

Host-academy, Cos’è un dominio?, 2018.
Nicola Losito, 22 consigli per la scelta del tuo prossimo nome a dominio, 2017.
ReteLab, Come scegliere un nome di dominio, 2016.
Andrea Di Rocco, Come scegliere un dominio per il tuo nuovo sito web, 2016.

Da melabit a melabit, la serie completa degli articoli

Dato che ormai il web è diventato onnipresente, l’acronimo www non è più indispensabile per riferirsi ad un sito, e quindi si può usare solo google.com (detto dominio nudo o naked) al posto di www.google.com. ↩︎
Nickname che deriva sia dal film più famoso dei grandi Monty Python, sia dal nome di uno dei fisici con cui più ho avuto a che fare, Brian Josephson, uno capace di vincere un premio Nobel pubblicando un solo articolo significativo. Tanto che subito dopo si è praticamente rimbambito. ↩︎

Da melabit a melabit: la scelta dell'hosting

Mon, 21 May 2018 06:00:00 +0000

Dopo l’introduzione generale di un mese fa (è già passato un mese!), eccoci subito a quello che forse è il passo più difficile della transizione, la scelta del servizio di hosting. Nella maggior parte dei casi, per avere una presenza su internet dobbiamo appoggiarci ad una azienda (provider) che ci mette a disposizione il server che ospita il sito (il servizio di hosting propriamente detto) e tutta l’infrastruttura hardware e software che rende il sito raggiungibile attraverso internet.

Ho letto da qualche parte che scegliere un servizio di hosting è come sposarsi: bisogna scegliere il partner, stabilire una relazione e sperare che duri nel tempo. E come nel matrimonio, separarsi non è mai facile né privo di conseguenze negative. Non so quanto sia vera la parte riguardante la separazione (dal provider), ma posso testimoniare che la semplice scelta del servizio-partner si è dimostrata molto più complicata di quanto potessi immaginare. Ho pensato quindi di elencare le linee guida che ho seguito per la scelta, sperando che possano essere utili anche a qualcun’altro.

Prima di iniziare un piccolo disclaimer: questi consigli sono adatti a chi voglia mettere su un blog o un sito web per un professionista o una piccola azienda, magari anche un piccolo sito di commercio elettronico. Chi ha bisogno di gestire un sito web di livello superiore farà meglio a rivolgersi altrove, i principi di base sono più o meno sempre gli stessi ma cambia parecchio il peso che si da ai vari fattori. E poi, è più che probabile che in questi casi non vi basti più un normale servizio di hosting condiviso (shared hosting) ma che abbiate bisogno di un server virtuale privato (VPS) o perfino di un server “fisico” vero e proprio (dedicated hosting).

Su internet le guide alla scelta dell’hosting non mancano, purtroppo per la maggior parte non sono altro che degli spot pubblicitari per questo o quel provider. Fra tutte quelle a cui ho dato una occhiata, l’unica che mi sento di consigliare è questa guida di SitePoint: c’è anche qui un po’ di pubblicità, ma almeno quelli di SitePoint lo ammettono onestamente.

Avere pazienza. Non sto scherzando, è una cosa fondamentale. I provider che forniscono servizio di hosting sono centinaia, se non migliaia (nel mondo). Ognuno di loro a parole fornisce un servizio esemplare, una assistenza immediata, un prezzo stracciato. Nella maggior parte dei casi sono delle balle o perlomeno delle affermazioni, diciamo così, piuttosto esagerate. Di conseguenza dovete rassegnarvi a navigare a lungo in rete, per cercare di capire cosa offrono (e soprattutto cosa non offrono) i vari provider e se quello che vi danno serve veramente.

Niente è per sempre. Niente è per sempre, soprattutto su internet. Un certo numero di aziende nascono, crescono e prosperano. Ma tante di più chiudono malamente dopo pochi anni. Come potete fidarvi di provider semisconosciuti che offrono servizi di hosting a vita, da pagare ovviamente sempre in anticipo, magari allettandovi con lo zuccherino di uno sconto mai visto?

Provare il servizio. Sono invece molto interessanti i provider che offrono pagamenti su base mensile o bimestrale. Si spende di più, è vero, ma si può provare direttamente la qualità del servizio offerto. E dopo un mese o due di prova sul campo, potrete decidere a ragion veduta se rimanere con quel provider passando ad una tariffazione annuale o se cambiare aria in cerca di qualcosa di meglio. E poi, se un provider decide di copiare Netflix e di farsi pagare ogni mese, secondo me sa il fatto suo ed è sicuro che il servizio che offre non fa fuggire i clienti dopo i primi trenta giorni. Proprio come Netflix.

Tenere i piedi per terra. Forse è una banalità, ma prima di scegliere questo o quel contratto bisogna fare due conti e valutare quanto spazio occuperà il vostro sito (oggi e nei prossimi anni). Con “spazio” intendo proprio lo spazio occupato sul disco rigido del server dai testi, dalle immagini e magari dai documenti allegati nonché, se usiamo un CMS dinamico come Wordpress, Drupal o, Dio ce ne scampi!, Joomla, dal database associato. Altrettanto importante è valutare il numero di utenti che visiteranno il sito. Inutile acquistare un servizio di hosting con spazio su disco “infinito” e banda di traferimento dati altrettanto “infinita” se poi non vi serve. A parte che l’infinito qui non esiste, a che vi serve tutto questo spazio se oggi avete solo dieci pagine e cento visitatori al giorno? Meglio iniziare con un contratto base, assicurandosi di poterlo aggiornare prontamente quando ce ne sarà bisogno. Anche perché i servizi di hosting forniti dai vari provider cambiano molto velocemente seguendo l’evoluzione tecnologica, per cui è probabile che, quando avrete veramente bisogno di più spazio e di più banda, riuscirete a spuntare prezzi e condizioni decisamente più convenienti di quelli odierni.

Ciò che è veramente importante. Tre parole: HTTP2, SSL, backup. Se il provider non vi garantisce queste cose fondamentali, andate da un’altra parte. E se ve le fa pagare a parte, valutate bene se vi conviene o se non è meglio rivolgersi altrove. In tutti i casi, su questo non ci piove, dovete averle tutte e tre. Per il backup in particolare, non fidatevi del provider e fate voi stessi un backup periodico del sito in aggiunta a quello automatico, che in ogni caso deve essere almeno giornaliero (penso comunque che nessun provider oggi possa pensare di stare sul mercato con qualcosa di meno). Perché? Perché non potete mai essere sicuri che il backup del provider funzioni finché non succede il fattaccio e in quel malaugurato caso è meglio avere una seconda alternativa. Ma anche perché potete essere ancora meno sicuri che un bel(?) giorno il provider non chiuda tutto all’improvviso, lasciandovi senza servizio e pure senza backup.

Ciò che è abbastanza importante. Server che usano dischi SSD al posto di quelli meccanici. Ho qualche dubbio che facciano veramente la differenza, vista la scarsa qualità delle linee dati del nostro Paese (che me ne faccio di un server che legge velocissimamente i file dal disco se poi ci vuole un sacco di tempo per trasmetterli a destinazione?), però i dischi SSD sono più affidabili di quelli meccanici, quindi: perché no?

Ciò che è piuttosto importante. Se il provider vi offre una CDN o dispone di più server sparsi per l’Europa (come è sufficiente per un sito italiano) o per il mondo, fateci un serio pensierino sopra, soprattutto se il prezzo è onesto. La velocità su internet è tutto, se il sito ci mette più del dovuto a caricare i testi e le immagini, i visitatori si scocciano e scappano via. Non ci vuole molto, basta un ritardo di due o tre secondi. Le nostre linee dati si danno già parecchio da fare per rallentare la velocità di accesso ai siti (l’avete già letto prima), per cui è consigliabile stare sul sicuro e ridurre per quanto è possibile gli altri colli di bottiglia. Non è male poter avere un accesso al server anche tramite SSH, ma solo se sapete già usare il Terminale, del Mac o di Linux, perfino quello di Windows (finalmente dalle parti di Microsoft si sono decisi a metterne uno decente).

Ciò che è incontrollabile. Tante guide che ho letto prestano molta attenzione (troppa attenzione, secondo me) ad aspetti come l’affidabilità del servizio di hosting, la velocità nel rispondere alle richieste di aiuto, la qualità del supporto tecnico, la reputazione dell’azienda. Purtroppo sono tutti fattori sui quali non potete avere il minimo controllo, almeno finché non provate il servizio per qualche mese (anche per questo è utile poter iniziare con dei pagamenti mensili). In teoria la reputazione aziendale può essere valutata leggendo qualche recensione sul web o dando una occhiata a quello che dicono i social. In teoria. Nella pratica le recensioni sono inutili, nel 99.99% dei casi sembrano, e sono, solo pubblicità. Sull’affidabilità di quello che compare sui social è inutile sprecare tempo e parole.

Sicurezza. Dovrei consigliarvi di scegliere un provider che curi particolarmente bene la sicurezza dei server e della infrastruttura di rete. Che disponga degli strumenti software adatti a respingere le principali tipologie di attacchi e che soprattutto sappia usarli. Che aggiorni rapidamente i software che girano sui server e magari anche quelli utilizzati dai siti web dei clienti, in modo da riparare velocemente alle vulnerabilità, agli errori di programmazione, che vengono scoperti ogni giorno e che possono essere sfruttati dai tanti malintenzionati che girano per il web. Purtroppo tutto ciò è forse ancora meno controllabile a priori della qualità del servizio offerto dal provider, e in questo caso anche i mesi di prova iniziale non bastano a darvi informazioni utili su questo aspetto (fondamentale!) del servizio. In questo caso particolare, una azienda nota e attiva da parecchi anni è potenzialmente preferibile ad una startup appena nata, ma non è neanche detto a priori, magari i gestori della startup sono particolarmente esperti in questo campo e possono agire con una rapidità ed una efficienza impossibili per una azienda di grosse dimensioni. Insomma, la questione sicurezza è veramente spinosa, l’unica cosa che mi sento di consigliare è quella di provare a verificare se il provider che avete scelto è stato soggetto ad attacchi nel passato e come ha reagito. È un consiglio molto debole, lo so, spero che qualcuno abbia delle idee migliori.

Prezzo chiaro. Questa cosa la metto alla fine, in modo che sia più evidente. Non so a voi, a me danno profondamente fastidio quei provider (e sono tanti, anche fra i più quotati, come Bluehost, SiteGround o per stare in Italia, Aruba o 1&1) che propongono un prezzo molto basso per il primo anno, che poi si duplica (o si triplica) negli anni successivi. Un sito web non è un affare di un solo anno, e anche il servizio di hosting dovrebbe essere una relazione a lunga scadenza. Un provider lo sa benissimo e, se fa così, mi da l’impressione di essere un furbetto che applica la stessa politica di marketing di un supermercato. Con la differenza che ci vuol poco a cambiare supermercato, mentre trasferire il sito da un provider all’altro è una faccenda molto più complicata.

Trasferimento. Se avete già un sito web e volete cambiare provider, siate consapevoli che trasferire il sito, fra DNS, dominio, email, database, CMS (e di tante altre cose che ora non mi vengono in mente), non è facilissimo. Se avete conoscenze tecniche sufficienti e tempo a disposizione fatelo pure da voi, in tutti gli altri casi vale decisamente la pena affidarsi al provider che avete scelto. Costa un po’ ma dubito che ve ne pentirete.