jAbLoK

… volal s nakažlivým úsměvem ve vestibulu metra Flora chlapík v oblečku prodejce Nového Prostoru. Zářil dobrou náladou a svým sloganem rozptyloval pochyby potenciálních zákazníků. Úspěšně, aspoň co mohu soudit podle sebe a té paní, co si za mě stoupla do fronty.

Velký školitel

V pravidelných zprávách z LinkedIn jsem potkal následující doporučení na pana Martina Janků:

“We hired Martin as someone who has to teach our non-IT employees to became top IT experts interviewing IT professionals and i must say he has done excellent JOB - everyone understands now what f.e. not only CISCO is…”

Říkam “wow”.

Nejsou lidi?

Roste vám firma a nestiháte nabírat? Stávají se z vašich obchodníků či project managerů vyhořelí mrzouti a nemáte, kde nabrat novou krev?

Snadná pomoc. Prostě si najměte pana Janků, a zajeďte spolu na Floru.

Jak to vypadá, když se za pomocí J2EE vytváří webová aplikace, jejíž databáze obsahuje přes dva petabajty dat (peta = 1024⁵) a jejíž dvě stě milionů registrovaných uživatelů jejím prostřednictvím v kterýkoli čas nabízí okolo sta miliónů položek?

Architektura eBay

• na nejhrubší úrovni rozděleno na databázovou vrstvu, aplikační vstvu, vyhledávací systém a operations
• Aplikační vrstva:
  • nedrží stav (tedy žádné sessions, natož stateful session beans)
    • schválně jsem se podíval na HTTP hlavičky, zaujala mě cookie jménem “nonsession”
  • asi 100 funkčních celků, v terminologii eBay “apps” (někdo by možná řekl “business services”), dohromady to dělá cca 15,000 serverů
  • aplikační servery spolu nekomunikují, běží nezávisle na sobě (což lze snadno díky předchozímu bodu)
• Databázová vrstva:
  • rozdělena vertikálně na něco přes 70 funkčních celků (databází). Ty jsou dále řezány horizontálně podle hlavního klíče pro daný logický celek
  • většina náročných obvykle databázových operací se provádí na aplikační vrstvě; zmiňují se joiny, kontrola referenční integrity, třídění. Nepěstují se žádné uložené procedury (sem tam nějaký jednoduchý trigger)
  • eBay nepoužívá transakce (tedy kromě PayPalu, který pod eBay taky patří)
  • v praxi to znamená, že je vymezena skupina životně důležitých dat, které musí být vždy v konzistentním stavu, u ostatních se garantuje pouze “best effort”

Kdy se hodí Java?

Zajímavé jsou použité technologie: J2EE (konkrétně WebSphere) a Oracle, čímž se eBay výraně odlišuje od různých Flickrů a podobné havěti. Co mají ale tyto weby s eBay společné, jsou architektonické patterny, které se na hony vzdalují představě správné J2EE aplikace z dob EJB2.0. Ale na tom samozřejmě není nic divného.

Proč tedy v eBay Javu vůbec používají?

Dan Pritchett ve své prezentaci z roku 2006 píše: “[we] rewrote the entire application in J2EE … which gave us chance to architect the code for reuse and separation of duties”. A co si tak vzpomínám, to byl možná hlavní důvod, proč jsem se kdysi dávno po nějakých pěti letech s Perlem a PHP pouštěl do psaní webových aplikací v Javě.

Odkazy

• InfoQ Interview: Dan Pritchett on Architecture at eBay
• Dan Pritchett: The eBay Architecture (PDF, prezentace z SD Fora 2006)
• eBay Architecture at HighScalability.com
• Nati Shalom: Why most large-scale Web sites are not written in Java

I pokud vás žádné gridy a podobné moderní výmysly vůbec nezajímají, na GridGain se podívejte aspoň pro příklad, jak taky může vypadat JavaDoc-em generovaná dokumentace API:

.

“Start Here” anotace, prolinkování s Wiki a fóry, jednotná struktura popisků tříd. Vlastně žádná věda. Ale potěší.

