GOTOconf Copenhagen 2016, dag 2

Jag har varit på GOTO i Köpenhamn i dagarna två och sitter nu på hotellrummet i väntan på morgondagens tåg hem. Tänkte som vanligt när jag varit på konferens dela lite minnesanteckningar och reflektioner...

Dag 2

Keynote: Small Is Beautiful - Kevlin Henney

Vi värderar möjligheten att slänga bort saker för lågt. 

Han pratade mycket om hur projektstorlek påverkar storleken på produkten som blir utvecklad (utan att det levereras ett större värde). Att när man tänker stort och börjar lägga till sätt att hantera komplexitet för problem som borde vara enkla. Även om FizzBuzz Enterprise Edition är på skämt så är det ofta som våra lösningar innehåller mer komplexitetshantering än problemlösning.

Disrupting Development using Reactive Event Sourced Systems - Jan Ypma

Visade hur de hade börjat använda eventsourcing som en väg för att trassla sig ur sina tillväxtproblem. 

Han hade en slide med krav på en fristående komponent. 

1) Inga utgående förfrågningar när man hanterar en inkommande (om databasen inte kan accessas utifrån kan den betraktas som intern i systemet).

2) Ingen single-point-of-failure.

3) Designen skall med triviala medel skala till minst 10x förväntat last, tex genom att dra i en slider på Amazon.

Den sista handlar om att om inte du kan hantera ökningen av last så skjuter du över problemet på någon annan och då är du per definition inte längre fristående. 

Microservices: A utopian mystery - Praveena Fernandes

Plockade 10 punkter ur ett projekt som hon varit i. Kanske inte så unika i sig själv men kopplat mot caset ändå intressanta med hur resonemangen gått och vad som hände när de gjorde på ett annat sätt. 

Educating the builders of tomorrow with science and technology skills using LEGO® Education WeDo 2.0 - Hanne Hylleberg Ravn, Flemming Bjørn Jessen

Jag kanske inte förstod det pedagogiska men kändes som en lång reklamfilm. 

Reclaim the stack: Why cross-functional teams build better microservices - Peter-Gillard Moss

Här hade jag en stund av koma och hade svårt att hålla mig vaken så min bedömning kanske inte är helt klar... men känslan var att det handlade mycket mer om teams än microservices. Inga noteringar.

Distributed - of Systems and Teams - Bridget Kromhout

Poängen gick mig helt förbi. Diverse anektoter men jag fick inget sammanhang eller idé om att det ledde åt något håll och gick därifrån undrande över vad jag sett. 

Sammanfattning av konferensen

Jag är på det stora lite besviken och tycker kanske inte att det konferensens fel i sig själv utan att jag kanske kunde läst på lite mer om vad talarna faktiskt skulle prata om. Jag hade hoppats på lite mer teknik och kanske lite mindre av team-building. Kanske lite mindre conways-law och mer kod. Det som var roligast för mig var fallstudierna med deras förväntningar och utfall. 

I sig själv var konferensen väl utformad med utställning, mat och dryck. Schemat höll och det kändes allt rullade på enligt plan. De flesta föreläsarna verkade vara kunniga i sina respektive ämne och ingen var helt borttappad på scenen. En detalj som de kanske hade kunnat utöka var möjligheten att ladda sina bärbara enheter där de hade små bås som kunde sitta i och till vilka ström var framdraget. 

Så, jag åker nog inte dit igen 2017. Det var för lite som när jag faktiskt skulle välja nästa föreläsning som faktiskt lockade mig. Men det kanske var lika mycket mitt fel. 

GOTOconf Copenhagen 2016, dag 1

Jag har varit på GOTO i Köpenhamn i dagarna två och sitter nu på hotellrummet i väntan på morgondagens tåg hem. Tänkte som vanligt när jag varit på konferens dela lite minnesanteckningar och reflektioner...


Dag 1


Öppning och Agile 2016 med Dan North
Outcomes creates options, om att faktiskt komma till leverans. Det är inte förrän folk faktiskt arbetar med en funktion som de bra idéerna om hur funktionen skall förbättras kommer.

Mycket Agil historia och ett något modifierat agilt manifesto med förflyttning mot hela tiden, i stället för regelbundet...

Han slog hårt mot kommersialisering av agila begrepp. Det finns inga agila arbetssätt, man är agil, följer inte en agil plan. Scrum-certifiering är världens största ponzi-bedrägeri.


The comming machine revoluition, Raffaello d'Andrea

Man har sett hans videos på nätet sedan tidigare med drönare som flyger synkroniserat, spelar pingis m.m. Berättade inte så mycket om hur det fungerade. 

Avslutade med att prata med faran som maskinerna utgör för människan nu när de blir smartare och smartare. Han är inte orolig alls för terminiator. Mer konkret däremot är han rädd att vi kopplar ihop system allt mer vilket kan ge upphov till ganska katastrofala feedback-loopar (ni som vet vad som kan hända om blixen slår ner i ett ställverk har en liten föraning om hur stor en sådan kaskad kan utveckla sig).

Monolithic batch goes microservice streaming – story about one transformation,
Anton Polyakov, Charles Tye

Visade hur de i ett projekt gått från relationsdatabas till eventsourcing för att lösa en applikation som testade de två senaste årens förändringar på en dags transaktioner... många nollor på antalet beräkningar som skulle göras.
Det stora de visade var att de använde en ramminnesdatabas för att utföra aggregeringar på stora datamängder. Man kan väl säga att det går att få in mycket data i ram nu för tiden.
Citat:
Building an app alongside the old one is an antipattern.
Turning spagetti to spagetti with a meatball. (om Microservices)

When DevOps Meets Regulation: Integrating 'Continuous' with 'Government', Jez Humble

Om de overthere kan sätta ihop ett team som kan ta fram gemensamma lösningar för flera myndigheter tänker man att hoppet kanske inte är helt förlorat här hemma heller. Mycket amerikansk förvaltning vilket kanske var intressant om man ska flytta dit. Sömnpiller för mig.

Cloud.gov 

Building an effective delivery culture, Stephen Foreshew-Cain

I stort sett samma samma som förra fast i Storbrittannien där han byggt en medborgarportal som väg in till ett stort antal myndigheter. GDS, ett kompetenscenter för myndigheter.

Exploring StackOverflow data - Evelina Gabasova

Här hade jag förväntat mig lite mer teknik om hur hon gjorde analyserna. Att det går ett bakgrundsjobb i F# som kan skanna av första raden i filer m.m. kändes inte så imponerande som hon ville göra gällande, men visst, det var en juste genväg. 

"Om du kan trycka in det i ram är det inte ett bigdata problem". Och stackoverflow fick hon inte i i minnet på sin bärbara, men den stationära hemma gick det bra.

Panel Discussion: The future of Robotics - Wouter Kuijpers, Dan North, Gregory Pelcha, Jørn Larsen, Marjon van ‘t Klooster

Här kändes det väldigt oförberett och närmast lite taffligt. Blev ingen diskussion. Fick svar på min fråga om vad som ligger runt hörnet för mig som vanlig människa (robotdammsugare och robotgräsklippare ganska vanliga inslag numera). Svaret var att jag förmodligen kommer att äta robot-stekt hamburgare på McDonalds. 

JavaScript, the Cloud and the Rise of the New Virtual Machine - Scott Hanselman

De här två dagarnas bästa framträdande, en ståuppshow på it-tema. Visste inte att Scott var rolig. Vet inte om jag fick med mig några lärdomar dock. 

Ändra databasstruktur under drift

Här kommer en liten programmeringsövning till. Denna syftar på att använda mönster som låter dig ändra ditt system under drift.

Förberedelse:
1) Sätt upp en rest-tjänst som tar emot ett objekt (tex en postadress) och sparar denna i en databas.
2) Sätt upp en resttjänst som listar de 10 senaste adresserna ur databasen.
3) Skriv en liten applikation som skickar en en random adress och sedan listar de 10 sista adresserna, varje sekund så länge applikationen är igång.

Övningen:
Utan att störa din applikationen som skickar in och listar data (den ska ticka in en adress varje sekund medans övningen pågår), migrera databasformatet, tex slå ihop två fält som sparades som ett tidigare, eller dela informationen till två fält. Ändringen ska inte påverka informationen som går ut i rest-tjänsten.

Denna artikel kanske kan vara till hjälp, men det finns säkerligen fler sätt att lösa det på.

En enkel övning

Den här övningen går ut på att implementera kraven i den ordning som de anges, utan att ta hänsyn till de krav som kommer senare. Du ska alltså inte implementera som om kände till samtliga krav från början utan bara ett krav i taget och sedan anpassa lösningen för varje nytt krav.

Du kan naturligtvis innan du börjar, sätta ramar för hur du implementerar, tex om ditt data ska vara på normalform eller någon form av blobbar. Övningen görs med fördel flera gånger, där du kan ställa upp olika ramar för den implementation du tänker göra för att sedan jämföra resultaten.

Du kan välja vilket gränssnitt du vill mot dessa krav, men tipset är att lägga minimalt med tid på gränssnittet och i fokusera på kraven i första hand. Unittester räcker väldigt långt.

Krav 1:
Implementera en enkel shoppingkorg. Du ska kunna lägga till en vara, ta bort en vara och lista varorna i korgen.

Krav 2:
Du ska kunna summera priserna på varorna i korgen. Du ska också kunna markera korgen som "klar", alltså markera att korgen har avslutats och inte längre kommer att uppdateras.

Krav 3:
För en given tidsrymd, beräkna den den mest sålda varan, både till antal och pris.

Krav 4:
En kundkorg anses vara övergiven om den inte har uppdaterats på två timmar. För en given tidsrymd, beräkna totalt värde på de övergivna kundkorgarna.

Krav 5:
Beräkna värdet på den vara som till antalet plockats in i varukorgen och sedan tagits bort ur varukorgen, alltså produkter som kunden visat intresse av men sedan aktivt valt bort (som extra krav skilj på avslutade och övergivna korgar)

Krav 6:
Om en kund har lagt 3 stycken av en vara i kundkorgen, ta bara betalt för två i prisberäkningen.

Krav 7:
Ge 50% på den billigaste varan om värdet på korgen överstiger 1000 kr.

Krav 8:
Ge 10% rabatt på dagens mest sålda vara om den sålts för mer än 1000 kr (när varan läggs i korgen).

Krav 9:
Ge 10% rabatt om det totala försäljningsvärdet före rabatter under innevarande timme överstiger 10000. Rabatten skall upphöra om ny timme påbörjats.

Som variant och överkurs kan du för varje krav skapa upp någon/några miljoner med varukorgar och sedan kräva att varje operation ska vara snabbare än 10 ms.

Man kan också göra övningen så att man tar höjd för alla kraven men stannar efter att man gjort några stycken. Är designen onödigt komplicerad och har du blivit sinkad jämför med den lösning de skulle ha gjort för en mindre uppsättning av krav? Kan du göra lösningen bra utifrån färre krav utan att det blir jobbigt sen?

Öva agila lösningmönster

När man får ett krav kan man implementera det eller så spenderar man en stund med att fantisera om vad som kan bli framtid krav. Ta tex en enkel shoppingkorg på en ehandelssida byggd på två tabeller, korg och varor där korgen innehåller information om vem som "äger" korgen. Korgen innehåller varor. Men när säljavdelningen kommer och säger att de vill veta vilka varor som kunden lagt i korgen men tagit bort innan köp kommer valet att implementera varukorgen med två tabeller kanske framstå som naivt och kortsiktigt.

Nu kan man förstås inte frångå kraven som ställts utifrån att man har en livlig fantasi där man kan föreställa sig ett antal framtida krav. Men det kan man göra är att känna till ett antal lösningsmönster och vilka vinster och förluster man gör med respektive lösning. Om man övat på dessa mönster kanske man ibland kan använda de lösningar som ger bäst möjligheter att hantera framtiden, vad den den nu kan tänkas ge oss.

I skrivande stund har jag två axlar som man kan variera sina övningar runt. Strukturerad/flexibel och stömmande/snapshot. Strukturerad/flexibel är mest utforskad inom programmeringsspråken där diskussionerna om dynamiska och statiska språk pågått länge. Diskussionen finns även i databasvärlden, då främst i konflikten mellan Nosql och relationsdatabaser.

Strömmande lösningar, tex genom eventsourcing syftar till att följa en ström av händelser och sedan agera på dessa, beroende på hur man väljer att bygga kan man återspela händelserna och agera på ett annat sätt då eller så är händelserna flyktiga. En snapshot-lösning håller ett tillstånd i systemet och uppdaterar detta tillstånd.

Ett mer traditionellt system lutar ganska tungt åt att vara strukturerat och av snapshot-karaktär. Man definierar typer och lagrar i tabeller i relationsdatabaser. I alla fall för mig är det mönstret jag kan och där jag känner till vägarna runt många många problem numera. Men som vi känner till finns det ibland godis i dynamiskta och strömmande lösningar men för att kunna komma åt det goda måste man öva, precis som vi gjort i många år med den traditionella lösningen.

Ett case till på immutability

Detta kanske är något krystat, men när jag gjorde det slogs jag av att det sättet jag gjorde det på åtminstone påminde om principer runt immutable infrastructure. Ja, inte i alla delar, men det påminde om...

Vad gjorde jag? Jo, jag bytte ut min gamla router mot en ny. Detta utan att någon tjänst stod still mer än några sekunder och med möjlighet att rulla tillbaka föregående steg.

Så hur gjorde jag detta då? Eller låt oss först börja med varför jag valde att göra på detta sätt. Svaret på den frågan är att jag inte kommit åt administrationsgränsnittet på den gamla routern på flera år då gränssnittet bara fungerar IE7 som var typ antikt när jag köpte routern. Alltså kände jag att det fanns en risk att jag kanske bara skulle kunna några tjänster till den nya routern och låta någon eller några få ligga kvar tills jag klurat ut vad jag behöver göra ytterligare.

Så, hur gjorde jag...

Steg 1
Koppla in den nya routern till ström (duh) och kolla att alla inställningar med portnummerserie m.m är vad jag förväntar mig. Aktivera trådlösa nätverk.

Steg 2
Koppla in den nya routern som slav bakom den gamla så att den nya når internet genom den gamla via sladd.

Steg 3
Kontrollera att den nya routern når internet och flytta över de trådlösa enheterna som jag telefoner, chromecast, skrivare och bärbara datorer så att de når internet (och varandra) till den nya routern.

Steg 4
Här är steget jag var mest orolig över att jag inte hade koll på vilken information som faktiskt gällde. Men jag satte upp port forwards mot det fasta ip-nummer som min server skulle få i det nya nätet. Flyttade sladden från den gamla routern till den nya och bytte ip-nummer på servern.

Tekniskt blev det två steg i ett. Hade jag vetat hur man gjorde hade jag föredragit att ip-numret hade varit orört så att jag kunna flytta sladden mellan routrarna utan att behöva ändra något på servern. Men riktigt så bra blev det inte.

Steg 5
Fram med skruvdragare och skruva upp den nya routern. Naturligtvis förbannar man att man var duktig och buntade upp saker snyggt förra gången eftersom alla sladdar är på fel ställe, för korta etc etc.

Steg 6
Flytta internetet från den gamla routern till den nya då inga tjänster längre antas gå vi den gamla routern.

Så, i princip (om än inte helt) så gick varje steg i processen att backa till det föregående. Tjänsterna var inte helt ovetandes om att de flyttats men brydde sig väldigt lite om vilken router som de faktiskt använde. Dessutom var båda routrarna igång samtidigt utan att ställa det för varandra vilket torde vara det mest centrala kravet för att kunna räknas som en immutable leverans.

Bara en liten notering ur verkligheten.

Ett case på immutability

Jag sitter och pillar med en presentation som jag eventuellt ska hålla någon gång i framtiden. Kanske skulle våga mig på att spela in den här gången.

Till denna presentation behöver jag ett case på hur en applikation kan utvecklas om man tar Open/Closed-principle lite mer på allvar.

Steg 1
En entitet, Person. Fälten id och namn.
En tjänst, PersonRepository. Fem metoder, create, read, update, delete och list100AfterId. De fyra första slänger en händelse, PersonUpdated. Sparar data i en relationsdatabas, tabellen Person.
Vi produktionsätter.

Steg 2
Vi upptäcker en brist i PersonEntiteten, det borde vara separata fält för förnamn och efternamn. För att inte förstöra för alla klienter till PersonRepository väljer vi att skapa en ny entitet, Person2 och ett nytt repository Person2Repository som sparar i tabellen Person2. Person2Repository använder list100AfterId från PersonRepository för att synka upp existerande data. För att fortsätta vara i sync lyssnar p2r även på PersonUpdated-händelsen.
Vi produktionsätter, allt fortsätter att fungera som tidigare. Vi kan bekräfta att den nya tjänsten fungerar som den ska och successivt skriva om klienter från den gamla tjänsten till den nya.

Steg 3
Ett behov av att kunna söka efter personer har identifierats. Då vi inte vill förändra i Person2Repository då det också skulle kräva ändringar hos tjänstens klienter väljer vi att skapa en PersonSök-tjänst.
PersonSök använder list100AfterId för att bygga upp ett index (Lucene, Elasticsearch, egen tabell i databasen eller något annat). Vi väljer att inte smälta ihop PersonRepository och PersonSok genom att integrera dessa i databasen. PersonSok lämnar alltid en lista av PersonId som svar på en sökning.
Vi produktionsätter. Det gamla rullar på, det nya kan verifieras och klienter kan snart börja använda.

Steg 4
Vi ska en tid senare implementera en tjänst som kan hitta personer som är nära dig. Vi kallar den för NäraDig. NäraDig använder sig av PersonSök7 som låter dig söka på fälten senastKändaPosition och returnera PersonId sorterat på tidFörSenastKändaPosition. Efter sökning hämtas Person-objekt från Person14Repostitory. Eftersom sök-tjänsten kan returnera många svar är vi oroliga för om Person14Repository orkar med den förväntade lasten. Därför implementerar vi olika anrops-scheman, ett anrop i taget, x synkrona anrop i taget och alla anrop på en gång. Vi implementerar en feature-toggle för att kunna ändra schema utan att behöva stoppa några tjänster.

Steg 5
Det visar sig att Person14Repository inte har tillräckligt goda prestanda för att NäraDig ska kunna användas och att kundnyttan är för dålig om man begränsar antalet personer som man hämtar information om. Man väljer att öka prestanda i PersonRepository.
I p15r byter man databas, egenskapen man söker är att man kan öka prestanda genom att lägga till fler noder av databasen. Man skriver dessutom om så att alla anrop till metoden read hanteras asynkront så att en instans av p15r kan hantera flera hundra tusen samtidiga anrop till read-metoden.

Steg 6
Person har nu efter ett antal "förändringar" blivit en trång punkt. Man väljer att lägga till nya fält för ofta, vilket leder till att övriga delar av systemet måste följa med (och synkronisering över flera versioner över lång tid är pita). Inom Person-entiten identifieras ett flertal objekt, namn, adresser, telefonnummer, epost, positioner, arbetsplatser etc, etc. Så nu har vi en mängd med entiteter med lika många repositories.

Steg 7
Det visar sig att förändringarna i steg 6 blir dyra att implementera då varje klient behöver skriva om all funktionalitet som berör Person till att hantera en mängd nya objekt. Så vi inför en ny tjänst, PersonAggregat. PersonAggregat samlar ihop all information om en Person som vi bröt isär i steg 6. Klienterna kan nu välja att bygga sina egna Person-objekt eller använda det färdigbyggda aggregatet.

