Browsed by
Tag: hosting

Class-action contro Aruba: la pazzia continua.

Class-action contro Aruba: la pazzia continua.

Solo un veloce aggiornamento sulla vicenda (di cui ho parlato dettagliatamente qui). L’idea di Class-Action contro Aruba da parte del Codacons ha riscosso molto meno successo di quanto pensassi. Immaginavo centinaia di commenti in pochi giorni sul blog dell’Avv. Rienzi (sul quale è stato formalmente richiesto dal Codacons di rilasciare una pre-adesione), invece dopo 5 giorni questi sono appena una sessantina, di cui almeno la metà sono contro l’azione di gruppo nei confronti del colosso dell’hosting o di persone che come me tentano di spiegare, a tempo perso, la situazione.

Così tanto FLOP che da ieri ho iniziato a taggare i miei tweet riguardo la vicenda con il tag #FLOP oltre che #Aruba e #Codacons.

Segnalo l’articolo di Antonio Angelino, che riprende in parte i miei punti del precedente post ed estende il discorso. Per chi fosse interessato ad approfondire un minimo il discorso tecnico o a leggere pareri di professionisti come me, segnalo questo thread su HostingTalk.it.

Sto anche continuando a leggere (e a rispondere) divertito ai commenti dei vari utenti che si lamentano delle perdite milionarie subite a causa del down di 12 ore si un hosting lowcost da 30 € annuali che non offre garanzie da contratto. Inutile commentarli o rispondere a uno a uno, ma nell’insieme emergono alcuni punti interessanti. Non intendo trattarli nel dettaglio (anche perchè un professionista del settore o presunto tale -questo dovrebbe essere il mio target, considerato che non so scrivere in modo umano- dovrebbe capire senza troppe spiegazioni), ma solo elencarli:

  • Nessuno dei clienti che intendono proseguire nell’azione contro Aruba ha letto il contratto prima di sottoscriverlo. Appare ovvio, perchè al suo interno è esplicitamente contemplata la possibilità di danni per incendio e l’impossibilità di offrire rimborsi ai clienti. Più in generale non ci si rende conto che al momento della firma di un contratto per un servizio lowcost, la sostanza dell’accordo tra Provider e Cliente è “Ok Cliente, io ti do un servizio che costa la metà, ma sappi che per abbassare il prezzo devo togliere garanzie, va bene?”.
  • C’è una scarsissima conoscenza del mercato. Anche una nocciolina (fatta eccezione per qualche mia amica l’arachide è la cosa più stupida che conosca), vedendo che esistono pacchetti di hosting da 10 €, da 40 €, da 250 € e da 1500, tenterebbe di informarsi e di capirne le differenze, arrivando così in ben poco tempo a parlare di uptime, garanzie, penali etc.
  • C’è anche una conoscenza tecnica pari a zero. E’ comprensibile ovviamente, ma quello che non è comprensibile è la pari presunzione di esprimere pareri a riguardo. Ci sono persone che parlano di “server di emergenza” senza sapere minimamente cosa significhino la parola failover o la parola sincronizzazione, altri che parlando di “misure di emergenza” che Aruba AVREBBE DOVUTO mettere in atto senza riuscire minimamente a spiegare di cosa si stia parlando.
  • Si nota anche un certo livello di illogicità: c’è chi fatica a capire che anche se ha acquistato 20 pacchetti da 40 €, questi rimangono 20 pacchetti lowcost, o chi tira fuori la solita storia del mancato pagamento del rinnovo causa imprevisto dell’ultimo momento (si, esatto, quello li, quello che ti impedisce di pagare al sessantesimo giorno il dominio, senza che si capisca bene cosa hai fatto per i 59 giorni precedenti).
  • AGGIUNTA: Me l’ero dimenticata ma è di importanza fondamentale. Certi utenti hanno un’idea di “pagamento rateale” abbastanza alterata. Il ragionamento, in sostanza è: “sono dieci anni che pago 30 euro, quindi dovrebbero aggiungere ridondanza”. Bene, svelerò un segreto: no, non funziona così. Pagare 30 euro annuali per 10 anni non obbliga l’azienda ad offrire un servizio da 300 euro annuali.

E molto, molto altro. #FLOP

Giorgio