Samozřejmě předevšim buzzword, jehož význam se oproti “dvojkové” verzi zatím neusadil. Osobně jsem se s ním poprvé setkal v nějakém rozhovoru s Novou Spivackem von Twine.

Příručka “jak blafovat o webu 3.0″ se dosud na pulty knihkupectví nedostala. Milovníkům buzzwordů určitě aspoň trochu pomůže článek Web 3.0 - The Semantic, Implicit, Mobile or Distributed Web?, ve kterém Jonas Bolinder sesumíroval přehled toho, co kdy kdo zajímavý za “web 3.0″ označil.

The biggest room in the world is the room for improvement.

Nalezeno včera v záhlaví feedu Zefa Hemela, původní autor patrně neznámý.

V roce 2005 jsem se dozvěděl, že existuje nějaký sematický web a technologie jako RDF a OWL.

Během času jsem usoudil, že se jedná o akademickou samohanu, z níž dosud nic kloudného nevypadlo.

Pak jsem náhodou potkal zmínku o firmě Radar Networks, kterou založil Nova Spivack. A tato firma tvrdila, že připravuje velkou pecku, která je na technologiích semantickém webu vystavěna.

Z informací, které Nova porůznu upouštěl, jsem zjistil, že má k semantickowebovým technologiím zdravě pragmatický vztah, že nepovažuje Semantic Web za umělou inteligenci ani za obrovské všezahrnující ontologie (ano, to sice už v roce 1998 tvrdil TBL, ale nějak se na to občas pozapomínalo). A že vlastně chtějí jen s pomocí RDF a spousty heuristik dodat chytrý organizér čehokoli.

Ten se jmenuje Twine, a mně dnes konečně přišla pozvánka do beta programu. A to je zatím k tématu vše.

Update: právě jsem zjistil, že mám k dispozici deset pozvánek.

Otázku poněkud rozvláčně rozebírá esej Magnuse Mårtenssona, naštěstí se dá ale zjednodušit na 4 body:

• User experience: na konci našeho snažení je vždycky uživatel (jasně, kritérium je trochu slabší u low-level programování)
• Komunikace: !!!
• Technologie: na tom se asi všichni architekti shodnou
• Umění: … a na tomhle taky, a zálibně si přitom pomlasknou

K té - často podceňované - komunikaci:

The architect can never sit behind closed doors and expect to succeed. The architect must be out there every day, communicating with stakeholders, in order to perform the job function with excellence. Wait, isn’t this the project manager that I am writing about now? No. The day-to-day tasks of the person who is doing the architecture quite often cross over into the realm of the manager. Also, I am a firm believer that each person on any team has to do everything possible to further the project. If that means the lines between roles become fuzzy, then so be it. The exact line is hard to define and is based on the needs of the organization.

A odkaz na Cockburnův článek The end of software engineering and the start of economic-cooperative gaming taky potěšil.

Možná by se Mårtenssonovo pojednání dalo zjednodušit na jednu větu: softwarová architektura je o komunikaci. Zbytek je tak nějak jasný.

Prosba pro čtenáře Jabloku: pokud vás nadpis odradil, dejte šanci aspoň poslednímu odstavci. Díky.

V původní zmínce o Google AppEngine na Jabloku jsem se zmínil, že při tvorbě vysoce škálující aplikace se vývojáři (vlastně i architekti) musí nemálo omezit. Aspoň pokud si škálovatelnost nezaměňují s “bude to nějak fungovat i na WebLogicovém clusteru”…

Podobně i poznámky z mailing listu o GAP zesumarizované na HighScalability.com se dají shrnout následovně:

• i ve velmi zatížené databázi jdou některé databázové poučky stranou
• v distribuované databázi tím tuplem

Pokud předpokládáme, že tam někde vzadu dříme neomezeně výkonná databáze, tak napsat škálující aplikaci je celkem triviální. Takový předpoklad je ale příliš silný. Když se podívám kolem sebe, nejpopulárnější jsou následující typy řešení:

