Forhistorie

I denne artikel får du svar på to primære spørgsmål: “hvorfor F#” og “hvad kræver det at komme i gang?”. Men før vi kommer til det, få du en forhistorie, så du har konteksten med.

En af vores kunder driver en større tjeneste til  musikstreaming.

Deres software er splittet op i 10+ microservices alle bygget op i C#/ASP.NET og integreret med REST API’er. De havde allerede et meget velfungerende teknisk setup, da vi kom ind i projektet.

Seks udviklere, ingen testere og op til tusindvis af automatiserede tests understøttede en samlet applikation, der betjente 100.000+ samtidige brugere. Opdateringer blev deployet i et continuous delivery setup, således at der mange gange dagligt blev leveret ny software.

Det var på stort set alle måder et ret avanceret setup og et meget modent udviklingsmiljø, vi kom ind i. Det var også en virksomhed og et team der var på en rejse, hvor vi passede perfekt ind. 

Hvad var målet?

Som rendyrket softwarevirksomhed og konkurrent til en af de musiktjenester, der ofte nævnes som eksempel på moderne softwarevirksomheder, var kravene til performance meget høje. Det betød, at der var et meget højt fokus på kvaliteten af softwaren og arkitekturen, og krav om et meget fleksibelt deployment setup. Stabilitet og performance er også meget vigtige i et marked med kræsne brugere og store spidsbelastninger. 

Målet var ikke bare høj kvalitet – målet var perfektion. I DevOps, i koden, i teamet – alt omkring tjenesten skulle køre i absolut højeste gear.

Det var her, vi kom ind i billedet.

Softwarearkitekturen

Som tidligere nævnt var applikationen delt op i en række mindre, selvstændige services. Det er nærmest en nødvendighed for den type applikation fordi dele af den (betalingsmodul og loginmodul for eksempel) slet ikke har det samme behov for kapacitet, som andre moduler.

Det fleksible microservices setup giver mulighed for at ”skrue op” for kapaciteten automatisk, når behovet er der. Det betyder at services der kører konstant (spillelister for eksempel) har brug for en stabil, men også forudsigelig høj kapacitet, mens andre (brugeroprettelse) har brug for en mere fleksibel løsning. Kører der for eksempel en større marketingkampagne i en periode, kan antallet af nye brugere mangedobles.

Fordi den samlede tjeneste er en white label-løsning, har serviceudbyderen ikke nødvendigvis adgang til information om, hvilke af deres partnere, der kører hårdt på med en kampagne i en given periode. Det betyder at de er nødt til at kunne reagere hurtigt og håndfast på øgede krav til kapacitet.

Ikke overraskende, men arkitekturen var skræddersyet til dette setup.

Ligesom det høje fokus på kvalitet, lå en microservice-baseret arkitektur perfekt til vores kompetencer.

Hvad var målet?

Målet var, kort fortalt, en bedre softwareapplikation. En applikation der, kan bære forretningen over en periode på 10 år.

Der var fem mere konkrete mål:

• Koden skulle kunne videreudvikles i 10 år
• Koden skulle kunne deployes kontinuerligt (mange gange om dagen)
• Koden skulle være let at læse
• Koden skulle kunne testes
• Teknisk gæld skulle kunne betales af med det samme

For at levere på disse mål anvendte vi en række sunde programmeringsprincipper fra funktionsorienteret programmering, herunder immutability og structural equality, for at nævne et par stykker. Disse principper bragte os et langt stykke af vejen mod vores mål, men det var også tydeligt, at C# til dels stod i vejen for, at vi kunne levere på det niveau, vi gerne ville. 

Derfor begyndte vi gradvist at anvende F# der, hvor det gav strategisk mening. Men hvorfor F#? Fordi du automatisk følger en række af de førnævnte principper, når du skriver F#. Vi oplevede derfor øget produktivitet, færre fejl og mere koncis og læsbar kode.

Og selvfølgelig fordi sprogene kan sameksistere i harmoni, fordi de afvikles på .NET platformen, hvorfor F# var det oplagte valg. Vi kunne anvende F# strategisk, uden at skulle sætte farten ned eller skrive allerede fungerende kode om.

Hvad vi lærte

Før du kan komme i gang med F#, er der nødt til at være to ting på plads:

• En kritisk masse af udviklere med interesse for F#
• Peer review proces – læs eventuelt vores tanker om code reviews her

Mængden af udviklere skal til, fordi der skal være nogle at sparre med i processen frem mod idiomatisk F#, og fordi et større team gør dig mindre sårbar. Men bemærk: F# er så nemt at komme i gang med, at i ikke behøver erfarne F# udviklere fra start.

Peer review processen er vigtig, fordi det er en god platform til vidensdeling på tværs af teamet. Ikke bare i forhold til at lære nyt, men også i det daglige arbejde. Code reviews er den fælles platform, der binder vores filosofi og principper for softwareudvikling sammen, og sikrer at den bliver spredt fra vores arkitekter til juniorer og udviklere hos kunderne.

Vi satte hurtigt et meget stærkt hold fra vores side, og de har, udover at løse denne konkrete opgave for vores kunde, også været evangelister internt i Copenhagen Software. Det er nu en fast begivenhed for vores konsulenter at tage på konferencen F# eXchange i London hvert forår.

Hvor vi endte

I skrivende stund har teamet netop fejret et helt år uden nedbrud i systemet – imponerende i betragtning af, at der er tale om en enorm tjeneste til musikstreaming.

I det forløbne år har teamet deployet kodeændringer 10-20 gange om dagen med automatiske tests, og de har haft 100.000+ samtidige brugere.

Udover 10-års perspektivet, som vi af gode grunde ikke har afprøvet, lever kodebasen og teamet, der arbejder i den, op til de oprindelige målsætninger.

Kodebasen er ikke udelukkende i F# i dag – der er stadig masser af C# i applikationen, men der er services, der udelukkende er skrevet i F#.

Nysgerrig efter mere?

Denne artikel er baseret på vores ekstremt populære foredrag “F# – hvorfor, hvordan og til hvad?”. Det er et foredrag vi har holdt for blandt andet Dansk IT, SimCorp, Jyske Bank og Mødegruppe for Funktionelle Københavnere.