PS: Non so quale sia la fonte dell’immagine di Aruba in fiamme. Io l’ho presa QUI.

Class-Action contro Aruba: un delirio?

Class-Action contro Aruba: un delirio?

Ieri, Venerdì 29 Aprile 2011, alle 4 di mattina un corto circuito nella sala batterie del sistema UPS della WebFarm di Arezzo del gruppo Aruba ha causato uno spegnimento di tutta la struttura, portando offline i milioni di siti ospitati, caselle email, server dedicati etc. Ne hanno parlato testate autorevoli, come il TGCOM, il Quotidiano Nazionale o il Giornale.

Alle 10.30 è iniziata la rimessa in tensione delle sale. In qualche ora tutti i server erano nuovamente alimentati e i servizi iniziavano a tornare online (discorso diverso chiaramente per le macchine con filesystem corrotti a causa dello spegnimento improvviso). In serata, poi, è arrivato il Comunicato Stampa.

Il Comunicato spiega che si è attivato normalmente il sistema antincendio della sala UPS, ma che poi il fumo, diffuso in tutta la struttura, ha fatto scattare anche quello delle sale dati che ha causato l’interruzione di corrente. Sembra quindi che dopo il corto circuito relativo agli UPS sia entrato in funzione senza problemi il sistema di bypass di questi ultimi e le sale dati siano rimaste alimentate, salvo poi essere “spente” per un “errore” del sistema antincendio. Ma la questione è di poca importanza, perchè comunque i Vigili del Fuoco avrebbero chiesto di staccare l’interruttore generale prima di intervenire.

La cosa veramente interessante (cioè, ridicola) in tutta la vicenda è la Class-Action (cos’è?) che il Codacons ha promesso nei confronti di Aruba, per i disagi causati ai clienti durante il downtime. Da leggere assolutamente i commenti sul blog dell’Avv. Rienzi di chi non si rende conto che nessuno ha in mano coltelli, ma c’è un contratto, firmato, di chi ha una mail fondamentale per il suo lavoro ma la mette su un lowcost, di chi ha un sito fondamentale tramite il quale fa un immenso fatturato ma decide di ospitarlo su un pacchetto lowcost senza garanzie etc etc.

Mi fanno piacere i commenti di chi ha si scelto di ospitare un E-Commerce (anzi, 30) su sistema lowcost, ma sapeva a cosa andava incontro, sapeva cosa stava comprando e ha agito di conseguenza. Sono molti anche quelli che insultano il Codacons contro la class-action, da notare chi assume un atteggiamento “pan per focaccia” nei confronti dell’avvocato e del suo blog. C’è poi chi come al solito incolpa l’Italia, e confonde il bollino dorato “Uptime Garantito” con una garanzia da contratto e non si rende conto che per quel prezzo è semplicemente IMPOSSIBILE offrire garanzie. Ovviamente ci sono anche il MIO commento e quello dello (stimato) ex-collega Domenico De Monte.

Il punto focale è che il contratto firmato dai clienti spiega chiaramente che non sono fornite garanzie in termini di uptime, e che il prodotto offerto è soggetto a questo tipo di problemi. Il pacchetto di hosting è quindi qualcosa di “best effort”, ovvero “il meglio possibile”, in parole povere Aruba promette di offrire al cliente un buon servizio (ovviamente non può essere down 24ore al giorno), ma senza offrire garanzie in caso di problemi. Il cliente deve quindi saper valutare, decidere se il rischio di downtime per lui è accettabile.

Se lo ritiene accettabile, utilizza un servizio risparmiando non pochi euro (per soluzioni con delle garanze di uptime si parlerebbe di prezzi intorno alle migliaia di euro annuali), ma accetta di non richiedere risarcimenti in caso di downtime. Se non lo ritiene accettabile, ovvero crede che il rischio sia troppo alto e che l’eventuale perdita sarebbe troppo grossa, deve guardare da altre parti e tirare fuori il libretto degli assegni.

Una class-action che costringa il provider a risarcire i clienti quando da contratto negava questa possibilità, nata da clienti insoddisfatti di un servizio che hanno semplicemente sbagliato a comprare, sarebbe distruttiva per il settore: si costringerebbero le aziende ad offrire risarcimenti in situazioni economicamente impossibili. Il che può portare ad una sola cosa: la fine del lowcost. Essendo costretti a fornire risarcimenti in caso di problemi, i provider deciderebbero di offrire solo servizi all’altezza di una simile prospettiva, al fine di evitare inutili perdite.

