Øredev är slut för i år. Sammantaget tycker jag att det var en bra konferens, alla arrangemang fungerade klockrent, men det var först sista dagen som jag såg en presentation som verkligen lyfte.

tl;dr
Om jag ska komprimera intrycket från årets talare så är det att det är hög tid att döda flerlagersarkitekturerna nu.
Systemen ska istället delas vertikalt – skivor snarare än lager – där samma team har ansvaret för allt från gränssnitt till databaser, test och drift.
En sån skiva mycket väl vara en fristående applikation.

Några korta tankar och observationer:

• Douglas Crockford framstod ganska munter. Han menade dessutom att han aldrig hävdat att han är en bättre programmerare än någon annan och berättade även att han skrev en bugg 2001.
• Många citat och referenser till Dijkstra och hans gamla artikel “GOTO statement considered harmful”, samt Conways lag om organisationers inflytande över design.
• Randall Munroe, skaparen av xkcd, var rätt rolig även på riktigt. Det var hans första besök i ett land med positivt “UTC time offset”.
• Årets tema var “Art”. Det kändes lite krystat.
• Det var inte så mycket fokus på programmeringsspråk. Förutom Java, C# och js hörde jag mest om Clojure.
• Det är upplyftande att de nya stora amerikanska bolagen släpper intressanta verktyg och produkter som opensource. På Øredev har bl a nämnts Netflix DNS cloud-verktyg Denominator och LinkedIns meddelandesystem Kafka.
• Starkast intryck gjorde Fred George när han pratade om Micro Service Architectures – uppfriskande och ganska omtumlande faktiskt, mer om den i slutet av detta inlägg.

“Layers considered harmful”
Christian Horsdal beskrev problemen med flerlagersarkitekturer i en av de första presentationerna.

Problemen som uppstår handlar i slutändan om prestanda i två former:
1. Programmets prestanda minskar. Även om varje lager i sig inte tillför mycket så blir det sammantaget en del overhead:

• Delegering i sig kostar något. Ofta sker egentligen inget intressant i ett lager förutom delegering till nästa lager. Utvecklare tenderar att vara strikta med att använda lagren även i de flöden när de inte behövs.
• Nya objekt (DTO:er) skapas i flera lager. Hanterandet av livscykeln för dessa objekt kostar något (Garbage collection etc.)
• I vissa fall införs I/O-operationer. Om det dessutom sker över nätverk blir tidförlusten än mer kännbar.

2. Utvecklingshastigheten minskar och Time to Market ökar:

• Ackumulerade beroenden. Med all delegering som sker ackumuleras beroenden. Om man behöver ändra något från toppen till botten på stacken så blir det många ställen att ändra på.
• Svårhanterliga monolitiska system. När man väl fått all arkitektur på plats frestas man att lägga in all funktionalitet i samma system. Även sånt som kanske inte logiskt hör dit.

Varför är egentligen användandet av lager så utbrett?

• Löftet om portabilitet. Exempelvis har man oftast abstraktionslager över databasservern, så man lätt kan byta leverantör. Christian ifrågasätter om det någonsin har hänt. Mig har det aldrig hänt.
• Tron att man isolerar det som ändras ofta från det som är stabilt. Grundat på antagandet att det som ändras ofta är användargränssnittet och att de underliggande lagren och datamodellen inte behöver ändras så ofta. Christians (och min) erfarenhet är att det rätt sällan är så att ändringar i användgränssnitt bara handlar om att flytta några pixlar eller ändra någon färg. Snarare handlar det om lägga till nya fält, som behöver läggas till genom hela stacken.
• Löftet om återanvändbarhet. Väldefinierade gränssnitt gör lagren återanvändbara. Överskattat, sker sällan – “use before reuse”!
• Sist men inte minst: Det är vedertagen Best Practice. Såväl Oracle  som Microsoft propagerar flerlagerslösningar. Det anses seriöst att göra på detta sätt.

Så vad föreslår Christian att vi borde göra?

