Jeg har længe ønsket at skrive en artikel om mikrotjenestearkitektur, men jeg er hele tiden blevet stoppet af to faktorer — jo mere jeg dykkede ned i emnet, desto mere syntes jeg, at det jeg ved, er åbenlyst, og det jeg ikke ved, kræver endnu mere studier. På den anden side mener jeg, at der allerede er noget at diskutere for et bredt publikum. Så alternative meninger er velkomne.
Conways lov og forbindelsen mellem forretning, organisation og informationssystem
Jeg vil endnu en gang tillade mig at citere:
«Enhver organisation, der designer et system (i bred forstand) vil få et design, hvis struktur kopierer strukturen af teamene i denne organisation»
— Melvyn Conway, 1967
Efter min mening relaterer denne lov sig mere til fornuften i at organisere en virksomhed end direkte til informationssystemet. Jeg vil forklare det med et eksempel. Antag, at vi har en stabil forretningsmulighed med en livscyklus, der er så lang, at det giver mening at organisere et foretagende (det er ikke en trykfejl, men jeg holder meget af dette udtryk, som jeg har stjålet). Det er klart, at det understøttende system for denne virksomhed vil organisatorisk og procesmæssigt svare til denne virksomhed.
Forretningsorientering af informationssystemer
Jeg vil forklare det med et eksempel. Antag, at der er en forretningsmulighed for at organisere en virksomhed til at sælge pizza. I version 1 (lad os kalde den den ikke-informationsbaserede) var virksomheden en pizzeria, kasse og leveringsservice. Denne version havde en lang levetid under forhold med lav volatilitet i den omgivende verden. Derefter kom version 2 — en mere avanceret, der kunne bruge informationssystemet som grundlag for en virksomhed med monolitisk arkitektur. Og her, efter min mening, opstår der en virkelig uretfærdighed over for monolitter — tilsyneladende matcher monolitisk arkitektur ikke virksomhedens domænemodel. Hvis det var tilfældet, ville systemet slet ikke kunne fungere - i strid med den samme Conway-lov og sund fornuft. Nej, monolitisk arkitektur stemmer fuldt ud overens med forretningsmodellen på dette udviklingsstadium — jeg mener selvfølgelig det stadium, hvor systemet allerede er opbygget og taget i brug. Det er en fuldstændig bemærkelsesværdig kendsgerning, at uanset den arkitektoniske tilgang, vil version 3 af serviceorienteret arkitektur og version N af mikroservicearkitektur fungere lige godt. Hvor er fangsten?
Alt flyder, alt ændrer sig, eller er mikroservicer et redskab til at bekæmpe kompleksitet?
Før vi fortsætter, lad os se på nogle misforståelser omkring mikroservicearkitektur.
Forkæmpere af mikroserviceprincippet taler ofte om, at opdelingen af et monolitisk system i mikroservicer forenkler udviklingsprocessen ved at reducere kodebasen for de enkelte tjenester. Efter min mening er dette udsagn komplet nonsens. Alvorligt, virker det virkelig komplekst at interagere inden for en monolit og homogen kode? Hvis det virkelig var tilfældet, ville alle projekter fra starten af være bygget som mikroservicer, mens praksis viser, at migration fra monolit til mikroservicer er meget mere udbredt. Kompleksitet forsvinder ikke, den overgår blot fra individuelle moduler til grænseflader (uanset om det er databusser, RPC, API og andre protokoller) og orkestreringssystemer. Og det er komplekst!
Fordelen ved at bruge en heterogen stab virker også tvivlsom. Jeg vil ikke argumentere for, at det også er muligt, men i virkeligheden sjældent ses (Bare for at være forudseende — det bør finde sted — men mere som en konsekvens snarere end en fordel).
Produktlivscyklus og servicelivscyklus
Tag et kig igen på diagrammet ovenfor. Jeg nævnte ikke tilfældigt den faldende livscyklus for den enkelte version af forretningen — i moderne tider er det netop accelerationen af overgangen mellem versioner, der er afgørende for dens succes. Produktets succes bestemmes af hastigheden af validering af forretningshypoteser i det.. Og her er, efter min mening, den vigtigste fordel ved mikroservicearkitektur skjult. Men lad os tage det skridt for skridt.
Lad os gå videre til den næste fase i evolutionen af informationssystemer — serviceorienteret arkitektur (SOA). Så på et bestemt tidspunkt adskilte vi os i vores produkt langlivede tjenester — langlivede i den forstand, at ved overgangen mellem versioner af produktet er der chance for, at livscyklussen for tjenesten vil vare længere end livscyklussen for den næste version af produktet. Det ville være logisk ikke at ændre dem overhovedet — vi er netop interesseret i hastigheden af overgangen til den næste version. Men desværre er vi nødt til at lave konstante ændringer i tjenesterne — og her gælder alt, hvad der kan tænkes, fra DevOps-praksis til containerisering osv. Men det er stadig ikke mikrotjenester!
Mikrotjenester som et middel til at bekæmpe kompleksitet… konfigurationsstyring
Og her kan vi endelig overgå til den afgørende rolle, som mikrotjenester spiller — det er en tilgang, der forenkler konfigurationsstyring af produktet. Mere specifikt beskriver funktionen af hver mikrotjeneste netop en forretningsfunktion inden for produktet i henhold til den domænemodel — og det er allerede aspekter, der lever ikke i kortlivede versioner, men i langlivede forretningsmuligheder. Og overgangen til den næste version af produktet sker bogstaveligt talt usynligt — du ændrer/tilføjer én mikrotjeneste, eller måske blot skemaet for deres interaktion, og pludselig befinder du dig allerede i fremtiden, efterladende grædende konkurrenter, der fortsætter med at hoppe mellem versioner af deres monolitter. Forestil dig nu, at der er et tilstrækkeligt stort antal mikrotjenester med foruddefinerede grænseflader og forretningsmuligheder. Og du kommer og bygger strukturen af dit produkt ud fra eksisterende mikrotjenester — bare ved at tegne et diagram, for eksempel. Tillykke — du har fået en platform — og nu kan du skabe dit forretning.
Konklusioner
- Systemarkitekturen skal bestemmes af livscyklussen for de komponenter, der indgår i den. Hvis en komponent lever inden for versionen af produktet — giver det ikke mening at øge kompleksiteten af systemet ved at anvende en mikrotjenestetilgang.
- Mikrotjenestearkitektur skal baseres på den domænemodel — fordi forretningsmuligheden er det mest langlivede område.
- Leveringsmetoder (DevOps-praksis) og orkestrering har en af de vigtigste betydninger for mikroservicesarkitekturen — fordi den stigende hastighed i ændringer af komponenter stiller højere krav til hastighed og kvalitet i leveringen.
Kilde: habr.com