Insomma, se volete sottoscrivere questa class-action, fatelo ma ricordate:

  1. Chi ha subito danni li ha subiti in quanto non ha letto il contratto e ha acquistato un servizio inadatto alle sue esigenze
  2. No, non avete perso email. Il protocollo SMTP è studiato per far fronte a queste situazioni
  3. Una azione simile, se vinta dai consumatori, creerebbe conseguenze catastrofiche sul mercato
  4. Eventi simili sono rarissimi, si fa prima a cancellare e ripartire

Vi terrò aggiornati.

Giorgio

TopBlog di TopHost: la recensione

TopBlog di TopHost: la recensione

E’ da un pò che non mi sentite, e ho deciso di riapparire con una recensione. Giorni fa ho trovato su twitter (io sono @g_bonfiglio) un codice coupon TopHost per attivare un pacchetto ad 1 € per il primo anno. Ero curioso, ed essendo in vacanza ho deciso di provare un TopBlog. Il servizio si presenta come una piattaforma di blogging completa basata su WordPress, corredata di un dominio e di 1 GB di spazio per gli allegati ed una casella email di 200 MB di spazio con infiniti alias attivabili, al prezzo normale di 9.59 € + IVA annuali.

Ho ordinato il pacchetto con un dominio .net, nelle prime ore del pomeriggio ed è stato attivato la mattina dopo. L’attivazione non è istantanea (non azzarderei, forse non è automatica) ma è veloce. Ho impressione che giri un qualche tipo di cron per completare le attivazioni, quindi con forte probabilità sarebbe stato attivato alle 7 di mattina anche se lo aveste ordinato due ore prima.

TopBlog è corredato da due pannelli di controllo: uno, quello classico di TopHost (ridotto) tramite il quale posso gestire l’account e gli alias email ed accedere alla webmail Horde e alle statistiche del server, ed il pannello di WordPress MU tramite cui si lavora sul blog vero e proprio.

Come ho più e piùvolte ripetuto, trovo il servizio email di TopHost ottimo: i filtri antispam funzionano egregiamente, è disponibile accesso sia POP3 sia IMAP4, ed è offerto anche il servizio SMTP (autenticato ovviamente). I tempi di accesso e le prestazioni del servizio in generale sono ottimi.

Per quanto riguarda il blog, non sono altrettanto soddisfatto. La prima cosa che mi ha colpito è stato lo sfondo blu dell’area di amministrazione e il suo vecchio design: chi conosce WP saprà certamente che la grafica è stata rinnovata da più di 2 anni. Ne deduco quindi che la versione di WordPress usata sia qualcosa come la 2.3/2.5, entrambe datate a metà 2008. Da una azienda che parla spesso di CMS abbandonati (nel post promettono la sospensione dei siti con cms non aggiornati… spero solo non si auto-sospendano) e chiede ai clienti frequenti aggiornamenti degli script usati, mi sarei aspettato se non una latest almeno una versione recente.

Non parliamo infatti di un CMS vecchio di qualche settimana o mese, ma di qualche anno: i rischi per la sicurezza derivanti da CMS non aggiornati come loro stessi ricordano sono alti, e non solo, gli utenti potrebbero apprezzare le nuove features e la notevole semplicità delle nuove versioni di WordPress. Ho subito aperto un ticket chiedendo la data dell’aggiornamento, credendo fosse una procedura ovvia e pianificata: mi è stato risposto che al momento non ci sono piani per l’aggiornamento della piattaforma.

Ho poi fatto un giro tra i plugin disponibili, che sono datati ed in numero veramente limitato. La stessa cosa dicasi per i temi: non sono molti (una ventina), e sono decisamente scarni, semplici e molto simili. La scelta dunque non è molta.

Mi sono poi imbattuto in un bug: un plugin chiede l’aggiornamento e mi offre il link per effettuarlo, ma non ho i permessi per completare l’operazione.

