A növekedés microservice elfogadása okozott egy kis népszerűsége néhány korábban figyelmen kívül hagyott szoftver tervezési minták. Ezek közül a minták közül sokat Eric Evans Domain Driven Design-jából bányásztak ki, egy könyv, amely ugyanúgy szól a csapat felépítéséről, mint a szoftverarchitektúráról.
ezen minták közül talán a határolt kontextus a legfontosabb, amelyet meg kell érteni. Mérnökökként a korlátozott kontextust Szoftverarchitektúra-tervezési mintának tekintettük. De ez azért van, mert egy kicsit az eredeti használatból választottuk. Ahogy Evans használta, a korlátozott kontextus ugyanolyan szervezeti minta, mint technikai.
ezért jöttem, hogy a korlátozott Kontextusmintát a mikroszolgáltatások megértésének láncszemeként tekintsem. Nem csak azt, hogyan építsük fel őket, hanem azt is, hogy miért építjük fel őket, és hogyan tehetik sikeresebbé szervezeteinket. Ha megértjük, hogy mi a határolt kontextus — ha elfogadjuk a határolt kontextus gondolkodásmódot mind technikailag, mind szervezetileg — akkor valóban sikeresek lehetünk a mikroszolgáltatások architektúrájának felépítésében.
miért érdemes áttérni a mikroszolgáltatásokra?
először hajtsunk végre egy kis gyakorlatot. Tedd fel magadnak ezt a kérdést: Miért építünk elsősorban mikroszolgáltatásokat?
szánjon egy percet arra, hogy átgondolja. Melyek azok az előnyök, amelyek először eszébe jutnak? Melyek a legfontosabb problémák, amelyeket meg kell oldanunk? Írj le néhány választ, csak hogy őszinte legyél.
…
megvan a válaszod? Jó. Olvasd vissza magadnak. Elérte a szokásos technikai előnyöket? Folyamatos szállítás, skálázhatóság, poliglot környezetek, konténerek és felhők, és mindezek a jó dolgok? Remek.
de a legfontosabb válaszod tartalmazott-e valamit a szervezet hatékonyabb működésének lehetővé tételéről? Kellene. Mivel a mikroszolgáltatások építése nem a technikai előnyök megvalósításáról szól. Valójában a szervezeti előnyök megszerzéséről szól. Minden más egy végrehajtási részlet.
Monoliths = coupled code and couped teams
ahogy monolitjaink egyre nagyobbak és nagyobbak lesznek, a termelékenység csökkenni kezd. Ennek legalább két fő oka van.
fékezzük a sebességünket
először is, minden mérnöki csapat hozzájárul egy hatalmas kódbázishoz. Mint ilyen, a csapatok egyre nagyobb valószínűséggel szembesülnek azzal, hogy kódjuk ütközik mások kódjával. A lehetséges problémák enyhítése érdekében eljárásokat indítunk — kódfagyasztások, minőségbiztosítási tesztelési időszakok, vonatok kiadása stb. – amelyeket szó szerint arra terveztek, hogy lelassítsák a termelékenységünket.
természetesen ezek az eljárások megakadályozzák a funkciók és fejlesztések időben történő telepítését. Pusztítást okoznak a mérnökök azon képességében is, hogy csapataik prioritásaira összpontosítsanak. Ha egy hiba egy tesztelési időszak alatt található, a felelős csapatnak kontextust kell váltania, és a hiba megoldására kell összpontosítania. Ha súlyos hibát találnak a gyártásban, a csapatnak nemcsak javítania kell a hibát, hanem át kell ugrania a karikákon is, hogy a következő kiadási vonat telepíthesse.
az ügyeleti szolgálat boondoggle-vé válik. Ha valami baj van a monolitunkkal, valakinek rendelkezésre kell állnia — éjjel — nappal-a probléma megoldásához. De ki? A nagy monolitokkal rendelkező nagy szervezetek általában két választási lehetőséggel szembesülnek:
- egy eseménykezelő csapat, amelynek egyetlen, szomorú, sajnálatos feladata a szervezeten belül az, hogy reagáljon más mérnökök kódja által okozott problémákra, és kitalálja, hogyan oldja meg őket.
- egy forgó ügyeleti ütemterv, amelynek során minden héten egy tetszőleges mérnöknek kijelölik azt a szomorú, sajnálatos feladatot, hogy felelőssé váljon olyan problémák megoldásáért, amelyeket valószínűleg egy másik mérnök, egy másik mérnöki csapat által írt kód okoz.
(Mis)csapataink szervezése
a monolitok még más módon keverednek szervezeteinkkel. Az egész szervezetünk ugyanazon a nagy terméken dolgozik. De még mindig meg kell szakítanunk a szervezetet kezelhető csapatokra. Tehát hajlamosak vagyunk funkcionális szerepeket keresni a csapat határainak megtalálásához:
sajnos ez a fajta szervezeti struktúra korlátozza az együttműködési munkát. Ahelyett, hogy együtt dolgoznánk a valódi probléma megoldásán (pl. hogyan tervezzük, építjük és karbantartjuk az X funkciót?) a különböző funkcionális területek tagjai egyszerűen a saját részükre összpontosítanak, metaforikusan dobják munkájukat a kerítésen, amikor elkészültek. Az együttműködés és a szinergia lehetősége — ahol a csapat erőfeszítéseinek együttes minősége sokkal több, mint az egyes csapattagok összessége — elvész.
szűk keresztmetszetekkel is elterjedt. Amikor csapatainkat funkcionális terület szerint szervezzük, akkor természetesen a prioritások eltérése lesz. Tegyük fel, hogy a termékmenedzsment csapat úgy döntött, hogy a monolith fizetési folyamatát meg kell újítani. Megbeszélik az időt a tervezőcsapattal, hogy összeállítsanak néhány gúnyt. Egy bizonyos ponton a gúnyok befejeződnek, és átadják a frontend csapatnak, hogy megvalósítsák. Természetesen a frontend csapatnak API-kat kell végrehajtania a backend csapatnak, így blokkolva lesznek, amíg ez be nem fejeződik. Miután a backend csapat prioritásként kezeli az új fizetési szolgáltatásokkal kapcsolatos munkáját, úgy találja, hogy segítségre van szüksége az adatbázis-felügyeleti (DBA) csapattól. Amelynek természetesen megvannak a maga prioritásai. Tehát a backend csapat blokkolva lesz, amíg a DBA felszabadul.
bizonyos értelemben ez a szervezeti felépítés kissé úgy tűnik, mint egy rosszul megtervezett, túlságosan összekapcsolt Szoftverarchitektúra… nem?
Microservices = függetlenített kód, függetlenített csapatok
ezzel szemben a mikroszolgáltatások architektúrája lehetővé teszi a csapat autonómiáját. Sokkal könnyebb olyan csapatokat alkotni, amelyek önállóak, hatékonyan működnek együtt, és amelyeket nem akadályoznak állandóan más csapatoktól való függőségek.
a csapatok teljes felelősséget vállalhatnak munkájuk felett, a tervezéstől a fejlesztésen át a telepítésig. Minden tag osztja a felelősséget a csapat céljának eléréséért, így ösztönzik őket arra, hogy ne csak a “részükben”vegyenek részt. Dolgoztam olyan csapatokkal, ahol termékmenedzserek, tervezők, front-end, back-end és mobil mérnökök összefogtak a termékjellemzők tervezésében, sokkal jobb eredményeket hozva, mint amit egy ember el tudott volna érni.
a csapat felelősséget vállal a saját tárgyaiért, miután azokat a gyártásba telepítették. Ez általában jobb minőségű kódhoz vezet, amelyet könnyebb hibaelhárítani. Miért is? A monolittól eltérően a csapatok általában holisztikus képet kapnak a saját mikroszolgáltatásaikról. Így sokkal könnyebb a csapat számára előre jelezni a problémákat, jó naplózást és mutatókat adni a problémák elhárításához, amikor azok előfordulnak, és helyesen használni a rugalmassági mintákat (pl. újrapróbálkozások, megszakítók és tartalékok stb.), hogy segítsen elkerülni a problémákat.
Továbbá, mivel a csapatoknak teljes felelősségük van a munkájuk felett, a szolgáltatásaik egészségének megőrzése és a termelésben való futás kevésbé egy rémálomszerű kiadási ütemtervről szól, és inkább az alkotásuk gondozásáról.
végül a csapatok ugyanazon cél felé dolgoznak, ugyanazon az idővonalon. Ez azt jelenti, hogy nincs több blokkoló egy személy, mert várni, hogy valaki egy másik funkcionális területen, hogy szabadítson fel.
szándékosnak kell lennünk az autonómiával kapcsolatban
de ezeket az előnyöket nem kapjuk meg ingyen egyszerűen azzal, hogy a monolitunkat mikroszolgáltatásokra bontjuk. Vessünk egy pillantást a mikroszolgáltatások architektúrájának első, naiv nézetére:
ha olyanok vagyunk, mint a legtöbb mérnök, akkor a mikroszolgáltatási architektúra kezdeti ötlete, nos, egy csomó mikroszolgáltatás. Mindegyik kitesz valamilyen API-t (talán ReST), hogy bármely más szolgáltatás olvashasson belőle és írhasson rá.
ahogy tapasztalatokat szerzünk, megtanuljuk, hogy nem minden mikroszolgáltatás szolgálja ugyanazt a célt — vagy legalábbis nem kellene. Ezért, hasonlóan a mi monolitunk rétegekbe rendeződött, ezért elrendezzük a mikroszolgáltatásainkat:
ezen a ponton meghatároztuk a különböző típusú mikroszolgáltatásokat és alkalmazásokat, amelyeket építeni akarunk. Remek. De még mindig nem értünk el sok előrelépést a csapat autonómiája szempontjából. Minden mikroszolgáltatásnak valamilyen csapatnak kell lennie. Így felmerül a kérdés: melyik csapat melyik mikroszolgáltatással rendelkezik?
kereszt funkcionális csapatok
első, naiv megközelítésünk az lehet, hogy csapatainkat a monolit szervezeti struktúránk utánzásával szervezzük meg:
itt látjuk csapatok (lila) által szervezett funkció: UX tervezés, frontend Engineering, backend Engineering, adatmérnökök, DBA-k, QA, stb.
Ez talán jó érzés, legalábbis kezdetben. De vegyünk egy lépést hátra, és nézzük meg, milyen értéket próbálunk nyújtani ügyfeleinknek. Célunk, hogy az alábbiakhoz hasonló dolgokat építsünk ügyfeleink számára?
- egy csomó adatbázis-séma
- egy csomó felhasználói felület makett
- egy csomó mikroszolgáltatás, amely képes beszélni egy MySQL adatbázissal?
nem igazán. Ezek csak azok az eszközök, amelyekkel értéket teremtünk ügyfeleink számára. A tényleges érték, amelyet ügyfeleinknek/felhasználóinknak nyújtunk, olyan funkciók és funkciók formájában jelenik meg, mint például:
- termékkatalógus A kereséshez
- a tételek bevásárlókosárba helyezésének mechanizmusa, majd azok megvásárlása
- értesítési rendszer, amely figyelmezteti az ügyfeleket vásárlásaik állapotáról
hasonlóképpen, nem akarjuk a csapatunkat funkcionális terület szerint szervezni. Inkább meg kell határoznunk csapatainkat az ügyfelek számára létrehozott érték alapján; vagyis a funkciók között, a (helyesen elnevezett) keresztfunkcionális csapatokban.
a keresztfunkcionális csapatokkal mindenki együtt dolgozik egy adott termék vagy szolgáltatás felépítésén, az elejétől a végéig. A csapatban mindenkinek ugyanazok a céljai és prioritásai vannak, tehát egyetlen funkcionális területet sem akadályoz meg egy másik. Az új backend API szolgáltatás igényel némi adatbázis-tervezési munkát? Rendben; a csapat háttérmérnöke és a DBA egyaránt prioritásként kezelheti a közös munkát.
legjobb esetben a keresztfunkcionális csapatok arra ösztönzik a tagokat, hogy működjenek együtt a projekt minden szakaszában. Minden csapattag hozzájárul a szolgáltatás általános kialakításához. A Frontend, a backend és a mobil mérnökök közösen határozzák meg az API szerződéseket. Mindenki tesztel. És mindenki jól ismeri a saját területét.
és így a csapat struktúrái valami ilyesmit kezdhetnek keresni:
ez jobb. De valami még mindig nem stimmel.
persze, olyan csapatokat alakítottunk ki, amelyek valószínűleg hatékonyabbak lesznek a termékek birtoklásában. De még mindig felülről lefelé irányuló megközelítést alkalmaztunk a szervezetünk által építeni kívánt mikroszolgáltatások topológiájának azonosítására. Az egymástól függő mikroszolgáltatások nagy gyűjteménye maradt, amelyek többsége összekapcsolódik. Egyszerűen kiosztottuk őket különböző csapatokhoz, hogy építsenek.
Ez olyan aggályokhoz vezet, mint például:
- hogyan hozhatunk létre olyan API-kat, amelyek megfelelnek minden ügyfél jelenlegi és jövőbeli igényeinek? Beágyazhatjuk-e adatainkat, amikor bármely szolgáltatásunkat más csapat szolgáltatásai felhívhatják?
- mennyi időt fogunk pazarolni arra várva, hogy más csapatok végrehajtsák a függőségeinket?
- milyen rendszerhibákat okozhatnak más rendszerek hibái (lépcsőzetes hibák)?
- szabályozhatjuk-e a szolgáltatásaink által érintett hívások számát? Biztosíthatjuk-e, hogy szervezetünk ne hozzon létre határtalan szinkron hívásokat a szolgáltatások között, ami csillagászati válaszidőkhöz vezet, vagy ami még rosszabb (és igen, láttam ezt megtörténni) végtelenül rekurzív hívásokat a szolgáltatások között?
- mi van akkor, ha csapatunk sajátos jellemzője vagy problématerülete nem megfelelő az előre megtervezett mikroszolgáltatási topológiához?
még más gondolkodásmódra van szükségünk. Talán már létezik egy minta, amelyet követhetünk?
adja meg a korlátozott kontextust
a korlátozott kontextus a tartományvezérelt tervezésen vagy DDD-n kívüli kulcsfontosságú tervezési minta. A korlátozott kontextus megértése segít önálló csapatok kialakításában, és kiterjesztve autonóm mikroszolgáltatási architektúrákat.
a DDD maga írja le a szoftverfejlesztés módszertanát, amelyben a szervezeten belüli egyének együtt dolgoznak egy közös nyelv meghatározásán. Könyvében Domain Driven Design, Eric Evans gyakran ábrázolja a terméktulajdonosokkal dolgozó mérnököket, hogy megállapodott szókincset hozzanak létre olyan dolgok leírására, mint a termékek, a termékek összetevői, a termék által végrehajtható (vagy a terméken végrehajtható) műveletek, munkafolyamatok részei stb. Ez a szókincs magában foglalja a szervezet domainjét.
sok nagy szervezetben azonban az egységes, következetes szókincs meghatározása megvalósíthatatlanná válik. Ezekben az esetekben a domainünket aldomainekre bontjuk. Az aldomainek például a következők lehetnek:
- Inventory management
- Product discovery
- Order management
- bevásárlókocsik és pénztár
mivel a tervezők, mérnökök, termékmenedzserek, stb, összejönnek, hogy építsenek ki egy aldomain, alkotják a saját gondolkodásmód és beszél az aldomain és összetevői.
itt találkozik a DDD a keresztfunkcionális csapatstruktúrával. Bár a csapat tagjai különböző funkcionális területekről származnak, felelősek a saját aldomainjükért, végül rezidens szakértőkké válnak. Ezenkívül a csapat feladata annak meghatározása, hogy mely tárgyak — mikroszolgáltatások, webes alkalmazások, mobilalkalmazások, adatbázisok és kapcsolódó infrastruktúra-szükségesek az aldomain életre keltéséhez és a szervezet ügyfeleinek.
úgy gondolhatunk a csapatra és annak tárgyaira, mint egy korlátozott kontextusra.
A korlátozott kontextus meghatározása
míg Evans könyvében gyakran tárgyalja a korlátozott kontextusokat, valójában nem határozza meg kifejezetten a mintát. Tehát itt megpróbálom megtenni:
Korlátozott kontextus:
egy belső konzisztens rendszer, gondosan megtervezett határokkal, amelyek közvetítik, hogy mi léphet be a rendszerbe, és mi léphet ki belőle.
más szavakkal, a korlátozott kontextus egy kontextust jelent — lényegében egy olyan rendszert, amely magában foglalja a kooperatív összetevőket — világosan meghatározott határokkal, amelyek szabályozzák, hogy mi léphet be a rendszerbe, és mi léphet ki belőle.
a sejtek (azok a kis dolgok, amelyek együttesen alkotják az összes élőlényt) szép analógiát kínálnak. A sejten belül mindenféle komponens található (a mag, riboszómák, citoplazma, citoszkeletonok stb.), amelyek mind magában a sejtben vannak beágyazva. Minden sejtet körülvesz egy membrán, amely gátként működik a sejt belső részei és a szervezet többi része között. A membrán megvédi a sejtet a környezetétől, lehetővé teszi bizonyos tápanyagok bejutását, és lehetővé teszi a különböző melléktermékek távozását.
ugyanebben az értelemben a korlátozott kontextus különféle összetevőkből áll (mikroszolgáltatások, webes alkalmazások, mobilalkalmazások, adatbázisok, üzenetsorok stb.). Logikai akadályként is szolgál, amely magában foglalja ezeket az összetevőket. Belsőleg az összetevők összekapcsolhatók, és szabadon átadhatják az adatokat egymásnak. De a korlátozott kontextus elősegíti a laza tengelykapcsoló külső érvényesítését, explicit pontok meghatározása, ahol:
- külső adatok léphetnek be (talán a fogyasztó feliratkozott egy Kafka témára)
- a belső adatok kiléphetnek (talán egy másik Kafka témán keresztül, vagy egy jól megtervezett GET API-n keresztül, gondosan megtervezve, hogy elrejtse a belső rendszer részleteit)
a korlátozott kontextus képviseli a keresztfunkcionális csapatát is. A csapat különböző csapattagokból áll (tervezők, frontend/backend/mobil mérnökök, termékmenedzserek, adatmérnökök és minőségbiztosítási mérnökök stb.). Belsőleg ezek a tagok együttműködnek ugyanazon következetes célok elérése érdekében. Sőt, ezek a csapattagok vannak (vagy kell) kapszulázva, hogy minimális függőségük legyen más csapatoktól.
tehát ahelyett, hogy szervezeti szinten kezdenénk, és meghatároznánk az összes olyan alkalmazást és mikroszolgáltatást, amelyet építeni akarunk, csapatokat építünk az aldomainjeink köré, lehetővé téve ezeknek a csapatoknak, hogy bővítsék aldomainjeiket, és meghatározzák, mit kell építeni. Megfelelően elvégezve hajlamosak vagyunk a szervezet különböző Korlátozott összefüggéseit organikusan növekedni, nem pedig merev, előre meghatározott struktúráknak tekinteni.
A monolit megtörésének következményei
Conway törvénye azt mondja nekünk, hogy a szervezetek olyan szoftverrendszereket terveznek, amelyek utánozzák szervezetük kommunikációs struktúráját. Ez gyakran igaznak bizonyul, ezért alaposan át kell gondolnunk, hogyan strukturáljuk szervezetünket, amikor elkezdjük építeni a mikroszolgáltatásokat.
valójában mostanra egy képnek kell megjelennie a fejedben. Ahogy a monolitról a mikroszolgáltatásokra lépünk, függőlegesen kell gondolkodnunk (elosztva a monolitot az aldomainjeivel), nem pedig vízszintesen (elosztva a monolitot funkcionális rétegeivel).
dolgokat nem úgy osztjuk el, mint a bal oldalon, hanem mint a jobb oldalon
más szavakkal, nem szabad azzal kezdenünk, hogy a Monolith adatelérési rétegét adatmikroszolgáltatásokra cseréljük. Inkább egy teljes szolgáltatás felosztásával kell kezdenünk (például a fizetési folyamat, vagy esetleg a termékkeresés). Minden funkció korlátozott kontextust képvisel. És mindegyiket egy dedikált keresztfunkcionális csapat osztja szét.
továbbá, hogy a csapat kell összpontosítania a feladat kéznél, ami vagy:
- hűségesen lemásolni a meglévő funkciókat,
- vagy (jobb), hogy építsenek egy teljesen új, továbbfejlesztett élményt az ügyfelek számára.
a folyamat részeként a csapatnak meg kell terveznie a törekvéshez legmegfelelőbb rendszert.
például úgy dönthetünk, hogy a termékkeresési funkciót kihúzzuk a monolitból. A termékkereső csapat végül olyan rendszert tervezhet, amely magában foglalja:
- Kafka fogyasztók hallgatni számos külső Kafka témák frissíteni a saját belső rendszer rekord (SoR) termékek.
- egy Kafka kiadó, amely a SoR változásait egy belső Kafka témára tolja
- egy másik Kafka fogyasztó, amely meghallgatja az adott belső témát, és frissíti az Elastic Search indexet
- egy GraphQL végpont a Szabad formájú keresésekhez, amely lekérdezi az Elastic Search-et
- egy ReST végpont, amely az egyes termékeket ID alapján lekéri
- újratervezett webes alkalmazás, amely ezeket a végpontokat használja, hogy lehetővé tegye az ügyfelek számára a termékek keresését és a termékadatok felfedését
- hasonló készlet a képernyők a mobil alkalmazások, amelyek ezeket a végpontokat
- a Kafka Kiadó, hogy tolja üzenetek, az ügyfelek által végzett különböző lekérdezések reprezentálása egy külső Kafka témához, bármilyen más korlátozott kontextus (mondjuk analitika) számára, amely érdekelheti
hogyan nézhet ki a termékkeresési határolt kontextusunk piros színnel burkolva
ahogy elkezdjük lehúzni a monolitunk egyre több függőleges részét, más csapatok felépítik saját határolt kontextusaikat. Ezek a határolt összefüggések teljesen eltérhetnek egymástól.
Figyeljük meg, hogy összetevőket belül egy adott Határolt Összefüggésben lehet, hogy szorosan összekapcsolva; ugyanakkor tartjuk a Határolt Környezetben független egymástól. Példánkban a korlátozott kontextusok közötti kommunikáció az üzenetek Kafka üzenetsoron keresztüli továbbításával történik. Fontos, hogy elkerüljük a szinkron kérés/válasz hívásokat a korlátozott kontextusok között.
Ez igaz a monolit maradványaira is. Természetesen nem akarunk szoros kapcsolatot az új mikroszolgáltatásaink és a régi monolith között. Tehát, ahogy lehámozzuk a monolit egyes részeit, kihasználjuk az üzenetátadást, hogy a fennmaradó részek kommunikálhassanak az új határolt Kontextusainkkal.
A valóság ellenőrzése ezen a függetlenítésen
Ezen a ponton feltehetjük magunknak a kérdést, hogy valóban lehetséges-e a korlátozott Kontextusainkat függetleníteni.
a való világban valóban megvédhetjük csapatainkat a külső függőségektől? Soha nem lesz olyan eset, amikor egy csapatot egy másik csapatnak blokkolnia kell a munkája elvégzéséhez?
és létre tudunk-e hozni olyan szolgáltatási architektúrákat az aldomainjeink számára, amelyek teljesen el vannak választva más aldomainektől? Valóban nincs szükség egy alkalmazásra egy korlátozott kontextusban, hogy valaha szinkronban hívjon egy szolgáltatást egy másikban?
a valóságban lehetetlen lehet 100% – ban szétválasztani a korlátozott kontextusokat. De közelebb kerülhetünk, sokkal közelebb, mint a legtöbben gondolnánk.
valós architektúrák
kezdjük azzal, hogy megnézzük a függetlenített architektúrákat. Gyakran bevesszük azt a tévhitet, hogy bármely adott típusú adatnak pontosan egy helyen kell élnie, és hogy bármely más rendszernek közvetlenül arra az egy helyre kell hívnia az adatokhoz való hozzáféréshez.
erre úgy hivatkozunk, hogy egyetlen Igazságforrást (SSoT) rendelünk adatainkhoz. De amint azt ebben a cikkben leírtuk, amely boncolgatja az SSoTs gondolatát, ez a fogalom nagyjából anti-minta. Ehelyett a legtöbb korlátozott kontextusnak tárolnia kell a használni kívánt adatok saját helyi másolatát.
ezt példázza az előző szakasz Termékkereséssel határolt kontextusa. Ez a korlátozott kontextus természetesen nagymértékben támaszkodik szervezetünk termékkatalógus-adataira. De valószínű, hogy az adatok egy másik korlátozott kontextusban jönnek létre (ezt nevezzük a Termékbejegyzés Korlátozott kontextusának).
az első (naiv) megközelítésünk az lehet, hogy felfedjük a REST API-t a Termékbejegyzés által korlátozott kontextusból, és arra kényszerítjük a szolgáltatásokat a Termékkeresés által korlátozott kontextusban, hogy hívják ezt az API-t. De jobbat is tudunk. Ehelyett a rendszereket függetleníthetjük azáltal, hogy a Termékbeviteli szolgáltatások által végrehajtott változtatásokat közzétesszük a Kafka-ban. Termékkeresőnk, a Kafka fogyasztói ezután felveszik ezeket az üzeneteket, és frissítik a termékkeresési adatbázisokat.
vegye figyelembe, hogy ez a két korlátozott kontextus végül következetes. Ez azt jelenti, hogy lesznek olyan rövid időszakok, amikor egy adott adat ellentmondhat a Termékbejegyzés és a Termékkeresés között. Például, ha a fehér Wombat widgetek ára 1,99 dollárról 2 dollárra emelkedik.49, lesz egy rövid idő (gyakran másodpercek kérdése, ha nem milliszekundum), ahol a fehér Wombat Widget árában a két határolt összefüggés között 50 6db különbség van.
Ez a valós esetekhez vezet, amikor nincs más választásunk, mint a korlátozott összefüggések összekapcsolása. Bizonyos esetekben az esetleges következetesség nem elfogadható. Például, mielőtt egy ügyfél befejezheti online vásárlását, előfordulhat, hogy biztosítanunk kell, hogy a bevásárlókosarában lévő minden elem valóban elérhető legyen abban a pillanatban. Még akkor is gyakran minimalizálhatjuk a két határolt összefüggés összekapcsolását.
interakcióink így nézhetnek ki:
- mivel az ügyfél a termékkereső felhasználói felületet használja a termékek keresésére, a termékkereső adatbázisok információkat (például stílusokat, vásárlói véleményeket, árakat stb.) a termékekről
- még akkor is, amikor az ügyfél megkezdi a fizetési folyamatot, továbbra is a termékkereső adatbázisokat használjuk a megjelenítendő információk lekérésére.
- végül, amikor az ügyfél rákattint a végső “teljes Vásárlás” gombra, egyetlen, szinkron hívást kezdeményezünk a Termékbejegyzéssel határolt kontextusba, hogy ellenőrizzük az elemek elérhetőségét a vásárlás befejezése előtt.
egy másik gyakori példa, amely azonnali következetességet igényel az engedélyezéssel kapcsolatban. Számos rendszerben a biztonsági tokeneket minden kérésre le kell tölteni vagy érvényesíteni kell. Ezekben az esetekben valószínűleg meg kell engednünk, hogy korlátozott Kontextusaink egy másik, biztonságorientált Korlátozott kontextust hívjanak.
valós szervezeti struktúrák
mi a helyzet az önálló, keresztfunkcionális csapatokkal? Mennyire lehetségesek ezek a Való Világban?
a valóságban ez egy folyamatos mozgás folyamata a teljesen önálló csapatok felé. Ritkán fogjuk elérni a 100% – os autonómiát csapatainkkal. De ha azzal kezdjük, hogy intelligensen szervezzük a csapatainkat, és felismerjük és reagálunk a felmerülő szűk keresztmetszetekre, akkor közel kerülhetünk.
kezdetnek maximalizálnunk kell a vertikális, keresztfunkcionális csapatainkat, és minimalizálni kell a horizontális, egyfunkcionális csapatok számát. Ez azt jelenti, hogy ellenállunk az úgynevezett “mag” csapatok létrehozásának késztetésének-amelynek küldetése az, hogy közös adatszolgáltatásokat építsen ki, amelyeket más termékorientált csapatok fogyasztanak—, és ehelyett csapatainkat az általuk nyújtott üzleti érték köré formáljuk.
sok szervezet lábujjhegyen e cél felé, először alkotó domain-orientált csapatok termékmenedzserek, valamint front-end és back-end mérnökök. Kezdetnek nem rossz. De ki mást kellene tartalmaznia ezeknek a csapatoknak? A pontos tagság eltérő lehet a különböző igényű csapatok között. De meg kell vizsgálni a dolgokat, mint:
- ha csapatunknak front-end mérnökei vannak, akkor valószínű, hogy szorosan együtt kell működniük egy grafikussal, aki elkötelezett a domain iránt.
- a mobil mérnököket — gyakran az org saját területére elkülönítve — be kell vonni a mobil komponenssel rendelkező domainekbe.
- az adathálókról szóló felvilágosító cikkében Zhamak Dehghani sajnálja, hogy az adatmérnököket gyakran kizárják a keresztfunkcionális csapatokból-az adatmérnökök és maguk a keresztfunkcionális csapatok kárára.
miután meghatároztuk csapataink tagságát, figyelnünk kell a szűk keresztmetszetekre. Vannak más csapatok, amelyek általában blokkolják a keresztfunkcionális csapatok termelékenységét?
például sok szervezetnek van egy dedikált biztonsági csapata. Ez természetesen jó gyakorlat; a szervezeteknek egységes biztonsági stratégiára van szükségük, és arra, hogy biztosítsák a stratégia irányítását. Ugyanakkor az is gyakori, hogy a csapatok különböző szakaszokban leállítják munkájukat, hogy lehetővé tegyék munkájuk biztonsági felülvizsgálatát. Még a legjobb helyzetekben is, ez rutinszerű üzleti gyakorlatként akadályozza csapatainkat. Sőt, ez gyakran ahhoz vezet, hogy a csapatoknak munkájuk egészét vagy egy részét le kell selejtezniük, és újra kell kezdeniük, mivel olyan biztonsági követelményeket tárnak fel, amelyek nem teljesültek.
Ez egyértelműen rossz szag. De hogyan tudjuk érvényesíteni szervezetünk biztonsági szabványait, miközben lehetővé tesszük a csapatok számára, hogy önállóak és produktívak maradjanak?
ezt úgy tehetjük meg, hogy biztonsági mérnököket adunk a keresztfunkcionális csapatainkhoz. Három megközelítést alkalmazhatunk:
- ha elég szerencsések vagyunk ahhoz, hogy viszonylag nagy biztonsági csapatunk legyen, minden keresztfunkcionális csapathoz hozzárendelhetünk egy teljes munkaidős biztonsági mérnököt (SE).
- kisebb biztonsági csapatokkal minden SE-t több keresztfunkcionális csapathoz lehet hozzárendelni részmunkaidőben. Ez továbbra is lehetővé tenné a SEs számára, hogy megértse a csapatok céljait és terveit, és együttműködjön a csapattal az org biztonsági szabványainak betartásában a folyamat során.
- Ha nincs elég biztonsági erőforrásunk egyikhez sem, akkor az ellenkező irányba mozoghatunk. Ahelyett, hogy a biztonsági csapat tagjait bevonnánk a keresztfunkcionális csapatainkba, a keresztfunkcionális csapatok tagjait ki tudjuk hozni a biztonsági csapatba. Minden keresztfunkcionális csapat egy vagy két biztonsági képviselőt jelölne ki. A képviselők rendszeresen találkoznak a biztonsággal, és lépést tartanak a szervezet biztonsági követelményeivel és szabványaival. Lehet, hogy maguk nem biztonsági szakértők. De képesek lesznek biztonsági mérnök szerepét betölteni, biztosítva, hogy csapataik betartsák a szervezet biztonsági gyakorlatait.
céhek
Ez egy másik szervezeti mintába illeszkedik, amely egyre vonzóbbá válik: céhek. A céh modell a keresztfunkcionális csapatmodellből született. Természetüknél fogva ezeket a csapatokat olyan tagok lakják, akik különböző funkciókra szakosodtak. Még, gyakran van értelme azoknak az embereknek, akik egy adott funkcióra szakosodtak, hogy együtt is találkozzanak; például, nak nek:
- élesítsék tudásukat és tanuljanak egymástól
- fedezze fel és hozza létre a legjobb gyakorlatokat az adott funkciójukhoz
- a funkciótól függően hozzon létre vállalati szabványokat és követelményeket
utolsó biztonsági megoldásunk hatékonyan létrehozott egy “biztonsági Céhet”. A csapat tagjai elsősorban vertikális csapataikkal dolgoztak; de időnként néhányan találkoztak a biztonsági “céhgel”, hogy megvitassák a szervezet biztonsági gyakorlatait és szabványait.
a guild modell különösen jól működik a Szoftverarchitektúra terén is. Különösen a mikroszolgáltatások architektúrája esetén bizonyos szintű szervezeti szintű műszaki irányításra van szükség. Mégis, ha egy építészcsoport metaforikus elefántcsonttoronyban ül, szabályokat osztogat a csapatoknak, általában kontraproduktív. Ehelyett a keresztfunkcionális csapataink vezető / vezető mérnökei rendszeresen találkozhatnak egy építészeti céhben. Ott problémákat vethetnek fel a csapataiktól, megoldásokat dolgozhatnak ki, és megállapíthatják a patteneket és a szabványokat.
Céhek is meg lehet hosszabbítani, hogy szinte minden más funkciókat is. Végül is azt akarjuk, hogy a tervezők fejlesszenek és dolgozzanak ki egy közös felhasználói felület stílusú útmutatót. Azt akarjuk, hogy frontend mérnökeink ugyanazokat az UI elemeket használják. A minőségbiztosítási mérnököket össze kell hangolni azzal, hogy a tesztelés hogyan történik szervezeteinkben. A termékmenedzsereknek szinkronban kell lenniük a szervezet általános terméktervével.
hozd össze az egészet
a mikroszolgáltatásokra való áttérés drámai módon javíthatja csapataink termelékenységét. De meg kell értenünk, hogyan lehet kihasználni a mikroszolgáltatások architektúráját, hogy odaérjünk. A mikroszolgáltatásokkal kapcsolatos összes tervezési minta és koncepció közül a korlátozott kontextus vitathatatlanul a legfontosabb, amely megadja nekünk ezt a megértést.
a korlátozott kontextus szilárd megértésével megértjük, hogy:
- szervezeti felépítésünk és műszaki architektúránk kéz a kézben járnak
- termékorientált csapatainknak minimális függőséggel kell rendelkezniük más csapatoktól, csakúgy, mint az általuk épített rendszereket el kell választani a többi rendszertől
általában a korlátozott kontextus befogadása azt a gondolkodásmódot jelenti, hogy sikeresnek kell lennünk a mikroszolgáltatások architektúrájával. Győződjön meg róla, hogy megértette ezt a fontos mintát, mielőtt elkezdené a mikroszolgáltatások útját!
