Digitale platforme bygget til innovation.

Foråret er over os. Solen skinner, fuglene vender langsomt tilbage, og folk begynder igen at vågne op fra den lange og mørke skandinaviske vinterhi og samles. Med andre ord – det er tid til den tredje bølge af COVID-19, selvisolering og denne serie.  

Som sædvanligt vil dette være meget sjovere, hvis du har læst del et og to, selvom det ikke er en forudsætning. Denne gang vil det (meget løse) tema være, hvordan man nemmere kan håndtere arbejde dag til dag og I fremtiden. 

Men hvis du lige vil være helt opdateret på, hvordan du skaber digitale platforme bygget til innovation, så kan du læse del et og to her.

Snup noget varmt at drikke, og lad os begynde!  

En stor fordel ved microservices er, at store projekter bliver nemmere at administrere, da ansvaret er mere adskilt. Vi inddeler vores platform I sektioner, så det giver kun mening at forsætte I den bane. Opdel dine store projekter op i mindre task forces, der kan fokusere på at lade en enkel service excellere, i stedet for at dele deres fokus mellem flere forskellige områder og kontekster. 

Et passende eksempel på dette er Amazons idé om "Two Pizza Teams”. Dette betyder, at de strukturerer deres platform på en måde, så hver tjeneste styres af sit eget team, som er lige akkurat stor nok til at blive fodret af to (amerikanske) pizzaer. Dette team er ansvarlig for deres service I hele denne services livscyklus. Hele vejen fra start til produktion til vedligeholdelse, hvilket gør dem til eksperter I deres egne stater in the US of Amazon. Ligesom med den virkelige verdens geopolitik overholder disse stater the rules of Amazon, men de har også friheden til at styre deres stat, som de finder passende til deres borgeres behov.  

At splitte ansvaret op skaber mange flere eksperter I dine teams, som igen kan hjælpe dig med at tage mere informerede og værdifulde beslutninger. 

 I en perfekt utopi fejler vores systemer aldrig. Sandsynligvis fordi vi har geniale AI’s, der automatisk kontrollerer vores kode og kravler rundt på vores servere, intelligent forudser, beregner og retter alt, hvad der går galt i samme millisekund det sker. Desværre troede den sidste AI, jeg stødte på, at “January, February, Maruary, Apruary” var en fantastisk måde at liste måneder på, så vi har sandsynligvis stadig en lang vej foran os. Indtil da er vi (desværre) nødt til at sikre vores systemer manuelt.  

Good news er, at microservices gør det nemt. Først og fremmest betyder det at have separate, veldefinerede og let vedligeholdte tjenester, at vi har elimineret mange fejlpunkter. For det andet er opdelt kode lettere at teste, og hvis vi gik efter “et team, en service, en livscyklus” metoden til at arbejde, har vi endda et dedikeret team, der kender alle ins, outs og svage punkter I servicen.  

Men selvom vi har alt dette, vil der altid være uforudsete fejlpunkter, og det er derfor, vi har automatiske tests og overvågning. Ved at oprette systemer, der konstant observerer vores forretningskritiske punkter, kan vi sørge for altid at opfange fejlene I tide. Dette bliver stadig vigtigere efterhånden som platformen vokser, men desværre implementeres den I de fleste tilfælde først, efter at manglen på overvågning har været et problem lidt for længe.  

Gør dig selv en tjeneste, og tag tid til at konfigurere overvågning I dine udviklingsestimater. Både på et praktisk niveau, men også på et mere teoretisk niveau. Se om der er en måde, du kan standardisere den måde, du overvåger de forskellige tjenester på. Udforsk forskellige overvågningsværktøjer og integrationer. Det er meget lettere (og meget sjovere) at gøre på et tidligt tidspunkt. 

Dette er meget vigtigt, selvom du ikke arbejder med micoservices, men eftersom vi har berørt emnet teamwork, regnede jeg med, at det kunne være nyttigt at medtage som et separat tip.   

Alle team har processer, uanset om vi vil det eller ej. De kan defineres eller de kan være underforstået. Under alle omstændigheder er processer det, der skaber eller bryder teams. Processer er det, der skaber eller bryder virksomheder. Sunde processer gør arbejdet hurtigt, sjovt og effektivt. Usunde processer gør Jack til en kedelig dreng – eksponentielt.  

I en af de forrige afsnit sagde jeg, at en microservice arkitektur ligner LEGO ®, dog digital og med mange flere muligheder. Lad os gå ud fra den metafor:  

Forstil dig at du har en kæmpe kasse med blandede LEGO ® klodser foran dig I alle mulige former og størrelser. Nu vil du gerne bygge et stort blåt hus, men du løber straks ind I problemer. Alle farverne er blandet sammen, så du skal grave rundt I kassen for at finde de blå klodser, og belysningen gør det svært at skelne mellem de blå og grønne klodser. Derudover har de alle forskellige størrelser, så selv når du finder en blå, passer den ikke altid til dine nuværende behov. Du graver og graver og til sidst bygger du dit hus, men med ømme hænder, trætte øjne og dårligt humør.  

Dette eksempel kan sammenlignes med ikke at have optimerede og klare processer. Det mål vi har sat os for at opnå, bliver kompliceret og kedeligt og resulterer I dårligt humør. Forestil dig den samme LEGO ® byggesession, men med de rette processer på plads. Du har det rette lys, du har alle dine mursten sorteret efter form, størrelse og farve, og du har bløde handsker til at modvirke klodsernes skarpe hjørner (for af en eller anden grund er dine hænder superbløde I denne metafor). Du bygger huset hurtigt, har endda lidt ekstra tid til at forbedre dit oprindelige design og går I seng tidligt med glade hænder, øjne og humør. Hvilken fornøjelse!  

Så I den virkelig verden (uden for LEGO ® - land) koges alt dette ned til standarder og retningslinjer. Hvordan kommunikerer vi mellem serviceteams? Hvordan ser vores release cyklus ud? Hvem har ansvaret for test og dokumentation? Hvornår er det seneste, vi kan foretage designændringer inden en release?  

Bliv ved med at stille disse spørgsmål, indtil alt dit akkumulerede arbejde er dækket. Kortlæg det derefter og spørg jer selv, hvad der fungerer, og hvad der skal forbedres. Og bliv tryg med det for dette er en proces, der vil vokse sammen med dig, dit team, din platform og dine læring. 

Aldrig set den titel til et outro afsnit før, har du? *Blink* *Blink*, nudge, nudge, say no more. Vi nærmer os slutningen af denne serie. Forhåbentlig fandt du det nyttigt og interessant, og måske en smule provokerende eller forvirrende. Det var godt – det betyder at du kommer uden for din komfortzone, og at du lærer nye ting.  

Det har været en fest at skrive dette, og hvis du læser alt på én gang, så håber jeg at dine øjne stadig er I deres stikkontakter og din hjerne I solid tilstand. Dette er et enormt emne, som vi elsker at tænker over, tale om og praktisere hos Kruso, og forhåbentlig fungerer dette som en god introduktion til emnet til dine egne fremtidige bestræbelser.  

Microservice-arkitekturen har eksisteret I et stykke tid, og vi er ikke nær af dens relevans. Som med enhver anden metode eksisterer den I sin egen tilstand af “never finished” (flashback til del 1 I denne serie), og nye indsigter og udviklinger opdages konstant. Du er velkommen til at kontakte os, hvis du har tanker, meninger eller kommentarer generelt.  

Indtil da: Take care og husk at holde dig hydreret og strække dine ben en gang hver time. Og held og lykke med hvad end du beskæftigede dig med, som fik dig til at interessere dig for dette blogindlæg.