Jiří Hradil blog

Pro jednoho z našich klientů navrhujeme HW infrastrukturu a vzhledem k přemrštěným cenám za značkové servery známých výrobců (IBM, Sun, HP…) padnul návrh na vybudování clusteru pro aplikační kontejnery z “neznačkových” desktopů, které bychom použili jako servery.  Myšlenka má původ v Google (zdroj: David A. Vise, Mark Malseed: Google Story, Pragma 2007, ISBN: 978-80-7349-034-8), kde je nestabilita desktopů vyvážena jejich množstvím. Pokud některý z  desktopů-nodů vypadne,  zafunguje fail-over a load balancer na něj přestane posílat požadavky. Klient v nejhorším případě zaznamená výpadek v řádu vteřin.

Klady řešení:

• cena, pokud bychom desktop=nod poskládali ze značkových komponent, pak je cena jednoho tohoto nodu v řádech tisíců
• jednoduchý upgrade - nod by mohl být při výpadku či upgrade nahrazen rychlejším, poskládaným z aktuálních “best of breed” komponent
• dostupnost - nod lze poskládat z komponent, nakoupených v jakémkoli supermarketu společně s rohlíky
• nezávislost na dodavateli - sbohem obchodníkům, prodávajícím řešení, kterým nerozumí nebo na kterých se chtějí napakovat

Zápory řešení:

• možná nekompatibilita komponent - paměť od výrobce ABC  si nerozumí s deskou výrobce XYZ, což nemusíme poznat okamžitě, nod může vykazovat nestabilitu náhodně, lze řešit intenzivním testováním
• poskytování SLA - infrastrukturu musíme podporovat sami, ideálně mít nakoupeno několik desktopů do zásoby a při výpadku nod rovnou vyměnit za jiný
• požadavky na prostor - pokud by nod byl umístěn v běžném mini či miditoweru, zabírá více prostoru, než hezké 1U či 2U skříně “značkových” výrobců. Nicméně desktopy lze do skříní montovat taky.

Co je třeba dále zvážit:

• pozor na SPOF (single point of failure), pokud např. máme relační databázi, která fail-over na jiný server neumí, potencionálně nestabilní desktop tady nelze použít
• disky použité v nodu, protože na nod bude deploynutý jen .war aplikace a relační databáze je umístěna v jiné vrstvě, stačí nám levné disky, zapojené do prostého RAID 1 (mirror), abychom při výpadku jednoho disku neohrozili stabilitu aplikace

Použité technologie:

• Platforma - samozřejmě Java
• Aplikační/servlet kontejner - Apache Tomcat
• ORM - Hibernate
• Prezentační vrstva  - JSP, Servlety, Apache Wicket
• Dependency injection a lepidlo - Spring
• Škálování, fail-over na aplikační vrstvě - Terracotta, tedy sdílená VM

Použil jste někdo podobnou infrastrukturu v ostrém provozu?

Aktuální informace přímo od zdroje - Oracle a Sun Microsystems vstupují do konečné fáze dohody, podle které Oracle koupí Sun za cca 7.4 miliardy dolarů. Oracle tak získává Javu, Solaris a ostatní technologie (zdroj: Sun Microsystems: Oracle to buy Sun). Vedle nezajímavých řečí o 20-letém partnersví a obrovském přínosu pro komunitu, uživatele, atd. bude velmi zajímavé sledovat skutečný důsledek této akvizice.

Sun byl sice skvělý technologický inovátor, ale svým technologiím nedokázal přinést vhodný obchodní model. Takže se necháme překvapit, co Oracle konkrétně s Javou provede. Co myslíte?

Proces vývoje software odráží několik posledních let jasný trend - nestálost prostředí a připravenost na změny. Pokud shrneme několik agilních metodik (extrémní programování, Scrum, RUP), tak řeší v podstatě naprosto stejné věci-krátké iterace, testy, otevřenost, zeptej se kódu, atd.  Některé z těchto pravidel rozeberu.

