Før jul dro Jan-Helge, Frode og Joseph på O’Reilly Software Architecture Conference i Berlin. Bli med når Jan-Helge deler erfaringer fra, som han selv sier, en strålende og profesjonell konferanse.
Dette er del 2, med detaljer fra sesjonene han var på. Les også gjerne del 1: O’Reilly Software Architecture Berlin 2019 – Takeaways
Sesjonsdetaljer
Technical debt hurts: How to recognize and eliminate it (Carola Lilienthal)
Dette var en god sesjon rundt både det å evaluere “arkitekturråte” ut i fra statisk kodeanalyse, men også hvordan man kan avdekke slitasje i (og av) organisasjonen som omgir/bærer arkitekturen basert på dialogene rundt disse metrikkene.
Talken er basert rundt Carolas bok “Sustainable Software Architecture” som virker litt parallel til “Evolutionary Architectures”, kanskje bare hvordan man skal håndtere det når det først går gærnt.
Ut fra denne boken var hun innom det hun kaller “The Crap Cycle” (Create, Refactor, Abandon, rePlace), illustrert på denne siden.
Her er det to “korridorer” for refaktoring, der man aller helst skal være i den nedre der alt er “billig”, men der de fleste baler rundt i den øvre og gjerne er på grensen til “Abandon”.
Siden jeg lenket til over viser også en figur som mapper elementer fra kognitiv vitenskap opp mot gode arkitekturprinsipper/-mønstre.
Hun hadde noen veldig gode poenger rundt verdien i det å ha en sterk arkitektur review-funksjon, da det jo er mye enklere å sette seg inn i andre sine “ting” om de ligner på dine egne “ting”.
Karakter: Veldig lærerikt: Oppovertommel!
Serverless containers: Nodeless Kubernetes and vertical pod autoscaling (Pavel Klushin @ Spotinst)
Dette viste seg vel å være en salgspitch, dessverre.
Problemet i seg selv er jo ganske interessant;
Premiss: alle tilbydere av skytjenester har overkapasitet der man kan kjøpe spot-instanser med nær ingen SLA (bortsett fra at man får en “best effort” event noen minutter før spot-instansen forsvinner).
Disse folkene har en tjeneste som fungerer som en megler på dette og bruker dette overkapasiteten til å skalere dine Kubernetes-kluster opp og ned.
De fungerer etter sigende både på AWS, Azure m.fl.
Konfigurasjon skjedde her ved hjelp av labels på Kubernetes-PODene.
Problemet med deres modell (i mine øyne) er at det er opp til deg som kunde å ha et kundeforhold til hver tilbyder samt gi disse gutta dine tokens/credentials slik at de kan operere på dine vegne.
Jeg hadde vel satt mye mer pris på å kunne sagt;
Jeg har X jern in-house, gi meg en Y faste skyjern med minimum Z spot-instanser klare for skalering.
Karakter: Levde ikke helt opp til abstract, skulle gjerne heller vært på Beyond the technical: Succeed at leading a software architecture team :-/
Modern machine learning architectures: Data and hardware and platform, oh my (Brian Sletten)
Noen gode betraktninger rundt AI + ML og hardware-evolusjonen, opp mot skyteknologier.
Fin knytning mellom kostnad og CO2-utslipp, med tanke på hardware som løsningen din trenger.
Litt artige tall rundt det å bruke for eksempel TensorFlow i browseren med og uten hardware-aksellerasjon.
Karakter: Interessant nok, men ikke nødvendigvis veldig nytt?
Next data platform architecture: Distributed data mesh (Zamak Dehgani)
Her pirkes det litt i hvordan hype og buzzword innsalg av teknologier fremdeles blir gjort og hvorfor de feiler.
“Alle” må jo ha en DataLake og et knippe Data Scientists, sant?
Build it and they will come?
Dette stemmer jo sjeldent, så det Zamak forfekter er å kanskje se på data som et (Enterprise) internt produkt og bruke litt lean metodikk for å utvikle selvbetjeningsløsninger og gjerne MVP-er.
I tillegg så hadde hun et element av at det kanskje er lurt å holde data domenesentrisk, og ikke smøre alt sammen i “Lake-en”.
Har litt på følelsen at ThoughtWorks, med denne talken, tester litt markedet for utvikling av verktøy for akkurat dette . Vi får se.
Karakter: Ikke så dumt, men var det produkt-pitch? Skuldertrekk.
The New Norms of Cloud Native (Cheryl Hung)
Cheryl er “Directory of Ecosystems” hos Cloud Native Foundation.
Denne talken var en god introduksjon og oppsummering på hva CNF er, hvordan de jobber og hva som skal til for å “komme inn i varmen”.
En god del presisering på hva CNF i hvert fall ikke er eller driver med (de er ikke produkteiere og de driver ikke med konsultering).
Karakter: Lærerikt: Oppovertommel!
Living in the first derivative: Architecting for velocity (Gregor Hohpe)
Gregor her har en blogg med noen interessante artikler på.
I denne talken så forsøkte han å fokusere på hva som kan gjøres for å øke leveransehastigheten, utover det som “alle” gjør (Agile utvikling, DevOps, Continuous Delivery etc).
Det gikk litt i “refaktoring av organisasjon”, egentlig.
Et artig sitat fra sesjonen:
Technical Debt is what ever slows you down — it may be software or it may be fleshware
Karakter: Interessant og livlig fyr. Oppovertommel!
7 years of domain-driven design: Tackling complexity in large-scale marketing systems (Vladik Khononov)
Til tross for litt stotrende engelsk så var dette et ganske fornøyelig foredrag, som burde resonnere hos alle som har vært involvert i DDD på et eller annet tidspunkt.
I hvert fall om det var DDD med Event Sourcing!
Vladik tok oss med på utviklings historikken til et system for booking av reklamekampanjer og alle feil stegene de gikk igjennom.
Det kan vel med sikkerhet sies at de var igjennom flere CRAP-sykluser!
I konklusjon så hadde han et ganske tosidig syn på “den blå boka” fra Eric Evans (d.v.s “Doman-Driven Design”), der han på den ene siden ikke kunne hylle den nok og på den andre siden kanskje tenkte at det var veldig feil bok å lese som første DDD-bok.
De forsøkte nemlig visstnok å implementere i henhold til boken.
Det ble en passelig Big Ball of Mud, men de kom seg ut av det.
Karakter: Akkurat slik en “How NOT To” erfaringsrapport skal være: Oppovertommel!
Cultivating architecture with principles (Birgitta Boeckeler)
Dette foredraget sirklet i bunn og grunn rundt håndtering av distribuerte team og hvordan man kan få til en uniform og sammenhengende (“uniform and cohesive”) arkitektur og unngå at det glir ut i anarki og kaos.
Kjernen som jeg fikk tak i var å heller gå for guiding mer enn kontroll, for governance av desentraliserte (og autonome) teams (med referanse til Westrum Organizational Culture).
Jeg likte godt at hun bygget det på grunnsteiner fra TOGAF og blandet inn litt psykologi og kognitiv vitenskap for å implementere ledelse og governance.
I bunnen har man forretningens bekymringer (concerns) som krystalliserer seg i arkitekturprinsipper.
Disse prinsippene blir igjen destillert til guidelines, patterns, “best practises” og standard verktøyvalg.
Men for å unngå at man får en “elfenbenstårn-effekt”, så er det viktig at prinsippene pares med rasjonaler.
Her pekte hun på f.eks John Lewis IT sin prinsippkatalog som en inspirasjonskilde.
En annen interessant tanke var å også ha en “Radar” for practices, over samme lest som en teknologiradar.
En ganske kul teknikk hun var innom, som var lånt i fra prosjektplanlegging, er Trade-off sliders for å vekte -ilities (kvaliteter) for å finne ut hva forretningen synes er viktig.
For distribuerte/autonome team så forfektet hun også per-team beslutningslogg som en viktig ting.
Beslutningslogger er jo et kjent begrep fra for eksempel TOGAF, men her er det trukket inn i design og team-metodikk mer enn for arkitektur.
I samme farten nevnte hun også RFC-bruken (fra Sound Cloud, se foredrag fra Patric Kua).
Karakter: Veldig interessant selv om man ikke jobber med distribuerte team: Oppovertommel!
Dynamic service meshes for microservices using Envoy proxy, Java, and Spring (Michael Hartle)
Her gikk det i runtime kontroll av Envoy via Java. Lurer litt på om han var ute etter å få med seg folk for implementasjon?
Det mest nyttige jeg fikk ut av dette var en sidekommentar der det ble nevnt at “service mesh control planes” kanskje var på vei inn i CNF som et standard API.
P.t. så virker det som om de fleste service mesh implementasjoner kontrolleres via pod-labels.
Karakter: Midt på tréet, men greit som en lett start på dagen.
Rethinking enterprise architecture for DevOps, Agile, and cloud native organizations (Michael Coté)
Artig start på foredraget;
Vi har byttet rom! Og hvis ordene “Enterprise Architecture” gjør at du kaster litt opp i munnen, så er du antageligvis i feil sal!
Dette foredraget var vel en kombinasjon av hjertesukk og advarsel.
Hjertesukk i det at trenden (eller hype?) med Agile, Autonome, Micro Service-orienterte team har på en måte etablert en illusjon for seg selv om at enterprise arkitektur ikke er nødvendig.
Faktisk er kanskje ikke arkitektur nødvendig?
Michael her drar opp paralleller til byplanleggere, arkitekter og de som faktisk leverer boliger.
Hvis du ikke vet hvor strøm, kloakk, vann etc går (eller kommer til å være), så er det ganske teit å begynne å bygge et hus.
I tillegg så er det jo ganske kjekt å vite at huset du bygger overlever der det er bygget.
Litt teit å bygge en stråhytte på Hardangervidda f.eks.
I bunn og grunn så ønsker mannen at “EA Architect”-rollen bør tas mer inn i varmen igjen; det er jo ikke alle prosjekter som er green field startups og det er jo litt dust om alle må gå igjennom de samme lærdommene gang på gang!
Karakter: Gode refleksjoner: Oppovertommel!
The three-headed dog: Architecture, process, structure (Allen Holub)
God rant mye fokusert på hvor mye som har gått galt med “Agile”. “People over process” … men “SCRUM” er vel de-facto blitt en prosess, eller?
Hovedpoenget jeg fikk med meg her, er at man kan ikke jobbe smidig i bare en av sfærene (f.eks utvikling) hvis de andre er rigide (f.eks prosess, struktur, ops og arkitektur).
Alle sfærene må ha i hvert fall et snev av “inspect & adapt”-loopen; bygg tingen, inspiser det som er bygget og tilpass til neste leveranse av tingen. (“Build, Measure, Learn” i Lean Startup-sjargong).
Ellers blir det bare genererert mye frustrasjon p.g.a. all friksjonen.
Også et godt poeng at bruken av all verdens smidige metodikker og verktøy på mange måter jobber i mot det som faktisk står i manifestet!
Karakter: Underholdende, men også litt trist: Litt mindre entusiastisk oppovertommel.
Cognitive biases in the architect’s life (Birgitta Boeckeler)
Fin introduksjon til hvor lite rasjonell man egentlig er, i dagens verden der vi jobber med kompliserte systemer med høy usikkerhet.
Usikkerhet både med tanke på krav (og kvaliteten på disse), hva som kan gå feil i en sky-orientert verden og organisasjonen som er en del av leveransen.
Birgitta gikk igjennom følgende utvalg fra listen over kognitive biaser og hvordan de kan relateres til arkitektrollen:
- Confirmation Bias: når du bare vet du har rett, og kun husker/finner ting som bekrefter dette.
- Zero Risk Bias: preferansen for å redusere risiko lokalt over det å redusere den globalt.
- Availability Heuristics: om noe er lett å huske, så må det være viktig (noe som ofte er motsatt)
- Outcome Bias: vår dårlige evne til å korrelere resultat med beslutning, eller skille skills fra flaks
- Self-serving Bias: går det bra, så er det på grunn av oss. Går det dårlig, så er det på grunn av “de andre”.
Et tips hun kom med for å prøve å motvirke disse (helt naturlige) tendensene er å forsøke å endre språk:
- I stedet for “Best Practice” kanskje det er “Good Practice”?
- I stedet for “Skal være løst koblet” kanskje det er “Skal ha passende løs kobling”?
Med andre ord; legg opp til at mottaker må resonnere litt på egne premisser.
Avsluttet med et artig spørsmål:
How confident are you about your confidence?
Karakter: Bra reflektert: Oppovertommel!
From the trenches (Patrick Kua, Neal Ford)
Dette var vel ment å være litt fasiliterte refleksjoner, men fremstod nesten mer som et reklamestunt for en man som er ute etter ny jobb.
Karakter: Meh.
Scaling out architectural decision making (Patrick Kua)
Ett av mine favorittforedrag. Bakteppet er Patricks erfaring fra N26, som er en ren mobil bank som har hatt stor vekst. Vekst både i mengde brukere, men også i diversitet geografisk og dermed også regulatorisk.
Dette medfører igjen at de har måttet skalere opp utvikling med alle de smertene som kommer med det, spesifikt da arkitekturfunksjonen/-rollen(e).
Så var de så heldig å ha ansatt en fyr fra Sound Cloud som tok med seg deres praksis for å bruke RFC (Request For Comments)-formatet under utvikling.
Han fulgte jo sine vaner og sendte ut en RFC på noe han funderte på, noe som resonnerte i resten av organisasjonen.
Det de oppdaget i N26 var at en slik RFC ikke kun kan brukes som et effektivt peer-review-verktøy, men i den prosessen så kan det også brukes til å skille mellom arkitektur og design.
For eksempel så er ikke det å bruke et nytt JavaScript-rammeverk for request routing i SPA noe som påvirker arkitekturen utenfor applikasjonen (og det teamet), men det å bruke en ny meldingstjeneste vil være det.
Det var 3 store fordeler de fant i å bruke dette:
- Kunnskapsspredning og -deling
- Peer-reviews isolerte arkitektene fra unødvendig involvering og møter
- Både utviklingsteam og arkitekter oppnådde større autonomi og derved større effektivitet både separat og samlet.
To andre neste gratis elementer:
- Tilstanden på RFC-katalogen kan nesten 1:1-mappes til en teknologiradar
- RFC-katalogen passer ganske bra inn i det TOGAF kaller Enterprise Continuum, henholdsvis som beslutningslogger og som katalog over ABB/SBBs (Architecture Solution Blocks/Software Solution Blocks)
Karakter: Tankevekkende og inspirerende: Oppovertommel!
Service mesh patterns (Alex Soto)
Dette var en 45-minutters live-demonstrasjon av hva man en service mesh kan gjøre, spesifikt Istio men de fleste komponentene som ligger under paraplyen vil kunne gjøre mye av det samme.
Kanskje mest fascinerende når han presenterte komposittproblemer, med retries, fail-over og auto-scaling i kombinasjon med MTLS (Mutual TLS) og JWT (JSON Web Token).
Alt håndtert out-of-app, dvs. at testapplikasjonen er kjempeenkel og ikke tar inn over seg noe av disse kompliserte NFR-problemstillingene.
Karakter: På tross av litt forvirrende Italinglish: Oppovertommel!
Honey, I shrunk the database: Resilience and recoverability in cloud native services (Sidney Shek, Jeff Farber)
To karer fra Atlassian som forsøkte på humoristisk vis å fortelle om hvorfor de skrev om Id-plattformen til Atlassian til event-sourcing (vel, kommando-sourcing) og bruk av CRDT-er, etter et par voksne kræsj av skytjenester (av den typen der du sitter med ~ 0 data etter tradisjonell restore).
Karakter: Litt lettbeint underholdning på slutten av dagen, med gjenkjennelige situasjoner: Smilebåndstrekk!
O’Reilly Software Architecture Berlin 2019 – Sesjonsdetaljer was originally published in Miles tones on Medium, where people are continuing the conversation by highlighting and responding to this story.