Moving to the cloud.

Moving to the cloud.

CloudFobia. Credo di esserne malato: perdo continuamente fiducia in tutte quelle strutture che non soddisfino certi requisiti, primi fra tutti ridondanza e scalabilità.

Fino a inizio 2010, grg-web.eu è stato completamente ospitato su un singolo server, DNS compresi. Era lì anche la mia casella email principale, quella con cui lavoro, quella che non può andare MAI down. C’è da dire che il servizio di hosting, da sempre offerto da Eticoweb, ha funzionato egregiamente per 4 anni. I down di fatto si contano sulle dita di una mano: la maggior parte di questi non erano neanche imputabili al fornitore del servizio stesso bensì alla webfarm che ospita i server di Eticoweb (Seeweb).

Considerato però il rischio, ho deciso mesi fa di trasferire il servizio EMail su Directi, noto provider americano. Dietro alle email dovevano andare per forza gli NS autoritativi del dominio (è chiaramente insensato utilizzare una struttura email ridondanta se poi il sistema DNS, da cui dipende quello EMail, è ospitato su un singolo nodo), e così è stato. Le uniche cose rimaste sul vecchio server erano il blog ed il suo database.

Da quel momento ho iniziato a valutare lo spostamento del mio blog su WordPress.com o Blogger: oltre ad una struttura di livello chiaramente più alto ci guadagnerei anche diversi servizi come antispam, maggiore possibilità di interazione sociale e, soprattutto, aggiornamenti automatici della piattaforma (che non sono di per sè complicati, sono solo lunghi e stancanti, a causa dei backup da fare e verificare ogni volta).

Ho scartato Blogger perchè WordPress mi piace veramente tanto, è comodo semplice e l’area di amministrazione ha un design pulito. Blogger mi da poi una forte idea di staticità, l’ho usato per la prima volta nel 2005/2006 (forse non era ancora stato acquisito da Google al tempo) e l’interfaccia non è cambiata, mentre WordPress.com è in continuo sviluppo (e continua crescita). Oggi ho testato per la prima volta lo spostamento di tutti gli articoli e dei contenuti tramite l’apposito tool, ed è andato tutto liscio al primo tentativo.

Ho cercato servizi, magari anche italiani, dedicati all’hosting di blog, ma ho trovato ben poco: uno di questi è TopBlog di Tophost, basato su WordPress MU. Il servizo offerto da TopHost mi era però piaciuto ben poco (e la sitazione da quel momento non sembra cambiata). C’è poi Aruba Blog, ma non lo ritengo abbastanza ricco di funzionalità e la piattaforma fatta in casa di fatto mi vincolerebbe all’utilizzo di quel servizio in eterno a meno di non decidere di trasferire tutti i post a mano, nel caso. L’ultimo, ma non per importanza (anzi, è il più interessante) è Altervista Blog: basato su WordPress sembra più una installazione autonoma con tool di gestione sviluppati da loro che una installazione Multi User. Sembra ricco di temi e di funzionalità, con tool per semplificare update e backup. L’unico motivo che mi impedisce di spostare tutto su questa piattaforma è la natura gratuita del servizio.

Sto anche guardando con interesse a servizi come Tumblr, Posterous o LiveJournal, ma difficilmente rinuncerò alla totale possibilità di movimento offerta da WordPress.

In conclusione, mi prendo ancora qualche giorno (o, dipendentemente dagli impegni, settimana) per valutare il tutto ma ormai do quasi per certo lo spsotamento su WordPress.com.

Giorgio

Una grande era sta per finire.

Una grande era sta per finire.

Lo spazio, le stelle, la luna e i pianeti mi hanno sempre affascinato. Ho sempre guardato con interesse alle missioni spaziali, NASA e tutto quello che ad essa è collegato: ricordo con quanta attenzione avevo seguito le missioni Mars Exploration Rover, i due straordinari rover che hanno funzionato per mesi e mesi oltre il tempo previsto.

Di pochi minuti fa la notizia: concludendo la storica terzultima missione STS (la STS-133) il Discovery si è fermato in fondo alla pista del Kennedy Space Center. Lo Space Shuttle Discovery ha volato per 39 missioni in 27 anni di servizio, per un totale di 148 milioni di miglia. Su YouTube è disponibile il video dell’ultimo, emozionante atterraggio.

