QCon SF ’07

QCon on selleks korraks läbi, vahepeal veel palju vett ka merre voolanud, aga nüüd lõpuks leidus aega, et see ammu-peaaegu-valmis kirjatükk üle vaadata ja siia üles riputada. Kes ei tea, mis üritusega tegu, siis siit saab vähe infot. Lend sinna oli pikk, aga selle eest oli ookeani kohal olles reisijate kasutada/käsutada KLMi personal entertainment system, mille lõputuna näiv audiovisuaalsete teoste valik algas hetke kuumadest kinohittidest ning lõppes selliste klassikutega nagu A-Team ja Tuvikesed. Aa, USAsse lendamise kohta veel selline mõttetera: (kaugesse) läände sõit on (tõsine) ajavõit :)

San Francisco

Üritus ise toimus täitsa kobedas downtown-i hotellis. Sponsorite kasutada oli fuajees mõned sajad ruutjalad pinda promoboxideks, kokku oli neid seal 6 kanti, seega jõudis kolme päeva jooksul vaevata kõige pakutavaga tutvuda. Iga päev toimus paralleelselt 4 track-i erinevatel teemadel pluss nn solution track, mida vedasid sponsorite esindajad (suts brainwash-i võib mõni kord elusid päästa). Ühel ja samal track-il oli küllaltki raske püsida (välja arvatud viimasel päeval), sest huvitavat oli kõikjal palju ning ega liigne ühekülgsuski kasuks tule.

Westin Market Street

Aga nüüd asja juurde.

1. päev

Ürituse avas Kent Beck (keyword: XP) kes jutles teemal Trends in Agile Software Development. Tema märksõnadeks agiilse softiarenduse kohta olid accountability, responsibility, transparency ja relationships. Et ühesõnaga räägi sellest, mida teed/tegid (selles osas olevat developeridel õppida äri-/müügiinimestelt), tunne oma business-it (ehk tunne oma tehnoloogiaid), ole avameelne (et keegi hiljem kummitama ei tuleks) ja mis kõige tähtsam, arenda/hoia inimsuhteid. Beck-i meelest kaaluvad sotsiaalsed skillid igal juhul üle tehnoloogilised ning et kui inimesed (arendajad) on kinnised, tuleks nad koolituma saata, et social intelligence-i juurde saada. Ning tee disaini, mitte ära kodeeri :)

Edasi algas 4 paralleelset track-i ning mina otsustasin kuulata, kuidas Richard Gabriel räägib XXL-suurusega ja iseennast üleval pidavate süsteemide disainist (Architecture of extraordinaly large, self-sustaining systems). Grady Booch hindab 1945ndast kuni praeguseni kirjutatud koodiridade arvuks 800 miljardit, aga kujuta ette süsteemi, kus triljoneid ridu koodi! Süsteem on nii suur seetõttu, et see annab suuri eeliseid vastaste ees (olgu need riigi vaenlased, viirusekirjutajad või konkurendid). See süsteem on real time, embedded, hajutatud, osa sellest on väga vana ja see on pidevas muutumises, seal juhtub pidevalt palju vigu, seda on pea võimatu täielikult monitoorida, see suhtleb teiste süsteemidega jne jne. Ühesõnaga – see tarkvara süsteem on üksikisikule hoomamatu. Masendav, kas pole? Aga tegelikult eksisteerib taolisi asju ju päris palju meie ümber. Näiteks kujuta ette New York-i transpordisüsteemi (bussid, metroo, sadamad jne), elektrisüsteemi, kanalisatsiooni, kommunikatsioonivõrke, toitlustust, üleüldse majandust, kultuuri ja inimesi. Kõikjal seal on samuti vana ja uus kõrvuti, on erinevad mastaabid, on olemas valitsus/kiirabi/politsei/tuletõrje, kõike parandatakse pidevalt ja üldse elu toimib. Analoogiaid nii et vähe pole.. Aga kuidas sellist süsteemi disainida? Dicki sõnul on disainimisele olemas 3 põhilist lähenemist:

