Minőségi jellemzők és kompromisszumok

Célok

A lecke végére fel tudod sorolni azokat a szempontokat, amelyek mentén az architektúrák összehasonlíthatók, és meg tudod indokolni, miért nincs minden helyzetben legjobb architektúra.

Miért kell közös szempontrendszer?

„Melyik architektúra a jobb?” kérdésre egyetlen szempont szerint nem lehet felelni. Egy döntés általában egyszerre javít valamit és ront valami mást. Ha a szempontokat előre megnevezzük, a vita a követelményekről szól, nem ízlésekről.

Mik a minőségi jellemzők?

A minőségi jellemzők (más néven nem funkcionális követelmények) azt írják le, hogyan működjön a rendszer, nem azt, mit tudjon. A tananyag a következő hét szempontot használja végig, mert az architektúrák közti különbségek nagy része ezeken látszik.

Szempont	Kérdés	Tipikus ellentét
Csatolás	Mennyire kell együtt változnia a részeknek?	Szoros csatolás egyszerű, de merev
Deployolhatóság	Mi adható ki önállóan, milyen gyakran és milyen kockázattal?	Önálló kiadás több egységet és több összehangolást jelent
Skálázás	Mi növelhető külön, ha nő a terhelés?	Finom skálázás több szereplőt és hálózatot jelent
Adatkezelés	Ki a gazda, ki olvashat, ki írhat?	Közös adat egyszerű, de összekapcsol
Konzisztencia	Mikor látja mindenki ugyanazt az állapotot?	Erős konzisztencia korlátozza az elosztást
Hibakezelés	Mi történik, ha egy rész kiesik vagy lassú?	Több önálló rész több hibalehetőséget is jelent
Csapat- és üzemeltetési költség	Hány csapat, milyen eszközök és mekkora működtetési teher kell?	Az önállóság szervezeti és infrastruktúra-költséggel jár

Hogyan viszonyulnak egymáshoz?

A szempontok nem függetlenek. A csatolás csökkentése (például külön szolgáltatásokkal) javíthatja a deployolhatóságot és a finom skálázást, de a hálózati hívás miatt rontja a hibakezelést, az adatkezelést és a konzisztenciát. Ezek a költségek nem „hibák”, hanem a döntés ára.

flowchart LR
  A["Kisebb csatolás<br/>(szétválasztott részek)"] --> B["Jobb: önálló kiadás,<br/>szelektív skálázás"]
  A --> C["Rosszabb: hálózati hiba,<br/>elosztott adat, működtetés"]

A jellemzők mérhető formában értelmesek. A „gyors” helyett jobb a „a keresés válaszainak többsége egy megadott határidőn belül érkezik meg adott terhelés mellett”; a „skálázható” helyett az, hogy „a keresés külön növelhető anélkül, hogy a számlázást is kiadnánk”. A mérőszám küszöbét mindig a követelmény adja, nem a tananyag.

A szervezet is a rendszer része

A csapatszervezés hat az architektúrára. Melvin Conway megfigyelése szerint a rendszert tervező szervezetek olyan tervet hoznak létre, amely a saját kommunikációs szerkezetük másolata. Ezért a csapatok száma és ügyességének mértéke is szempont: ugyanaz az architektúra másként működik egy négyfős és egy több tucat csapatot koordináló szervezetben.

Nincs legjobb architektúra

Egy architektúra attól jó, hogy a fontos jellemzőket a követelményekhez mérten teljesíti, a többi rovására. Ha a gyors piaci visszajelzés a fő cél, az egyszerű kiadás és a közös adat előnyös lehet. Ha sok csapat külön ütemben dolgozik, az önálló kiadás ára vállalható lehet. A következő fejezetek minden stílusnál ugyanazokat a szempontokat használják.

Gyakori tévhitek

Állítás	Pontosítás
„A legfejlettebb architektúra mindig a legjobb.”	A legjobb az, amelynek a költségei vállalhatók a tényleges követelményekhez.
„A skálázhatóság azt jelenti, hogy sok gépen fut.”	A skálázhatóság azt jelenti, hogy a növekedés a szükséges ponton növelhető, elfogadható költséggel.
„A hibatűrés azt jelenti, hogy nem lehet hiba.”	A hibatűrés ismert, korlátozott viselkedés hiba esetén.
„A csapatszervezés nem architekturális kérdés.”	Conway megfigyelése szerint a rendszer szerkezete követi a kommunikációs szerkezetet.

Röviden

• A minőségi jellemzők azt írják le, hogyan működjön a rendszer.
• A tananyag hét szempontot használ: csatolás, deployolhatóság, skálázás, adatkezelés, konzisztencia, hibakezelés, csapat- és üzemeltetési költség.
• Egy döntés általában az egyiket javítja, a másikat rontja.
• A jellemzőket mérhető követelményként érdemes megfogalmazni.
• A szervezet szerkezete is része az architektúrának.

Ellenőrző kérdések

1. Miért javíthatja egy szolgáltatásra bontás a deployolhatóságot, és miért ronthatja a konzisztenciát?
2. Fogalmazz át egy homályos követelményt („legyen gyors”) mérhető formára.
3. Hogyan hat a csapatok száma az architektúra megválasztására?

Források

• Conway's law (Wikipedia) — a törvény megfogalmazása és forrása: Melvin E. Conway, „How Do Committees Invent?”, Datamation, 1968. április.
• Architecture styles as constraints (Azure Architecture Center) — a stílusválasztás üzleti és nem funkcionális szempontok alapján.