altre destinazioni
vedi anche
- Google, Motorola, e... Mantellini «
- Spigolature / 28 «
- Gmail ha rotto «
- Finalmente! «
- Google e Jotspot, disinformazione dal Corriere «
ultimi post
- Come si incentiva il trasporto pubblico in Lombardia / 1 «
- Dieci e uno «
- Maratoneti «
- Jiayu G3, dove comprarlo (e ne vale la pena)? «
- Come risparmiare batteria su Android «
ultimi commenti
- ludo, Dieci e uno «
- theo, Dieci e uno «
- ludo, Libevent-based HTTP/1.1 client «
- george d, Libevent-based HTTP/1.1 client «
- ludo, Libevent-based HTTP/1.1 client «
tag principali
- blogging
- italia
- milano
- spigolature
- conferenze
- top100
- python
- web 2.0
- blogbabel
- rugby
- calcio
- ebook
- tv
- barcamp
- musica
- nanopublishing
- lightpress
- django
- php
categorie
- blogging «
- books «
- calcio «
- design «
- digital underground «
- ebay «
- eventi «
- gadget «
- games «
- general «
- guest blogger «
- help «
- in evidenza «
- internet business «
- lazyweb «
- letture «
- linux «
- luambo «
-
ludo «
- audio e musica «
- foto «
- quotidianità «
- rete «
- luoghi «
- milano «
- misc «
- miscellanea «
- mobile «
- mobile e pda «
- motori di ricerca «
- music «
- musica «
- news «
- personal «
- php «
- podcasting «
- podcasts «
- prima pagina «
- python «
- rugby «
- screencasts «
- simpleaggregator «
- sistemi operativi «
- smanettando «
- software «
- staticblog «
- sviluppo «
-
tech «
- ipaq «
- palm «
- programmazione «
- tecnologie varie «
- web «
- technology «
- tecnologia «
- tex «
- tv «
- varie «
- web 2.0 «
- web design «
archivi
- luglio 2013 «
- aprile 2013 «
- marzo 2013 «
- febbraio 2013 «
- novembre 2012 «
- ottobre 2012 «
- aprile 2012 «
- settembre 2011 «
- agosto 2011 «
- luglio 2011 «
- giugno 2011 «
- maggio 2011 «
- marzo 2011 «
- febbraio 2011 «
- gennaio 2011 «
- dicembre 2010 «
- novembre 2010 «
- ottobre 2010 «
- settembre 2010 «
- giugno 2010 «
- maggio 2010 «
- novembre 2009 «
- settembre 2009 «
- agosto 2009 «
- luglio 2009 «
- giugno 2009 «
- maggio 2009 «
- aprile 2009 «
- marzo 2009 «
- febbraio 2009 «
- gennaio 2009 «
- novembre 2008 «
- ottobre 2008 «
- settembre 2008 «
- agosto 2008 «
- luglio 2008 «
- giugno 2008 «
- maggio 2008 «
- aprile 2008 «
- marzo 2008 «
- febbraio 2008 «
- gennaio 2008 «
- dicembre 2007 «
- novembre 2007 «
- ottobre 2007 «
- settembre 2007 «
- agosto 2007 «
- luglio 2007 «
- giugno 2007 «
- maggio 2007 «
- aprile 2007 «
- marzo 2007 «
- febbraio 2007 «
- gennaio 2007 «
- dicembre 2006 «
- novembre 2006 «
- ottobre 2006 «
- settembre 2006 «
- agosto 2006 «
- luglio 2006 «
- giugno 2006 «
- maggio 2006 «
- aprile 2006 «
- marzo 2006 «
- febbraio 2006 «
- dicembre 2005 «
- novembre 2005 «
- ottobre 2005 «
- settembre 2005 «
- agosto 2005 «
- luglio 2005 «
- giugno 2005 «
- maggio 2005 «
- aprile 2005 «
- marzo 2005 «
- febbraio 2005 «
- gennaio 2005 «
- dicembre 2004 «
- novembre 2004 «
- ottobre 2004 «
- settembre 2004 «
- agosto 2004 «
- luglio 2004 «
- giugno 2004 «
- maggio 2004 «
- gennaio 2004 «
- dicembre 2003 «
- novembre 2003 «
- ottobre 2003 «
- settembre 2003 «
- agosto 2003 «
- giugno 2003 «
powered by
- WPFrontman + WP
friends
copyright
- © 2004-2011
Ludovico Magnocavallo
tutti i diritti riservati
Un'occhiata al Google File System
Oggi sembra essere un Google Day: dopo l’annuncio di Checkout e quello meno importante di Google Auth, due bei post di Storage Mojo sul Google File System.
Lavorando in un ambiente che ha nel mainframe (soprannominato “la lavatrice”) il cuore del proprio sistema informatico, ed essendomi occupato negli ultimi tempi di sistemi fault tolerant (come questi), dei post di Storage Mojo mi ha colpito particolarmente questa frase: “rather than build availability into every IT element at great cost, build availability around every element at low cost”. Erlang, architetture shared nothing, Unix, linguaggi di scripting, insomma tutto il parco di tecnologie e metodi che chi è cresciuto a stretto contatto con Internet negli ultimi dieci-quindici anni da per scontato.
E’ la grande sfida dei prossimi anni in ambito Enterprise (o almeno in certi ambiti come quello in cui lavoro), distante anni luce dalle complicazioni — e dai costi — infernali del mainframe, ma purtroppo anche dalla mentalità e dalla cultura dominanti in azienda. Google ci è arrivata qualche anno fa, e parte del successo straordinario che ha conosciuto è dovuto proprio a questo approccio. Far digerire la stessa cosa alle imprese di casa nostra è un altro paio di maniche. More later.
3 luglio 2006 #
E’ vero anche l’opposto. Chi è cresciuto a stretto contatto con internet queste cose le mastica meglio del pane, ma è vero anche che le stesse persone tipicamente ignorano quasi del tutto il mondo dei mainframe. E’ un problema stranoto.
Raggiungere la garanzia di SLA estremo come un "zero error & downtime 24x7x365" a fronte di carichi enormi (Google non garantisce alcuno SLA… è una situazione più tipicamente bancaria) si può con qualunque tecnologia, ma nel mainframe c’è da anni by design; sulle altre piattaforme no, e va costruito con non pochi strati di complessità aggiuntiva (e costi, che alla fine quanto a "infernalità" non diventano da meno). Che poi è il semplicissimo motivo per cui i mainframe crescono felici del 20% anno su anno.
Da qui a 10 anni chissà… magari anche l’hardware x86 o POWER evolveranno al punto da sopportare in modo trasparente errori nelle pipeline di calcolo come fa il mainframe con le r-unit, scalando linearmente di 4 ordini di grandezza come possono i mainframe, oppure altre tecnologie renderanno questo e altri approcci inutili (con riferimento a "around" invece che "into")…
Ma per allora anche il mainframe si sarà evoluto come ha fatto sinora, e come adesso per alcune cose non sarà adatto mentre per altre sarà forse la piattaforma migliore. Nel dubbio, io da "nato a contatto con internet" preferisco comunque capire anche le logiche dei mainframe, che se resistono senza sosta da 40 anni qualcosa di buono lo devono pur avere. ;-)
Ciao!
3 luglio 2006 #
Nepher grazie del commento. Per mia esperienza lo "zero error & downtime 24x7x365" è (almeno per il downtime) una frottola. Il mainframe (inteso come somma di hw, os e applicazioni) è di una complessità spaventosa, e a volte un guasto o errore risibile su altre piattaforme (come un disco di un array che si fotte, visto un paio di anni fa, o il cambio dell’ora legale, visto qualche mese fa) comportano un fermo totale e tempi di ripristino assurdi. Per non parlare poi dei costi di sviluppo, e della difficoltà estrema ad integrarsi con altre piattaforme.
Quello che ancora spinge il mainframe (almeno per mia esperienza) sono la base software che raccoglie esperienze e conoscenze di qualche decennio, e la paura di lasciare un mondo noto per uno sconosciuto (con conseguente perdita di potere, budget, ecc.) che attanaglia chi ha vissuto solo di mainframe.
4 luglio 2006 #
Grazie a te per gli spunti, sono argomentazioni che mi interessa capire.
Immagino ci sia uno scotto da pagare in termini di complessità della piattaforma, in effetti non mi aspetto che un oggetto che eredita 40 anni di storia informatica possa essere anche semplice come un sistema concepito di recente. In fondo diceva già Brecht che è proprio la semplicità che è difficile a farsi. ;-)
Sul costo di sviluppo, è una lamentela che sento spesso. Sono in parte d’accordo con te, ma poi indaghi e scopri che nessuno usa WDZ che sgraverebbe l’host dalle compilazioni; che java e linux, che hanno costi di esercizio radicalmente inferiori e potrebbero non essere sviluppati ma solo testati su host, vengono messi su altre piattaforme e su mainframe si lascia solo il costoso CICS/Cobol; che nessuno esige dagli ISV dei prezzi per MSU invece che per MIPS così da sfruttare il subcapacity pricing. Sono solo esempi, ovviamente.
Prendo sempre le affermazioni inerenti i costi con le pinze, senza particolari pregiudizi ma anche con una giusta dose di legittimo dubbio. E’ chiaro che la percezione sia di un oggetto costosissimo… ma la dimostrazione in un senso o nell’altro non l’ho mai trovata banale, a parità di SLA e funzionalità.
4 luglio 2006 #
Nepher i commenti diventano sempre più interessanti, quando ho tempo li riassumo in un post. Aggiungo due righe di commento a quello che scrivi prima di entrare in meditazione per la partita di stasera.
Parte del problema, oltre ai 40 anni che giustamente citi, è da imputare alla filosofia ed all’organizzazione interna di IBM: non è solo il mainframe a soffrire di complessità, buona parte delle tecnologie prodotte da Big Blue per funzionare hanno bisogno di impostazioni arcane e danze della pioggia, che di norma conoscono solo i consulenti IBM.
Riguardo a Java sul mainframe, uno dei progetti di cui mi sto occupando è appunto il porting da WebSphere Z/OS a Tomcat/Zlinux (meglio sarebbe stato Linux 386 ma è un passo che adesso non possiamo fare). Su Z/OS infatti Java (e ancora più WebShpere) sono lenti e poco affidabili, e soprattutto se come spesso accade le risorse mainframe sono tariffate a consumo i programmi Java costano più di ottimizzazione per spremere fino all’ultimo MIPS che di sviluppo vero e proprio.
More later…
4 luglio 2006 #
Ci sono molti casi in cui il workload Java, in presenza di processori zAAP, viene rediretto da z/OS su questi fino al 90%; dato che il lavoro su zAAP non genera alcuna bolletta software a consumo, il costo di esercizio viene abbattuto quasi del tutto: minori ottimizzazioni dovrebbero diventare così accettabili.
Sulla lentezza di WS/Java, mi informerò surante l’attesa del tuo prossimo post a riguardo. ;-)
Buona partita!!!
4 luglio 2006 #
So dei processori zAAP, il problema è che la diffusione è minima rispetto ad ambienti Java tradizionali, e quindi c’è poca esperienza e virtualmente nessuna knowledge base diffusa. Chi da noi sviluppa in Java vuole usare una JDK 1.5, e usarla in ambienti dove è supportata da comunità il più ampie possibile di sviluppatori.
E poi non so il costo dei processori zAAP, ma se è come i processori IFL (40k all’anno per un processore che dovrebbe essere un power5) e a questo aggiungi la RAm necessaria per le applicazioni Java, e la contesa sull’I/O con tutto il resto che gira sull’host, a mio parere il gioco non vale la candela.
Certo, per utilizzare un’architettura 386 (o SPARC/Solaris, ecc.) in ambiente Enterprise bisogna dotarsi di infrastrutture di supporto, gestione operativa e monitoraggio adeguate. Ed è qui che stanno i maggiori problemi a migrare per chi queste strutture le ha già in ambiente mainframe.
Nepher ti ringrazio ancora dei commenti, sono argomenti su cui mi è difficile fare un post, molto più facile svolgerli come discussione. :)
9 luglio 2006 #
Ci sono molti casi in cui il workload Java, in presenza di processori zAAP, viene rediretto da z/OS su questi fino al 90%; dato che il lavoro su zAAP non genera alcuna bolletta software a consumo, il costo di esercizio viene abbattuto quasi del tutto: minori ottimizzazioni dovrebbero diventare così accettabili.