Per quanto mi riguarda il servizio allo stato in cui è ora, è inutilizzabile: non trovo un tema fresco e decente, mi mancano alcuni plugin utili e non affiderei mai il mio blog ad una piattaforma così vecchia e a rischio (googlando si trovano diversi report di vulnerabilità XSS di WordPress MU, sempre prontamente corretti… per chi ha aggiornato).

Sono rimasto seriamente deluso dal servizio, e come risultato, dopo neanche 10 giorni di TopBlog (di cui 8 passati lontano dal pc) ho chiesto il passaggio a TopWeb che ho potuto completare rinnovando il pacchetto in anticipo, con l’idea di installare il CMS per conto mio. Per chi continuasse a preferire una piattaforma hosted per la sua semplicità, consiglio wordpress.com o blogger.com, a cui manca solo il dominio di secondo livello, che è acquistabile a circa 15 $.

A questo  punto sarei curioso di recensire le alternative (tra cui anche Aruba Blog e i servizi classici come Tiscali Blog o Libero Blog), potrebbe interessare come serie di articoli? Fatemelo sapere, grazie.

Buone Vacanze

Giorgio

No al low-cost: davvero una scelta?

No al low-cost: davvero una scelta?

Eh si. Questa è la domanda.

Mi ricordo un post su un blog che ho letto tempo fa, TANTO tempo fa, quando il low-cost come lo intendiamo oggi (per intenderci, parlo dell’era “tophost” non dell’era “aruba”) era ancora agli inizi. Non ricordo le parole precise e non riesco a ritrovarlo (la rete è grande), ma diceva qualcosa tipo:

“Per offrire hosting a 30 € annui servono un server e una licenza Plesk. Per offrire hosting a 10 o 1200 € serve una infrastruttura.”

La frase può sembrare banale, ma racchiude una interessante distinzione. In pratica, offrire un servizio a 10 € è complicato e richiede investimenti come un servizio di alto livello. Non a caso, e qui il riscontro è immediato, tutte le aziende che nascono in questi anni, si stabilizzano su quella fascia di offerte e prezzi, non sul low-cost estremo o sull’alto livello.

Le realtà che offrono low-cost estremo, come lo ho definito, infatti, quali sono, in italia? Tophost, che ha una infrastruttura leggendaria e che sicuramente ha alzato all’infinito i costi di startup. Netsons che ha potuto lanciare questo tipo di servizi solo dopo 3 anni di esperienza sull’hosting gratuito. OVH, che non è proprio l’ultima arrivata (qui però va fatto notare che il loro pacchetto gratuito e quello a 14 €/anno sono spariti da qualche mese). Per ultimo, in ordine di tempo, Web4Web, che nasce dalla decennale esperienza della Guest SRL. Così, a memoria, altri non me ne vengono.

I motivi? Prima di tutto, va minimizzato l’intervento umano, perchè far fare una cosa ad un umano costa. Far far la stessa cosa ad una macchina, nella maggior parte dei casi, ha un costo trascurabile. Questo significa studiare un sistema di gestione clienti automatico, creare una buona KB per i clienti, semplificare e minimizzare le procedure.

Il secondo problema è relativo alle macchine stesse. In questo tipo di low-cost si arriva a toccarne i limiti. Mettere 10 000 siti a carico 0 su un server non è semplice come lo è metterne 300 molto frequentati: servono sistemi di gestione e di controllo del carico, perchè il minimo overload, il minimo bug di uno script o un semplice errore di un utente possono, in ambienti normali, far volare giù la macchina, creando disagi agli altri 9999 clienti.

Insomma, parliamo di problemi non indifferenti, che richiedono soluzioni non indifferenti che hanno costi non indifferenti. Siamo abbastanza lontani dall’ordinare un server da ovh, installarci plesk, aprire una partita IVA e iniziare a rivendere hosting.

Alla luce di tutto questo discorso la domanda è: le realtà di piccola/media grandezza, che dichiarano di “non voler entrare nel low-cost”, lo fanno per reale scelta o perchè, semplicemente, non possono entrarci?

Credo che la mia risposta sia chiara dopo questo articolo :), però sarebbe interessante avere altri pareri.

Giorgio

Quanto tempo resta agli ambienti monolitici?

Quanto tempo resta agli ambienti monolitici?

lamp

