Qix.it

7 commenti

• Nepher
  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!

• ludo
  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.

• Nepher
  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à.

• ludo
  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…

• Nepher
  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!!!

• ludo
  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. :)

• Christian
  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.