Steg 8
Verksamheten vill kunna ta ut rapporter från det data som systemet innehåller, men har noterat att vi har minst tre datakällor, den vanliga databasen, PersonDatabasen som egentligen är 10 databaser och sökindexet, vilket ställer till det för det valda rapportverktyget. Vi tar fram en datamodell och använder list100AfterId-metoderna för att fylla en rapporteringsdatabas. Uppsidan blir att man kan köra så mycket rapporter man önskar utan att störa produktionssystemen.

Det jag tycker är intressant i dessa steg är att de aldrig kräver att klienterna måste vara klara att använda det nya. Det problemet blir en administrativ fråga där man får väga problemet med att synkronisera datakällor mot att kunna gå frammåt.

Att vi helt undviker att utföra joins i databasen och i stället väljer att ha en aggregat-tjänst som gör joinen mycket senare och som tillåter underliggande struktur att förändras är också värt att notera.

Detta är bara ett hypotetiskt case. Många frågor måste lösas. Tex om vi har flera versioner av en tabell, vilken är sanningen och hur upprätthåller man den? Eller hur ska händelser propageras på ett rimligt sätt?

JFokus 2016

Jag var på JFokus 2016 och här kommer mina anteckningar och lite allmänna kommentarer. Jag gör ingen ansats att fylla ut anteckningarna till en ordentlig text, så ta det för vad det är, anteckningar.

Måndag

Chris Richardson - Introduction to microservices.

http://microservices.io

http://eventuate.io

http://plainoldobjects.com

Elefanten och ryttaren, om hur vår hjärna fungerar.

The art of scalabiliy, bok

Det är olyckligt att de kända exemplen på microservices främst handlar om high-scalability.

Fred George, testning in production.

Microservices kräver agile och devops...

Antipatterns:
*Nano-service
*Distributed monolith

Aron Gupta - Docker & Kubernetes 

Inga anteckningar

Tisdag

Brian Goetz - Keynote

Java 10, immutable var det stora nya.

Holly Cummins -  Microservices: dream to reality

Don't unless you have devops.

Petter Måhlen - Modelling microservices at Spotify

Squad äger en "funktion" från DB till Gui.

System Z för att hålla ordning metadata

Scaling of the team drives microservices more than perforamace?

Bert Ertman - Microservices for mortals

Var inte naiv, du måste först vad du gör.

Ivar Grinstad - SnoopEE

SnoopEE kanske kan vara något för min nuvarande kund.

Kristoffer Erlandsson - Fault tolerant microservices

Relase it

Hystrix

Circuit breakers

Bulkheads

Har du inga nätverksproblem, mäter du fel.

Kathrine Stanley -Testning microservices

Inga anteckningar

Onsdag

Tim Berglund - Git from the bits and up. 

Läs Beowulf

Barush Sadogursky - Docker container lifecycles

Every plays with docker but noone gets to production

Docker images is just another artifakt, like jar-files.

The promotion pyramid. The promotion pipeline. Quality gates.

Build only once, including the Docker packaging. Only once. Only once, only once.

Arifactory metadata kan användas för att visa vilka qualitygates som passerats och dess resultat.

Rafael Winterhalter - Making java more dynamic

Använd agenter i stället för ramverk. Skriv plain old java applikations instead of EE, spring etc.

Bytebuddy

Manuel Bernhart - Reactive web applikation

(inga anteckningar)

Markus Esiele - CI Docker and JEE

Fabric8 kanske kan vara skoj om man vill gå redhat.

Sammanfattning

Devops är förutsättningen för microservices. Med egen drift eller molnet spelar ingen roll. Applikationsdriften sköts av utvecklingsteamet.

CD som en del av devops är förutsättning för microservices.

När du har CD och devops på plats, kan du börja med microservices.

Storleken på utvecklingsteamen driver Microservices lika mycket som prestanda.

Kunskap är viktigt, microservices kräver kunskap så att verkligen vara engagerad i ämnet är viktigt. Akta sig för hypen. Även om det finns verktyg så måste du känna till begränsningarna och fallgroparna.