Come dicevo, negli ultimi mesi ho dedicato moltissimo tempo allo studio delle infrastrutture che stanno dietro ai servizi cosiddetti “Cloud” più utilizzati al giorno d’oggi (Google, Youtube, Facebook, Amazon, Linkedin, Azure etc).

Il motivo è semplice: gli ambienti LAMP usati fino ad ora (e qui mi riferisco alle classiche strutture utilizzate dalla maggior parte degli hosting provider, un server con su installato mysql, apache, php), non coprono le più basilari necessità di un sito web. Stiamo parlando, sia chiaro, di un sito qualunque, quale può essere il mio blog.

Mi spiego meglio: fino a qualche anno fa (ma, oserei dire, qualche mese fa, perchè, alla fine, l’esplosione di questo cloud computing è stata tutta questa estate), era assolutamente normale, quando il pacchetto hosting non bastava più (spazio esaurito, costanti abusi di cpu), acquistarne uno più grande, scaricare files e db dal vecchio spazio, spostarli sul nuovo e riconfigurare il tutto (io stesso lo ho fatto più volte con il mio blog: partito da tophost, passato a netsons, poi a eticoweb openhost e poi ad un piano personalizzato eticoweb).

Ma, riflettendoci, che senso ha? Perchè stressarsi con questo lavoro quando con un account Blogger/WordPress ho un sito esattamente uguale a questo in grado di reggere praticamente qualunque carico di lavoro? Stessa cosa dicasi per i server dedicati. Quando il mio dedicatino non regge più ne prendo uno nuovo più potente e ci sposto tutto. Anche qui, c’è un senso? Perchè comprare un piccolo dedicato quando con una VPS (mi riferisco a RackSpace CloudServers, Amazon EC2 e GoGrid) ho lo stesso servizio, scalabilità immediata e semplice, ridondanza ed in più i vantaggi di un ambiente “burstable”?

Altro problema ricorrente è l’uptime. Leggevo tempo fa “The Big Switch” di Nicholas Carr. Fa un interessante paragone tra gli anni 70, in cui, se cadeva il server aziendale, si chiamava IBM che lo ritirava su in 3/4 giorni, gli anni 80/90 in cui c’è stata la corsa all’offerta del servizio di supporto onsite più efficiente (il down di un server con un gestionale iniziava ad essere un serio problema, avendo completamente sostituito gli archivi cartacei), e oggi, dove si è capito che l’erogazione del servizio semplicemente NON PUO’ più interrompersi (basti pensare allo scompiglio creato dal down di 12 minuti di GMail di qualche mese fa).

Il servizio, è ovviamente erogato da servers. L’ultimo passaggio è quindi immediato: ogni singolo componente dell’infrastruttura, per quanto ridondato possa essere, può fermarsi. Servono quindi strutture che sappiano utilizzare gruppi (pool) di macchine, e che possano gestire il down di uno o più componenti in modo totalmente trasparente all’utente finale, l’utlizzatore del servizio. La struttura deve essere in grado di gestire la caduta di un singolo server, rack, sala o datacenter, come se fosse una cosa di routine che può accadere tutti i giorni.

E qui abbiamo una ulteriore divisione: per grandi servizi come Google, per cui adattare gli strumenti esistenti sarebbe complicato se non impossibile, sono state create strutture proprietarie, perfettamente ottimizzate, volte a svolgere precisi compiti. In altre parole, “su misura”.

C’è poi chi sta lavorando per “accogliere” gli utenti che vengono dagli ambienti che ho definito mono-server, che sta quindi lavorando per creare piattaforme che pur essendo basate su quello che compone i sistemi LAMP (banalmente, Linux, Apache, MySQL e PHP), godano di caratteristiche che a questi mancavano, come, ancora una volta, scalabilità e ridondanza (io resto comunque abbastanza convinto che tuttora ci siano limiti sopra i quali non si può andare. non ho infatti trovato uno di questi servizi “cloud hosting” in cui mysql scali a dovere).

Quindi, concludendo, mi chiedo: per quanti anni ancora vedremo siti ospitati su server singoli senza alcun tipo di fail-over? Questi vecchi ambienti, alla luce di queste considerazioni, sono davvero così terribili? Strutture come RackSpace CloudSites e Seeweb Cloud Hosting, prenderanno piede così velocemente?

%d bloggers like this: