Bankdata dropper 3-lagsarkitekturen og bruger mikroservices: »Det her er ret fedt, og det skalerer«

Bankdata dropper 3-lagsarkitekturen og bruger mikroservices: »Det her er ret fedt, og det skalerer«
Illustration: Bankdata.
Gennem de seneste år har Bankdata taget mikroservices-arkitekturen i anvendelse.
2. december 2020 kl. 03:45
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

3-lagsarkitekturen er død. Sådan lyder udmeldingen fra Bankdata, der de seneste par år har taget mikroservices-arkitekturen til sig og er begyndt at lægge 3-lagsarkitekturen i graven.

»Mange taler stadig om 3-lagsarkitekturen fordi de tror, at de har 3 lag i deres program. Men det har de ikke,« siger Michael Rahbek, Senior Software Developer hos Bankdata.

Det var tidligt i 1990’erne at 3-lags-arkitekturen med et præsentationslag, forretningslogiklag og et databaselag blev introduceret af John J. Donovan.

Siden gik arkitekturen sin sejrsgang blandt udviklere, da det blandt andet gav en naturlig opdeling af et systems kode i veldefinerede løst-koblede lag, der ifølge teorien skulle være nemme at udskifte eller modificere uden at det gav anledning til at ændre i under og/eller overliggende lag.

I teorien skulle det også være muligt at skalere de enkelte lag, men i realiteten har det ifølge Bankdata ikke været tilfældet.

Log ind og få adgang
Du kan læse indholdet ved at logge ind eller oprette dig som ny bruger.
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
11
8. april 2021 kl. 10:07

Depenency inversion er ikke noget nyt. Det er også best-practice i en 3-lags model.

Hexagon-modellen er i virkeligheden "bare" en 3-lags-model hvor data-laget kan være delt op i flere typer (f.eks. databaser og eksterne services som kaldes via REST, messages, events osv.). User interfacet er "bare" et generisk API som forskellige klienter (apps, websites, eksterne systemers data-lag) kan kalde. Data-lagets forskellige afhængigheder løses nemt med f.eks. Repository-pattern hvor hvert repository ved hvordan den skal få fat i data for den pågældende entity.

Men 3-lagsarkitekturen og microservices er ikke mutual-exclusive. Man kan sagtens implementere en given microservice med en 3-lags arkitektur :)

10
5. december 2020 kl. 13:22

Hej,

I trelagsmodellen er det sidste lag databaselaget, men i hexamodellen ovenfor tilgås databasen igennem en adapter, hvor selve ideen er, at du kan udskifte databasen som du har lyst. Dvs. databasen er ikke et lag, men en port ud.

Det kræver dog noget implementering for at virke efter bogen, såkaldt "dependency inversion", hvor databaseadgang er igennem et interface, og implementationen af den leveres udefra.

9
3. december 2020 kl. 08:26

Til Emil: Ja de kan næsten de fleste teknologier så det gør det ikke mere relevant.

Jeg kunne godt tænke mig at vide om der er noget Bankdata gør anderledes nu, drevet af denne hexagon model. Jeg kan ikke finde ud af om den skal opfattes som et "view" på de ting man i forvejen var begyndt at gøre drevet af ændrede krav og teknologier (f.eks. implementere et API til en ny type klient, tilsluttet en kø fordi interfacet nu engang var en kø eller lavet en adapter fordi nogen vil have et eller andet legacy API på en bestemt måde o.s.v.)? Eller gør hexagonmodellen at der nu er identiske problemstillinger man løser anderledes?

Ja der er altid udfordringer :-) Heldigvis ikke på performance. Vi har i flere tilfælde omlagt services så vi har haft mulighed for at køre og måle paralelt. Vi kan ikke måle noget latency. Men arkitekturen tager fx ikke højde for flodding. Det skal forsat løses pr. kanal

5
2. december 2020 kl. 14:54

Der er flere og flere virksomheder der laver API'er til at tilgå forretningssystemer og services. Og trenden for tiden er vel, at API skal være generisk, og ikke afhængigt af det underliggende systems datamodel. For i dag ved man ikke hvor længe det underliggende system eksisterer, og hvor det eksisterer. Så det er nødvendigt at oprette generiske interfaces. Det gør det også muligt at bygge interne applikationer der kører på tværs af systemer. Microservices har vel alene deres fordel i at der er andre der skalerer dem, og driver alt det nedenunder. Det kunne man også gøre med App-instancer ude i skyen. Jeg kan se at en af de store problemer med microservices har været manglende sikkerhed. Det har været gæt-en-url, og så er regningen bare vokset. Så de små microservices skal indeholde en hel masse sikkerhed foran den reelle kode.

4
2. december 2020 kl. 12:33

Vores nuværende systemer er i høj grad opbygget med vandrette tråde. Vi må finde ud af gøre det samme med lodrette tråde.

De vandrette tråde pløjer gennem store mængder cachelinier og pauser kun ved eksterne kald. Lodrette tråde bruger mindre cache på hver enkelt kerne og "opgaven" sættes i kø på "den næste" kerne efter eksterne kald.

3
2. december 2020 kl. 09:05

Ville skrive ca. det samme Thomas. Virker måske som om de egentlig ikke har forstået hvad 3-lags arkitekturen. I hvert fald kan det de har lavet fortolkes som en 3-lags struktur selvom den er tegnet som en smart hexagon i powerpoint. Kan virkelig ikke forstå hvad de mener. F.eks.

»Hvis du kun har 3 lag, en database, forretningslogik og et user interface så vil 3-lags- arkitekturen kunne skalere 100 procent. Men hvilke programmer ser sådan ud? Ikke mange. Det er ikke rigtige business-programmer, hvor alt kalder alt på kryds og tværs. Det går galt, når man siger, at der er én brugergrænseflade. Der er ikke kun én brugergrænseflade. Der er mange brugergrænseflader. Der er en app, der er et website, der er nogle der kalder udefra. Det samme gælder datalaget. Der er mange datalag. Brugen af et program er slet ikke som det er designet i 3-lagsarkitekturen

Kan virkelig ikke finde hoved og hale i dette og forholdet til 3-lags arkitekturen. Der er vel ingen modstrid mellem flere user interfaces (d.v.s. klienter) og 3-lags arkitektur. Kan heller ikke forstå hvor det med "skalere 100%" kommer ind i billedet, og iøvrigt skalerer det jo ikke nødvendigvis 100% blot fordi man bruger 3-lags struktur. Endelig ved jeg heller ikke hvad der menes med "der er mange datalag". Med mindre de forskellige databaser, køer m.m. ligefrem kalder hinanden på tværs (på tværs af forretningslogikken) er det stadigvæk bare almindelig 3-lagsarkitektur. Hvis centrum i deres hexagon var f.eks. en data-lake kunne jeg måske se hvad de mener, men der er det lidt mere obskure "proces" og "domain", men det virker som om det er service-laget der ligger her.

2
2. december 2020 kl. 07:52

Prøv at gå fra en vilkårlig "pil ind" til en vilkårlig "pil ud" og se hvor mange "lag" man skal gennem :)

Tror den store ændring i deres tilgang ift. den klassiske 3-lags arkitektur er at applikationen ikke kun har DB som afhængighed, men det har de fleste applikationslag haft i de sidste årtier, i form af REST/SOAP/filer/MQ/Event bus/ObjectStorage/....

1
2. december 2020 kl. 05:23

Ikke så snart man påpeger en fejlmulighed et sted, opstår den et andet sted.