Vyvíjíme po malých částech, čili v iteracích=cyklech=sprintech. Jedním z důvodů je nestálost prostředí, ve kterém má být software používán (např. situace na trhu či legislativa), ale hlavně neschopnost a nemožnost vyprodukovat stabilní analýzu systému, podle které se dá programovat. Analytiky software považuji za dinosaury, jejichž doba dávno skončila a při vývoji software jednoduše nejsou potřeba. Základ software z pohledu uživatele má navrhnout klient a proveditelnost návrhu určují koneční vývojáři. Setkal jsem se s tím, že analytik (který nikdy neprogramoval), vygeneroval stovky stránek krásných diagramů a dokumentů, které si nechal nebohým klientem schválit. Klient samozřejmě netušil, co ty obrázky znamenají (když ony byly tak hezky barevné…). Poté se tento stoh dokumentů předhodil vývojářům, kteří obrázkům taky nerozumněli, ale dostali jasný pokyn - “programujte!” Po několikaměsíčním vývoji při prezentaci systému klient zjistil, že vlastně teď potřebuje už něco úplně jiného a software se do produkce vůbec nedostal.

Doporučení:

• iterace je dlouhá max. 1 měsíc, v počátcích vývoje kratší, klidně i 1 týden
• vývojáře musíme protlačit ke klientovi, protože jedině zadavatel a tvůrce systému umí pokládat správné otázky a generovat správné odpovědi
• po každé iteraci následuje prezentace klientovi, který potvrdí aktuální verzi a na jejím základě generuje požadavky další
• popis systému je obsažen ve zdrojovém kódu a v uživatelských zadáních
• podrobná dokumentace je zbytečná - vývojáři ji nepotřebují, tvůrce ji musí aktualizovat a koneční uživatelé jsou tak frustrovaní množstvím software, který musí ovládat, že ji číst nebudou. Složitá sice může být problémová doména, kterou software řeší (třeba statistický software), ale nikdy nesmí být složitý software samotný. Pokud např. posadíme statistika k našemu statistickému softwaru, musí ho být schopen do několika minut bez problémů ovládat, protože ovládá problémovou doménu, do které je náš software zasazen a kopíruje ji.

Testujeme - test simuluje používání systému uživatelem. Ať už to schováno pod pojmy test jednotkový (na úrovni metody), integrační (na úrovni větší části systému), zátěžový, opičí, či jiný, smyslem testu je software nastartovat, aby ukázal, co umí. Testy se mají psát průběžně a to z toho důvodu, že na konci je už nikdo psát nebude. Stejně tak s každým testem vytvoříme nekonečného automatického robota, který nám bude hlásit, jestli pořád software dělá, co dělat má. Psaní testů z krátkodobého pohledu zdržuje, ale dlouhodobě nám právě testy drží software stabilní.

Doporučení:

• kontrolovat pokrytí software testy (např. v Javě přes Cobertura), stanovit si hranici, pod kterou nesmíme jít, ideálně nad 80%)
• maximálně urychlit psaní a spouštění testů (mock objekty, databáze v paměti)
• nepřetržitě integrujeme pomocí integračního serveru (Continuum, Hudson, Bamboo…)

Jsme malí - neudržujme velké týmy. Čím více vývojářů, tím více tření, komunikace, rozhodování, administrativy a neefektivity, kterou nakonec (zbytečně) platí klient.

Doporučení:

• ideální velikost týmu je 3-5 vývojářů, pokud se jich vývoje účastní více, uděláme více týmů a každý z nich má svou problémovou doménu. Tyto týmy však musí být vzájemně synchronizovány, např. pomocí scrum of scrums-porad, kterých se účastní pouze vyhrazený člověk z každého týmu, nikoli všichni členové  dohromady.

Posaďme tým dohromady, čili  “seat the team together”. Tým musí sedět pohromadě. Tečka. Tohle je nejrychlejší způsob řešení komplikací během vývoje a udržení synchronizovaných znalostí o systému. Pokud má kdokoli v týmu otázku, může ji položit a dostane se mu okamžité odpovědi.

Doporučení:

• respektovat klid pro práci - pokud máme otázku, nekřičíme na celou místnost, ale zeptáme se, zda můžeme vyrušit, v extrémních případech si zavedeme každou hodinu několik minut na otázky a odpovědi
• červená čepice - jednoduché pravidlo - v týmu je k dispozici symbol “červené čepice” (ať už cedulka, nebo opravdová kšiltovka), kdo ji má na hlavě, ten nesmí být rušen
• nepracovat z domova přes Internet, bohužel, zatím se ukazuje, že je stále efektivnější být fyzicky pohromadě v 1 místnosti, než komunikovat přes Skype, Jabber, atd. Budu rád, když mi tuto neefektivitu někdo vyvrátí a přidá praktické zkušenosti.