henrik knopper bloghoved

Hippie-arkitektur?

Jeg sidder til daglig meget, meget dybt nede i tunge procedurer og komplekse systemer.

Faktisk alt det Mogens Heller Grabe advarer imod i foromtalen til i sit indlæg på årets GOTO.

Jeg ser frem til at høre om hans hippie-bus til enterprise-arkitektur og håber på at blive udfordret og inspireret, men jeg er også skeptisk.

For hvis man bruger hippie-tilgange og gør systemerne mindre, så bliver integrationsopgaven det større. Altså er det bare en genopfindelse af SOA.

Måske.

Som sagt jeg er skeptisk, men forberedt på at blive overrasket.

Og det er vel det man tager på konference for, ikke?

Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Josef Assad

"For hvis man bruger hippie-tilgange og gør systemerne mindre, så bliver integrationsopgaven det større" - Henrik Knopper

"Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." - Doug McIlroy

Men McIlroy var jo heller ikke tvunget til at bruge "enterprisey" udviklingsplatforme.

  • 4
  • 0
Lars Tørnes Hansen
  • 2
  • 0
Henrik Knopper

Kan man sige at det er lidt a la UNIX tilgangen til tingene, sådan som de er beskrevet i "The art of UNIX programming" -> "Basics of UNIX Philosophy" ?
http://www.catb.org/esr/writings/taoup/html/

Det kan man sagtens. Men den demonstrerer jo også at små enkle værktøjer som skal løse komplekse opgaver kræver meget af de personer og de programmer der skal binde det hele sammen i form af dokumentationsevner og forretningsoverblik.

  • 0
  • 0
Jeppe Cramon

Hvad vil du helst have - en stor gang spaghetti hvor alt hænger uhjælpeligt sammen eller mindre klumper af spaghetti der er løst koblede? Hvis de små klumper er små og løst koblede er det meget nemmere at skifte dem ud eller ændre dem end hvis det hele ender om med at være hårdt koblet.

Integrations opgaven med mange små services kan blive stor og kompleks hvis grænserne mellem services ikke er vel tunede (en kontinuerlig process) og hvis man går til det på den klassiske lagdelte SOA måde. Der skal andre ingredienser i retten hvis det skal smage godt, f.eks. Process centric, EDA, CEP, Composite UI's.
Det kræver meget af arkitekturen og endnu mere af organisationen at komme væk fra store system komplekser og hen i mod veldefinerede, mindre og løst koblede systemer/services. Det er nok derfor at så mange er endt op med store komplekse systemer.

Hvis du er interesseret i mere, har jeg lagt en video + slides fra et tidligere foredrag jeg holdt om emnet op på http://www.tigerteam.dk/2013/slides-and-video-from-our-iddd-tour-dk-talk...

/Jeppe

  • 3
  • 0
Henrik Knopper

Hvorfor er det et komplekst system og en tung procedure ? I min optik er det negativt, er det også det i din ?

Det hedder GAMP (Good Automated Manufactoring Practice) og læner sig tæt op ad ISO 9001:2004.

Det er hverken positivt eller negativt, det er bare virkeligheden.

Men hvis folk ikke har forstået, men bare lært udenad, vælger de som regel den mest komplicerede vej til målet.

Enkelhed kræver alt for stort overblik.

Det er derfor jeg håber i årevis har ledt efter inspiration til at introducere Zen i GAMP - eller sådan noget.

  • 0
  • 0
Henrik Knopper

Det kræver meget af arkitekturen og endnu mere af organisationen at komme væk fra store system komplekser og hen i mod veldefinerede, mindre og løst koblede systemer/services. Det er nok derfor at så mange er endt op med store komplekse systemer.

Er det virkelig der skoen trykker?

Eller trykker den der at i "The Spaghetti Incident" skal arkitekten både tage ansvaret og formå at formidle visionen.

Med monolitten betaler organisationen sig fra begge dele.

  • 1
  • 0
Ninna Fedder Jensen

Hvad med performance?

Løst koblede, modulære simple systemer, bruger en forfærdelig masse ressourcer på at flytte data rundt imellem modulerne og i sidste ende, et eller andet programmel til GUI, print eller batch.

Vi har problemer med timeouts i det system jeg arbejder på, og det er en kompleks monolit. Hvis jeg, givet at jeg fik nogle millioner og samarbejde med andre specialister, brød den ned til et modulært design, så ville dens performance blive dårligere - alle de bevægelser af data kræver processor trin og tilgang til hukommelse.

Jeg er heller ikke helt sikker på om det gør det mere simpelt som helhed (helheden er jo funktionelt identisk), men måske kunne man fordele vedligeholdelsen bedre da flere mennesker kunne vide mindre, for at ændre programmellet.