1. Postavené na marketingu: vezmeme drahý hardware, velké diskové pole, rozběhneme drahou automagii typu Oracle RAC (wiki) a budeme doufat, že to našim potřebám postačí.
2. Postavené na skromnosti: vezmeme levný hardware, memcached nebo nějaké podobné kešovátko, a budeme doufat, že to našim potřebám postačí
3. Postavené na ambicích: stanovíme si neomezeně škálující databázi jako hlavní zadání a vypadne nám S3 nebo BigTable. Sami to asi dohromady nedáme, ale můžeme či budeme moci si za rozumný peníz pronajmout cizí infrastrukturu.
4. Postavené na koleně: zamyslíme se nad tím, co naše aplikace chce a jaká omezení jsou akceptovatelná, a zohledníme požadavky na škálovatelnost databáze už v návrhu aplikace. Vypadne nám třeba něco jako Flickr.

Varianta č. 1 se úspěšně etablovala v oblasti interních podnikových aplikací - požadavky na škálovatelnost jsou relativně omezeny velikostí korporátu, a utrácení peněz za hardware a licence u velkých dodavatelů je přece osvědčený postup

Druhá varianta je úspornější variantou téhož, i když zlí jazykové mohou poukázat na to, že úspora za hardware a licencích se vykompenzuje náklady na lidi. Těžko říct.

Varianta třetí je nejmladší. Škálovatelnost obvykle znamená, že databáze je při jakémkoli zatížení a objemu dat stejně, byť jakž takž únosně pomalá. Nutno kombinovat s variantou č. 2 (kešování). Omezení jsou předem daná - mohou vás odradit, na druhou stranu vás ochrání před tím, abyste si je bolestivě objevovali sami.

Varianta poslední byla obvykle implementována jako znouzectnost firmami, kterým předchozí varianty nestačily (a často v době, kdy varianta č. 3 nebyla na trhu). Pokud se člověk poučí od ostatních, může to být pro složitější aplikace zlatá střední cesta.

Názory ctěného čtenářstva uvítám. Pokud váš názor je “jdi s tím do háje, na jabloku chci číst o Javě”, dejte prosím taky vědět. Díky.

Pár zkratek:

• TLA = Three Letter Acronym
• SaaS = Software as a Service
• HaaS = Hardware as a Service
• IaaS = Infrastructure as a Service
• PaaS = Platform as a Service
• DaaS = Database as a Service
• 3AS = AaaS = Anything as a Service

P.S. spousta dalších více i méně příčetných *aaS pojmů je k dostání v přehledu Siliness as a Service

S uvolněním AppEngine od Google (na Jabloku zde) se vyrojily nářky, že Google chce div ne ovládnout Web: naláká zákazníky na svůj úžasný hosting, tam ale zůstanou uzamknuti bez možnosti odchodu jinam.

Teoreticky je to pitomost, jak ukazuje projektík AppDrop.com Chrise Andersona: vzal AppEngine SDK od Google, vykostil závislosti na Google a uvolnil jako open-source (to vše zcela legálně díky Apache License). Toto triviální řešení ale neškáluje ani omylem - jako databázi například používá stejně jako runtime z AppEngine SDK obyčejné soubory.

Na druhou stranu nikomu nic nebrání škálovatelnost Chrisova řešení postupně zvyšovat dopisováním dalších vychytávek počínaje třeba podporou MySQL schovanou za původním databázovým API. Teoreticky může následovat HBase (něco jako Googlí BigTable, ale vyvíjená pod ASF). Teoreticky…

A prakticky pak přinejmenším zajímavý pokus, který se díky popularitě AppEngine a AdSense reklamách na AppDropu Chrisovi aspoň trochu vyplatí

Zdroje:

• AppDrop
• Exclusive: Google App Engine ported to Amazon’s EC2 na waxy.org
• Announcing AppDrop.com (host Google App Engine projects on EC2) na Andersenově blogu

Doplnění:

Cesta plain files - MySQL - HBase je samozřejmě dlouhá a bez směřování k podpoře HBase či ekvivalentu nesmyslná - neřešila by vendor lock-in těch uživatelů, kteří používají AppEngine k tomu, k čemu je určen - tedy k hostování aplikací s nemalými nároky na škálovatelnost