Il comandante Lindsey ha annunciato con queste parole la fine della missione: “And Houston, Discovery. For the final time, wheelstop.”, mentre Josh Byerly, commentatore NASA: “And to the ship that has led the way time and time again, we say farewell, Discovery.”.

Nel momento in cui scrivo continua la diretta su NASA TV: i veicoli di supporto hanno appena raggiunto lo shuttle. Ho seguito il tutto in diretta su Twitter (@NASAKennedy) e sullo “Shuttle Landing Blog” ufficiale NASA. Vale la pena di riportare uno screenshot dei tweet che rimarranno nella storia:

Per concludere, una foto dell’ultimo equipaggio del Discovery davanti alla navetta:

L’ultima missione per lo shuttle Endeavour sarà la STS-134 (il lancio è in programma per il 19 Aprile). L’Atlantis volerà invece per la sua seconda ultima volta: il suo ultimo volo previsto era per la STS-132, ma poi è stata finanziata e approvata una nuova missione, STS-135. Sarà quindi l’Atlantis e non l’Endeavour come inizialmente previsto a chiudere quella che ormai è definita “The Space Shuttle Era”.

Addio Discovery.

Hello MX!

Hello MX!

A volte capita, dopo aver lanciato un HELO ad un MX, di ricevere risposte veramente simpatiche, carine, o stupide e inutili, comunque molto lontane dal default. Lo stesso, a volte, succede dopo il QUIT.

E’ curioso notare come gli amministratori di queste strutture si divertano a studiare queste risposte, quasi come fosse un must alla pari dell’antispam nel processo di configurazione di un mailserver.

Mi sembra quindi il caso di farne una sorta di rassegna di seguito:

Postini, il noto servizio di Google, appare molto freddo e professionale, mettendo subito in chiaro chi comanda:

 

