pondělí 8. srpna 2011

Aplikace kontra Služba kontra Knihovna

Jeden z problémů, ke kterému dojde při kontinuálním vývoji aplikací je její neustále nafukování přihazováním nové funkcionality někdy společně s novými technologiemi, které k tomu potřebujete. Klasickým příkladem je webová aplikace její WAR, který se nafukuje jako otesánek. Přijde mi, že skoro nikde se vlastně nemluví a neakcentuje o tom jak tenhle problém řešit a každý se musí učit z vlastních chyb. Já se v tomhle článku pokusím nejdřív popsat v čem je problém otesánka a jak si představuji jeho řešení. Budu to popisovat z pohledu, který vnímám při vývoji u nás v GoodData, kdy jsme Software As A Service poskytovatel.

Koncept otesánek

Alias: monstrum

Popis: aplikační logika má lokální interface (z pohledu JVM). Všechny použité knihovny musí být na classpath a vhodně nakonfigurované a zinicializované při startu aplikace. Volání jednotlivých aplikačních celkú je vždy synchronní. Znovupoužitelnost kódu je na úrovni knihoven.

Třída problémů

Deployment

Rychlost inicializace je přímo úměrná velikosti, jedná se především o konfiguraci aplikační logiky a knihoven, které se používají. Rychlost inicializace může mít negativní dopad na down time aplikace (doba nutná k odstávce), pokud nemůžeme běžet paralelně starou a novou verzi aplikace. Velikost deployvatelného balíčku (desítky megabajtů) znesnadňuje rychlost distribuce pokud chceme například udělat simultánní deploy v clusteru.

Jednotný classloader prostor diktuje použití stejných verzí knihoven, to se týká především knihoven třetích stran. Nutnost použití novější verze knihovny může vést k tomu, že musíme upravit a otestovat části aplikace, kterých by se změna nemusela vůbec dotknout.

Runtime

Nezřízené nároky na paměť, nemůžeme rozdělit paměť přidělenou jednotlivým částem aplikace a s tím související vzájemné interference mezi nimi. Vyšší spotřeba jedné části aplikace může mít negativní dopad na zbytek systému. To se týká prakticky jakýchkoliv sdílených prostředků na úrovní JVM.

Synchronní volání jednotlivých aplikačních bloků mezi sebou blokuje volajícího a neumožňuje efektivně reagovat na výpadek části systému, který není z pohledu vyřízení požadavku kritický (zápis do audit logu, notifikace).

Údržba

Příliš mnoho funkcionality neumožňuje jednoduchou odstávku, oprava chyby nebo servisní restart, protože má dopad na systém jako celek. Složitější monitoring, v podstatě blackbox s tunou odpovědností.

Řešení

Pokud je vztah částmi aplikační logiky takový, že na sobě nejsou přímo závislé (např. transakční kontext) a jejich vzdálená komunikace není výkonnostním problémem, pak je řešením jejich zapouzdření jako služeb. Služby nám umožňují vytvořit systém, který bude volněji provázaný. Díky tomu nám odpadne řada problému, které vznikají těsnými vazbami. To se týká všech oblastí (deployment, runtime, údržba), které byly výše popsané. Jedna z příjemných věcí, kterou tím získáme je koncept okleštěných služeb. Ten umožňuje v případě problému odstavovat služby, které nejsou pro běh systému kritické a zachovat primární ůčel systému. Pokud máte herní systém pro online hry, pak jeho primárním učelem je, aby mohli hráči pařit a pokud vám začne kolabovat sekundární systém např. registrace nových hráčů, pak není důvod, aby to vzalo sebou i ty stávající.

Služby nám umožňují, aby byly používány nejenom z jazyka, ve kterém byly samy napsány, ale i v jazycích jiných. Jejich použití je prakticky omezené jenom jejich rozhraním. To nabízí daleko lepší znovypoužitelnost. Každá služba může definovat vlastní podmínky použití (SLA) jako jsou doby odezvy, maximální počet obsloužených požadavků apod.

Samozřejmě to, že část aplikační logiky běží jako služba vystavená například přes REST a nebo messaging přináší jinou třídu problémů. Návrh rozhraní služeb a jeho vývoj je věc poměrně drahá pokud se bavíme například o RESTu. Vzdálená komunikace přes síť sebou přináší problémy se spolehlivostí resp. jediné ne co se můžete spolehnout je, že nic není spolehlivé. Tomu musí odpovídat i design a implementace konkrétní služby.

Tohle určitě není renesance zprofanovaného slova SOA, to slovo se mi příčí a je kolem něj tolik balastu, že je těžké si pod ním něco konkrétního představit. Tohle je lekce, kterou jsem se naučil postupem času.