Er du interesseret i at få den fulde historie med mulighed for at stille spørgsmål undervejs? Læs mere om foredraget her.

Hvorfor principper for softwareudvikling?

Vi har samlet vores principper for softwareudvikling. Fordi vi ser det alt for tit – nærmest hver gang. Hver gang vi ansætter en ny medarbejder, får et nyt teammedlem hos en kunde eller begynder at arbejde tættere sammen med en ny udvikler. Hvad er “det”? Dårlige vaner, manglende struktur… og sjusk.

Dårlige vaner kommer snigende ind på os, og før vi ved af det, er de blevet en del af vores måde at arbejde på. Stort set alle vi arbejder med får en brat opvågning. Fordi vi – i modsætning til mange andre – kontinuerligt arbejder med nogle faste principper. Og fordi vi er mange, der konstant holder hinanden op på de principper.

Det er både vores løfte til hinanden, men også vores løfte til vores kunder. En udvikler fra Copenhagen Software har styr på nogle basale, men meget vigtige principper. Det er selvfølgelig også et løfte til nye medarbejdere. Hos os, kommer du til at blive rigtig, rigtig skarp på de her principper (og en masse andet).

Og mindst ligeså vigtigt – det er vores løfte til os selv. En række principper, der formaliserer nogle af de principper vi mener kan gøre den største forskel. Både som oplæring til juniorer, men også som opfriskning til erfarne udviklere.

Code reviews

Code reviews er hjørnestenen i vores måde at opkvalificere vores udviklere på. Det er gennem systematisk gennemgang af hinandens arbejde, at vi deler viden, diskuterer løsningsmetoder og kvalitetssikrer. Du kan læse meget mere om, hvorfor vi ser code reviewet som et ekstremt vigtigt element for et kvalitetsbevidst udviklerteam i denne artikel.

I code reviewet sikrer vi, at koden lever op til nummer to af vores principper for softwareudvikling.

C#-principper for god, robust kode

Stort set alle vi møder, der skriver objektorienteret kode, fastholder at deres kode er SOLID. Går man dem lidt på klingen, kan mange nævne, hvad principperne står for. Lidt færre kan uddybe de enkelte principper mens ganske få reelt kan forklare principperne.