Men givet at det kunne lade sig gøre, ville jeg nok gerne. Så kan jeg dog ikke gemme mig så nemt under undskyldningen af at systemet ikke kan dokumenteres i sin helhed pga. kompleksitet :-|

Dokumentation må så dog være alt, ellers er man lige vidt. Så har man bare tusind programmer, ingen fatter sammenhængen af. Det er set før ;-)

  • 1
  • 0
Nikolaj Brinch Jørgensen

Hvad med performance?

Løst koblede, modulære simple systemer, bruger en forfærdelig masse ressourcer på at flytte data rundt imellem modulerne og i sidste ende, et eller andet programmel til GUI, print eller batch.


Det er en rigtig god pointe. Men det kommer igen an på hvordan man arkitekturmæssigt har skruet sin løsning sammen. Altså om data SKAL flyttes rundt mellem modulerne (og hvordan man cacher i sin arkitektur).
Det er klart at ekstern kommunikation over netværk, altid vil være langsommere end kommunikation på program-stakken, eller heap.
Men man må jo nødvendigvis lave en afvejning af, hvad der er væsentlige kriterier og mål, for den arkitetur man laver.

Det er ofte her kæden springer af. Det skal ikke nødvendigvis være 100% SOA, eller 100% pure monolith. Det handle om at finde den middelvej der passer til den enkelte organisations kriterier/mål for vedligelholdelse, performance osv.

Monolitten har iøvrigt den ulempe, at med tiden skal dens data også kommunikeres ud eksternt. Da den med tiden vil få selskab af andre systemer. Derudover er der den frygtelige big bang udviklingsmodel, som præger denne system type. Den tror jeg de fleste kan være enige om at komme af med.

Den tidligere chefarkitekt for ebay, Randy Shoup, har nogle rigtigt gode pointer, når det handler om at lave meget store systemer. Ligeså har folkene bag Overstock.com m.fl.

Note: Databaser af alle typer er et godt eksempel på den løst koblede arkitektur. Her stilles der aldrig spørgsmålstegn ved, at dette er et godt system til at løse denne ene lille opgave, at opbevare data. At der så er rigtigt mange der formår at koble de omkringliggende systemer hårdt til den specifikke instans er noget andet.

  • 2
  • 0
Jeppe Cramon

Løst koblede, modulære simple systemer, bruger en forfærdelig masse ressourcer på at flytte data rundt imellem modulerne og i sidste ende, et eller andet programmel til GUI, print eller batch.

Under forudsætningen at du implementerer og løser den modulære opgave på samme måde som du ville gøre i en typisk monolit, så vil du sandsynligvis ende op med dårligere performance end monolitten.

Hvis et system skal designes modulært kræver det at man bruger tid på at sætte sig ind i domænet og de subdomæner der er involveret og får adskilt dem både data og ansvarmæssigt. I DDD (Domain Driven Design) kaldes disse afgrænsninger Bounded Contexts og den vigtigste opgave et at finde disse tidligt, da det er omkring disse at systemerne brydes. Bounded Contexts fokuserer på sproget og hvordan man omtaler forretnings objekterne i systemet. Det er klassisk at høre to forskellige forretnings enheder tale om forskellige forretnings objekter men kalde dem det samme (det omvendte findes selvfølgelig også). Den klassiske fælde at falde i, både kompleksitets mæssigt og performance mæssigt, er at ophøje disse fælles objekter til et domæne/system. F.eks. et kunde system. Der findes typisk rigtig mange forskellige perspektiver på en kunde i en større virksomhed afhængigt at afdeling og hvilket stadie af en process/livscyklus kunden befinder sig på. Hvis alle skal blive enige om eet kundebillede bliver det formentligt både meget stort og meget komplekst (husk du ikke kan læse disse 10 associationer med mindre kunden er pensioneret, osv).
Timeouts og performance problemer i monolitter opstår tit fordi forskellige transaktioner/processer kæmper om de samme data (lock contention) og det at transaktions scopet (antallet af entiteter/aggregates der bliver berørt ifb en transaktion) er for stort. Pat Hellands "Life Beyond Distributed Transactions" beskriver dette rigtig godt (han kalder dog ikke objekt klumperne for aggregates) -
I DDD kigger man meget på processerne og usecases og sørger for at objekt boundaries (inden for en Bounded Context) har den "rigtige" størrelse. Nogle gange er store transaktioner i virkeligheden en forretnings process in disguise og bør håndteres anderledes og eksplicit.