Lite synd om Holly Cummins vars dator inte fungerade. Arun Gupta kändes trött och oinspirerad jämfört med vad jag sett tidigare.

En agil mjukvaruarkitektur

En agil mjukvaruutveckling brukar beskrivas som att man låter programvaran växa genom evolution i stället för genom en förutbestämd plan. Man hävdar alltså (korrekt) att det är svårt att i förväg förstå vilka konsekvenser beslut om en applikation får, förrän man faktiskt upplever hur det fungerar i "verkligheten", alltså när det är implementerat och klart.

Så, om du är agil så ska du göra fel, ändra, se att det fortfarande inte är bra och ändra igen. När du är klar med detta så ska du välkomna förändrade krav. Men i de projekt jag har jobbat i har man ansett att en utforskande ansats är för dyr, eftersom det är svårt att förändra när saker väl blivit skrivna. När kraven förändras väljer man ta långa omvägar för att det är så svårt att ändra i det man redan har. Med andra ord väljer man bort ett agilt förhållningssätt och lägger stor möda på att försöka att göra rätt på första försöket.

Jag ska nedan försöka beskriva några mönster och dess möjlighet till att göra det lättare att arbeta agilt. Dessa mönster kommer inte gratis på något sätt. Man kan se det lite som att med dessa mönster hoppas man på en komplexitetsökning som ser ut som O(log n) där den traditionella modellen något elakt skulle efterlikna O(n*n) (n i kvadrat alltså). Dock så börjar den agila modellen med en mycket större insats i kunskap och stödjande tjänster för att inte leda till katastrofens rand. Vet du inte vad du gör är det läge att låta bli och inte härma de som faktiskt vet vad de gör och varför.

Microservices
Med microservices väljer man att dela upp sin applikation i många små fristående delar i stället för en. Varje microservice blir simpel men man blir inte av med komplexiteten, utan den flyttar ut i nätverket där man hoppas att den ska gå och hantera på ett bättre sätt. Microservices stödjer det agila arbetssättet genom att du kan byta ut en microservices relativt enkelt utan att påverka resten av systemet och du är fri att ta beslut om hur din microservices ska fungera internt utan hänsyn till hur de andra är implementerade, kanske byta till ett mer lämpat programmeringsspråk, uppgradera bibliotek etc etc.

Prestanda brukar vara den brukar beskrivas som  drivkraften för microservices, men jag skulle hävda att möjligheten till att olika utvecklingsteam kan arbeta utan att påverka varandra är mycket starkare i normalfallet (Amazon och Netflix är inte normalfall)

Eventsourcing
Med eventsourcing sparar du ditt data utifrån vilka förändringar som har gjorts i systemet (verben) i stället för att lagra entiteter (substantiven). Man kan jämföra med en läkare som har sparat din journal (med alla undersökningar, prover och anteckningar) och använder den som grund för att ställa diagnos och väljer att inte ordinera jordnötter eftersom det står att du är allergisk i journalen till motsats till en akutläkare som ser att blodet sprutar och får utgå från det hen kan se just nu.

Med eventsourcing har du inte en modell utan snarare en modell per händelse och en modell per slutsats eller rapport du önskar skapa från dina händelser, även om du naturligtvis kan ha en övergripande modell någonstans i bakgrunden. Flera modeller gör det svårare att hitta hur ett enskilt attribut kom till världen men som å andra sidan gör att du kan anpassa dina modeller efter olika behov i stället för att anpassa behovet efter modellen. Attribut som tex rubrikfärg har jag sett många gånger krypa in i tex en person-entitet eller telefonnummer-entitet där man kanske hade varit mer betjänt av att ha en modell över presentations-stöd och en annan över domän-information. Så i stället för att ha en modell där en förändring påverkar all annan funktionalitet väljer man att kunna förändra en funktions modell separat från de andra. Notera att detta kan innebära en hel del dubbellagring av data och synkronisering av detta data måste ske på ett kontrollerat sätt.