mx-test:~# telnet google.com.s9a1.psmtp.com 25
Trying 74.125.148.10…
Connected to google.com.s9a1.psmtp.com.
Escape character is ‘^]’.
220 Postini ESMTP 213 y6_26_2c0 ready.  CA Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements.
HELO mx-test.grg-web.eu
250 Postini says hello back
QUIT
221 Catch you later
Connection closed by foreign host.
mx-test:~#
Quando mi presento (HELO mx-test.grg-web.eu) però si calma e mi saluta tranquillamente. Anche alla chiusura, vengo salutato amichevolmente.
L’MX di Youtube appare meno cattivo ma ancora più freddo:
mx-test:~# telnet sjl-mbox1.sjl.youtube.com 25
Trying 208.65.153.154…
Connected to sjl-mbox1.sjl.youtube.com.
Escape character is ‘^]’.
220 sjl-mbox1.sjl.youtube.com ESMTP Postfix
HELO mx-test.grg-web.eu
250 sjl-mbox1.sjl.youtube.com
QUIT
221 Bye
Connection closed by foreign host.
mx-test:~#
GMail si dimostra subito sottomesso, dichiarando di essere “al mio servizio” e blaterando un qualche codice nella sua lingua:
mx-test:~# telnet gmail-smtp-in.l.google.com 25
Trying 209.85.129.27…
Connected to gmail-smtp-in.l.google.com.
Escape character is ‘^]’.
220 mx.google.com ESMTP 13si5734471fks.30
HELO mx-test.grg-web.eu
250 mx.google.com at your service
QUIT
221 2.0.0 closing connection 13si5734471fks.30
Connection closed by foreign host.
mx-test:~#
cPanel invece, dopo avermi spiegato chiaramente che non posso usarlo per inviare SPAM, mi sbugiarda facendo notare che non sono chi dico di essere (mx-test.grg-web.eu) ma ec2-79-125-117-117.eu-west-1.compute.amazonaws.com. Da notare, come GMail si dimentica di salutarmi quando me ne vado:
mx-test:~# telnet mx1.cpanel.net 25
Trying 208.74.121.68…
Connected to mx1.cpanel.net.
Escape character is ‘^]’.
220-mx1.cpanel.net ESMTP Exim 4.69 #1 Sun, 25 Apr 2010 04:04:28 -0500
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
HELO mx-test.grg-web.eu
250 mx1.cpanel.net Hello ec2-79-125-117-117.eu-west-1.compute.amazonaws.com [79.125.117.117]
QUIT
221 mx1.cpanel.net closing connection
Connection closed by foreign host.
mx-test:~#
Microsoft Live Mail si comporta in modo molto simile:
mx-test:~# telnet mx1.hotmail.com 25
Trying 65.54.188.72…
Connected to mx1.hotmail.com.
Escape character is ‘^]’.
220 bay0-mc1-f17.Bay0.hotmail.com Sending unsolicited commercial or bulk e-mail to Microsoft’s computer network is prohibited. Other restrictions are found at http://privacy.msn.com/Anti-spam/. Violations will result in use of equipment located in California and other states. Sun, 25 Apr 2010 02:08:58 -0700
HELO mx-test.grg-web.eu
250 bay0-mc1-f17.Bay0.hotmail.com (3.10.0.73) Hello [79.125.117.117]
QUIT
221 bay0-mc1-f17.Bay0.hotmail.com Service closing transmission channel
Connection closed by foreign host.
mx-test:~#
Mi fa notare che non posso inviare SPAM, e mi dice in tono minaccioso quali saranno le conseguenze in caso di una eventuale violazione. Appena mi presento mi saluta, ma si dimentica di farlo quando me ne vado.
Molto nella norma, appare invece Yahoo, che va diretto al punto saltando i convenevoli:
mx-test:~# telnet a.mx.mail.yahoo.com 25
Trying 67.195.168.31…
Connected to a.mx.mail.yahoo.com.
Escape character is ‘^]’.
220 mta181.mail.ac4.yahoo.com ESMTP YSmtp service ready
HELO mx-test.grg-web.eu
250 mta181.mail.ac4.yahoo.com
QUIT
221 mta181.mail.ac4.yahoo.com
Connection closed by foreign host.
mx-test:~#
Simpatico invece GMX, che continua a ripetere il suo nome come se quasi non sentisse il resto. Non mi saluta:
mx-test:~# telnet mx0.gmx.net 25
Trying 213.165.64.100…
Connected to mx0.gmx.net.
Escape character is ‘^]’.
220 mx0.gmx.net GMX Mailservices ESMTP {mx061}
HELO mx-test.grg-web.eu
250 mx0.gmx.net GMX Mailservices {mx061}
QUIT
221 2.0.0 GMX Mailservices {mx061}
Connection closed by foreign host.
mx-test:~#
AOL prima di farmi parlare mette in chiaro le regole del gioco. Non mi saluta all’inizio ma solo all’uscita quasi come se volesse mandarmi via:
mx-test:~# telnet mailin-01.mx.aol.com 25
Trying 205.188.146.193…
Connected to mailin-01.mx.aol.com.
Escape character is ‘^]’.
220-mtain-dg04.r1000.mx.aol.com ESMTP Internet Inbound
220-AOL and its affiliated companies do not
220-authorize the use of its proprietary computers and computer
220-networks to accept, transmit, or distribute unsolicited bulk
220-e-mail sent from the internet.
220-Effective immediately:
220-AOL may no longer accept connections from IP addresses
220 which no do not have reverse-DNS (PTR records) assigned.
HELO mx-test.grg-web.eu
250 mtain-dg04.r1000.mx.aol.com
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
mx-test:~#
Facebook, invece, è educatissimo:
mx-test:~# telnet mx.sf2p.tfbnw.net 25
Trying 69.63.176.71…
Connected to mx.sf2p.tfbnw.net.
Escape character is ‘^]’.
220 pp-in02.sf2p.tfbnw.net ESMTP Sun, 25 Apr 2010 02:22:01 -0700
HELO mx-test.grg-web.eu
250 pp-in02.sf2p.tfbnw.net Hello ec2-79-125-117-117.eu-west-1.compute.amazonaws.com [79.125.117.117], pleased to meet you
QUIT
221 2.0.0 pp-in02.sf2p.tfbnw.net closing connection
Connection closed by foreign host.
mx-test:~#
RackSpace tenta di fregarmi con un antiquato Greet-Pause, ma poi mi saluta:
mx-test:~# telnet mx1.sat.rackspace.com 25
Trying 64.39.1.223…
Connected to mx1.sat.rackspace.com.
Escape character is ‘^]’.
HELO mx-test.grg-web.eu
554 mx1.sat.rackspace.com ESMTP not accepting messages
250 mx1.sat.rackspace.com Hello ec2-79-125-117-117.eu-west-1.compute.amazonaws.com [79.125.117.117], pleased to meet you
QUIT
221 2.0.0 mx1.sat.rackspace.com closing connection
Connection closed by foreign host.
mx-test:~#
Inbox, infine, “fa il figo” sbandierando un server SMTP fatto in casa, un numero di versione che non finisce più e ilk nome del suo creatore (MatriX):
mx-test:~# telnet inc.inbox.com 25
Trying 64.135.83.90…
Connected to inc.inbox.com.
Escape character is ‘^]’.
220 WH96.inbox.com [InBox.Com SMTP Server] ver. 1.0.3504.17794 by MatriX ATC:61
HELO mx-test.grg-web.eu
250 WH96.inbox.com says hello
QUIT
221 [InBox.Com SMTP Server] service closing transmission channel
Connection closed by foreign host.
mx-test:~#
Se avete trovato qualcosa di peggio, segnalatemelo!
Giorgio
Anche i più grandi tra i grandi…