Vi tager den rejse et skridt videre og arbejder konstant med udfordre hinanden – ikke på forståelse af principperne, men abstraktionerne, der ligger til grund for dem. Men vi stopper ikke ved mestring af SOLID. Vi har tilføjet vores egne principper for softwareudvikling (i C#). Vi søger konstant:

• At simplificere vores kode, og begrænse kodens kompleksitet – i størrelse eller i form – så kodeopgaver altid er overskuelige
• At etablere konventioner for koden, så alle udviklere hurtigt og nemt kan forstå dele af projektet
• At undgå at bruge null  – det virker måske som en detalje, men det er virkelig noget, der giver mange problemer hos vores kunder

Målet er naturligvis at skrive kode der:

• Gør det, den er designet til
• Ikke stopper uventet
• Har en fornuftig performance i forhold til behovet
• Kode som er nem og billig at ændre

Automatiserede tests

En vigtig del af en automatiseret proces omkring udvikling og frigivelse af software er kvalitetssikring, så du ikke frigiver software med fejl i. Code reviews er en meget vigtig del af den proces, men automatiseret testing er også absolut essentielt.

Det er en meget effektiv måde at automatisere repetitive testopgaver i en struktureret testproces. Vi arbejder med automatiserede tests, der sikrer at blandt andet vores API’er opfører sig, som vi forventer under stress. Målet er ikke at erstatte manuel QA og manuelle tests, men snarere at komplimentere, så vi får den sikrest mulige pipeline.

Automatiserede tests er, ligesom code reviews, et meget vigtigt princip for os. Det er de, fordi de ikke bare har værdi i sig selv, men også er en byggesten for det næste princip for softwareudvikling – continuous delivery.

Continuous delivery

CD er operationalisering af LEAN-tankegangen. Vi bygger software i mindre bidder, der kan deployes stort set kontinuerligt. På den måde sikrer vi, at der ikke på noget tidspunkt ligger ”død” kode på arbejdsbordet. Vores kode kommer ud at arbejde for os, så hurtigt som overhovedet muligt.

CD bygger videre på nogle af de andre principper. Uden code reviews, automatiserede tests og processer til hurtigt og nemt at rulle ændringer tilbage, er CD en racerbil uden rat og bremser. Det er ikke nogen langtidsholdbar løsning.

CD er det sidste trin af en automatiseringsproces, der gør os i stand til at bygge, gennemgå, justere og frigive ændringer i softwaren løbende.

Principper for softwareudvikling generelt

”God” software og ”dårlig” software er en lidt besværlig kategorisering at arbejde med uden nærmere definerede kriterier. Derfor arbejder vi med vores principper for softwareudvikling. Vi fokuserer på dem i vores arbejde, vores mentoring og vores oplæring. Principperne er ikke udtømmende – vi kan af gode grunde ikke fokusere på alt – men sikrer en overordnet høj kvalitet i arbejdet.

Og det er essensen af høj kvalitet for os – konstant at udfordre os selv til at bygge løsninger, der er bedre og mere holdbare. Kontinuerligt at skubbe til rammerne for effektiv deployment, så vi kan bygge endnu mere kvalitet ind i den software, vi bygger.

Cloud er her og der og alle vegne. Det er et buzzword der er vokset fra IT-afdelingen og via smartphones ind i dagligstuerne. Om det er Dropbox, iCloud, GMail eller noget fjerde, så er de fleste danskere koblet op på cloud teknologi i en eller anden udstrækning.

Hvad er Cloud?

Cloud er en fællesbetegnelse for en række netbaserede tjenester og ydelser. Tidligere var de installeret på virksomhedernes egne servere. I takt med at internettets grundlæggende infrastruktur er blevet udvidet og hastighederne dermed er øget, er en stor del flyttet ud på internettet.
Det gælder naturligvis backup og lagring generelt, men i de senere år er mange softwareudbydere også begyndt at sælge cloudbaseret software. Office365, Netflix, Skype og assistenterne i vores smartphones er alle eksempler på cloudbaseret software – ligesom Facebook og de andre sociale medier er.

Cloud computing er  en brug af computere, hvor programmer eller data ikke ligger på den lokale maskine. I takt med at teknologien udvikler sig, taber begrebet gradvist betydning på samme måde som ordet ”digitalt” stille og roligt taber betydning. Indenfor en overskuelig fremtid giver det ikke længere mening at tale om ”cloud” fordi det kommer til at være standarden. Til den tid vil vi sandsynligvis nævne, hvis noget ikke er cloudbaseret – det der også hedder ”on premise”.

Hvor er mine data?

Begrebet ”cloud” eller ”skyen” kan godt være lidt misvisende. Det handler ikke om at dine data svæver rundt i luften, men at data og applikationer kan tilgås gennem forskellige servere/datacentre. Når dine data og applikationer kan tilgås gennem mange datacentre, er de de facto i skyen. Data, der er alle steder, er på sin vis ingen af de steder. I hvert fald ikke udelukkende.

I takt med at cloud-teknologien er blevet mere udbredt, har udbyderne arbejdet på at nedbryde de barrierer der holder virksomheder fra skyen. Det betyder blandt andet at du kan få en ren europæisk cloud, for at undgå at for eksempel NSA kan få adgang til dit materiale.
Det kan også være, at du af sikkerheds-/GDPR-årsager gerne vil vide, hvor dine data befinder sig lidt mere specifikt. Uden at det betyder at du gerne vil have din data på din egen fysiske server.

Fordele ved cloud

Der er mange fordele ved cloud, men først og fremmest handler det om fleksibilitet, simplificering af administration og betalingsmodel. Men der er også muligheden for at skalere din cloudserver, hvis dit behov stiger pludseligt. Ikke bare i forhold til plads, også i forhold til hastighed – det er særligt brugbart, hvis du har en sæsonbetonet virksomhed.
Især skaleringsdelen er et virkelig stærkt argument, hvis det kombineres med en microservice-baseret arkitektur. Det kan du læse mere om her – den korte forklaring er, at du får mulighed for at skalere hver enkelt del (service) i din software individuelt – det sikrer at du kun køber den serverkapacitet du har behov for.

Cloudteknologien har også gjort software-as-a-service muligt. Begrebet dækker over de utallige tjenester der, typisk med månedlige abonnementer, tilbyder en softwareløsning. Office og Dinero er to eksempler på SaaS, men der findes også forskellige nært beslægtede fætre i Dropbox, GMail, iCloud og lignende. Nogle af dem er strengt taget nærmere hardware-as-a-service, men det er stadig abonnementsbaserede ydelser faciliteret af cloudteknologi.
Cloud giver mulighed for at købe og bruge softwaren overalt (hvor der er internet). Det giver en stor fleksibilitet i forhold til hjemmearbejdspladser, devices, og det gør dig meget mindre afhængig af hardware.

Sidst men ikke mindst, er lagerpladsen stort set ubegrænset og backup, integration mellem platforme og genskabelse af backups typisk meget mindre teknisk krævende at bruge.
Med alle de fordele er det svært ikke at være begejstret, men der er også nogle ulemper.

Ulemper ved cloud

Selvom meget af teknologien og hardwaren bliver ”gemt væk” til fordel for en strømlinet brugerflade, kan der stadig opstå tekniske udfordringer. Selv de bedste udbydere af cloudløsninger har tekniske problemer fra tid til anden. Også selvom de har en høj grad af kvalitetssikring.
Men vigtigere endnu er den åbenlyse udfordring at cloud-teknologi kræver internetadgang. Måske ikke noget vi tænker over i hverdagen, men det kan give udfordringer i nogle situationer, hvor vi ikke har den adgang til internettet, som vi er vant til i Danmark.

Sidst men ikke mindst, kan der være sikkerhedsudfordringer ved at bruge cloud. Intet på internettet er fuldstændig sikkert, så der er altid en risiko for hackerangreb eller datalæk. Derfor er det en god ide at vælge den mest pålidelige udbyder, så du er sikker på, at de gør alt for at holde din data sikker.
I forhold til fortrolig, forretningskritisk information er det en rigtig god ide at have sikre passwords og totrins-verificering. Ofte i form af en kode via sms, der skal tastes ind efter dit password.

Opsummering:

Fordele ved cloud:

• Fleksibel kapacitet – det gør det nemt at skalere (både op og ned)
• Facilitering af andre ydelser (Hardware/Software as a service
• Fleksibilitet i forhold til devices og eventuelle hjemmearbejdspladser
• Ubegrænset lagerplads
• Nemmere integration af tjenester

Ulemper ved cloud:

• Kræver internet
• Sikkerhedsudfordringer – alt med internetadgang har en (ekstremt lille) risiko for at blive udsat for hackerangreb mm.
• Uptime/tekniske problemer – selvom cloud-teknologien er meget stabil, vil der altid være udfald

Vi har arbejdet med cloud i omkring ti år. De erfaringer bruger vi dagligt til at sikre gode implementeringer af cloud for vores kunder. Typisk betyder det systemer bygget op i microservices, der kan skaleres uafhængigt ved hjælp af cloud-teknologien.
Vi kan hjælpe med inspiration i form af foredrag.

Interaktive code reviews i praksis

• Forstå hvilket problem, koden skal løse
• Tænke kritisk over løsningen
• Overveje om koden ville være forståelig uden en guidet tour

Socialt pres

Mangel på fleksibilitet

Introspektion

Code reviews på den rigtige måde

• Udføres af revieweren – alene
• Foretages asynkront

Konklusion

Hvad er software?

Computerprogrammer, programmer eller software er en sekvens af instruktioner, der fortæller en computer, hvordan den skal løse en bestemt opgave. Hver instruktion er designet til at kunne eksekveres på en computer. Essensen i en computer er, at den kan eksekvere programmer.

Software er en overordnet betegnelse for samlinger af programmer. Ordet software står i kontrast til hardware, der dækker over fysiske dele – RAM, processor, harddisk og så videre.

Softwareudviklerens rolle

Instruktionerne i et program er som regel specificeret af en udvikler, programmør, koder eller (software)arkitekt. Han skriver dem i et programmeringssprog, der gennem en compiler (der oversætter kildekode til maskinkode) kan fortælle, hvad computeren skal. En computer kan ikke direkte forstå den kode, udvikleren skriver. Den skal som udgangspunkt enten bruge en compiler til at omsætte koden til maskinkode eller en interpreter til at eksekvere koden.

Softwareudvikleren arbejder med andre ord på et niveau, hvor der gælder en række regler. Hans arbejde i det niveau, omsættes til et andet niveau med andre regler. Teoretisk set kunne udviklere godt arbejde direkte i maskinkode, men det ville kræve meget mere arbejde og være langt sværere at læse. Hvorfor du gerne vil have kode, der er let at læse, kan du blandt andet læse mere om her.

Hvordan fungerer et program?

Et program lagres normalt på en harddisk eller i skyen – tidligere har vi brugt disketter, CD-ROM, DVD’er og endda kassettebånd. Over de seneste år har forbedrede internetforbindelser skabt muligheden for at køre software fra skyen – ofte som software-as-a-service (forkortet SaaS).

Fra lagringsmediet overføres programmet (eller dele af det) til RAM – computerens arbejdshukommelse, hvor det løser den opgave, det er designet til.

Programmet står normalt ikke alene, men kører under et styresystem som for eksempel Windows, IOS eller Linux. Styresystemet styrer afviklingen af opgaver og har typisk en grafisk brugerflade, der gør det tilgængeligt for almindelige brugere.

Styresystemet sørger for at jonglere hardware og software og sikrer at resurser bliver prioriteret og styret og at de forskellige elementer kan udveksle data.

Styresystemer er vokset i omfang og indeholder i dag typisk drivere, grafisk brugerflade, widget toolkits og småprogrammer (lommeregner, musikafspiller, tekstredigering, browser etc.). Alle elementer der, strengt taget, ikke er en del af styresystemet, men oftest kommer sammen med det.

Typer af software

Software fordeler sig nogenlunde i seks forskellige kategorier, hvoraf det kun er et par stykker, normale brugere er i kontakt med. De seks kategorier er:

• Softwareapplikationer (eller apps) dækker over alt fra spil, tekstbehandling, projektstyring og databaser til email, bogføring og videoredigering
• Hjælpeprogrammer er applikationer designet til at hjælpe systemadministratorer og softwareudviklere
• Styresystemer er, som tidligere nævnt, mellemledet mellem brugeren af en computer og dens hardware
• Boot programmer ligger i computerens skrivebeskyttede hukommelse og sørger for, at styresystemet bliver kørt og at computeren starter op og er klar til brug
• Firmware er software, der er indbygget i et stykke hardware. Firmware bruges, når programmet kun sjældent eller aldrig skal ændres og har brug for at køre selvom computeren er slukket
• Microkode programmer er en intern del af computeren der kontrollerer hardwareelementer i computeren. Det er ikke en type programmer, der er tydelig for brugerne af et system

En normal bruger vil typisk kun bruge softwareapplikationer og styresystemer, og mens hjælpeprogrammer typisk bruges af IT-specialister, så er de resterende tre typer software som regel forbeholdt hardwareproducenter.

Udviklingen af softwareindustrien

Hvor software tidligere har været relativt simple og isolerede systemer, er det i dag svært at drive en virksomhed uden god software. Simpelthen fordi konkurrenten, der bruger de digitale muligheder intelligent vil have en enorm fordel.

Et eksempel, der efterhånden er blevet brugt lidt for mange gange, er Netflix. En virksomhed, der så muligheder for at bruge software til at løse et problem hos forbrugerne bedre end deres konkurrenter.

Det hører naturligvis med til eksemplet, at de muligheder opstod i kølvandet på voldsomt forbedret infrastruktur (internethastighed) op gennem 00’erne. Netflix’ succes sendte dem i en positiv spiral, hvor TV-producenter i dag bygger Netflix-apps i deres fjernsyn. Der er endda producenter, der har Netflix-knapper på fjernbetjeningerne.

Hvis du er nysgerrig på, hvordan du bruger software som facilitator i din virksomhed, kan du læse mere her.

IT generelt og mere specifikt software er ikke længere en mindre del af virksomhederne. Det er blevet en af de vigtigste i mange af verdens allerstørste virksomheder. I takt med at vi bliver endnu mere digitale, vil behovet for kvalitetssoftware kun blive større. Det er ikke utænkeligt at programmering i en eller anden udstrækning vil sprede sig til mange andre erhverv og uddannelser.

Softwarearkitektur

Også på arkitektursiden er der sket store fremskridt. Software eksisterede tidligere som særskilte enheder, der ofte kun var forbundet gennem skuffesystemer og manuelle indtastninger. I dag er integrationer og API’er helt basale elementer i stort set al software. Det er ikke bare i hverdagen, at vi er mere forbundne – det er et krav, at din software også er. De virksomheder, der forstår at bruge dataopsamling og software intelligent har en kæmpe konkurrencefordel. Både på eksisterende forretningsområder og potentielle nye områder.

Det kunne for eksempel være gennem et optimeret salgsværktøj, som det vi har hjulpet Widex med (læs mere her). Men med IoT er det nærmest kun fantasien, der sætter grænserne.

Men applikationer, der nemt kan forbindes med hinanden er ikke den eneste måde, softwarearkitektur har udviklet sig på. Hos mange af vores kunder arbejder vi med microservices – selvstændige enheder i den enkelte applikation. Hvorfor det kan være en god ide, kan du læse mere om her, men i korte træk betyder det, at vi kan bygge software, der understøtter forretningen endnu bedre.

Udviklingen mod microservices er en konsekvens af de muligheder, udviklere har fået med cloud, hurtigere hardware og større fokus fra forretningen. Det betyder at software i dag reelt kan være en helt anden størrelse end for bare fem år siden.

Software driver i dag forretninger, og vores kunder er enige med os – vi er ikke et eller andet tilfældigt konsulenthus – vi er de bedste i Danmark.

Software i sig selv er sjældent målet. Det skulle da lige være for en softwareproducent eller en softwarekonsulent. Selv der er software for det meste et middel til at opnå noget. Det giver mening at se på software som facilitator. Et værktøj.

Et fantastisk avanceret og spændende værktøj, men ikke desto mindre et værktøj.

Vi har specialiseret os i at bygge de absolut bedste værktøjer på .NET-platformen – ofte i en form for microservice arkitektur. Det gør vi fordi microservices giver nye muligheder for at bygge software, der passer til kundens behov. Vi kan bygge mindre, uafhængige moduler tilpasset virksomhedens forretningsgange. Det synes vi giver mere mening end en stor samlet løsning, hvor alle afdelinger smelter sammen i en softwareapplikation.

Det betyder, at de enkelte moduler kan være ”specialister” på deres felt og kan skaleres uafhængigt. Det svarer lidt til klassisk organisationsstruktur i en virksomhed. I en mindre virksomhed vil alle typisk arbejde sammen og have overlappende ansvarsområder. I takt med at virksomheden vokser, vil der blive etableret afdelinger med interne service level agreements. Det betyder i bund og grund at alle afdelingers ansvarsområder er klart defineret, og at der er klare regler for, hvordan afdelingerne kommunikerer indbyrdes.

På samme måde organiserer vi software omkring forretningsbehov og specialistkompetencer. Software opbygget til at udfylde et specifikt behov i forretningen og designet, så den nemt kan kommunikere med resten af forretningen.

Software som facilitator – fokus på forretningen

Som udviklere har vi altid forsøgt at bygge software, der passer til vores forretning. Men i takt med at software er blevet mere og mere vigtig for stort set alle typer virksomheder, er kravene til manøvredygtighed, udviklingshastighed og tilpasning steget eksponentielt. For bare 10-15 år siden var det store sager, hvis et økonomi- og et CRM-system kunne kommunikere nogenlunde effektivt med hinanden. I dag bygger vi komplicerede løsninger til musikstreaming, produktionsstyring og e-handelssystemer, der integrerer med økonomi og lagerstyring.

På grund af den tredje industrielle revolution er software blevet en vigtigere og vigtigere del af praktisk taget alle forretninger. Hvad enten det er 100% digitale forretninger, der sælger digitale ydelser digitalt, traditionelle offlinevirksomheder, der bevæger sig mod en online fremtid eller virksomheder, der driver al forretning offline, så er der masser af værdi at hente i god software.

I takt med at internettet spreder sig til alt fra elpærer til atomreaktorer og flere og flere industrier bliver ramt af digitalisering, vil det kun blive mere og mere relevant med software der på den ene side fungerer uafhængigt, men samtidig integrerer fuldstændig sømløst med resten af forretningens software.

Det er her der hviler et tungt ansvar på os som udviklere og arkitekter. Det er os, der forstår hvordan vi bedst muligt bruger software som facilitator, der kan understøtte forretningen – derfor er det vigtigt, at vi holder fast i vores principper og sørger for at holde et højt niveau på vores kode og arkitektur.

Håndværket skal være i orden

Som markedet ser ud lige nu, er der mangel på dygtige udviklere i Danmark og virksomhederne begynder derfor at kigge udenfor landets grænser. Det er der ikke som udgangspunkt noget problem i, men vi oplever alligevel at kvaliteten ikke lever op til de standarder, vi sætter for god software.

Lavkvalitets kode kan sagtens virke. Men dårlig kode vil over tid være en så stor modspiller for forretningen, at det i sidste ende kan tvinge virksomheden i knæ. Men hvordan er det, at god kode kan give din forretning de optimale betingelser? Er det ikke bare meningen at software skal virke hurtigst muligt og til den laveste pris?

Hurtig leveringstid og lav pris er selvfølgelig vigtige elementer for enhver virksomhed, men der er også andre essentielle elementer i en softwareløsning. Software kan på mange måder sammenlignes med en bygning – problemet med software er bare, at det kræver en høj teknisk forståelse at kunne vurdere kvaliteten.

Hvad får forretningen ud af en bedre kodebase? Vi har samlet 6 punkter:

1. God software er nemmere at bygge videre på

En god softwareapplikation er ikke bare bygget til at håndtere de nuværende behov. Den er bygget, så den kan udvides, modificeres og skaleres uden at skulle skrives om. Det betyder ikke at vi altid bygger et fundament, der passer til et palads, men det betyder at vi sikrer os, at der er plads i arkitekturen og teknologien til at forretningen kan vokse. På den måde sikrer vi at softwaren altid bliver facilitator frem for bremseklods.

2. God kode er nem at læse

Det er et af de vigtigste fokusområder for en udvikler – at koden skal være nem at læse. Det betyder, at det er hurtigere og lettere for fremtidige udviklere at læse din kode. Hvad er nemt at læse? En konsistent stil med mellemrum, indrykninger og betegnelser, der giver mening.

En tommelfingerregel lyder ”kode bliver skrevet en gang, men læst hundredevis af gange” – derfor er det så vigtigt at koden er læsbar. Både, som nævnt ovenfor i formateringen, men også at kommentarerne til koden forklarer hvorfor koden gør det, den gør.

3. God kode er simpel

God kode er grundlæggende simpel. Simplere kode er lettere at læse og vil generelt have færre bugs end kompliceret kode. Det er en af grundene til at vi er glade for F#, men princippet gælder på tværs af sprog. Simpel kode er lettere at læse, overskue, vedligeholde og modificere.

4. God software er fleksibel

Fleksibilitet er ikke bare i koden, men også i arkitekturen som heldhed. Fleksibilitet er en af grundene til, at microservice-arkitektur er så populær. Men på kodeniveau er det også vigtigt at sikre, at der kan justeres, udbygges og genbruges elementer, efterhånden som behovene ændrer sig. Fleksibilitet er den ultimative facilitator.

5. Nem at vedligeholde

Langt størstedelen af al kode indeholder bugs – derfor er det vigtigt at det er tydeligt, hvorfor du har skrevet et givent stykke kode. Simpel kode med gode kommentarer er også nemmere at rette i. Det er her, at de virkelig dygtige udviklere stikker af fra feltet – ved at skrive kode, der scorer højt på ”maintainability” – hvor nem den er at vedligeholde.

6. Den virker

Det giver måske lidt sig selv, men kode skal helt grundlæggende virke. Koden skal løse de problemer, den er skrevet til at løse efter hensigten.

Softwarens arkitektur er ligeså vigtig som koden

Men det stopper ikke der – det er som tidligere nævnt ikke kun koden, der skal være simpel, overskuelig, fleksibel og nem at vedligeholde. Det samme gælder for arkitekturen. Og så er vi tilbage ved microservices. Den modulære struktur i microservices gør det til en tilgang til arkitekturen, der er så fremtidssikret, som man kan være, når vi nu ikke kender fremtiden.

Microservice-arkitekturen er bygget, så de enkelte moduler i softwaren kan opgraderes, modificeres og udskiftes uafhængigt. Og de kan bygges op på forskellige teknologier. Det betyder også, at alle moduler kan omskrives, fjernes eller skiftes ud, hvis behovet opstår. Det er netop fleksibiliteten der gør microservices til en superfleksibel arkitektur.

Men det er ikke kun i forhold til fremtidssikring at microservices har sin berettigelse. Hvis du skal bruge din software som facilitator, er det vigtigt at den understøtter forretningen så godt som overhovedet muligt. Så er det smart at de enkelte dele af softwaren kan opgraderes og modificeres uafhængigt.

Det betyder at alle afdelinger i virksomheden teoretisk set kan styre hvordan, hvornår og hvorfor deres software skal opdateres – dog med forbehold for, at den samlede mængde udvikling skal passe til størrelsen på teamet selvfølgelig.

Microservice-arkitektur giver mulighed for skræddersyet serverkapacitet

Det giver også mulighed for at skalere de enkelte moduler gennem en Microsoft Azure eller en Amazon Web Services-løsning. Hvor forretningens software tidligere kørte på en fysisk maskine enten i virksomheden eller hos en leverandør, kan den i dag køre fra cloudtjenester. Det giver mulighed for at købe præcis den kapacitet, du har brug for, når du har brug for den. Hvis du driver en sæsonbetonet virksomhed, kan du have brug for måske to, tre eller ti gange mere kapacitet i peakperioder.

Med cloud-baserede microservices kan hver enkelt modul i forretningen få allokeret den kapacitet den har brug for. Så behøver i ikke have en hel serverpark stående fordi dit behov stiger voldsomt i december måned. Du kan betale for den kapacitet, du bruger – når du bruger den.

Igen handler det om at teknologien er tilpasset forretningens behov – ikke omvendt.

Hvorfor nu? Hvad har ændret sig?

Det er egentlig relativt simpelt – processorkraft, cloudteknologi og ændrede behov. De mange uafhængige komponenter har brug for mere hukommelse og CPU. Det er ikke længere et problem – vi har så meget processorkraft og båndbredde til rådighed, at vi til dels kan flytte fokus fra performance til andre ting.

Det samme gælder for cloudteknologien, der først for alvor er blevet foldet ud i takt med at den globale digitale infrastruktur er blevet bedre.

Og det er i kombinationen af de to teknologier at magien for alvor opstår. Det er når vi bygger software, skræddersyet til forretningens behov. Det er en ny verden, men det er absolut essentielt for at være succesfuld med en digital transformation. Der skal du kunne parre forretningensbehov med de digitale muligheder og bruge software som facilitator.

Digital transformation er et nøgleord fordi den stiller øgede krav til integrationen mellem og funktionaliteten i vores software. I den verden er vandfaldsmodellen og monolitten i højere og højere grad for langsom.
Er du interesseret i at læse mere om microservices, kan du gøre det her.

Hvad er Microservices?

Microservices er et af de hotteste buzzwords indenfor softwarearkitektur lige nu – det er en tilgang til softwareudvikling, der kommer som en direkte videreudvikling af serviceorienteret arkitektur og til dels også agil-/scrum-baseret projektledelse.

Microservices er en god måde at opbygge software på, hvis du er interesseret i:

• At sætte forretningens behov i centrum
• At reducere time-to-market for nye features med continuous delivery
• At kunne vælge det bedste værktøj til hver enkelt opgave
• Fleksibel software, som kan videreudvikles i årevis
• Uendelig skalering
• Bedre kommunikation mellem forskellige systemer
• Forenkling af forretningsprocesser
• At kunne genbruge services og fokusere på udvikling af kritiske, nye elementer

Vandfaldsmodellen

I mange gik monolitten og vandfaldsmodellen hånd i hånd og udvikling foregik i (ofte lange) fastlåste faser med en større implementering i enden. For at have historikken på plads, kommer her en kort gennemgang af den tilgang til udvikling – hvis du har helt styr på den, så kan du springe de to næste afsnit over og gå direkte til ”Alternativet: microservices”.

Vandfaldsmodellen går i korte træk på at bygge komplette systemer i en samlet proces. Du kan sammenligne det med at bygge et hus, hvor du går gennem faserne specifikation, design, implementering, test, integration og vedligeholdelse. Når vandfaldet så er færdigt, er tanken, at du står med et færdigt hus, der lever op til alle de opsatte krav.

Det giver et meget langt feedback loop (hvis der overhovedet er et feedback loop) og dermed en risiko for at udvikle i en forkert retning og bruge mange resurser på det. Har du for eksempel taget et forkert valg i designprocessen eller overset noget i kravspecifikationen, så kan der gå måneder før det bliver rettet. Typisk går vandfaldsmodellen hånd i hånd med mindre frekvente deployments (eller endda Big Bang), hvilket også betyder at du kommer til at have mange timers arbejde (design, kode og så videre) til at ligge “dødt” i et testmiljø.

Hvad er en monolit?

Monolitten er betegnelsen for en samlet, selvunderstøttet softwarestruktur. En applikation, der rummer alle delene af din software i en udelelig komponent.

I takt med at computere og internet er blevet hurtigere og software har fået en større betydning i mange virksomheder, er begrænsningerne ved monolitten blevet tydelige: arkitekturen kommer til kort for softwareløsninger, der skal dække flere forretningsområder, eller i applikationer, der bruger flere forskellige teknologier. Det er, lidt forenklet, en arkitektur, der hører en tid med mindre applikationer til.

Alternativet: microservices

Kort fortalt er microservices en måde at opbygge en softwareapplikation på, hvor udgangspunktet er at se på den som en samling af mindre tjenester, der alle kører deres egne processer og kommunikerer via simple mekanismer – oftest et API. Hvor du kan se en monolit som en samlet struktur, er microservices mere som LEGO-klodser. Det kan eksempelvis være en loginklods, en playliste-anbefalingsklods eller en betalingsklods.

Det giver fleksibilitet i udviklingen, fordi kommunikationen tjenesterne imellem er skarpt defineret via deres API. Derfor kan du bruge den rigtige teknologi til den enkelte tjeneste i stedet for at bruge den teknologi, som tjener hele systemet bedst. Med microservices får du frihed til at vælge .NET baserede programmeringssprog, Python, eller Java eller noget tredje. Baseret på, hvilken teknologi der er bedst til den enkelte tjeneste. Du har også  frihed til at vælge den bedste cloud platform, den bedste database, den bedste webserver etc.

Fordi den enkelte microservice er lille, og har en meget klart defineret grænseflade, kan microservicen opdateres uafhængigt af resten af systemet. Dermed kan hele systemet løbende tilføjes nye features eller fejlrettelser. I modsætning til monolitten, hvor nye features leveres ved en opdatering af hele systemet, med hvad dertil hører af procedurer og nedetid, kan microservices levere nye features til slutbrugerne hver uge, hver dag eller hver time.

Hvad er en microservice?

En microservice er en softwarekomponent, der kan udskiftes og opgraderes uafhængigt. Der er ikke nogen hård definition på størrelsen, så det er op til arkitekten at sikre at de enkelte moduler er tilpas små og uafhængige til, at de kan opgraderes og deployes hurtigt.

En microservicearkitektur har et minimum af central styring og kan bruge forskellige teknologier til at opbevare data – mere om det i næste afsnit.

For at opsummere, så er en microservice kendetegnet ved:

• • Et velafgrænset modul i en applikation eller et system
• • Uafhængigt opgraderbar og udskiftelig
• • Ikke bundet til specifik teknologi
• • Begrænset i omfang – dækker en specifik, afgrænset funktion
• • Tilgængelige kontaktflader

Og så er der skalerbarheden, der ofte følger med – de enkelte moduler i applikationen er uafhængigt skalerbare, fordi de ikke behøver at bruge samme tekniske setup.

”Microservices is a label, not the description”. Citat: Martin Fowler i denne artikel.

Microservices og cloud – det perfekte par

Du kan godt køre en microservicebaseret applikation on premise, men i langt de fleste tilfælde ligger den serviceopdelte arkitektur i skyen. Det gør den især fordi cloud infrastruktur støtter op om en af microservicearkitekturens styrker – den uafhængige og dynamiske skalerbarhed.

Hvor en monolit skaleres ved at køre hele systemet på kraftigere servere, kan du med microservices nøjes med at skalere de specifikke moduler, du har behov for. Det giver dig et mere fleksibelt og et billigere setup.

Hvor monolitten er en stor supertanker, kan du se microservices-applikationen som en flåde af samarbejdende speedbåde, der hver især kan sejle hurtigere eller langsommere end resten af flåden. Synergien mellem de dynamiske cloud-muligheder og den opdelte arkitektur i microservices giver en manøvredygtighed som aldrig før.

Microservices er en meget velegnet tilgang, hvis du har en lokal monolit, du gerne vil have i en cloud tjeneste: du bryder gradvist monolitten ned i microservices, og flytter dem løbende til en cloudplatform.

Decentraliseret styring og datahåndtering

Hvor en monolitisk applikation bygges med en central database, ligger databaserne i en microservices-arkitektur decentralt sammen med de enkelte services. De enkelte moduler kan enten dele en database eller have deres egen. Det kan være forskellige instanser af den samme databaseteknologi, men det kan også være bygget på forskellige teknologier – såkaldt ”polyglot persistence”.

Polyglot persistence kan bruges i en monolitisk arkitektur, men forekommer oftest med microservices fordi den arkitektur støtter op om individuelle teknologivalg for de enkelte moduler.

At decentralisere styringen med data påvirker den måde, du kan opdatere de enkelte moduler på. Historisk set har opdateringer krævet skarpt fokus på at alle dele af monolitten fortsat kan kommunikere med hinanden – med microservice-arkitekturen skal API’er holdes konstante, men udover det påvirker opdateringer af de enkelte moduler ikke resten af applikationen.

Risikostyring

Kontinuerlig deployment og konstant feedback giver sikkerhed for stabilitet af den samlede applikation og prioritering af udviklingstid. Hvis du konstant deployer små opdateringer, er det nemmere at se, hvis noget giver problemer. Det er nemmere at gå tilbage til en tidligere version uden at flere måneders arbejde går tabt.

Men der er flere fordele i forhold til risikostyring. Klart definerede services med definerede API’er er ikke integrerede i samlede system, som en monolitisk applikation. Det betyder, at risikoen for at hele applikationen bliver ustabil mindskes drastisk. Typisk vil problemer, der opstår i en afgrænset service også have afgrænsede implikationer i produktionsmiljøet.

En afledt fordel ved at bruge services modulært er, at de skal kunne håndtere at andre tjenester ikke svarer. Her bevæger vi os ind på en af de ting, der gør, at du skal holde tungen lige i munden, når du bygger microservices.

Forbered hver enkelte service på det værste

Det er vigtigt, at sikre at alle komponenter kan håndtere, hvis andre komponenter ikke svarer. Helst på en måde, så brugeren så vidt muligt ikke opdager noget. Det betyder at udviklerteams der arbejder med microservices konstant skal tænke over, hvordan eventuelle fejl skal håndteres. Nogle teams arbejder endda med automatiske og planlagte kaostilstande i produktionsmiljøet, for at sikre, at monitoreringstjenester fanger alle problemer.

Alle services altid kan fejle, derfor er det vigtigt at opdage fejlene hurtigt og reagere på dem. Sofistikerede monitoreringssystemer, der kigger på både strukturelle- og forretningsmetrikker er derfor en helt essentiel del af en microservicebaseret arkitektur.

Små, løbende justeringer

En af grundene til at microservices er blevet så populære er, at arkitekturen ligger i direkte forlængelse af agil softwareudvikling ved at understøtte korte feedbackloops. Du kan konstant forbedre, justere og fejlrette i enkelte elementer i din applikation.

Med korte feedback loops bliver din udvikling meget mere manøvredygtig – det svarer til at tage mange korte skridt i stedet for få lange skridt – bortset fra, at agil udvikling ikke er langsommere end klassisk vandfaldsudvikling.

Agil udvikling er inspireret af LEAN-princippet fra Toyotafabrikkerne. Helt grundlæggende er tanken, at jo mindre arbejde du har i gang, desto mindre må du smide væk, hvis du skal skifte retning. Det understøttes typisk af sprints der, i Scrum-baseret udvikling, maksimalt varer en måned. Det står i skarp kontrast til vandfaldsmodellen, der ofte løber over både 3, 6 og 12 måneder. Med continuous integration/delivery er det ikke utænkeligt at deploye ny kode til produktion 5-10 gange om dagen. Det giver dig en ekstrem manøvredygtighed i forretningen.

Det betyder primært to ting:

• At du meget hurtigere kan rette op på fejl og komme tilbage på sporet
• At det er markant hurtigere at skifte retning, hvis forretningens behov ændrer sig (og det gør de!)

Det er to temaer, der gennemsyrer hele microservices-tilgangen – bevægelighed og fokus på forretningens behov. To helt essentielle faktorer i det nuværende og fremtidige digitale landskab.

Hvor stor er en microservice?

Der findes ikke en størrelse, men der er en guideline: den skal kunne skiftes ud og opgraderes uafhængigt. Det betyder også, at hvis du tit opgraderer de samme to services samtidig, skal du overveje at slå dem sammen.

Det er ikke et mål i sig selv at bryde applikationen op. Målet er at bruge den arkitektur, der bedst kan støtte op om forretningen.

Det betyder ofte, at de enkelte services afgrænses af forretningsmæssig organisation – centreret omkring produkter, tjenester eller særlige opgaver. Derfor undgår du interessekonflikter internt i virksomheden. Det bliver også nemmere at prioritere og scope den enkelte service, når de er uafhængige af resten af applikation.

Et eksempel: du opgraderer den del af din applikation, der sikrer, at lagerstatus og tilgængelighed på hjemmesiden er synkroniseret. Kundeservice er glade for den nye feature – den giver færre utilfredse kunder. Salg derimod, anser det ikke for væsentligt nok til at køre en fuld deployment med den risiko det indebærer. Salg vil gerne have, at hjemmesiden er oppe 100% af tiden.

I det scenarie er microservice-arkitekturen perfekt. Det nye modul påvirker ikke eksisterende funktioner og bør derfor ikke give nogen udfordringer.

I virkeligheden er ”micro-”-delen af microservices vildledende. Det er ikke størrelsen, der er vigtig – det er uafhængigheden, det skarpe fokus og de hårdt definerede grænseflader.

Opsummering: en microservice er stor nok, til at være uafhængig, men lille nok til at kunne opgraderes og justeres ”hurtigt”.

Er microservices fremtidens softwarearkitektur?

Microservices er en relativt ny måde at tænke på. Det er derfor ikke til at sige hvor vi er om 3, 5 eller 10 år. Men – der er dog nogle klare indikationer på, at konceptet kommer til at holde ved. Det er vigtigt at huske at det meste software bliver bygget med en ambition om at levere et godt produkt. Det er lappeløsninger, for hurtige småjusteringer, uigennemtænkte tilføjelser og manglende tid til vedligeholdelse der er problemet. Et problem, der over tid får applikationer til at degradere, ofte i en sådan grad, at applikationen helt må udskiftes.

Selvom microservice-arkitekturen modvirker det problem med skarpt definerede grænseflader, så er det en ny måde at bygge software på. Kigger man på Google Trends er det først i 2015, der for alvor begyndte at ske noget omkring microservices. Det betyder ikke at microservices blev ”opfundet” i 2015, men det siger noget om den samlede interesse omkring arkitekturen.

Med så relativt få år på bagen, kan vi ikke definitivt sige, at arkitekturen vil holde i mange år. Der er dog klare tegn både teknologisk og forretningsmæssigt på, at det er en langtidsholdbar løsning.

De store tech-virksomheder

Mange store softwarebaserede virksomheder med microservices – Netflix, Amazon, Spotify, Facebook, Google er eksempler på giganter, der bruger microservice-orienteret software. For enorme tech-virksomheder giver det rigtig god mening. Det ville være meget besværligt, hvis Facebook skulle opdatere hele deres software, hver gang de ændrede en funktion. Det ville også skabe en situation, hvor forretningens evne til at implementere nye funktioner ville blive afhængig af. Hvilke funktioner, der kunne passes ind i en given update. Det ville betyde en deadline, hvor al kode skulle være klar for at nå den regelmæssige opdatering.

For de store softwarevirksomheder er den uafhængige, agile og forretningsorienterede udvikling et kritisk element. De ville ikke kunne fungere med en monolitisk struktur. Og de har i virkeligheden arbejdet i en microservices-lignende arkitektur, før det kom til at hedde microservices.

Udviklingen mod microservices er en direkte konsekvens af de større muligheder vi har fået af større computerkraft og internethastighed. Vi er derfor ikke længere er tvunget til at bygge software, optimeret mod performance (den har vi typisk rigeligt af). Vi kan begynde at kigge på, hvordan softwaren bliver en naturlig forlængelse af virksomheden. Set i det perspektiv, er det svært at se hvordan den udvikling ikke skulle fortsætte.