Ofte, i komplekse systemer, er det bedre at blive enige om at vi taler om samme entitet (f.eks. en person), men at vi har hvert vores syn på entiteten, muligvis arbejder vi også med entiteten på forskellige tidspunkter (udbetaling i pensions sammenhæng ser ikke kunden før vedkommende bliver pensioneret, bliver invalideret, afgår ved døden, etc.). Hvorfor skal udbetalings systemets kunde syn forurene indbetalings, police administrations systemerne kunne man spørge.

Deling af data mellem løst koblede systemer er formentlig der du ser problemer (GUI, print, batch). Det er her composite UI kommer ind, fordi vil bliver nød til at sikre at systemerne kan dele data løs koblet og uden øget performance overhead. Med et Composite UI leverer hvert domæne/system selv UI'en til de applikationer hvor der er behov for data fra systemet, f.eks. GUI/Print/Batch/Mobile app. Det sikrer en meget lavere kobling (og selvfølgelig nogle projekt og organisatoriske udfordringer - there' unfortunately no free lunch) og hvert system kan selv afgøre hvordan det vil sikre at de leverer data til tiden og med den rigtige kvalitet. Forskellen fra monolitten hvor du ofte ender med at databasen (i ental) er flaskehalsen kan du med der modulære design vælge kun at skalere/tune den/de services/systemer som performer dårligt. At skalere een stor database er typisk MEGET dyr både i licenser og i det isenkram som kræves. At skalere mindre systemer bør alt andet lige være billigere. Mit foredrag går dybere ned i skalering, composite UI, mv. end der er plads til her.

  • 2
  • 0
Nikolaj Brinch Jørgensen

Hvis et system skal designes modulært kræver det at man bruger tid på at sætte sig ind i domænet og de subdomæner der er involveret og får adskilt dem både data og ansvarmæssigt. I DDD (Domain Driven Design) kaldes disse afgrænsninger Bounded Contexts og den vigtigste opgave et at finde disse tidligt, da det er omkring disse at systemerne brydes...


Alt sammen korrekt.

Min pointe ovenfor var, at der ikke er nogen one-size fits all, heller ikke i løsnings-arkitektur. Monolit vs snow-flake-schema-like SOA, løsningen ligger for det meste et sted imellem de to yderpunkter. Hvordan man kommer derhen, kan sagtens være med DDD (Så kan Eric Evans få solgt nogle bøger), men der kan være andre måder. Der er en myriade af rammeværker og metoder til analyse af den slags, og ikke kun een er den bedste.

  • 1
  • 0
Jeppe Cramon

Min pointe ovenfor var, at der ikke er nogen one-size fits all, heller ikke i løsnings-arkitektur.


Virkelighedens løsning lander som regel altid et sted midt i mellem. Nogle systemer har en karakter der ikke berettiger at bygge løstkoblede alternativer af økonomiske årsager (f.eks. ERP).

Der er en myriade af rammeværker og metoder til analyse af den slags, og ikke kun een er den bedste.


Nu har jeg ikke påstået at DDD er den eneste eller altid bedste vej (det siger Evans heller ikke), men det er een vej mod en løsning (og tit bliver flere metodikker taget i anvending). I stedet for blot at skrive "der er mange måder at gøre det på" uden at give et eksempel eller komme med konsulent svaret "it depends" gav jeg et eksempel hvor DDD terminologien bliver anvendt (det har nogle fordele som at man kan slå definitionerne op). Hvordan du fik det til at jeg mener DDD er den bedste og eneste måde at gøre det på må stå for egen regning ;-)

  • 1
  • 0
Nikolaj Brinch Jørgensen
  • 1
  • 1
Jeppe Cramon

Tja, det kan du have ret i, det har jeg svært ved at afgøre. Har nogen forsøgt at lave løst koblede ERP systemer?


Jeg arbejdede med en REA pattern ERP implementation tilbage i 1999, men det holdt sig stadig inden for et subdomæne. Så nej.
Min pointe var at et ERP system, selv om det er teknisk simpelt, så er det forretnings mæssigt forholdsvist komplekst (lovgivning, moms regler, skat, told, etc.). Jeg tror ikke en cost benefit analyse, mht egen implementering blot for at opnå løsere kobling, højere skalering, etc. vil se specielt positiv ud. Så er det nok bedre at leve med en monolit, evt afskærmet.

Ja det må du undskylde, det var ikke meningen at det skulle fremstå som om at du sagde at DDD er den eneste vej til himlen. Jeg ville bare sørge for at ingen ville misforstå dit indlæg.


Fair nok - tak :)

  • 1
  • 0
Log ind eller Opret konto for at kommentere