3.0 Introduktion till del 3: System

Arkitektur är den uppsättning beslut som är dyra att vända. Hur delar du upp ett system i delar? Hur talar de delarna med varandra? Hur modelleras data? Och hur beter sig helheten under belastning och under fel? Del 3 handlar om att fatta de besluten med avsikt. I ett litet team kan arkitektur bo i några få huvuden och utvecklas allteftersom. I en stor organisation (hundratals ingenjörer, dussintals team, system som kommer att överleva karriären hos de människor som bygger dem) blir arkitektur det som håller alla samordnade. När den är tydlig rör sig team oberoende utan att krocka. När den är vag blir varje beroende mellan team en förhandling och varje incident ett arkeologiprojekt.

Insatserna är högst i företag och myndigheter. En skattemotor, en bidragsplattform, ett nationellt hälsoregister eller en banks kärnhuvudbok är långlivad, starkt reglerad, delad mellan avdelningar och ansvarig inför allmänheten. De beslut du fattar i dag om koppling, dataägarskap och kvalitetsegenskaper kommer att begränsa vad som är möjligt i ett decennium eller mer. Tillsynsmyndigheter och revisorer förväntar sig alltmer dokumenterad, försvarbar arkitektur, med verkliga belägg för att tillförlitlighet, säkerhet, integritet och beständighet byggdes in, inte skruvades på efteråt. De misslyckanden som blir rubriker är arkitekturmisslyckanden: portaler som viker sig på lanseringsdagen, ingivningssystem som får tidsgränsfel vid deadline, migreringar som tappar eller dubbelräknar poster.

Den här delen börjar med de varaktiga grunderna, rör sig genom konkreta strukturella val, vidare in i verkligheten kring distribution, data och skala, och avslutas med det svåraste problem de flesta stora organisationer faktiskt möter: att modernisera de system de redan kör. Den röda tråden: god arkitektur är en serie medvetna avvägningar, inte ett modernt standardval.

Kapitel i den här delen

