Hej, skriver live GOTO cph, sidder og lytter til Adrian Cockcroft som fortæller om fast delivery, om hvordan de hos Netflix kom ud så hurtigt på cloud.
Han beretter om en kultur som blandt andet indeholder:
- Om man koncentere sig om at hastighed vinder i markedet
- Man skal fjerne friktion i udviklings cyklusen
- Managere og udviklere skal have høj tillid, udvilking skal ikke styres med process, og ingen overlevering mellem teams, alle team skal behandle alle andre teams som 3’de parts kode (man snakker kun med API’er)
- En kultur hvor Frihed til prøve nye ting er vigtig
- Man skal koncentere sig om sit kerne område, og køre andre til at gøre resten
- Brug simple deploy teknikker ved hjælp af værktøjer
- Arkitekter prøver at fremme brugen af gode patterns, mens man fraråder dårlige
- Lad arkitektur være offentligt, således kan mange give feedback på det – Adrian snakker om at han har brugt konferencer til at verificere nye arkitekturer
- Alle har adgang til at tilføje services til et cloud miljø (her skal det nævnes at de bruger continous delivery, som man kan høre jez humble blandt andet snakker om i hans deep dive om Lean Enterprise som starter om lidt)
”assumptions: process prevents problems.”
Et problem i mange firmaer er Hver gang noget går galt, så laves en process så man undgår at det sker igen, hvilket er godt i det øjeblik problemet opstod, men i ældere firmaer bliver det en hemsko da de antagelser som gik forud for problemet ofte ikke er opfyldt et år eller to senere, men processen bliver.
Det gælder om at få tiden fra ide til markedet forkortet så meget som muligt. Mens jeg skriver dette sidder Jex Humble faktisk ved siden af mig og gnider sig i skægget – faktisk står Alistair gentager mere eller mindre hvad jeg lærte i går til Jez’ tutorial om Continuous Delivery.
Efter at have siddet i flere firmaer som har vokse værk og som er meget fokuseret på hvordan man kan få sat så meget i process som muligt er det meget interessant at høre disse ting.
Han anbefaler at alle læser The phoenix project.
Mikroservices
I udviklings afdelingen er en af problemerne at når man laver et release, afhænger det af mange udviklere, så hvis bare en udvikler har lavet en fejl, er hele systemet pludselig bremset, derfor er det en god idee at bruge microservices, som kan releases isoleret. Således kan alle release uden at være afhængige af andre, For at ungå at man ødelægger noget ved et release af en mikroservice bruges noget som hedder non destructive production update, som betyder at man aldrig overskriver en version, den nye version kører side om side med den gamle, således at man ikke ødelægger noget ved release. Når man har verificeret at ting virker kan man langsomt lade andre afhængige service migrere til den nye service. Den måde risikere man aldrig at ødelægge systemet.
En mikroservice kan fylde millioner af kode, men må kun udføre en ting. Alle mikroservices skal ejes af mindst to udviklere. Således at man kan sende den ene på ferie engang imellem.
Det hele koger ned til at mindske prisen ved ændringer.
Open Source
Ved at bruge open source kode kan man spare meget udviklings tid, omvendt så kan man vinde meget ved at lade mange ting være open source og offentlig tilgængelige, der vil lade en mange mennesker teste koden, og hjælpe med at udvide det.
Høre ham sige:
De fleste nye spændende projekter er skrevet i Go (http://golang.org/) uden at jeg fik fat i konteksten.
Løs kobling
For at man kan lave små opdateringer uden at man skal opdatere alt, skal alt være løst koblet, og altid kun snakke med andre service gennem API’er.
DevOps
En ting som mange snakker om her på konferencen er at development og operations skal smelte sammen, således at en udvikler ikke er færdig med koden, før den dag det er færdigt med at køre i produktion ikke når man overlever det til QA.
Igår sagde Jez:
Release skal være så rutinerede at det er kedeligt.
Stateless business logic
Her brugte han en rimlig drablig analogi: Man skal have Køer ikke kæledyr: Nogen køer kan godt dø, og du kan stadig få mælk og tilføje nogle flere køer til at få ligeså meget mælk som før, man må ikke ha kæledyr som ikke kan udskiftes.
Læs også Domain Driven design bogen siger han også
Man får fornemmelsen af at I dag er lidt af en forsmag til det 2 timers deep dive som han giver i morgen om hvordan de gør det hos Netflix. Han havde mange flere gode points som jeg ikke fik med, da jeg desværre ikke er så god til at oversætte og skrive mens jeg lytter. Men jeg kan kun anbefale at se det når det kommer online.