jAbLoK

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

Předevčírem jsem se o své první dojmy z EC2 chtěl nadšeně podělit s Františkem. Jenže František je - jak známo - všude první, a tudíž mohl být nad nějakou virtualizaci povznesen - samozřejmě už předtím četl spekulace o tom, že se Google chystá nabídnout svou infrastrukturu jako službu. Což se během dvou dnů také stalo.

Služba se jmenuje appspot.com, a v tuto chvíli se nachází ve stadiu “preview release”, což znamená testovací provoz pro prvních 10,000 zájemců, kteří se ozvali během několika hodin po oficiálním oznámení (já to bohužel nestihl). K dispozici je vývojové prostředí AppEngine, které obsahuje potřebné knihovny a hlavně lokálně spustitelný runtime, v němž je možná aplikaci otestovat před uploadem na appspot bez jakýchkoli úprav. Služba je při omezené návštěvnosti a velikosti persistentních dat zdarma, v plánu je placená varianta, kde tato omezení padnou.

AppEngine nabízí oproti Amazonu škálovatelnost transparentní, samozřejmě za cenu jistých omezení. Zatimco amazoními služby (AWS) vám usnadňují žonglování se serverovou farmou, jejíž možnosti můžete využívat dle architektonické i programátorské fantazie, Google vás zcela odstiňuje od konkrétního (byť virtuálního) serveru, operačního systému a jeho limitů. Zkrátka poskytuje transparentně škálující aplikační server.

Tato transparentnost je samozřejmě možná jen za cenu několika omezení, které musí takto vyvíjená a nasazená aplikace splňovat. Namátkou:

• Persistentní vrstva
  • Používá speciální API a dotazovací jazyk pro persistentní ukládání dat (pro lepší srozumitelnost ale budu dál používat pojmy z relačnch databází)
  • Omezené dotazovací možnosti (nelze “najít NULL”, nelze kombinovat porovnávací operace nad více “sloupci” a pokud je použijeme, musíme je v připadné ORDER BY klausuli dát na začátek, a navíc není podporován operátor nerovnosti)
• Aplikace běží v omezeném kontejneru (sandboxu), který neumožňuje:
  • zápis na filesystem; číst je mоžné pouze soubory aplikace
  • práci se sockety (je ale možno použít explicitně poskytovanou službu pro odesílání e-mailů a pro přístup k vzdáleným zdrojům přes HTTP či HTTPS přes standardní porty)
  • spouštět nová vlákna nebo procesy
  • zpracovávat požadavek příliš dlouho
  • další systémová volání (např. práci se signály)
• Veškerá serverová logika se točí okolo zpracovávání požadavků, žádné další služby jako plánování úloh nejsou k dispozici
• Jediný podporovaný jazyk je (zatím?) Python

Jestli jste se někdy zajímali o to, jak škálují weby jako Flickr, Wikipedia, Amazon nebo samotný Google, asi je jasné, že dobře škálující aplikace prostě musí být s ohledem na škálovatelnost navržena. Jinými slovy, musí brát v úvahu některá omezení: nepřehánět to s normalizaci dat, s používáním sessions, nenačítat při zpracování požadavku zbytečně mnoho dat, snažit se o co nejrychlejší odezvu atd. atd. Z tohoto pohledu jsou omezení AppEngine pochopitelná - nějak byste se omezit stejně museli, takže Google vám vlastně jen nutí své best practices.

Škálovatelností se samozřejmě nedá vysvětlit omezení na Python - ale darovanému koni na zuby nehleď. Předpokládám, že spolu s placenou verzí budou další jazyky muset následovat. Na druhou stranu si dokážu představit, že při určitém poměru návštěvnosti a složitosti aplikace by hodnota infrastruktury mohla převážit jednorázové náklady na nahrazení aplikace i programátorů pythonovými alternativami

Zdroje:

• Google App Engine Developer’s Guide
• Google Appengine: A first Look na High Scalability
• Google App Engine: History’s Next Step or Monopolistic Boondoggle? na Read Write Webu

Před časem jsem odkazoval na desatero jak správně programovat. Teď jsem narazil na další z podobného ranku: 10 vlastností dobrého programátora.

1. Programuje rád
2. Dotahuje věci do konce
3. Kód průběžně refaktoruje (doplňuju: aniž by se dostal do konfliktu s bodem #2)
4. Používá návrhové vzory (čti: nevymýšlí kolo)
5. Píše testy
6. Využívá existujícího kódu (opět čti: nevymýšlí kolo)
7. Stará se o použitelnosti svých výstupů (tedy ví, že praktický vývoj software není zkouška z implementance algoritmu)
8. Píše čitelně (i s ohledem na budoucí kolegy, kteří nemusí dosahovat jeho geniality)
9. Je schopen psát v jakémkoli jazyku
10. Má nějaké teoretické základy

Předevčírem večer jsem - uznávám, že s mírným zpožděním - objevil Amazon Elastic Cloud (neboli EC2, toho času v beta-verzi). EC2 díky virtualizaci nabízí ekvivalent dedikovaných serverů, které si můžete přidávat či ubírat dle libosti. Je vaše aplikace v noci bez návštěv a odpoledné nestíhá odpovídat? Prostě si ráno zapnete další server a v poledne třeba ještě další dva, a na noc naopak necháte jen jeden.

Virtualizace jako služba zákazníka odstíní od otravných záležitostí souvisejících s hostováním webové apliakce. Stačí si připravit image operačního systému s předinstalovanou vlastní aplikací, a vše ostatní už se zařídí přes Amazoní API. Případně přes balík nástrojů Cloudtools od Chrise Richardsona.

Výhodou není jen flexibilní správa serverové infrastruktury: s EC2 máte především pod kontrolou průběžné náklady. U Amazonu platíte od hodiny a serveru, a k tomu pár šušňů za přenos dat. Ceny jsou velmi kulantní: hodina provozu instance s 7.5 GB RAM a ekvivalentem dvou Xeonů na 1.7 GHz a blíže nespecifikovanou “high” I/O performance vyjde na 40 centů, tedy momentálně něco přes 4,500 Kč měsíčně. Skromnější jednoprocesorová verze s 1.7 GB RAM vyjde na čtvrtinu. 18 centů za gigabajt odchozích dat měsíčně (tedy 284 kč za 100 GB!) se pak v nákladech víceméně ztratí.

Z toho plyne, že pokud vaše aplikace není napsána příliš distribuovatelně, klidně si můžete podle denní doby přepínat mezi dělem a šunkou, chce to jen dvakrát denně před přehozením výhybky přesypat změněná data. Jedním slovem, radost.

Mimochodem, nedávno v konferenci o SEO Dušan Janovský vysvětloval ekonomická omezení objemu dat indexovaných Seznamím vyhledávačem; ve stručnosti: máte servery, ty něco stojí, něco žerou, navíc oproti globálně působícímu Googlu nejde dobře rozkládat špičku. Nabízí se otázka: nechce Seznam vlastní serverovnu zabalit a přejít k Amazonu?

Člověka časem omrzí opečovávat vlastní instalaci zastarávajícího blogovacího systému.

A v případě Jabloku to znamenalo včerejší přesun na hostovaný blog u WordPressu. A když už jsem byl u toho, rovnou jsem si vybral i jednodušší skin. Pevně doufám, že obě změny jsou většině vážených čtenářů zhluboka ukradeny.

Původní feed na www.jablok.cz zatím funguje a odkazuje na tuto přesunutou verzi. Raději si ale prosím zavčasu ve svých čtečkách upravte URL feedu na http://feeds.feedburner.com/jablok.

Mimochodem, člověka časem omrzí opečovávat vlastní instalaci a servery s ledasčím. A o tom snad něco stihnu napsat za chvíli.