1) MetaDisain 1 – kogu disain enne ehitamist (süsteemi inverse mudelit on võimalik konstrueerida ehk meil on ettekujutus süsteemist ja selle põhjal oskame ’tagurpidi minnes’ välja mõelda järjestikused variatsioonid, mis toovad enamvähem soovitud lõpptulemuse). Märksõnad: tõsta abstraktsiooni taset, kasuta paremaid keeli, saa paremini aru põhimõtetest, õpi loomulikult esinevatest süsteemidest (nt bioloogia).

2) MetaDisain 2 – samm sammult disain (süsteemi inverese mudelit ei ole võimalik konstrueerida ehk tuleb kasutada iteratiivset (traditsioonilist disaini-ja-testi) lähenemist, sest me ei suuda ära arvata samme, mis meile soovitud tulemuse produtseeriksid)

3) MetaDisain 3 – evolutsiooniline disain (ei edaspidi- ega tagurpidi mudelit ole võimalik konstrueerida).

Ei esimene ega teine variant sobi ultrasuurte süsteemide disainiks, seega jääb üle kolmas variant. Üks võimalus on kasutada geneetilisi algoritme. Dick tõi näite, kuidas ühed mehed kirjutasid geneetilise algoritmiga Gate Array programmi, mis pärast 5000 mutatsiooni suutis ühe spetsiifilise ülesande lahendamiseks genereerida väga kiire (ja müstilise) lahenduse. Kõik inimeste tehtud (FPGA) skeemid on siiani oma töötamiskiiruse poolest sellele alla jäänud ning teadlastele on siiani mõistatus, kuidas täpselt ikkagi see skeem töötab (tulemus on spetsiifiline konkreetsele FPGA-le, simulatsioonid sellel skeemil ei näita mingeid põhjapanevaid tulemusi jne). Skeemi iseloomustamiseks kasutati lauset: “…probably the most bizarre, mysterious, and unconventional unconstrained evolved circuit yet reported.” Täpsemalt saab lugeda siit.

Evolutsioonilise disaini märksõnad (kopi-paste slaidi pealt :)

  • no distinction between design and implementation
  • can explore regions of design space beyond
  • conventional methods
  • not constrained by understandability, modularity, or beauty / elegance (vastandiks on inimeste poolt loodud disani suundumused ehk beauty, elegance, modularity, understandability, maintainabilit and mathematics)
  • intermediate best results (can sometimeas be absurd)

Seega, et disainida ultra-suuri süsteeme, tasuks tähelepanu pöörata järgnevale:

  • high-level mechanisms must be used to help produce the code for the ULS
  • generate parts of the system from models, use domain- and task-specific languages
  • use automated reasoning as part of the generation process
  • digital software evolution

Vanakesel oli palju huvitavaid ideid, ta tõi välja mitmeid värvikaid analoogiaid arvuti- ja inimmaailmade vahel ning pakkus välja võimalusi, kuidas neid sarnasusi enda huvides ära kasutada. Tema sessioon jäi võibolla natuke (tava)eluvõõraks, esmapilgul isegi ulmeliseks ja kõigest maailma targemaile suunatuks, kuid samas oli see inspireeriv ning tulevikku vaatama panev… (Matrix, anyone!?)

Järgmisena valisin 3 Three steps for turning your Tier-Based/Spring-Application into dynamically Scalable Services (without Web Services) by Nati Shalom. Kuna Nati on üks GigaSpaces loojatest, siis ta promos arhitektuuri, mida soosib nende toode (eXtreme Application Platforma single platform for managing the data, messaging, and business logic associated with a business transaction). Tema arust ei ole aplikatsiooni juures kõige tähtsam see, kuidas iga tier ise töötab, vaid kuidas nad omavahel suhtlevad. Analoogiana võib võtta tööstusliku tootmise, kus üks variant on teha tehased, milledest mõned toodavad detaile, mõnedes toimub nende kokkupanemine ning nende omavaheline suhtlus käib transpordiettevõtete kaudu. Kui sellise arhitektuuriga tootmise puhul on nüüd tootmist vaja laiendada, siis tuleb igasse tehasesse juurde ehitada tootmisliine/palgata uusi töötajaid (millega läheb lõpuks kitsaks) jne. Teine variant on aga viia kogu tootmine ja kokkupnaek ühe katuse alla ning kui on vaja skaleeruda, siis võib lihtsalt samasuguseid tehaseid “kloonida”. Nii ka arvutisüsteemide puhul. Nati jagatud 3 nõuannet selle saavutamiseks:

1) elimineeri data-tier I/O vähendamiseks:

backup memory

in-memory data-grid andmebaasi asemel (väiksem latency, parem jõudlus, persistency kui teenus)

– batch andmete kirjutamine kettale,

2) elimineeri messaging-tier:

– too andmed ja nende saatmine kokku (mida vähem liikuivaid osi, seda parem). Nt kui kasutad JMSi, siis jäta interface samaks, tee nn fassaad ning hajutatud serverite asemel too kogu messaging ühte klastrisse kokku.

3) pane esimene ja teine nõuanne koos töötama :)

Nati promos ka sellist asja nagu Space-based architecture, mis aitab sul oma aplikatsioonil saada lineaarselt skaleeruvaks, vähendada võrguliiklust, parandada vastupidavust, võimaldada agiilset arendust jne.

Sessioon oli suht juhitud Gigaspaces toodete põhimõtetest, aga suurte ja väga suurte ettevõtete infosüsteemide puhul tundub asi töötavat, sarnaseid mudeleid kasutavad ka Google (Cloud Computing), Amazon jt. Ajasin Natiga veidi ka pärast sessiooni juttu ning sain teada, et T-Mobile läks enne iPhone-i GB launch-i GigaSpaces platvormile üle kartes, et muidu ei pea olemasolevad süsteemid vastu. Ja nad tegid seda (alates analüüsist kuni testimise lõpetamiseni) kõigest 3 kuuga. Impressive, ütleks! Kui Nati kuulis, et meiegi teeme koostööd ühe suure telekomi ettevõttega, läksid tal silmad särama ning ta soovitas kindlasti veebist demot vaadata/näppida ning siis asi kasutusele võtta :)

Järgmise 4 esineja seast läksin kuulama Brian Goetz-i, tema sessiooni pealkirjaks oli Concurrency past and present. Brian oli täitsa muhe vana, rääkis hästi-hästi kiiresti ning mõistis ka nalja visata. Java põhimõtted on simplicity & security – aga need ei kehti kahjuks thread-ide puhul… Thread-e käsitsi hallates (mida tema arust ei tohiks üldse teha) kaob ära determinism ning inimmõistusele on seda raske hoomata. Vanasti võis developer halvasti kirjutatud programmi jõudluse probleemi nii lahendada, et ütles ülemusele “mul läheb veel 6 kuud asja tuunimisega”. Tähtajaks tulid välja juba uued ja kiirema taktsagedusega protsessorid ning jõudluse probleem oligi lahenenud. BUT NOT ANYMORE! Programme tuleb hakata optimeerima mitmetuumaliste protsessorite jaoks, see tähendab aga sageli thread-idega mässamist. Nt kasuta Javas immutability-t. Kui mõne aasta eest oli OO promo ning propageeriti private muutujate kasutamist, gettereid ja settereid, siis uue suundumuse kohta võib öelda final is the new private :) Pärast seda lauset hakkas kõlama väga „rahustav” tuletõrjealarm, mis äratas üles tukkuma jäänud inimesed ning mille peale meil kenasti hotellist lahkuda paluti. Poole tee peal siiski keegi saatis tagasi sõnumi, et tegu oli false-alarm-iga ning kuna suitsu tõepoolest ei paistnud, taastasime oma esialgsed positsioonid. Huhh, see oli vist meelega tehtud, et päeva lõpuks väheke teravust oleks. Igal juhul jõudis Brian veel mõned tarkuseterad pillata:

* Use messaging instead of shared state (like its done in Erlang or Scala)

* Allocating memory is quite cheap in modern JVMs, caching might be slower

Tulevikus tuuakse concurrency lihtsustamiseks keelde uus konstruktsioon atomic block (põhimõtteliselt transaktsioonne mälu), mis vajab küll riistvara tuge, kuid mille kallal praegu usinalt vaeva nähakse. Ma näen juba praegu, kuidas see asju lihtsamaks teeks, kuid kahjuks ei ole seda enne viite aastat oodata.

