vækst af microservice vedtagelse har medført en genopblussen i popularitet af nogle tidligere-overset software design mønstre. Mange af disse mønstre er blevet udvundet fra Eric Evans ‘ Domain Driven Design, En bog, der handler lige så meget om teamstruktur, som det handler om programmelarkitektur.
og af disse mønstre er den afgrænsede kontekst måske den vigtigste at forstå. Som ingeniører er vi kommet til at betragte den afgrænsede kontekst som et designmønster for programmelarkitektur. Men det er fordi vi har valgt det lidt fra dets oprindelige brug. Som brugt af Evans er den afgrænsede kontekst lige så meget et organisatorisk mønster som det er teknisk.
derfor er jeg kommet for at se det afgrænsede Kontekstmønster som en lynchpin i forståelsen af mikroservices. Ikke kun hvordan man bygger dem, men virkelig hvorfor vi bygger dem i første omgang, og hvordan de kan gøre vores organisationer mere succesrige. Hvis vi forstår, hvad afgrænsede sammenhænge er – hvis vi vedtager den afgrænsede Kontekstindstilling både teknisk og organisatorisk — så kan vi virkelig få succes med at opbygge vores mikroservices arkitektur.
hvorfor flytte til microservices?
for at begynde, lad os udføre en lille øvelse. Stil dig selv dette spørgsmål: Hvorfor bygger vi mikroservices i første omgang?
Tag et øjeblik til at tænke over det. Hvad er de fordele, der først kommer til at tænke på? Hvad er de største problemer, vi skal håbe på at løse? Skriv nogle svar ned, bare for at holde dig ærlig.
…
har du dit svar? God. Læs det tilbage til dig selv. Har du ramt de tekniske standardfordele? Kontinuerlig levering, skalerbarhed, polyglot miljøer, containere og skyer, og alle de gode ting? Stor.
men inkluderede dit øverste svar noget om at gøre det muligt for din organisation at fungere mere effektivt? Det burde det. Fordi opbygning af mikroservices ikke handler om at realisere tekniske fordele. Det handler virkelig om at opnå organisatoriske fordele. Alt andet er en implementeringsdetalje.
Monoliths = koblet kode og koblede hold
efterhånden som vores monolitter bliver større og større, begynder produktiviteten at aftage. Der er mindst to hovedårsager til det.
at sætte bremserne på vores hastighed
for det første bidrager hvert ingeniørteam til en kæmpe kodebase. Som sådan står hold over for en stadigt voksende sandsynlighed for, at deres kode vil være i konflikt med andres kode. For at hjælpe med at afbøde de potentielle problemer, dette kan medføre, indfører vi procedurer — kode fryser, KVALITETSTESTPERIODER, frigør tog osv. – det er bogstaveligt talt designet til at bremse vores produktivitet.
selvfølgelig forhindrer disse procedurer funktioner og forbedringer i at blive implementeret rettidigt. De skaber også kaos på ingeniørers evne til at fokusere på deres teams prioriteter. Hvis der findes en fejl i en testperiode, det ansvarlige team skal kontekstskift og fokusere på at løse denne fejl. Hvis der findes en alvorlig fejl i produktionen, holdet skal ikke kun rette fejlen, men også hoppe gennem bøjler for at få den implementeret af det næste frigivelsestog.
vagt bliver en boondoggle. Hvis noget går galt med vores monolit, skal nogen være tilgængelige — dag eller nat — for at løse problemet. Men hvem? Store organisationer med store monolitter står generelt over for to valg:
- et hændelsesledelsesteam, hvis eneste, triste, triste job i organisationen er at reagere på problemer forårsaget af andre ingeniørers kode og finde ud af, hvordan man løser dem.
- en roterende vagtplan, hvor hver uge tildeles en vilkårlig ingeniør det triste, triste job med at blive ansvarlig for at løse problemer, der sandsynligvis er forårsaget af kode skrevet af en anden ingeniør, i et andet ingeniørteam.
(Mis)organisering af vores teams
Monoliths rod med vores organisationer på endnu en måde. Hele vores organisation arbejder på det samme, store produkt. Men vi er stadig nødt til at opdele organisationen i håndterbare teams. Så vi har en tendens til at se på funktionelle roller for at finde teamgrænser:
desværre begrænser denne form for organisationsstruktur samarbejdsarbejde. I stedet for at arbejde sammen om at løse det sande problem ved hånden (f. eks. hvordan designer, bygger og vedligeholder vi funktionen?) medlemmer af de forskellige funktionelle områder fokuserer simpelthen på deres egen del og kaster metaforisk deres arbejde over hegnet, når de er færdige. Potentialet for samarbejde og synergi — hvor den samlede kvalitet af holdets indsats er meget mere end summen af de enkelte teammedlemmer — går tabt.
det er også fyldt med flaskehalse. Når vi organiserer vores teams efter funktionsområde, vil vi naturligvis have forkert justering i prioriteterne. Lad os sige, at produktledelsesteamet besluttede, at vores monoliths købsproces skal moderniseres. De planlægger tid med designteamet for at sammensætte nogle mocks. På et tidspunkt vil mocks være færdige og afleveret til frontend-teamet for at implementere. Selvfølgelig vil frontend-teamet have brug for API ‘ er, der skal implementeres af backend-teamet, så de blokeres, indtil det er afsluttet. Når backend-teamet prioriterer sit arbejde med de nye checkout-tjenester, finder det ud af, at det har brug for hjælp fra Databaseadministrationsteamet (dba). Hvilket selvfølgelig har sine egne prioriteter. Så backend-teamet blokeres, indtil en DBA frigøres.
på en måde virker denne organisationsstruktur lidt som en dårligt designet, alt for koblet programarkitektur… gør det ikke?
Microservices = afkoblet kode, afkoblede teams
derimod muliggør en microservices-arkitektur teamautonomi. Det bliver meget lettere at danne hold, der er selvstændige, der arbejder effektivt sammen, og som ikke konstant blokeres af afhængigheder af andre hold.
Teams kan tage fuldt ejerskab over deres arbejde, fra design til udvikling til implementering. Hvert medlem deler ansvaret for at nå deres holds mål, så de bliver incitamenterede til at deltage i mere end bare “deres del”. Jeg har arbejdet med teams, hvor produktledere, designere, front-end, back-end og mobile ingeniører er kommet sammen for at designe produktfunktioner, hvilket giver langt bedre resultater, end en person kunne have opnået.
holdet får ansvar for sine egne artefakter, når de er indsat i produktionen. Dette fører generelt til kode af højere kvalitet, der er lettere at fejlfinde. Hvorfor det? I modsætning til med en monolit har hold en tendens til at have et holistisk syn på de mikroservices, de ejer. Så det er meget lettere for teamet at forudse problemer, at tilføje god logning og målinger til fejlfinding af problemer, når de opstår, og at gøre korrekt brug af modstandsdygtighedsmønstre (f.eks.
desuden, da hold har en fuld følelse af ejerskab over deres arbejde, bliver deres tjenester sunde og kører i produktion mindre om en mareridtsagtig udgivelsesplan og mere om at pleje deres oprettelse.
endelig arbejder holdene mod det samme mål på samme tidslinje. Det betyder ikke mere at blokere en person, da de venter på, at nogen i et andet funktionelt område frigør sig.
vi skal være bevidste om autonomi
men vi får ikke disse fordele gratis ved blot at bryde vores monolit i mikroservices. Lad os se på vores første, naive visning af en mikroservices-arkitektur:
Hvis vi er som de fleste ingeniører, er vores oprindelige ide om en mikroservicearkitektur, ja, en flok mikroservices. Hver udsætter en slags API (hvile, måske) for at tillade enhver anden tjeneste at læse fra den og skrive til den.
når vi får erfaring, lærer vi, at ikke alle mikroservices tjener det samme formål — eller i det mindste burde de ikke. Og derfor, ligesom vores monolit var blevet arrangeret i lag, så arrangerer vi vores mikroservices:
på dette tidspunkt har vi defineret de forskellige typer mikroservices og applikationer, som vi vil bygge. Stor. Men vi har stadig ikke gjort meget fremskridt med hensyn til teamautonomi. Hver mikroservice skal ejes af et team. Og så opstår spørgsmålet: hvilke hold vil eje hvilke mikroservices?
Cross functional teams
vores første, naive tilgang kan være at organisere vores teams ved at efterligne vores Monolith org-struktur:
Her ser vi hold (i lilla) organiseret efter funktion:
dette kan føles rigtigt, i det mindste oprindeligt. Men lad os tage et skridt tilbage og se på den værdi, vi forsøger at levere til vores kunder. Er det vores mål at bygge ting som følgende for vores kunder?
- en flok databaseskemaer
- en flok brugergrænseflade mockups
- en flok mikroservices, der kan tale med en Myskl-database?
ikke rigtig. Det er bare de værktøjer, som vi bruger til at skabe værdi for vores kunder. Den faktiske værdi, som vi giver vores kunder/brugere, kommer i form af funktioner og funktionalitet som:
- et produktkatalog for at søge
- en mekanisme til at placere varer i en indkøbskurv og derefter købe dem
- et underretningssystem for at advare kunderne om status for deres køb
På samme måde ønsker vi ikke at organisere vores team efter funktionelt område. Vi bør snarere definere vores teams efter den værdi, de skaber for kunderne; det vil sige på tværs af funktioner i (de passende navngivne) tværfunktionelle teams.
Med tværfunktionelle teams arbejder alle sammen om at opbygge et specifikt produkt eller en funktion, fra start til slut. Alle på holdet har de samme mål og prioriteter, så intet funktionelt område blokeres af en anden. Kræver den nye backend API-tjeneste noget databasedesign? Bøde; holdets backend-ingeniør og DBA kan begge prioritere deres arbejde sammen.
når det er bedst, opfordrer tværfunktionelle teams medlemmerne til at samarbejde gennem hver fase af projektet. Hvert teammedlem bidrager til det overordnede design af funktionen. Frontend, backend og mobile ingeniører definerer i fællesskab API-kontrakter. Alle prøver. Og alle begynder at blive velbevandrede i deres særlige domæne.
og så kan vores teamstrukturer begynde at se sådan ud:
det er bedre. Men noget føles stadig ikke rigtigt.
sikker på, vi har dannet hold, der sandsynligvis vil være mere effektive til at eje produkter. Men vi har stadig taget en top-ned tilgang til at identificere topologien af mikroservices, som vores organisation har til hensigt at opbygge. Vi står tilbage med en stor samling af indbyrdes afhængige mikroservices, hvoraf de fleste er koblet sammen. Vi har simpelthen tildelt dem til forskellige hold til at bygge.
dette fører til bekymringer som:
- Hvordan kan vi oprette API ‘ er, der opfylder alle nuværende og fremtidige behov, som enhver klient måtte have? Kan vi indkapsle vores data, når nogen af vores tjenester kan kaldes af et andet teams tjenester?
- hvor meget tid vil vi spilde på at vente på, at andre hold implementerer vores afhængigheder?
- hvilke fejl i vores systemer kan være forårsaget af fejl i andre systemer (cascading fejl)?
- kan vi kontrollere antallet af opkald, som vores tjenester kan være involveret i? Kan vi sikre, at vores organisation ikke ender med at skabe ubegrænsede synkrone opkald mellem tjenester, hvilket fører til astronomiske responstider eller værre (og ja, jeg har set dette ske) uendeligt rekursive opkald på tværs af tjenester?
- hvad hvis vores teams specifikke funktion eller problemplads ikke er velegnet til den forudplanlagte microservice-topologi?
Vi har brug for endnu en anden måde at tænke på. Måske findes der allerede et mønster for os at følge?
Indtast den afgrænsede kontekst
den afgrænsede kontekst er et nøgledesignmønster, der bæres ud af domænedrevet design, eller DDD. At forstå den afgrænsede kontekst hjælper os med at danne autonome teams og i forlængelse heraf autonome mikroservicearkitekturer.DDD beskriver selv en metode til udvikling af programmer, hvor enkeltpersoner i en organisation arbejder sammen om at definere et fælles sprog. I sin bog Domain Driven Design skildrer Eric Evans ofte ingeniører, der arbejder med produktejere for at etablere et aftalt ordforråd til at beskrive ting som Produkter, Komponenter i produkterne, handlinger, som et produkt kan udføre (eller kan udføres på produktet), dele af arbejdsgange osv. Dette ordforråd omfatter organisationens domæne.
i mange store organisationer bliver det imidlertid umuligt at definere et enkelt, konsistent ordforråd. I disse tilfælde bryder vi vores domæne ind i underdomæner. Eksempler på underdomæner kan omfatte:
- lagerstyring
- produktopdagelse
- ordrestyring
- indkøbsvogne og checkout
som designere, ingeniører, produktledere osv.
det er her DDD møder tværfunktionel teamstruktur. Selvom teammedlemmerne kommer fra forskellige funktionelle områder, er de ansvarlige for deres eget underdomæne og bliver til sidst bosiddende eksperter. Desuden er teamet ansvarligt for at bestemme, hvilke artefakter — mikroservices, internetapplikationer, mobilapps, databaser og relateret infrastruktur — der er nødvendige for at bringe underdomænet til liv og til organisationens kunder.
Vi kan tænke på holdet og dets artefakter som omfattende en afgrænset kontekst.
definition af den afgrænsede kontekst
mens Evans diskuterer afgrænsede sammenhænge ofte i sin bog, definerer han ikke rigtig mønsteret eksplicit. Så jeg vil forsøge at gøre det her:
afgrænset kontekst:
et internt konsistent system med omhyggeligt designede grænser, der formidler, hvad der kan komme ind i systemet, og hvad der kan afslutte det.
med andre ord repræsenterer en afgrænset kontekst en kontekst — i det væsentlige et system, der indkapsler kooperative komponenter — med klart definerede grænser, der styrer, hvad der kan komme ind i systemet, og hvad der kan afslutte det.
celler (de små ting, der kollektivt udgør alle levende væsener) tilbyder en god analogi. Inden for en celle er alle mulige komponenter (kernen, ribosomer, cytoplasma, cytoskeletter osv.), som alle er indkapslet i selve cellen. Omkring hver celle er imidlertid en membran, der fungerer som barrieren mellem cellens indre og resten af organismen. Membranen beskytter cellen mod sit miljø, tillader specifikke næringsstoffer at komme ind i den og tillader forskellige biprodukter at forlade.
i samme vene består en afgrænset kontekst en række komponenter (mikroservices, internetapplikationer, mobilapps, databaser, meddelelseskøer osv.). Det fungerer også som en logisk barriere, der indkapsler disse komponenter. Internt kan komponenterne kobles og kan frit videregive data til hinanden. Men den afgrænsede kontekst hjælper med at håndhæve løs kobling eksternt, definere eksplicitte punkter hvor:
- eksterne data kan indtaste (måske via forbruger abonneret på et Kafka-emne)
- interne data kan afslutte (måske via et andet Kafka-emne eller via et godt design GET API, omhyggeligt udformet til at skjule eventuelle interne systemoplysninger)
en afgrænset kontekst repræsenterer også dets tværfunktionelle team. Holdet består af forskellige teammedlemmer (designere, frontend/backend/mobile ingeniører, produktledere, data ingeniører og KVALITETSSIKRINGSINGENIØRER osv.). Internt, disse medlemmer arbejder sammen mod de samme konsekvente mål. Desuden er disse teammedlemmer (eller bør være) indkapslet, så de har minimal afhængighed af andre hold.
så i stedet for at starte på et organisatorisk niveau og definere alle de applikationer og mikroservices, vi forventer at bygge, bygger vi teams omkring vores underdomæner, så disse teams kan vokse deres underdomæner og definere, hvad der skal bygges. Udført korrekt, vi har tendens til at se forskellige afgrænsede sammenhænge i organisationen som voksende organisk, snarere end som stive, foruddefinerede strukturer.
implikationer for at bryde monolitten
Convas lov fortæller os, at organisationer designer programmelsystemer, der efterligner deres organisations kommunikationsstruktur. Det viser sig ofte at være sandt, så vi bør være tankevækkende om, hvordan vi strukturerer vores organisation, når vi begynder at opbygge mikroservices.
faktisk skal der nu opstå et billede i dit sind. Når vi bevæger os fra monolit til mikroservices, skal vi begynde at tænke lodret (dividere monolitten med dens underdomæner) i stedet for vandret (dividere monolitten med dens funktionelle lag).
med andre ord bør vi ikke starte med at erstatte monolitens dataadgangslag med datamikroservices. I stedet skal vi starte med at opdele en hel funktion (såsom købsprocessen eller måske produktsøgning). Hver funktion repræsenterer en afgrænset kontekst. Og hver vil blive opdelt af et dedikeret tværfunktionelt team.
desuden bør dette team fokusere på deres opgave ved hånden, som er at enten:
- trofast replikere den eksisterende funktionalitet,
- eller (bedre) at opbygge en helt ny, forbedret oplevelse for sine kunder.
som en del af processen skal teamet designe det system, der er bedst egnet til bestræbelsen.
for eksempel kan vi beslutte at skrælle vores produktsøgningsfunktionalitet ud af vores monolit. Produktsøgningsteamet kan i sidste ende designe et system, der inkluderer:
- Kafka forbrugere, der lytter til en række eksterne Kafka emner at opdatere sin egen interne system of record (SoR) for produkter.
- en Kafka-udgiver, der skubber ændringer til sin SoR på et internt Kafka-emne
- en anden Kafka-forbruger, der lytter til det interne emne og opdaterer et elastisk søgeindeks
- et Graphkl-slutpunkt for freeform-søgninger, der forespørger elastisk søgning
- et ReST-slutpunkt, der henter individuelle produkter efter ID
- en redesignet internetapplikation, der bruger disse slutpunkter til at give kunderne mulighed for at søge efter produkter og udforske produktoplysninger
- en lignende sæt med skærme i vores mobilapps, der bruger disse slutpunkter
- en Kafka-udgiver, der skubber beskeder, repræsenterer forskellige forespørgsler udført af kunder til et eksternt Kafka-emne til brug af enhver anden afgrænset kontekst (f.eks. analyse), der kan være interesseret
når vi begynder at skrælle flere og flere lodrette dele af vores monolit, bygger andre hold deres egne afgrænsede sammenhænge. Disse afgrænsede sammenhænge kan ende med at se helt anderledes ud end hinanden.
bemærk, at komponenter inden for en given afgrænset kontekst kan være tæt koblet; vi holder dog vores afgrænsede sammenhænge afkoblet fra hinanden. I vores eksempel sker enhver kommunikation mellem afgrænsede sammenhænge ved at sende meddelelser via en Kafka-meddelelseskø. Det er vigtigt, at vi undgår synkrone anmodninger/svaropkald mellem afgrænsede sammenhænge.
dette gælder også med hvad der er tilbage af monolitten. Vi ønsker bestemt ikke tæt kobling mellem vores nye mikroservices og vores arv monolit. Så når vi skræller dele af monolitten væk, vi udnytter meddelelsesoverføring for at give de resterende dele mulighed for at kommunikere med vores nye afgrænsede sammenhænge.
Reality check på al denne afkobling
på dette tidspunkt kan vi spørge os selv, om det virkelig er muligt at holde vores afgrænsede sammenhænge afkoblet.
i den virkelige verden, kan vi virkelig holde vores teams beskyttet mod eksterne afhængigheder? Vil der aldrig være tilfælde, hvor et hold skal blokeres af et andet hold for at få deres arbejde udført?
og kan vi faktisk oprette servicearkitekturer til vores underdomæner, der er helt afkoblet fra andre underdomæner? Er der virkelig ikke behov for en applikation i en afgrænset kontekst for nogensinde synkront at kalde en tjeneste i en anden?
i virkeligheden kan det være umuligt at holde vores afgrænsede sammenhænge 100% afkoblet. Men vi kan komme tæt på, meget tættere end de fleste af os måske tror.
virkelige arkitekturer
lad os starte med at se på afkoblede arkitekturer. Ofte køber vi ind i den fejlslutning, at en given type data skal leve på nøjagtigt et sted, og at ethvert andet system direkte skal ringe til det ene sted for at få adgang til dataene.
Vi henviser til dette som at tildele en enkelt sandhedskilde (SSoT) til vores data. Men som beskrevet i denne artikel, der dissekerer ideen om SSoTs, er selve forestillingen stort set et anti-mønster. I stedet skal de fleste afgrænsede sammenhænge gemme deres egen lokale kopi af de data, de skal bruge.
Dette er eksemplificeret ved vores produktsøgning afgrænset kontekst fra det foregående afsnit. Denne afgrænsede kontekst er naturligvis stærkt afhængig af vores organisations produktkatalogdata. Men odds er, at data genereres i en anden afgrænset kontekst (vi kalder det Produktindtastningsbegrænset kontekst).
vores første (naive) tilgang kan være at udsætte en ReST API fra den afgrænsede kontekst for Produktindtastning og tvinge tjenesterne inden for den afgrænsede kontekst for produktsøgning til at kalde den API. Men vi kan gøre det bedre. Vi kan i stedet holde systemerne afkoblet ved at offentliggøre de ændringer, der er foretaget af Produktindgangstjenesterne, på Kafka. Vores produktsøgning Kafka-forbrugere henter derefter disse meddelelser og opdaterer databaserne for produktsøgning.
Bemærk, at disse to Afgrænset Sammenhænge er i sidste ende-konsekvent. Dette betyder, at der vil være korte perioder, hvor et givet stykke data kan være inkonsekvent mellem Produktindtastning og produktsøgning. For eksempel, hvis prisen på hvide Livmoderkontroller hæves fra $1,99 til $2.49, vil der være en kort periode (ofte et spørgsmål om sekunder, hvis ikke millisekunder), hvor der er en 50 liter forskel i hvid Livmoderkontrolpris på tværs af de to afgrænsede sammenhænge.
dette fører til de virkelige tilfælde, hvor vi ikke har andet alternativ end at parre afgrænsede sammenhænge. I nogle tilfælde er eventuel konsistens ikke acceptabel. For eksempel, før en kunde kan gennemføre deres online køb, skal vi muligvis sikre, at hver vare i deres indkøbskurv faktisk er tilgængelig i det øjeblik. Selv da kan vi ofte minimere koblingen mellem de to afgrænsede sammenhænge.
vores interaktioner kan se sådan ud:
- da kunden bruger brugergrænsefladen til produktsøgning til at finde produkter, bruges databaserne til produktsøgning til at hente information (såsom stilarter, kundeanmeldelser, priser osv.) om produkterne
- selv når kunden begynder købsprocessen, bruger vi stadig produktsøgningsdatabaserne til at hente de oplysninger, der skal vises.
- endelig, når kunden klikker på den endelige “komplet Køb”-knap, foretager vi et enkelt, synkront opkald til den afgrænsede kontekst for Produktindtastning for at validere varernes tilgængelighed, inden købet gennemføres.
et andet almindeligt eksempel, der kræver øjeblikkelig konsistens relateret til autorisation. I mange systemer skal sikkerhedstokens hentes eller valideres på enhver anmodning. I disse tilfælde er vi sandsynligvis nødt til at lade vores afgrænsede sammenhænge kalde en anden, sikkerhedsorienteret afgrænset kontekst.
virkelige org-strukturer
hvad med selvstændige, tværfunktionelle teams? Hvor mulige er de i den virkelige verden?
i virkeligheden er det en proces med kontinuerlig bevægelse mod helt selvhjulpne hold. Sjældent vil vi nogensinde nå 100% autonomi med vores hold. Men hvis vi starter med at organisere vores teams intelligent og genkende og reagere på flaskehalse, der opstår, kan vi komme tæt på.
til at begynde med skal vi maksimere vores lodrette, tværfunktionelle hold og minimere antallet af vandrette, enkeltfunktionelle hold. Det betyder at modstå trangen til at danne såkaldte “core” teams-hvis mission er at opbygge fælles datatjenester, der forbruges af andre produktorienterede teams — og i stedet danne vores teams omkring den forretningsværdi, de vil give.
mange organisationer tiptoe mod dette mål, først danner domæne-orienterede teams af produktledere, og front-end og back-end ingeniører. Det er en begyndelse. Men hvem ellers skal disse hold omfatte? Præcis medlemskab kan variere på tværs af forskellige hold med forskellige behov. Men vi bør overveje ting som:
- hvis vores team har front-end ingeniører, så er odds, at de skal arbejde tæt sammen med en grafisk designer, der er dedikeret til domænet.
- Mobile ingeniører — ofte sekvestreret i deres eget område af organisationen — bør medtages for domæner med en mobil komponent.i sin oplysende artikel om datamasker beklager han, at dataingeniører ofte udelukkes fra tværfunktionelle teams-til skade for dataingeniørerne og de tværfunktionelle teams selv.
når vi har bestemt medlemskab af vores teams, skal vi passe på flaskehalse. Er der andre hold, der sædvanligvis blokerer for vores tværfunktionelle teams produktivitet?
for eksempel har mange organisationer et dedikeret sikkerhedsteam. Dette er selvfølgelig en god praksis; organisationer har brug for en sammenhængende sikkerhedsstrategi og en måde at sikre styring over denne strategi. Det er dog også almindeligt, at hold stopper deres arbejde på forskellige stadier for at tillade sikkerhedsanmeldelser af deres arbejde. Selv i de bedste situationer, dette etablerer vejspærringer for vores teams som en rutine en forretningspraksis. Desuden vil det ofte føre til, at hold skal skrotte hele eller en del af deres arbejde og starte forfra, da de afdækker sikkerhedskrav, der ikke var opfyldt.
Dette er helt klart en dårlig lugt. Men hvordan kan vi håndhæve vores organisations sikkerhedsstandarder, samtidig med at holdene forbliver autonome og produktive?
Vi kan gøre dette ved at tilføje sikkerhedsingeniører til vores tværfunktionelle teams. Der er tre tilgange, vi kan tage:
- hvis vi er heldige nok til at have et relativt stort sikkerhedsteam, kan vi tildele hvert tværfunktionelt team en fuldtids sikkerhedsingeniør (SE).
- med mindre sikkerhedsteams kan hver SE tildeles et antal tværfunktionelle teams på deltid. Dette vil stadig give SEs mulighed for at forstå holdets mål og design og arbejde sammen med teamet for at overholde organisationens sikkerhedsstandarder gennem hele processen.
- hvis vi ikke har nok sikkerhedsressourcer til enten kan vi bevæge os i den modsatte retning. I stedet for at bringe medlemmer af sikkerhedsteamet ind i vores tværfunktionelle teams, vi kan bringe medlemmer af de tværfunktionelle teams ud til sikkerhedsteamet. Hvert tværfunktionelt team udpeger en eller to sikkerhedsrepræsentanter. Repræsentanterne mødes med jævne mellemrum med sikkerhed og holdes ajour med organisationens sikkerhedskrav og standarder. De er måske ikke selv sikkerhedseksperter. Men de vil være i stand til at tjene rollen som en sikkerhedsingeniør og sikre, at deres hold overholder organisationens sikkerhedspraksis.
Guilds
dette hænger sammen med et andet organisatorisk mønster, der har fået trækkraft: guilds. Guildmodellen blev født fra den tværfunktionelle teammodel. Af deres natur er disse hold befolket med medlemmer, der specialiserer sig i forskellige funktioner. Endnu, det giver ofte mening for folk, der specialiserer sig i en bestemt funktion, også at mødes; for eksempel, til:
- finpudse deres færdigheder og lære af hinanden
- Opdag og etablere bedste praksis for deres særlige funktion
- afhængigt af funktionen, oprette virksomhedens standarder og krav
vores sidste sikkerhedsløsning dannede effektivt en “sikkerhedsgilde”. Teammedlemmer arbejdede primært med deres lodrette hold; men med jævne mellemrum mødtes nogle af dem med sikkerheds “guild” for at diskutere organisationens sikkerhedspraksis og standarder.
guild-modellen fungerer også særligt godt, når det kommer til programmelarkitektur. Især med en mikroservices-arkitektur kræves der et vist niveau af teknisk styring i hele organisationen. Men at have en gruppe arkitekter, der sidder i et metaforisk elfenbenstårn, uddele regler til hold, er generelt kontraproduktivt. I stedet kan senior / ledende ingeniører fra vores tværfunktionelle teams regelmæssigt mødes i en arkitekturgilde. Der, de kan rejse problemer fra deres teams, og udarbejde løsninger, og etablere pattens og standarder.
guilds kan også udvides til næsten alle andre funktioner. Trods alt, vi ønsker, at designere skal udvikle sig, og arbejder ud fra, en fælles UI-stilguide. Vi ønsker, at vores frontend-ingeniører skal bruge de samme UI-elementer. KVALITETSTEKNIKERE bør være på linje med, hvordan test udføres i vores organisationer. Og produktledere skal være synkroniseret med organisationens overordnede produktkøreplan.
Bring det hele sammen
flytning til microservices kan dramatisk forbedre produktiviteten i vores teams. Men vi er nødt til at forstå, hvordan vi kan drage fordel af en mikroservices-arkitektur for at få os der. Af alle designmønstre og koncepter, der vedrører mikroservices, er den afgrænsede kontekst uden tvivl den vigtigste, der giver os den forståelse.
med en solid forståelse af den afgrænsede kontekst forstår vi det:
- vores organisationsstruktur og vores tekniske arkitektur går hånd i hånd
- vores produktorienterede teams skal have minimale afhængigheder af andre teams, ligesom de systemer, de bygger, skal afkobles fra andre systemer
generelt sætter omfavnelse af den afgrænsede kontekst den tankegang, at vi har brug for at få succes med vores mikroservices-arkitektur. Sørg for at forstå dette vigtige mønster, før du går i gang med din microservices-rejse!