Immutable
Att vara immutable innebär att man aldrig modifierar sitt data, man lägger bara till ny information till systemet. Det kanske låter som lite slöseri med hårddisk men det ger en del intressanta möjligheter, främst att du får möjlighet att titta på hur ditt data såg ut vid en tidigare tidpunkt. Som extra bonus blir cachning enkelt, eftersom den information som finns där aldrig förändras (det kommer ny information naturligtvis, men de gamla värdena är orörda).

Man kan dra immutable-begreppet längre än data och ta in begreppet immutable-everywhere. I princip innebär det att du aldrig ändrar i integrationer, du skapar en ny och den gamla får leva vidare tills det är säkert att ta bort den. Du ändrar aldrig i dina installationer på dina servrar utan gör en ny och låter den gamla leva vidare tills det är säkert att ta bort den gamla. Det ger bland annat möjlighet att skapa en ny integration till en ny klient som innehåller alla de senaste funktionerna, samtidigt som övriga klienter kan fortsätta att använda den gamla tjänsten tills de är redo att uppgradera. Drar man den tanken till sin spets får varje klient sin egen tjänst och kan där med förändras oberoende av andras behov.

Även vid serverdrift, särskilt i mer eller mindre virtuella sammanhang kan man välja att skapa en ny "image" som kan driftsättas parallellt med den gamla installationen och testas om den fungerar i produktion på en delmängd av trafiken innan man "pekar om" alla användare till den nya servern.

Automatisering
Människan är ganska dålig på att utföra repetitiva uppgifter och detta leder till ett kontrollbehov, eftersom vi kort och gott inte är att lita på. Detta leder till ett behov av kontrollstrukturer som i sig själva driver behovet av fler människor som ska utföra alla kontroller och i sin tur kontrolleras och ingen tillför värde för användaren av systemet (åtminstone inte direkt).

Vägen ut ur detta är automatisering. Efter att ha kontrollerat att automaterna(?) fungerar (tex gör rätt sak vid feltillstånd) kan de släppas lösa. Eftersom du kan ha ett större förtroende för att saker och ting fungerar kommer du också våga att förändra och förbättra i dina system. Detta leder till att ditt system blir större efter som fler uppgifter behöver programmeras och underhållas.

Sammanfattning
Att vara agil är så mycket mer än att ha en iterativ process. Det handlar också om att inte bara vara en döv, stum och blind idiot för vad kraven på systemet säger idag utan även för vad de kan komma att säga i morgon och förutsätta att saker kommer att förändras. Att placerat sig i en position där man kan välkomna förändringar även sent i projektet.

De mönster jag skrivit om ovan kommer inte gratis utan är dyra, både i tid och kunskap. De löser vissa problem men för med sig många andra som du också måste förstå innan du börjar, oavsett projektstorlek. Men när du börjar få problem med att du inte längre kan anpassa ditt system snabbt och smidigt kommer du önska att du tittat på ovanstående mycket tidigare.

En ny skön värld

Ibland får man uppenbarelser, en känsla av att man förstått något och nu vet hur en aspekt av världen fungerar och varför det är som det är. Allt är självklart och nu är det dags att agera och inte svamla något om kanske och eventuellt.

Professionellt som programmerare är det ganska långt mellan varven som jag upplevt detta men nu de sista 1-2 åren har det hänt ganska ofta. Begrepp som
* händelsebaserat
* immutable
* functional
* reactive
* single responsibility
* continious delivery
* micro services
har allt gått som en blixtar genom mitt huvud.

Det är inte så att jag levt i en bunker isolerad från omvärlden. Det är inte nytt, men en förståelse för vad de faktiskt innebär och vad var de hör hemma har kommit till mig (hoppas jag i alla fall).

Den senaste blixten i allt detta är insikten att ingen av dessa är fantastisk i sig själv utan att de tillsammans bildar en helhet. En ganska radikalt annorlunda helhet än den vi är vana med men ändå en helhet som tar sin utgångspunkt i reaktion. Detta kanske motställt till den traditionella modellen som åtminstone i praktiken fokuserar på planering och förutsägelse.