SOA - A kezdetek

Mielőtt az agilis integráció jövőjét megvizsgálhatnánk, meg kell azt is értenünk, mi volt a korábbiakra jellemző. A SOA (szolgáltatásorientált architektúra) az ezredforduló elején jelent meg és az alapját képező szabványok széleskörű elfogadása egy olyan fényes jövőt hirdetett, ahol bármely vállalati rendszer felfedezheti a többi rendszert és velük kommunikálhat (leggyakrabban szinkron) szolgáltatáshívásokon keresztül.

Ez jellemzően az ún. szolgáltatásbusz („ESB”, „Enterprise Service Bus”) formájában valósult meg. Az ESB egy olyan architektúra elem, amelynek célja a hívó rendszer számára egységes kapcsolatot biztosítani a háttérrendszerek felé, jellemzően WebService szabványon keresztül. Míg sok vállalat sikeresen alkalmazta az ESB-mintát, az bizonyos értelemben saját sikerének áldozatává vált:

Az ESB alapú integrációk gyakran egyetlen infrastruktúrát alkottak az egész vállalat számára, több tíz vagy száz konkrét integrációval, egy éles szerverfürtre telepítve. Bár az ESB minta nem követeli meg a nagyfokú központosítást, a megvalósított topológiák szinte mindig erre jutottak.

A központosított ESB-minták gyakran nem hozták meg a vállalatok által remélt jelentős megtakarításokat, mivel kevés interfészt lehetett újra felhasználni egyik projektről a másikra.

A SOA bevezetés kérdése összetettebbnek bizonyult, mint pusztán egy ESB implementálása, különös tekintettel arra, hogy ki finanszírozna egy vállalati szintű programot. A vállalaton átívelő kezdeményezések, mint például a SOA és az alapjául szolgáló ESB, mivel nem egy konkrét üzleti projekthez kötődtek, nehezen találtak finanszírozást, és ez a finanszírozás gyakran csak olyan konkrét szolgáltatásokra vonatkozott, amelyek eléggé újra felhasználhatók voltak a létrehozási költségük fedezésére.

Ennek az lett az eredménye, hogy a szolgáltatások e speciális SOA-csapat általi létrehozása néha a projektek szűk keresztmetszetévé vált, ahelyett, hogy azokat elősegítette volna. Ez gyakran rossz hírnevet eredményezett a központosított ESB-minta számára.

Mindazonáltal a központosított ESB-minta előnyökkel is jár, különösen akkor, ha a vállalat rendelkezik egy képzett, állandó (külső vagy belső) integrációs csapattal, és a felmerülő integrációs követelmények előre tervezhető ütemben és megfelelően specifikálva érkeznek. Egy egységes, központosított ESB bizonyosan leegyszerűsíti annak elérését, hogy a konkrét megvalósítások konzisztensek, megfelelően kontrolláltak és szabályozottak („governáltak”) legyenek.

Sok szervezetnek azonban rugalmasabb és dinamikusabb követelményei vannak, és nyomás nehezedik rájuk, hogy az integrációt a szervezet más részeiben használthoz hasonló felhő-natív technológiák és agilis módszerek segítségével hajtsák végre. Jó példa erre a mikroszolgáltatás architektúrára való átállás, amely jellemzően az alkalmazásfejlesztési területről indult.

Valami régi, valami új - SOA és MSA

A SOA és a mikroszolgáltatás architektúra (MSA) között sok párhuzam van, de valójában teljesen különálló fogalmak.

A szolgáltatásorientált architektúra és a hozzá tartozó ESB minta egy olyan vállalati szintű kezdeményezés, aminek célja, hogy az egyes vállalati IT rendszerekben meglévő adatok és a funkciók könnyen elérhetők legyenek az új alkalmazások számára. Ennek eszközei újra felhasználható, szinkron interfészek, például WebService-ek és REST API-k, melyekkel gyorsabban hozhatók létre új innovatív alkalmazások akár több rendszerből származó adatok valós időben történő beépítésével.

A mikroszolgáltatás architektúra ezzel szemben egy-egy konkrét alkalmazás új megközelítésű fejlesztési módja. Az alkalmazást kisebb komponensek (mikroszolgáltatások) halmazaként alkotjuk meg, ezáltal az alkalmazást agilisabbá, skálázhatóbbá és rugalmasabbá tesszük.

Összefoglalva tehát, a szolgáltatásorientált architektúra elsősorban az alkalmazások közötti valós idejű integrációról szól, míg a mikroszolgáltatás architektúra inkább magának az alkalmazásnak a belső felépítéséről.

Tudnivalók, ha agilis integrációba vágnád a fejszéd

Miért vált olyan népszerűvé az MSA az IT alkalmazások területén? Mert egy olyan alternatív megközelítést nyújt az alkalmazások strukturálására, ahol ahelyett, hogy egy alkalmazás egy nagy monolit kódhalmaz legyen, mely ugyanazon a szerveren fut, ehelyett az alkalmazást kisebb, teljesen függetlenül futó komponensek gyűjteményeként tervezzük.

