středa 16. července 2014

Deset let, které neotřásly Spring frameworkem


Dnes jsem náhodou zjistil, že už je to pěkných pár let - konkrétně 10 - co se s touto ctihodnou technologií setkávám. Když se psal rok 2004, existovala nemalá skupina vývojářů, která věřila, že jediná a správná cesta vývoje aplikací spočívá v následování Java EE, tehdy ještě J2EE (ve zbytku článku zůstanu u aktuálního označení). Jako každá jiná v uvozovkách správná cesta i tahle nebyla úplně správná, jak potvrdilo právě uplynulých deset let. V tomto článku se pokusím vyložit historický kontext, ve kterém Spring framework vznikal, a nastínit hlavní důvody, které vedly k tomu, že i přes posun v architektuře aplikací, je stále platným nástrojem a de facto standardem pro vývoj Java aplikací.



Abychom pochopili historický kontext a vznik Spring frameworku, je potřeba vrátit se na přelom milénia. V té době internetová bublina dosahovala svého vrcholu a akcie technologických společností, jako byl Sun, stoupaly do nebes. Slovy Ivana Horníka - neslavně známého díky fotbalové korupční aféře - s municí nebyl problém vole a peníze do vývoje tekly proudem. V té době přišel Sun - a asi nejenom on, tipoval bych určitě na Microsoft - s myšlenkou vytvořit platformu, která by umožňovala vývoj enterprise (podnikových?) aplikací tempem Fordovy pásové výroby. Na jedné straně měli být vývojáři a na straně druhé dodavatelé middleware řešení - rozuměj aplikačních serverů. Mezi nimi měla stát standardizovaná platforma s kontraktem v podobě API a specifikací. Toto rozdělení mělo zaručit snadnou přenositelnost aplikací a zároveň vytvořit konkurenční prostředí pro dodavatele aplikačních serverů. Myšlenka to nebyla vskutku špatná, ale v praxi měla celou řadu problémů.



Předně celá Java EE byly navržená jako rodina technologií, které byly vzájemně provázané. Když jste například chtěli používat Enterprise Java Beans, znamenalo to, že jste se museli naučit další navazující technologie, jako například Java Transaction API. Další problém byl v tom, že Java EE vám v podstatě předurčovala architekturu vašich aplikací. Tvůrci počítali s tím, že jedna velikost stačí všem, čili že všechny aplikace budou mít víceméně stejné požadavky. Celý koncept vznikal v době, kdy si mohl těžko někdo představit, jaké typy aplikací se budou vyvíjet s masivním rozšířením internetu to doslova za pár let. Někdy kolem roku 2002 začala pomalu nastupovat první vlna frustrace z používání Java EE. V té době se objevila poměrně zásadní kniha J2EE design and development napsaná duchovním otcem Spring frameworku Rodem Johnsomem. Johnson se v této knize snažil poskytnout recept na správné používání Java EE a to včetně "frameworku", který pro tyto účely vyvinul. Není bez zajímavosti, že zdrojové kódy z této knihy (asi 30000 řádků kódu) se staly pozdějším základem Spring frameworku. Rod Johnson přesně trefil oblasti, které lidi pálily, a kniha zaznamenala velký úspěch.



Hlavní myšlenkou byla jednoduchost vývoje, testování a nasazení aplikací. Řečí technologie to bylo použití pár jednoduchých vzorů, které v té době již existovaly. Inversion of Control pro řízení vztahů mezi objekty, Template method pro izolaci často se opakujícího kódu, Aspektově orientovaného programování - pro řešení aspektů kódu prostupujících napříč aplikací. Johnson si díky zkušenosti s Java EE světem uvědomil, že celé řešení musí být co nejméně invazivní ve vztahu k uživateli. Díky tomu byl hned od počátku Spring framework koncipován jako modulární technologie - použij co potřebuješ - a tím pádem nenutil vývojáře ohýbat architekturu aplikací, tak aby vyhovovala frameworku. Udělal to přesně naopak, framework byl jako Lego skládačka, ze které si člověk vzal to co potřeboval.



Celou tuto filozofii a zmiňované tři vzory můžeme potkat v jakémkoliv dalším projektu, který se stavěl v Spring ekosystému. Spring framework nebyl nikdy žádná raketová věda a jediné kouzlo bylo v eleganci jeho používání. Elegance vycházela z jednoduchosti. Bylo to přesně jako podle příručky, framework by měl řešit často se opakující problémy a ulehčit život aplikačnímu programátorovi. Nic víc, nic míň. To je důvod, díky kterému přežil bez výraznějších veletočů a změn, prakticky ve stejné podobě, posledních deset let.


Zajímavý vývoj za tu dobu prodělala architektura aplikací. Dlouhou dobu byla celkem běžná monolitická architektura aplikací - eufemismus používaný pro jednu velkou kouli propletených špaget. Tato architektura se pomalu začala měnit a její transformaci akceleroval příchod chytrých mobilních zařízení. Najednou nebylo možné podporovat jedno zařízení - webový prohlížeč - ale jejich celou řadu - mobilní telefony, tablety. Díky sociálním sítím a obchodům s aplikacemi (Appstore) přišla jednoduchá možnost oslovit levně velké množství uživatelů. Všichni měli potřebu a nebo zadání vyvíjet aplikace rychlostí kulového blesku. Jednu z možností, jak zkrátit dobu potřebnou k doručení aplikace koncovému zákazníkovi, představoval Cloud.


Zatímco enterprise aplikace se provozovaly na zakoupeném a spolehlivém hardware pěkně v datových centrech bank a korporací, začala růst rodina aplikací provozovaných na hardwaru, který byste označili za komoditní. Aplikace nevznikaly roky, ale spíše měsíce nebo týdny. Při jejich úspěchu pak často docházelo k problémům se škálovatelností a stabilitou. Ne že by tyto problémy neexistovaly před tím, ale docházelo k nim mnohem méně často. Za poslední dva roky jsme mohli zaznamenat změny v architektuře, která se posouvá směrem od monolitických aplikací k aplikacím založeným na mikrošlužbách běžících v Cloudu - bez ohledu na to, jestli je privátní nebo veřejný. Jestliže je dnes ten poměr 80/20 ve prospěch monolitických aplikací, do dvou let může být pro nové aplikace přesně opačný. Když se dnes rozhodnu postavit si aplikaci s architekturou postavenou na mikroslužbách, budu jako vývojář opět vyžadovat to samé co v roce 2004 - jednoduchost vývoje, testování a nasazení. Možná to nebude znít dost sexy pro technologické hypstery, ale Spring - ta deset let stará technologie - mi přesně tohle splní. Bavíme se tady o kódu jehož závislosti popisuji pomocí anotací, používám convention over configuration, každá mikroslužba používá REST rozhraní a REST klienta, případně komunikuje přes messaging a běží v Spring Boot kontejneru.

Spring ušel za těch deset let dlouhou cestu a pro mnohé je to technologie, která se vlastně moc nemění a vlastně ji skoro každý zná. Je to pravda. Spring byl vždy postavený na jednoduchých konceptech, které skvěle fungovaly, a vývojáři s nimi byli spokojení. Přejme si, aby se této filozofie držel i nadále, protože jenom díky ní skvěle splňuje nároky architektury aplikací, která se diametrálně liší od architektury aplikací pocházejících z doby svého vzniku. Co by za to jiné technologie daly...