All-in-all, mingeid väga uusi teadmisi sellest sessioonist ei saanud, kuid Brian juhtis tähelepanu väga olulisele tulevikus ees seisvale probleemile ja parem valmistuda varem kui hiljem.

Järgmine sessioon minu jaoks oli Cameron Purdy ja The Top 10 Ways to Botch Enterprise Java Technology-Based Application Scalability and Reliability.

Cameron Purdy

Cameron on Tangosol-i asutaja (mille Oracle omandas aprillis), rääkis samuti hästi-hästi kiiresti (vist korraldajate peale sunnitud rääkimisstiil napi sessiooni kestuse tõttu) ja viskas kogu aeg kildu. Pull kuju. Kuna selles jutus tuleks liiga palju võõrsõnu kasutada (ma hakkan mõtlema, et tegelikult oleks võinud ju kogu selle blogi sissekande inglise keeles kirjutada – kõigil lihtsam), panen põhilised (vale)ideed kirja ameerikamaal räägitavas keeles.

#10 Optimize performance assuming that it will translate to scalability & ignore the potential impact of performance on scalability (and vice-versa)

#9 Assume you are smarter than the infrastructure & follow the rules blindly

#8 Abuse the database & avoid the database

#7 Introduce single points of bottleneck & introduce single points of failure

#6 Abuse abstractions & avoid abstractions

#5 Assume disaster recovery can be added when it becomes necessary

#4 Use a one-size-fits-all architecture

#3 Use big JVM heaps

#2 Assume the network works

#1 Avoid proprietary features & believe product claims

Päris palju asju, millega on võimalik oma J2EE aplikatsiooni tuksi keerata… Kokkuvõte on see, et use common sense, know your environment and sometimes you need to break the rules!

Päeva lõpetas arutelu (e panel) teemal What will the future of Java development be?, kus rambivalguses olid Rod Johnson (Spring-i isa), Charles Nutter (JRuby mees), Chet Haase (Sun-i tähtis Java-tegelane), Joshua Bloch (tõeline Java Guru [vaata ka Pro raamatukokku]) ning Erik Meijer (hetkel töötab M$-is, aga ta oli ka üks Haskell98 disaneritest).

Java future panel

Sessioonil kõlasid läbi järgmised arvamused (kuid mitte dogmad):

  • arendus peaks olema lihtsam
  • core APIt peaks väiksemaks tegema
  • kaasame rohkem arendajaid keele arendusprotsessi
  • ei taha Javas ära kaotada strong typing-ut
  • keel ei tohiks liiga kiiresti muutuda
  • keeled ja nende arendamise tool-id võiksid parema arendatavuse huvides sõltuvusse jääda

Konverentsipaigast suundumise edasi Google poolt korraldatud avapeole kohalikus popis kõrtsus nimega Thirsty Bear.

Google Party

Söögi ega joogi pealt Google ei koonerdanud, vastutasuks kõigi hüvede tarbimise eest pidi aga „reklaami kuulama” (kohal oli värbajate armee ja nännijagajad). See aga ei häirinud võtmast üks hea kokteil ning lävimast uute ja huvitavate inimestega :)

2. päev

…algas tänu Google lahkusele veidi uniselt, ohter Starbucksi kohvi aga turgutas vaimu peagi värskeks ning uus päev võis alata. Ja umbes siin kohal lõppes ka jutt, mille olin nädalaid tagasi valmis kirjutanud. Aga pigem saagu seegi vähene rahvale avalikuks kui jäägu mu kõvakettale tolmu koguma…

Mainiks veel seda, et konverentsi veebi Schedule menüüpunkti alt saab vabalt kätte kõikide esinejate slaidid. Ning üht koma teist leidub ka QCon-i ametlikus wikis. Enjoy!

Surfer

PS! Ja külma need jänkid ka ei karda… (õhk ca 19C, vesi 14C)

1 thought on “QCon SF ’07”

Leave a Reply

Your email address will not be published. Required fields are marked *