Az MSA három kulcsfontosságú előnyt tesz lehetővé:

1. Nagyobb agilitás – A mikroszolgáltatások elég kicsik ahhoz, hogy egymástól függetlenül meg lehessen érteni, és akár meg lehessen változtatni őket.
2. Skálázhatóság – Az egyes mikroszolgáltatások erőforrás-felhasználása önállóan szabályozható, összhangban az üzleti modellben betöltött szerepükkel. Mindezt a konténer környezetek jól automatizálni is képesek.
3. Rugalmasság – Megfelelő szétválasztással az egyik mikroszolgáltatás módosítása nem befolyásolja a többit futás közben.

Ezeket az előnyöket szem előtt tartva, hogyan nézne ki, ha újragondolnánk a vállalati integrációt (amelyet eddig általában egy központosított silóban alkalmaztunk), egy új, mikroszolgáltatás architektúrán alapuló nézőpont szerint? Ezt hívjuk „agilis integrációnak”.

Az agilis integrációnak három kapcsolódó, de különálló aspektusa van:

1. szempont: Az integráció finomszemcsés telepíthetősége.

Az MSA fenti fogalmait használva feloszthatjuk az egész vállalatra kiterjedő ESB-t kisebb, jobban kezelhető és dedikáltabb darabokra (extrém esetben akár interfészenként külön runtime-ra). Ezek a „finomszemcsés integrációs telepítések” megfelelő méretű konténereket biztosítanak, javítva a méretezhetőség és rugalmasságot. Az MSA-nál leírt előnyök így az integrációs rétegben is elérhetők.

2. szempont: Az integráció decentralizált „tulajdonlása”.

A finomszemcsés integráció-telepítésre való áttérés azt is lehetővé teszi, hogy az integrációk létrehozásának és karbantartásának tulajdonjogát az egyes alkalmazásokért felelős csoportok között meg lehessen osztani. Nem ésszerűtlen, hogy az üzleti alkalmazásokkal foglalkozó IT csapatok integrációs munkát is vállalnak és ésszerűsítik az új integrációk megvalósítását.

3. szempont: Felhő-natív integrációs infrastruktúra.

Az agilis integráció megköveteli, hogy az integrációs topológia is változzon. Ennek egyik kulcsfontosságú szempontja a modern integrációs futási környezet, amely konténer alapú, és jól illeszkedik a felhő alapú telepítési módokhoz (ebbe a privát vagy hibrid felhőt is beleértve).

A legfontosabb elvárások:

•       Gyors, könnyűsúlyú runtime, melyek konténerben futnak, másodpercek alatt elindíthatók és leállíthatók;
•       Függőségmentes: már nem igényel előkövetelményként adatbázist, illetve üzenetsorokat, bár természetesen tud kapcsolódni ezekhez;
•       Az elterjedt DevOps eszközkészletek teljeskörű támogatása;
•       REST API fókusz, szabványos interfész leírókkal;
•       Széleskörű kapcsolódási képességek, beleértve a modernebb erőforrások széles körét, mint pl. noSQL adatbázisok, üzenetkezelő rendszerek (pl. Kafka), különböző SaaS (software-as-service) rendszerek;
• „Folyamatos szállítás” támogatása: a korábbi merev, hosszú szoftverfejlesztési ciklusok helyett egy rapid élesítési rend megvalósítása.

Egy erős vállalati platform az agilis integrációhoz

Az IBM hosszú évek óta kínál piacvezető nagyvállalati integrációs szoftverplatformokat SOA, MSA és egyéb környezetben. Az IBM Cloud Pak for Integration egyesíti a kulcsfontosságú integrációs képességeket egy koherens platformba, amely egyszerű, gyors és megbízható. Segítségével könnyen és gyorsan létrehozhatók és üzemeltethetők integrációk és API-k, mindezt kiváló teljesítmény jellemzők és skálázhatóság mellett, természetesen nagyvállalati szintű biztonság mellett. Az IBM Cloud Pak for Integration a konténerek orchesztrációja tekintetében a nyílt forráskódú Kubernetes platformra épül.

Hazánkban számos nagyvállalat alkalmazza sikerrel az IBM integrációs platformjait, többek között a pénzintézeti, gyógyszeripari és kormányzati szektorokban. IBM Gold fokozatú szakmai partnerként az Intalionnál évtizedes tapasztalattal rendelkezünk integrációs platformok bevezetésében, fejlesztésében és üzemeltetési támogatásában. Ha felülvizsgálnád meglévő integrációs megoldásaidat vagy egy új fejlesztés küszöbén állsz, kérd szakértőink segítségét!

[Az Intalion megbízásából készített, fizetett anyag.]