Apache Camel K aneb kam míří integrace
O posunu integrace z klasického ESB přes API gateway až k Service Mesh jsem psal v mém předchozím článku Není gateway jako gateway. V tomto článku nejdřívě představím Apache Camel K a v druhé části se zamyslím nad posunem integrace s příchodem mikroservisní architektury, kam dnes směřuje a jaké máme možnosti.
Apache Camel K
Apache Camel K is a lightweight integration framework built from Apache Camel that runs natively on Kubernetes and is specifically designed for serverless and microservice architectures.
V následujících odrážkách představím hlavní vlastnosti Apache Camel K:
- souvislost s Apache Camel není nahodná, jedná se o podprojekt a Camel K přímo závisí na jádru Camelu, lze využít více jak 300 již existujících komponent, psát integrace pomocí stejného DSL atd. (pozn. Camel v době psaní tohoto článku je těsně před vydáním první stabilní 3.x verze. Nejzásadnějších změn dostalo jádro Camelu a jeho modularizace, což byl jeden z předpokladů pro vznik Camel K).
- Camel K běží nativně v Kubernetes a OpenShift prostředí, je od začátku navržený pro běh v serverless a mikroservisní architektuře
- Camel K podporuje nativně i Knative (odtud “K” v názvu), což je platforma provozování serverless aplikací
- součástí Camel K jsou CLI tool “kamel”, který slouží pro konfiguraci clusteru a běh integrace a Camel K operator, který zajišťuje úzké propojení s Kubernetes/OpenShiftem. Z vývojářského pohledu se mě díky tomu okamžitě propagují změny v kódu do běhového prostředí a nebo na pozadí dochází ke konfiguraci runtime podle analýzy Camel DSL, např. pokud použijete “pooling”, tak se podle toho nastaví odpovídajícím způsobem Cronjobs
- samotné integrace mohou být opravdu atomické (na úrovni jednotlivých route), pro implementaci je možné si vybrat jeden z následujících jazyků: Groovy, Kotlin, JavaScript, Java, XML
Ukázka integrace v Groovy (pozn. opravdu se jedná pouze o tento samostatný Groovy skript, o vše ostatní se postará Camel K operator):
from(“timer:tick?period=3s”)
.setBody().constant(“Hello World from Camel K!!!”)
.to(“log:message”)Spuštění integrace:
kamel run hello.groovy
Sice je zdrojů o Camel K poskromnu, nicméně není mojím cílem zde duplikovat informace v nich uvedené, raději uvedu ty nejzajímavější a doporučím k vlastnímu prozkoumání:
Jako vsuvku ještě přidám informaci o podpoře Camelu pro Quarkus. Všichni víme, že klasické Java aplikace s klasickým JVM nejsou úplně ideální pro běh v mikroservisním světě, protože jednoduše řečeno zabírají moc paměti a pomalu bootují. Možností jak to řešit je více — buď se podívat po jiné virtual machine, např. GraalVM nebo upravit samotnou aplikaci, např. Quarkus a nebo obojí.
Kam kráčí integrace?
Co to všechno znamená pro dnešní podobu integrací?
- klasické ESB (myšleno zde z pohledu existence jednoho centrálního integračního prvku) zdaleka ještě nevymřely. Člověk sledující dnešní technologický svět v IT magazínech získá brzy mylný pocit, že nic než mikroservisy neexistuje (v tomto článku Mikroservisy všude kam se podíváš jsem se na toto téma rozepsal více), ale tak to opravdu není. Tedy klasické integrační projekty tu stále jsou a budou.
- z pohledu deploymentu se jedná často o jeden bundle obsahující většinou všechny integrační routy, na úrovni kódu nejčastěji oddělených dle business domén. Modularita je zde především na úrovni zdrojového kódu, z pohledu runtime se jedná o jednu aplikaci. Nicméně i v tomto případě lze s úspěchem použít Kubernetes jako běhové prostředí, ale ideálně s “drobnými” úpravami, např. využít Quarkus, viz výše.
- mikroservisní přístup mě nabízí granularitu na úrovni jednotlivých integračních route. Líbí se mě lehkost použití, učící se křivka je minimální a díky tomu lze použít Camel K pro sebemenší integrační úlohu (buďme k sobě upřímní, protože málokdy někdo přidá Camel do své aplikace, i když potřebuje vyřešit jeden netriviální integrační scénář).
- nemyslím si, že mikroservisní přístup (jedna routa rovná se jedna mikroslužba) bude pro klasické integrační projekty to nejefektivnější. Jednak z pohledu zdrojů (pokud budu mít 20 služeb a budu k tomu muset vytočit 20 podů, tak to zabere více než mít vhodně zvolené 3 moduly a tedy vytáčet jen 3 pody) a jednak z pohledu samotného vývoje — sdílení a reuse společného kódu. Jednoroutové mikroslužby považuji za výborný doplněk k řešení integračních scénářů v jinak klasické aplikační doméně — jednoduše a rychle dokážu vyřešit složitější integrace, které bych normálně řešil na úrovni aplikace.
- “designed for serverless” — pro synchronní integrační scénáře nečekám žádné problémy, ale pro asynchronní scénáře už ano resp. bude nutné zvolit jiný přístup. Integrační platforma mě odděluje různé systémy a jejich různé chování. Velkým pomocníkem v tomto případě je schopnost přijmutí zprávy od volajícího systému a garance jejího doručení do cílového systému. Toto v serveless architektuře lze vyřešit dvěmi funkcemi, kdy jedna mě bude ukládat vstupní zprávu do úložiště a druhá mě bude tuto zprávu z úložiště číst a dále zpracovávat. Úložiště v tomto případě může být cokoliv, co mě zaručí “garantované” uložení, např. databáze nebo message queue.
- využití mikroservisní architektury pro integrace nabízí velkou výhodu v podobě škálování, protože vždy jsou různé performance požadavky na různé business domény nebo i jednotlivé integrační scénáře, což se špatně řeší v momentě, kdy mám jeden balíček k nasazení.
S příchodem mikroservisní architektury (serverless, event sourcing, …) se mění i paradigmata pro realizaci integračních projektů. Stále je možné se dívat na integraci pohledem jednoho spojujícího samostatného bodu někde uprostřed (klasické ESB) a nebo stejně jako samotný vývoj aplikací se posouvá od jednoho monolitu k více (mikro)službám, tak i integrace se posunou k (mikro)integracím. A důvody k tomuto posunu jsou identické — škálovatelnost a performance nebo organizační důvody jako např. rozdělení do týmů.
