Není gateway jako gateway
Jak se mění architektonické přístupy k návrhu aplikací resp. celých řešení, tak se mění i potřeba kladená na jednotlivé komponenty. Před cca 15 lety, v době kdy SOA dobývalo svět, tak největší byla poptávka po Enteprise Service Bus (ESB) řešeních. V té době často zastoupenými velkými, drahými a neflexibilními produkty od firem jako IBM (WebSphere ESB), Oracle (Oracle Enterprise Service Bus), Tibco nebo Miscrosoft (BizTalk). Naštěstí v průběhu času se objevilo dostatek lightweight open-source řešení, převážně programátorsky zaměřených, nikoliv jen klikacích, jako např. MuleESB, Apache Camel nebo Spring Integration.
Před necelými 10 lety, s nástupem používání RESTu, oddělením frontendových částí aplikací od backendu nebo obecně s potřebou vystavování “kvalitních” API (contract/design-first přístup), se objevila poptávka po komponentě API gateway.
V dnešní době, kdy mikroservisní architektura mění pohled na návrh aplikací, kdy je potřeba primárně řešit komunikaci mezi samotnými mikroservisními službami a zároveň se vypořádávat se složitostmi distribuovaného světa, tak je poptávka po service mesh řešeních.
Ve zbývajících částech článku se zaměřím na bližší popisy jednotlivých integračních přístupů.
Úkolem ESB je nahradit přímé komunikace mezi jednotlivými aplikacemi (point-to-point) tak, že se zbaví závislostí aplikací mezi sebou a odstíní rozdílnosti každé z aplikací. Rozdílnosti mohou být na úrovni:
- komunikačního protokolu
- datových struktur
- zpracování vstupních požadavků (synchronní vs asynchronní komunikace, garantované zpracování zpráv dle určitého pořadí, max. počet souběžně zpracovávaných požadavků za určitý čas apod.)
ESB slouží primárně k datové transformaci a orchestraci volání cílových systémů.
Řešeních v této oblasti je opravdu hodně a více než podporované funkce bude rozhodovat přístup k implementaci integračních scénářů (programování vs DSL vs klikání) a licenční politika. Osobně nevidím výrazné rozdíly ve většině podporovaných funkcí jednotlivých ESB řešení, rozdíly jsou pouze v přístupu k implementaci konkrétních integračních patternů. Kde je nicméně možné vidět výrazný rozdíl z pohledu funkčnosti, tak to je podpora asynchronního zpracování zpráv — nemyslím nyní asynchronní způsob komunikace např. pomocí message queue, ale pattern, kdy ESB přijme zprávu, potvrdí její přijetí volajícímu systému a následně se stará o její úspěšné zpracování a doručení cílovým systémům. Základní podporu lze najít snad u všech open-source řešení, nicméně reálné potřeby, aspoň takové jsou naše zkušenosti, jsou často někde jinde — proto je nutné se porozhlédnout po nějakém komerčním řešení a nebo zkusit naší vlastní integrační platformu OpenHub, kde jsme tento způsob komunikace implementovali a ladili na několika projektech.
V mikroservisní architektuře je také potřeba data transformovat nebo orchestrovat volání přes více (mikro)služeb, nicméně z povahy běhového prostředí (nejčastěji Kubernetes) je potřeba mít ESB řešení velmi malé (zabírající málo paměti) a velice rychlé, jak na start, tak na samotný processing. Zde lze doporučit samotné integrační enginy jako Apache Camel nebo Spring Integration. Zajímavou iniciativou z poslední doby je Apache Camel K (malá video ukázka):
Apache Camel K is a lightweight cloud integration platform based on the Apache Camel framework. It runs natively on Kubernetes and Openshift and it’s specifically designed for serverless and microservice architectures
OpenHub je ideální volbou pro ty, kdo chtějí používat Apache Camel (preferují programátorský přístup k implementaci integrací, nikoliv klikací) a ocení odladěný aplikační stack včetně spousty rozšíření a fixů — např. nové Camel komponenty, podpora běhu v clusteru, administrační konzole. OpenHub používáme jako lightweight ESB řešení nebo v roli API (mobilní) gateway.
API gateway tvoří rozhraní mezi systémy a jejich konzumenty. Rozhraní definuje možné chování pro konzumenty služeb (dnes nejčastěji v podobě OpenAPI specifikace), odstiňuje komplexitu vnitřní implementace a stanovuje pravidla komunikace (např. bezpečnostní politika nebo omezení na počty volaní). Použití je jak v rámci interního prostředí nebo zejména ve vztahu k externím subjektům.
Kromě toho je potřeba mít možnost monitorovat (a zpětně analyzovat z reportingu) všechny volání, definici rozhraní správně zdokumentovat a zpřístupnit potenciálním konzumentům včetně možnosti mockování odpovědí pro usnadnění napojení na API. V poslední době začíná být i čím dál častější požadavek na monetizaci vystavených API — schopnost API gateway umět napočítávat počty volání per klient. V základní podobě si lze vystačit s funkcionalitou, která dnes začíná být součástí samotných API gateways, pro složitější účtování je potřeba využít samostatnou monetizační platformu, napr. Qubefy.
API gateway lze úspěšně využít i k základní datové transformaci, ale není to její primární úkol.
Několik představitelů “klasické” API gateway:
Doposud jsme se bavili o “klasické” API gateway a její použití je opravdu široké, nicméně asi nejčastěji se používá k odstínění interní infrastruktury a vystrčení rozhraní služeb pro třetí strany. Svět mikroservisních aplikací má velice podobné funkční požadavky jako “klasická” API gateway, ale jedná se více o “engine” (knihovnu) než o plnohodné aplikace včetně GUI na monitoring a dokumentaci.
Jedná se o řešení neutrální k cílovému běhovému prostředí (Spring Cloud Gateway nebo Zuul) nebo naopak jsou s ním úzce spojeny — nejčastěji s Kubernetes, implementující ingress controller:
Pojem service mesh nebude asi všem známý, proto ho nejdříve vysvětlím:
Service Mesh is a network communication infrastructure which allows your to decouple and offload most of the application network functions from your service code.
Service mesh is a new architectural paradigm that delivers services such as traffic management, security, and observability to container-based microservices applications directly within the compute cluster. A service mesh provides monitoring, scalability, and high availability services through software components controlled by APIs instead of using discrete hardware appliances. This flexible framework reduces the operational complexity associated with modern, disaggregated applications.
Service mesh je převážně “infrastrukturní” záležitost a slouží k řízení interní komunikace mezi službami (pozn. API gateway slouží primárně ke komunikaci s okolím). Service mesh je reakcí na nutnost řešení problémů distribuovaných systémů, které se doposud řešily skoro výhradně na aplikační úrovni, např.:
- CircuitBreaker pomocí Netflix Hystrix
- routing/load balanging pomocí Netflix Zuul a Eureka
- security apod.
Díky service mesh je možné se v samotné aplikaci soustředit na vlastní aplikaci a tyto “infrastrukturní” věci pořešit v rámci běhového prostředí.
Mezi hlavní představitele patří:
(pozn. v tomto článku je jejich porovnání)
Jak je vidět z obrázku, tak někde se schopnosti/možnosti API gateway resp. ESB resp. Service mesh trochu překrývají, ale obecně každá oblast má svá specifika podle kterých se jednotlivá řešení odlišují a tedy mají různou cílovou skupinu problémů, které umí snadno a rychle implementovat. Správnou volbou vhodného řešení pro vaše očekávané případy použití si usnadníte svůj “vývojářský” život.
