Allan Ebdrup

Hvor fremstår du bare super sympatisk i dette interview Anders. Man forstår godt hvorfor dine kollegaer har indstillet dig til prisen.

Jeg er så rørende enig i dine betragtininger om at arbejde som et team og aldrig være alene på en opgave.

Når I-profiler/specialister sidder alene på ogaver, har jeg erfaret igen og igen at motivationen daler, humøret daler og ikke mindst kvaliteten af koden daler. Det er ikke i nogens interesse.

Derfor har vi en tommelfingerregel om, at enhver opgave der tager mere end 2 dage SKAL man mindst være to til at løse. Og vi fremelsker en kultur af samarbejde konstant.

Trygt, ambitiøst samarbejde og flere af din slags i branchen tak, godt gået Anders! Og alt held og lykke til dig i fremtiden :-)

Hej Allan. Vi vil rigtig gerne dele ud af vores erfaring, og vi gør det allerede lidt i smug i den som måtte være interesserede over en kop kaffe, så du siger bare til :)

Super tilbud, jeg skal lige finde tid. Vi arbejder solen sort for tiden, for at levere den frivillige vaccinationsordning :)

Jeg vil også sige, at jeg personligt har fået meget ud af at forberede foredrag om processer - det har været en virkelig øjenåbner for mig at reflektere grundigt over min og det team jeg er en del af's udvikling og skulle forklare den.

Man lærer om sin egen læring ved at skulle præsentere den for andre. For mig har det været en del af arbejdet med processer og gjort os endnu skarpere på hvorfor vi gør som vi gør. Så jeg vil stadig opfordre jer til at holde nogle foredrag om det. I kan godt!

Spændende at der bliver prøvet grænser af i processer. Jeg har altid været fan af at når man prøver nye metoder af, så gør man det på en måde hvor man er meget tro mod nogle principper og dyrker dem helt ud i ekstremerne. Så kan man altid iterativt justere ind til noget mindre ekstremt når man har afprøvet grænserne og opnået læring sammen. Jeg håber at Abtion stiller sig op og holder nogle foredrag om hvad de har lært af det hele om 1-2 år - det ville ihvertfald være et foredrag jeg godt gad høre.

Jeg kunne godt tænke mig en løsning der er lige så praktisk som det månedskort jeg havde da jeg var på kontoret hver dag. Månedskortet kræver nemlig ikke check ind/ud. Det kan ikke stå alene det ved jeg, det skal være i samspil med andre løsninger. Men en app hvor man kunne slå automatisk check ind/ud til, ville være optimalt. Er det virkelig så svært at lave (oprigtigt spørgsmål)

Giver pigz hastighedsfordel ved dekomprimering? De skriver i manpage at selve dekomprimeringen ikke kan paralleliseres, men at der er nogle tråde til read/write/check-calculation. Men kan det mærkes, specielt hvis det bruges i en tgz unpack pipeline?

Det lyder umiddelbart som om at det virkelig har potentialet til bare at gøre det hele værre (IT-landskabet i Skatteforvaltningen).

Tak for at du deler erfaringer, der er interessant ??

Du stiller mange spørgsmål, tak for det. Noget kunne tyde på at at jeg har sat nogle tanker igang hos dig. Hvis de tanker primært går i retningen af: “Bah humbug, det er en forkert måde at gøre det på og vil aldrig virke hos os”, fair nok, så lad os bare hver især komme videre med vores liv.

Jeg har ikke skrevet blogindlægget for at overbevise nogen om noget, for at sige at nogen skal gøre som os, eller for at sige at det vi har gjort er bedre end andre måder. Jeg har skrevet blogindlægget for at inspirere nogle få af dem der læser det og fordi jeg selv var overrasket over at det kunne lade sig gøre at forbedre vores ulrulningstider så meget.

Hvis min mission derimod er lykkes, og du tænker at du måske vil prøve nogle ting af i jeres setup, så vil jeg anbefale at du går i gang med at eksperimentere - du skal alligevel finde dine egne svar på hvordan I gerne vil gøre i jeres unikke kontekst.

Du er også kommet med mange råd i tråden her, også tak for det. Det kunne da også være interessant at vide: Hvor lang tid tager udrulning af microservices hos jer? Kører I også alle tests hver gang? Har i også lavet en intensiv omgang optimering af ulrulningstiden, og hvis ja, hvad var så i overskrifter de ting der gjorde den største forskel?

Jeg kan måske forklare at fx cyprress dependencies er ikke nødvendige at have installeret mens dit build laver sit "byg-step" (webpack osv), så cypress installeres i baggrunden mens webpack kører, og sådan er der faktisk en del ting der ikke er nødvendige før tests skal køres, de installeres i baggrunden - jeg ved ikke om det hjælper?

For måske er der noget i har overset, som gør det kunne gå endnu hurtigere, eller også er der en potentielt ret stor "oh fuck, a-ha!" gemt her for os alle sammen. Men det er lidt svært at vurdere uden en egentligt root cause :)

Jeg tror desværre ikke at jeg kommer det meget nærmere end hvad jeg allerede har skrevet, uden at skulle bruge en masse tid på det - og det har jeg desværre ikke lige nu. Min analyse er stadig:

• Et stort image blokerer meds det downloader
• Layers blokerer resten af dit build mens de downloader. Selv om de forskellige layers måske kan installeres parallelt med hinanden, (det er er jeg ikke 100% sikker på), så skal alle layers stadig downloades på CircleCI før dit egentlige build starter.

Ovenstående gør den måde vi gør det på 20-30 sekunder hurtigere for vores builds, fordi den del der blokerer selve buildet før det starter næsten er væk (3-10 sekunder tager det). Her er CircleCI faktisk også ustabile, så Layers tager nogle gange et minut at downloade eller mere. Denne voldsomme variation fjerner man også med et simplere setup.

Men som du kan se er den ene detalje du dykker ned i ikke det vigtigste punkt i vores performanceforbedringer. De andre punkter står for langt størstedelen af forbedringen.

Hvis du vil komme det nærmere og hvis du vil lære mere, vil jeg klart opfordre dig til at prøve at eksperimentere med det selv. Jeg hører gerne om hvad du finder ud af :-)

Som Klavs også nævner, ville min tilgang være at lave det som en totrins-raket – det lyder som om i har ét base image til alle jeres services? Det burde kunne bygges (og tagges/pushes) separat til jeres registry...

Som jeg skriver så er blogindlæget overhovedet ikke ment som en opskrift andre skal følge, hvert setup er unikt. Så jeg ved ikke hvor meget vi får ud af at dissektere fremgangsmåden. Pointen er at ved at virkeligt eksperimentere rent faktisk måle og fokusere på build tid at vi fik vores builds meget hurtigere.

På CircleCI er der ofte ikke en lokal cache eller den er outdated, jeg tror vi har eksperimenteret med alle de indstillinger og features vi kunne. Jeg ved ikke om layers installeres parallelt på CircleCI, det kan faktisk godt være. Ikke desto mindre tager det 10-20 sekunder ekstra i build time at installere via docker layers. Fordi installationen blokerer alt andet indtil den er færdig, hvorimod den måde vi installerer cypress nu tillader andre ting at køre parallelt. Vi brugte også tidligere layers til nodejs og mongodb. De var meget langsommere end tgz filer hvor nodejs stadig er blokerende for os. Men tager ca 2-3 sekunder og mongodb ikke er blokerende og tager ca 6-10 sekunder, men har ingen impact på buildets tid for andre ting på den kritiske vej kører parallelt.

Jeg ved godt at det umiddelbart virker skørt at installere hver gang, men hvis man tænker over det, hvor forskelligt er det så egentligt far at smide et docker layer på hver gang?

Jeg kan kun opfordre til egne eksperimenter i jeres setup, måske gemmer der sig nogle overraskelser? Jeg er ihvertfald meget interesseret i at høre om dine erfaringer - jeg vil gerne lære mere.

Practio vandt region Syddanmark i udbuddet.https://www.linkedin.com/feed/update/urn:li:activity:6785243702991368193/

Det fremgår det ikke af artiklen hvordan Sundhed.dk har firdoblet kapaciteten. Jeg tænker at de sandsynligvis har tildelt nogle flere cpu kerner/ram osv. til nogle VM'er evt. købt nogle flere hosts med nyere og hurtigere CPU'er, men det er de færreste løsninger der kan skalere på den måde.

De udtaler selv at de er gået fra en til fire servere:

https://www.version2.dk/artikel/sundheddk-opgraderer-serverplads-efter-stormloeb-nedbrud-1092344

Og at de vil op på seks servere snart.

Tja, det gik måske lidt hurtigt. Men måske er der andre end mig der har haft svært ved at finde https://covid-19-kort.dk/ og funktionaliteten med nuværende position. Derudover synes jeg stadig at det er cool med en open source version, som mange kan bidrage til. Det kunne være dejligt hvis det offentlige tænkte i at lave løsninger som https://covid-19-kort.dk/ open source så alle kan bidrage.

Selv da du jeg vidste det var det tog det mig et stykke tid at finde. Men du har ret, der er et ikon man kan klikke på for at komme til nuværende lokation på den side du delte.

Det er nok smag og behag, men jeg tænker også at en open source version har potentiale til at blive rigtig god. Fx med features som at zoome til til nuværende lokationog andet. Hvis flere mennesker bidrager.

Jeg tænker specielt at en feature der tillader brug af aktuel lokation og zoomer kortet til hvor du er ville være lækker :-)

OBS: Der er en offentlig side i forvejen:

https://www.regionh.dk/Sider/kort.aspx

Den er tung at danse med og kun på dansk.

Vi har en nem måde at opdatere den ene build config vi har på alle services - så vi kan nemt opdatere versioner osv.

Men hvis du spørger mig, er det en kæmpe design-fejl at CircleCI ikke understøtter en centraliceret konfiguration der gælder for flere repositories. Når hvert repository har sin egen build konfiguration, sander det hele hurtigt til, og det bliver uoverskueligt at optimere, fordi du skal gøre det i 30 unikke microservice-konigurationer. Det har vi lavet fra starten så alle repositories har samme konfiguration, og så ruller vi opdateringer og performanceforbedringer ud til alle på een gang.

Det ville have været et uoverstigeligt arbejde at optimere vores builds, hvis vi ikke havde den samme konfiguration over det hele fra starten.