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

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 :)

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.

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?

Det lyder mere som at du tænker på "API'er du betaler dig fra at bruge" end "Microservices"?

Vilket retfærdigvis sagtens kan være en del af en micro service arkitektur.

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

Microservices har vel alene deres fordel i at der er andre der skalerer dem, og driver alt det nedenunder.

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.

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.

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.

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/....

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