Anche i più grandi tra i grandi…

…eh si, volano giù

Sono un Google-Lover. Da quando esiste, ho spostato tutte le mie applicazioni su Google App Engine. Non mi dilungo nei dettagli, ma la struttura fa impressione: scala senza il minimo problema, sia per quanto riguarda la parte web che la parte db/storage, e non ha i limite che ha Amazon AWS. Ho fatto diversi test sul servizio, se a qualcuno interessano potrei pubblicare un post descrivendone i risultati.

Torniamo al down: il 24 Febbraio stavo lavorando ad una mia applicazione basata su GAE, quando, intorno alle 17.00, tutte le richieste hanno iniziato a finire in timeout. Appena il tempo di realizzare (ho impiegato 30 minuti per convincermi che il servizio era veramente down) e il mio aggregatore mi segnala un nuovo post nel gruppo GAE Downtime Notify di Google in cui vengono pubblicate informazioni sui down previsti e su quelli un pò meno previsti. Sono circa le 17.30.

Il suo contenuto è:

Since 7:53am PST, App Engine has been experiencing an unexpected outage affecting the majority of App Engine applications.  The team is working quickly to correct the cause and will have an ETA on the fix shortly.

Please watch this thread for updates. We sincerely apologies for the inconvenience.

Il servizio rimane KO, e alle 18.30 circa ricevo un confortante aggiornamento:

We are still actively working on the on-going outage.  We’ve also experienced a problem with our backup datacenter. We will continue to provide status updates on this thread every thirty minutes.

Il messaggio mi informa che stanno lavorando al problema, ma che ci sono altri problemi con il datacenter secondario (su cui, probabilmente, avevano pianificato di swappare il traffico in caso di failure del primario).

Dopo altri 20 minuti, alle 18.50 (o qualcosa di simile) la mia applicazione riprende a rispondere, ma segnala che il DataStore è in read-only. Un nuovo post conferma quanto ho appena notato:

As of 9:48am, all applications should now be available in read-only mode.

Aspetto altri 20 minuti e tutto torna a funzionare normalmente, anche se in modo estremamente lento. Probabilmente -penso- sono partiti tutti i processi cron schedulati durante il down.

Arriva un nuovo update:

As of 10:09am, all application should be serving traffic and successfully reading/writing from the datastore.  Again, apologies for the inconvenience of the outage.  We will follow up with a post-mortem.

Per me si chiude qui, nel senso che dalle 19.30 più o meno, lentezza a parte, riprende a funzionare tutto. Per altri utenti no, Google infatti parla di problemi ancora presenti su “a small percentage of datastore entity groups”. Più tardi, in una rettifica, parleranno di problemi di inconsistenza del DataStore per circa 25 applicazioni.

La sera del 25 Febbraio (il giorno dopo) Google pubblica un aggiornamento:

We continue to work diligently in the wake of yesterday’s unforeseen App Engine outage on a number of issues, so we wanted to provide you an update with our current list of tasks.

– Applications will not be charged for any App Engine resource usage that occurred during Feb 24th, 2010.

– We are still working on fix for writes and transactional reads affecting a small number of datastore entity groups.  We have determined that approximately 25 application IDs have been affected by this issue.  If you feel you are having difficulties with certain entity groups in your application, please respond to this thread with your App ID.

– We are working hard on putting together a detailed post mortem that we will be making public.  We expect to have this available to you next week.

Again we sincerely apologize for yesterday’s service disruption.  We take App Engine’s reliability very seriously and we are confident we can use the hard lessons learned from yesterday’s event to improve our offering to you.