• Låta systemen växa inkrementellt
• Prioritera i första hand efter affärsnyttan
• och in andra hand efter risk. Upptäck de svåra problemen så tidigt som möjligt.
• Leverera tidigt och ofta.
• Akta sig för YAGNI, att bygga saker som man inte vet om man kommer behöva.
• Föredra enkla lösningar
• Just-in-time abstraktioner. Skapa abstraktioner när de behövs, inte innan – men heller inte för sent.
• Använd testdriven utveckling utifrån och in. Bygg “walking skeletons” först. Börja med att bygga en vertikal del, end-to-end, av funktionaliteten.

De vertikala skivorna ska vara den övergripande arkikturella modellen snarare än lager. Skivorna kan vara helt skilda system.

• Varje sån skiva blir lättare att överblicka och förstå.
• Som en följd blir skivorna små och lätta att göra sig av med. Om en del blir helt fel så är inte jobbet att göra om den från grunden oöverkomlig och man slipper problemet med Grand Rewrites.
• Driftsäkerheten blir bättre. Om delsystemen inte är beroende av varandra, så kan en användare fortsätta använda huvudelen av applikationen även om en delkomponent havererar.

Matematikern John Conway gjorde en sociologisk observation, som brukar kallas “Conways Lag“:

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”

Så – om vi vill ha applikationer som är indelade i vertikala skivor, kan vi inte ha en organisation där vi har separata team för olika lager. Det funkar inte optimalt att ha t ex ha ett DBA-team.

Fallstudie från Spotify
När Per Eckerdal och Mattias Björnheden från Spotify beskrev sina problem och lösningen på dessa, så var det nästan exakt en fallstudie av problemen med många lager.
Tidigare byggde alla olika Spotify klienter på en stor gemensam kodbas med adapters för respektive klient.
Om någon som jobbade med spellistor ville göra en ändring tvingades man be teamet som jobbade med den gemensamma kodbasen,
om att göra ändringen. På grund av prioriteringar kunde detta dra ut på tiden och bli en flaskhals, som gjorde att nya features tog lång tid att utveckla färdigt.

Det man nu gör annorlunda är att alla team jobbar mera featureorienterat i vertikala skivor snarare än horisontella lager.
T ex kan ett team jobba med spellistor och då ha hela ansvaret för både utveckling och testning av denna domän för alla plattformar.
Teamen är då mindre beroende av varandra och flaskhalsarna undviks.
Noterbara följder av detta sätt att arbeta är att man har:

• En hel del duplicerad kod, då man inte har någon kanonisk representation av domänklasser som används i flera team, t ex “Artist”, “Spår”.
• Mer färdigaggregerat data från backend, då man kan optimera mer för en specifik frågeställning.
• Klienter som är tunnare, med färre lager och är mer av dumma dataförmedlare.

Micro Service-Arkitekturer
Fred George beskrev ett rätt radikalt sätt att bygga system på. Det är motsatsen till monolitiska enterprise applikationer. Faktum är att Fred menar att “applikation” överhuvudtaget är en dålig konceptualisering.
Han bygger mikrotjänster som:

• Är löst kopplade.
• Är pyttesmå – ofta bara några hundra rader kod.
• Är jättemånga – > 100 st
• Är självmonitorerande – Rapporterar själva när de inte fungerar och tas då ur drift.
• Ofta kan leva i flera versioner samtidigt
• Publicerar “intressanta grejer” på en meddelandebuss. Även om ingen just då ber om det. Andra tjänster lyssnar och reagerar om det kommer nåt på bussen som de bryr sig om.

Eftersom tjänsterna var så små och enkla i sig, så slängdes de ofta bort. Det gjorde det lätt att experimentera, valet av tekniker blev inte så viktigt. Om något inte funkade gick det snabbt att göra om.
Till och med var det så att man ibland inte ens brydde sig om att stänga ner tjänster som inte användes längre.

Jag rekommenderar varmt att kolla in videon när den kommer upp inom kort.