3.1 Arkitekturens grunder. De varaktiga verktyg som överlever teknikmoden: kvalitetsegenskaper, arkitektoniskt betydande krav, anpassningsfunktioner (automatiserade tester som vaktar en vald arkitektonisk kvalitet) och evolutionär arkitektur, lätt dokumentation med C4-modellen (nästlade arkitekturdiagram på fyra zoomnivåer) och arc42 (en mall för arkitekturdokumentation) samt strukturerad avvägningsanalys.
3.2 Arkitekturstilar och mönster. En översikt över de stora systemformerna, från monolit genom mikrotjänster, händelsedrivna arkitekturer med CQRS (Command Query Responsibility Segregation, som skiljer läsmodeller från skrivmodeller) och händelselagring (att lagra tillstånd som en endast-tilläggs-logg av händelser), tjänstenät (ett dedikerat infrastrukturlager för kommunikation mellan tjänster) och gateways, serverlös samt hexagonal och ren arkitektur, med vägledning om när var och en passar, inramad av Conways lag (system tenderar att spegla kommunikationsstrukturen hos den organisation som bygger dem).
3.3 Distribuerade system. De hårda sanningar som dyker upp i samma stund du korsar en nätverksgräns (opålitliga nätverk, partiellt fel, ingen gemensam klocka) och de vanliga försvaren: konsistensresonemang, idempotens (att göra en operation säker att upprepa), omförsök med fördröjning, kretsbrytare (som slutar anropa ett felande beroende), sagor (sekvenser av lokala transaktioner med kompenserande ångersteg) och distribuerad observerbarhet.
3.4 Dataarkitektur och lagring. Hur data modelleras, lagras, hålls konsistenta och serveras snabbt i stor skala: de stora lagringsparadigmen och när man använder vart och ett, polyglot persistens (att använda flera specialiserade datalager i ett system), schemautveckling och migrering, cachelagring och CDN:er (innehållsleveransnätverk) samt transaktioner och samtidighet under belastning.
3.5 Skalbarhet, prestanda och motståndskraft. Tre skilda kvaliteter som utformas in snarare än eftermonteras: horisontell och vertikal skalning, tillståndslöshet och sharding (att dela data över maskiner efter en nyckel), lastbalansering och autoskalning, prestandabudgetar, motståndskraftsmönster och kaosteknik samt multiregion-katastrofåterställning inramad av RTO (recovery time objective) och RPO (recovery point objective).
3.6 Modernisering av äldre system. De inkrementella mönster som faktiskt fungerar, kvävarfikon (att växa ett nytt system runt det gamla tills det gamla kan avvecklas) och gren-via-abstraktion (att ersätta en komponent bakom ett gränssnitt på utvecklingens huvudlinje), plus riskbedömning av äldre system, förvaltning av stordator och COBOL (Common Business-Oriented Language), datamigrering och dubbelkörning, och hur man motstår frestelsen till den stora omskrivningen som ger fältets dyraste misslyckanden.
3.7 Programvaruunderhåll. Den dominerande fasen i programvarans livstid: korrigerande, anpassande, förbättrande och förebyggande underhåll, programförståelse och omkonstruktion samt att designa för underhållbarhet så att långlivade system förblir prisvärda att ändra.
3.8 Interoperabilitet och öppna standarder. Att designa system för att samverka genom öppna standarder snarare än skräddarsydda integrationer: teknisk, syntaktisk och semantisk interoperabilitet, domänstandarder som FHIR inom hälso- och sjukvård och kostnaden för proprietär inlåsning.
3.9 Systemteknik. Att konstruera komplexa system från början till slut, ofta kombinerande programvara, hårdvara, människor och processer: livscykel, kravallokering och spårbarhet, gränssnitt, integration samt verifiering och validering.
3.10 Inbyggda system och realtidssystem. Programvara för enheter under snäva begränsningar: realtidsbeteende och determinism, ett RTOS eller hårdvarunära fast programvara, begränsat minne och begränsad ström, hårdvaruinteraktion och säkerhetskritiska standarder.
3.11 Molnarkitektur. Att designa för molnet snarare än att lyfta-och-flytta ett datacenter: tjänstemodeller och serverlös, regioner och tillgänglighetszoner som felområden, modellen med delat ansvar, avvägningar kring hanterade tjänster och inlåsning, multimoln och hybrid när de förtjänar sin komplexitet samt kostnadsmedveten, välarkitekterad design.
3.12 Händelsedriven arkitektur och meddelandehantering. Att bygga system som kommunicerar genom att producera och reagera på händelser: köer mot varaktiga strömmar, koreografi mot orkestrering, händelselagring och CQRS där de förtjänar sin plats, sagor för distribuerade transaktioner, leveransgarantier och idempotens samt de mönster som håller asynkrona flöden pålitliga.
3.13 Nätverk och uppkoppling. Det nätverkande en applikationsingenjör faktiskt möter: DNS, TCP och HTTP:s utveckling, TLS-terminering, lastbalansering och omvända proxyer, innehållsleverans och kant, tjänsteupptäckt och tjänstenät samt de tidsgränser, omförsök och kretsbrytare som gör nätverkets opålitlighet överlevbar.
3.14 Multitenans och SaaS-arkitektur. Att betjäna många kunder från en programvaruinstans utan att låta dem se eller svälta varandra: spektrumet isolering mot effektivitet, datapartitionering, kvoter per tenant mot bullriga grannar, tenantens livscykel och kostnadsfördelning.
3.15 Cachelagring och innehållsleverans. Att byta lite inaktualitet mot stora vinster i latens, belastning och kostnad över cachehierarkin (klient, kant och CDN, omvänd proxy, applikation och datalager), medan cacheinvalidering och stampedeskydd behandlas som förstklassig design.
3.16 API-gateways och tjänstenät. Att hantera nord-sydlig trafik vid en API-gateway (routing, autentisering, hastighetsbegränsning, komposition) och öst-västlig trafik genom ett tjänstenät (ömsesidig TLS, trafikomläggning, omförsök, observerbarhet) och att avgöra när ett nät förtjänar sin komplexitet.
3.17 Sökning och informationsåtervinning. Att behandla sökning som ett förstklassigt system, från det inverterade indexet och relevansrankning till frågeförståelse, fasettering samt vektor- och hybridåtervinning, med verklig relevansutvärdering snarare än gissning.

Hur kapitlen hänger ihop

Kapitlen bygger på varandra i ordning. Kapitel 3.1 ger dig ordförrådet (kvalitetsegenskaper och avvägningsanalys) som varje senare kapitel använder. Ilitetsegenskaperna det namnger är exakt vad kapitel 3.4 och 3.5 gör konkreta. Kapitel 3.2 förvandlar dessa grunder till strukturella val, och de mer distribuerade stilar det förordar (mikrotjänster, händelsedriven, tjänstenät) för med sig de kostnader kapitel 3.3 lär dig hantera. Kapitel 3.3, 3.4 och 3.5 lutar sig tungt mot varandra: distribution tvingar fram konsistens- och beständighetsbesluten i dataarkitekturen, och tillsammans formar distribution och data vilken skalbarhet och motståndskraft du faktiskt kan nå. Kapitel 3.6 sluter ringen, eftersom de flesta stora organisationer inte bygger på ett blankt blad: de utvecklar register-system som begränsar varje val de tidigare kapitlen beskriver.

Del 3 sträcker sig också utåt. Kapitel 3.2 hämtar från designprinciperna och den domändrivna designen i kapitel 2.2 för att hitta goda tjänstegränser. De operativa discipliner som håller dessa system igång finns i del 9: driftsäkerhetsteknik (site reliability engineering, kapitel 9.1) och observerbarhet (kapitel 9.2) är där arkitektonisk motståndskraft bevisas i produktion. De säkerhets- och integritetsegenskaper som tillsynsmyndigheter kräver utformas här men beskrivs i detalj i del 4, och plattforms- och leveranspraxis i del 8 avgör om en arkitektur faktiskt kan levereras och drivas av många team på en gång.