Attendo il post-mortem fino al 5 Marzo, quando, finalmente, ricevo la tanto attesa mail. Inizia con un riepilogo sul downtime:

On February 24th, 2010, all Googe App Engine applications were in varying degraded states of operation for a period of two hours and twenty minutes from 7:48 AM to 10:09 AM PT | 15:48 to 18:09 GMT.

The underlying cause of the outage was a power failure in our primary datacenter. While the Google App Engine infrastructure is designed to quickly recover from these sort of failures, this type of rare problem, combined with internal procedural issues  extended the time required to restore the service.

Parla di “internal procedural issues”, “problemi nelle procedure interne” meglio descritti poco sotto:

– Although we had procedures ready for this sort of outage, the oncall staff was unfamiliar with them and had not trained sufficiently with the specific recovery procedure for this type of failure.

– Recent work to migrate the datastore for better multihoming changed and improved the procedure for handling these failures significantly. However, some documentation detailing the procedure to support the datastore during failover incorrectly referred to the old configuration. This led to confusion during the event.

– The production team had not agreed on a policy that clearly indicates when, and in what situations, our oncall staff should take aggressive user-facing actions, such as an unscheduled failover.  This led to a bad call of returning to a partially working datacenter.

– We failed to plan for the case of a power outage that might affect some, but not all, of our machines in a datacenter (in this case, about 25%). In particular, this led to incorrect analysis of the serving state of the failed datacenter and when it might recover.

In breve (ed in italiano): lo staff oncall non era pronto a far fronte a questo tipo di problemi. La documentazione di supporto, si riferiva ad una versione obsoleta del sistema (e probabilmente totalmente incompatibile, perchè è stato recentemente aggiornato il sistema di replicazione del DS), e i tecnici che avrebbero dovuto iniziare il failover si sono trovati davanti a due procedure contrastanti senza sapere quale utilizzare.

I sistemi di controllo interni hanno poi segnalato come utilizzabile un datacenter che non lo era, poichè non erano studiati per considerare una perdita di alimentazione parziale e non totale. Lo staff, infine, dopo aver tentato, con esito negativo, di spostare il traffico in read-only sul datacenter secondario, ha deciso di girare di nuovo il tutto sul primario, credendo, erroneamente, che stesse tornando online.

Dalla cronologia, riportata in calce al post mortem,  scopro in dettaglio cosa è successo durante le due ore di down (riporto gli orari originali, tenete conto che noi siamo avanti di 9 ore):

Alle 7.48 si iniziano a riscontrare errori nel traffico servito dal DC primario. Alle 7.53 i “Google Site Reliabilty Engineers” segnalano che nel DC c’è stata una perdita di alimentazione, e che a causa di un problema con l’alimentazione secondaria circa il 25 % dei server sono in crash.

Alle 8.01 viene confermato che GAE è down. Viene deciso di darne comunicazione ufficiale agli utenti. Alle 8.22 viene confermato che diverse macchine non sono ripartite, e che il cluster GFS e BigTable non sono funzionanti a causa dell’alto numero di server persi. Si decide di avviare la procedura di failover verso il DC secondario.

Alle 8.40 viene scoperto un conflitto nella documentazione sulle procedure di failover. Non potendo decidere quale fosse la procedura da utilizzare, gli ingegneri decidono di contattare la persona responsabile del cambio di procedura. Alle 8.44, mentre una parte dello staff sta ancora lavorando alla procedura di failover, si tenta di servire il traffico in sola lettura dal DC primario. Un problema nella configurazione, però, impedisce al DC secondario di servire il traffico.

Alle 9.08, mentre parte dello staff sta tentando di risolvere il problema di configurazione nel DC secondario che impedisce di servire le richieste e un’altra parte sta ancora lavorando alla procedura di failover, il “Primary OnCall Engineer” ritenendo che il DC primario fosse tornato completamente operativo e pronto a servire tutte le richieste, avendo in mano dati dei sistemi di diagnosi che confermavano ciò, senza sapere però che non era mai usccesso prima che un DC dopo un danno simile tornasse utilizzabile, devia nuovamente il traffico su quest’ultimo, nel tentativo di far tornare online il servizio.

Alle 9.18 si rendono conto che il DC primario non è tornato online, e che non può servire il traffico. Si concentrano quindi gli sforzi sul DC secondario, si devia nuovamente lì tutto il traffico e si inizia la procedura di failover.

Alle 9.35 viene raggiunto un ingegnere con esperienza nella procedura e si inizia il failover. Alle 9.48 il DC secondario inizia a servire le richieste in read-only.

Alle 9.53 viene confermata la corretta procedura di failover per il read-write, e si avvia il processo.

Alle 10.09 il processo termina, ed il traffico riprende ad essere servito normalmente. Google App Engine da questo momento è considerato online.

Il post-mortem contiene anche una serie di correzioni che Google intende attuare per evitare il ripetersi di casi simili:

As a result, we have instituted the following procedures going forward:

– Introduce regular drills by all oncall staff of all of our production procedures. This will include the rare and complicated procedures, and all members of the team will be required to complete the drills before joining the oncall rotation.

– Implement a regular bi-monthly audit of our operations docs to ensure that all needed procedures are properly findable, and all out-of-date docs are properly marked “Deprecated.”

– Establish a clear policy framework to assist oncall staff to quickly and decisively make decisions about taking intrusive, user-facing actions during failures. This will allow them to act confidently and without delay in emergency situations.

We believe that with these new procedures in place, last week’s outage would have been reduced in impact from about 2 hours of total unavailability to about 10 to 20 minutes of partial unavailability.

In response to this outage, we have also decided to make a major infrastructural change in App Engine. Currently, App Engine provides a one-size-fits-all Datastore, that provides low write latency combined with strong consistency, in exchange for lower availability in situations of unexpected failure in one of our serving datacenters. In response to this outage, and feedback from our users, we have begun work on providing two different Datastore configurations:

– The current option of low-latency, strong consistency, and lower availability during unexpected failures (like a power outage)

– A new option for higher availability using synchronous replication for reads and writes, at the cost of significantly higher latency

We believe that providing both of these options to you, our users, will allow you to make your own informed decisions about the tradeoffs you want to make in running your applications.

Termina con delle scuse:

We sincerely apologize for the impact of Feb 24th’s service disruption on your applications. We take great pride in the reliability that App Engine offers, but we also recognize that we can do more to improve it. You can be confident that we will continue to work diligently to improve the service and ensure the impact of low level outages like this have the least possible affect on our customers.

Un down, prima o poi capita a tutti. Per quanto mi riguarda, rinnovo la mia fiducia nella grande G.

Giorgio

Anche i più grandi…

Anche i più grandi…

…volano giù.

WordPress.com e i 10 milioni di blog che ospita in 3 datacenter su un migliaio di servers HP, down per 110 minuti il 19 Febbraio 2010. Il peggiore down di sempre per il secondo servizio di blogging mondiale (online dal 21 Novembre 2005).

La descrizione delle cause dell’accaduto non è proprio precisa e completa, ma il down è stato dovuto, stando al post pubblicato sul blog ufficiale del servizio, pubblicato qualche ora dopo l’accaduto, ad un problema di configurazione “hardware”: un cavo collegato nel posto sbagliato, che ha causato il routing del traffico di rete interno su un link che non poteva -sempre secondo la fonte- reggere nemmeno il 10 % del flusso dati.

Questa configurazione, non si spiega come, ha retto per diversi mesi, finchè la saturazione di questo link ha portato offline uno dei 3 datacenters. I sistemi di failover, non preparati a far fronte ad un problema di questo tipo, non hanno funzionato correttamente e hanno bloccato l’erogazione del traffico anche dagli altri due DC.

Certamente, fa riflettere. Io stesso ho considerato lo spostamento del mio blog su Blogspot o WordPress.com, a causa delle maggiori garanzie che danno rispetto ad un servizio di hosting.

A dire il vero, da diversi mesi mi faccio paranoie, definite da una amica “paranoie da scalasistemistanonrelazionale*”, sulla ridondanza e scalabilità dei sistemi, e stavo considerando lo spostamento di blog e tutto quello che ci sta dietro su una struttura SERIA. Questo vuol dire, dominio da Directi o Google. Email su Google Apps Premium. Blog su Blogspot. E qualunque tipo di applicazione su GAE. Per i documenti uso ormai da tempo Google Docs.

Questo down, non si direbbe, è per me una forte spinta in quella direzione.

Giorgio

* Non si è ancora capito se il nonrelazionale fosse dovuto al tipo di DBM’s su cui lavoro o proprio alle mie relazioni interpersonali O_O.