Category

Artikler

principper for softwareudvikling

Principper for softwareudvikling

By | Artikler

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 computing sky SaaS HaaS

Cloud computing

By | Artikler

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.

code reviews interaktive code reviews

Interaktive code reviews er spild af tid

By | Artikler
Interaktive code reviews har eksisteret siden de første code reviews – omkring sidst i 70’erne. I dag er det et fast værktøj for stort set alle gode udviklerteams (laver i ikke code reviews, så læs denne artikel). Men – ikke alle code reviews er skabt lige. En særlig udbredt type er på en god dag værdiløs.
Den type reviews vi oftest møder er det, vi kalder ”interaktive” code reviews. Der sætter udvikleren og revieweren sig ned sammen og gennemgår koden. Hvis de sidder det samme sted, foregår gennemgangen ofte ved udviklerens skrivebord – måske endda ved at revieweren står bag ved og kigger over skulderen.
Alternativt, kan det selvfølgelig foregå gennem et videokonferenceværktøj. Det er typisk en relativt hurtig proces, men også en proces med nogle udfordringer, som vi kigger nærmere på her:

 

Interaktive code reviews i praksis

Når revieweren og udvikleren sidder sammen, er det normalt udvikleren, der sidder i førersædet og guider revieweren gennem koden. Det sker ofte når udvikleren er ivrig for at vise sit arbejde frem eller hvis han har kæmpet med opgaven længe, og gerne vil have den lukket, så de kan arbejde videre på næste opgave.
Mens udvikleren blæser afsted gennem mesterværket, skal revieweren:
  • 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
At holde styr på alle de opgaver er ikke nemt, og revieweren vil typisk være nødt til at antage en masse ting. Det begrænser den kritiske tænkning, der er så vigtig en del af reviewet. Udover det er en guidet tour gennem koden kontraproduktiv, når reviewerens opgave i bund og grund er at vurdere, om koden er let at læse og forstå uden forklaring.

 

Socialt pres

En undersøgelse foretaget af Microsoft Research viser, at reviewerens status i det sociale hierarki på teamet påvirker kvaliteten af code reviewet. Den viste, at en reviewer, der er placeret lavere i hierarkiet end udvikleren, vil være mindre kritisk i sit review. Den effekt bliver sandsynligvis kun større af at de to sidder sammen.
Sociologen Erving Goffman har også fremsat ”Face teorien”. En teori der grundlæggende siger, at mennesker gerne vil hjælpe andre mennesker med at opretholde deres facade (’face’). På samme måde som Microsoft Research’s undersøgelse ligger det lige for, at det bliver forstærket af at sidde sammen.
Et review vil være mere objektivt, hvis reviewer og udvikler ikke sidder sammen.

 

Mangel på fleksibilitet

For at lave et review sammen, skal udvikler og reviewer finde et tidspunkt, der passer ind i begges kalender. Det fører til forstyrrelser og en præference for korte code reviews. Det betyder også at flere iterationer og flere forskellige reviewers bliver rigtig besværligt.
Problemet bliver kun større hvis revieweren også har kontakt med andre afdelinger (forretningen) – det betyder typisk at kalenderen er godt fyldt med møder.

 

Introspektion

Der er ikke kun dårlige ting ved den interaktive metode. Når udvikleren gennemgår sin kode og forklarer den for revieweren, forklarer han også sin egen tankeproces. Det kan hjælpe ham til at opdage fejl i hans ræssonement eller forkerte antagelser. Det kan også bare vise, at en del af koden ikke er så forståelig, som han troede til at starte med.
De erfaringer vil hjælpe udvikleren forstå hans egen tendenser og vaner. Som Galileo sagde: ”Du kan ikke lære et menneske noget. Du kan bare hjælpe det til at opdage det i sig selv.”
Selvom det kan “virke”, virker det ineffektivt at skulle forstyrre en kollega med et interaktivt code review, bare for at gennemgå din egen tankeproces igen.
Der findes historier om udviklerteams, der har en bamse på kontoret til samme formål. Det er måske ikke så fjollet som det lyder – det kan ofte være en fordel for tankeprocessen at forklare problemstillinger højt.

 

Code reviews på den rigtige måde

Reviewet er en ekstremt effektiv måde at dele viden og hjælpe yngre udviklere på vej på. Det kan du læse mere om her.
Men hvordan får vi skabt en effektiv proces for reviews? Du kan spørge dig selv: “hvad ville jeg gøre, hvis jeg havde hyret en korrekturlæser til en bog eller en artikel?”.
Du ville formodentlig lade revieweren læse og komme med kommentarer i fred og ro – når det passer ham/hende. Det du gerne vil have er en ærlig vurdering, baseret på hans/hendes erfaring. Er det til at læse? Nemt at forstå? Fejlfrit?
Det leder os til den konklusion at code reviews skal:
  • Udføres af revieweren – alene
  • Foretages asynkront
Ved at lade revieweren foretage reviewet når det passer ham, kan han passe det ind, når det passer ham. Det giver ham mulighed for at bruge den tid, han har brug for, hvis han skal gøre det ordentligt. Og det giver ham mulighed for at gøre det på et tidspunkt, hvor hans energiniveau og mindset matcher opgaven. Det asynkrone review betyder også, at det er praktisk muligt at have mere end en reviewer.
Processen hvor en reviewer sidder for sig selv og skal gennemgå koden minder om, når en udvikler skal grave i en kodebase for at lave rettelser. Det bliver på den måde en direkte test af, om koden er til at vedligeholde. Udover det – i kraft af at revieweren skal kommunikere med udvikleren på skrift, vil alle kommentarer være dokumenteret til senere brug.
De fleste værktøjer til version control giver en mekanisme til at reviewe kode på denne måde. Bitbucket og Github har begge rigtig gode værktøjer til at reviewe på den måde. Men du har også masser af muligheder, selvom du ikke bruger en af de tjenester.

 

Konklusion

Undgå interaktive code reviews. De er, i bedste fald, spild af tid. For at være effektive skal code reviews gennemføres på reviewerens præmisser.
code reviews interaktive code reviews

Hvorfor code reviews er en god ide

By | Artikler
En af de ting, vi altid prædiker hos vores kunder er code reviews. Fordi code reviews alene kan hæve kvaliteten af en kodebase, og samarbejdet omkring den, markant.
Fordi code reviews har flere fordele end bare fejlfinding:
  • De faciliterer videndeling
  • De gør koden nemmere at vedligeholde
Hvis du skriver kode med et langsigtet perspektiv, anbefaler vi, at code reviews bliver et nøgleelement i din udviklingsproces.
Som udviklere gør vi vores bedste for at skrive kode uden bugs. Et af de bedste værktøjer vi har mod bugs er code reviews. En simpel proces, hvor al den kode der bliver skrevet bliver kigget igennem af en anden, inden det kommer i kodebasen. På trods af det, har få udviklerteams code reviews som en prioriteret del af deres udviklingsproces.
Hvorfor?

Hvorfor undlade code reviews?

I nogen teams er det ikke et bevidst valgt ikke at lave reviews. Det er typisk ikke noget de forskellige skoler/universiteter underviser i – det er en praktisk færdighed du skal lære af erfaring. Siden der ikke er særlig mange teams, der bruger code reviews, så kan du relativt nemt bruge et par år i branchen uden at møde et code review. Det er med andre ord slet ikke utænkeligt, at et team ikke foretager code reviews simpelthen fordi ingen har tænkt over at gøre det. Næste skridt er så at de skal have erfaring nok til at forstå værdien på den lange bane.
Og så er der selvfølgelig de teams, hvor lead udvikleren kender til dem, men ikke mener at de er arbejdet værd.
Fordi selvfølgelig kræver de arbejde. Skal de være rigtig effektive, kræver de også en helhjertet indsats. Det opdager alle teams, der går i gang med reviews ret hurtigt. Derfor må investeringen også give et værdifuldt afkast, hvis ikke det skal være en dårlig tidsinvestering.

Kan vi måle fordelene? To tilgange til code reviews:

Hvis et team er meget opsatte på, at forbedre deres udviklingsproces, tester de code reviews i en defineret periode. Ved afslutningen tæller de de bugs de har fundet under reviews og ser det som udbyttet.
Et team, der ikke er ligeså opsat på at opsamle empirisk data, kan finde på at tælle alle bugs identificeret i deres software i periode (i produktion, gennem test eller andet) og bruge det som benchmark for, hvad code reviews potentielt kan bidrage med.
Sidder du på et projekt, hvor du bygger software til rumraketter, så er det ekstremt vigtigt at finde bugs, og konklusionen bliver sandsynligvis at testen var en succes. De fleste teams bygger dog noget lidt mindre avanceret, hvor lejlighedsvise bugs er en accepteret risiko. Den type teams (langt størstedelen af alle udviklerteams) vil sandsynligvis komme frem til, at code reviews koster for meget.

Code reviews handler om andet end bugs

At lave code reviews primært for at fjerne bugs er misforstået. Kun ca. 15% af alle review kommentarer er knyttet til potentielle bugs. Resten af kommentarerne går på muligheder for at forbedre klarhed og læsbarhed for at sikre mere langtidsholdbar kode.
Værdien af læsbarhed alene er enorm. Før vi kan arbejde med og ændre i eksisterende kode, er vi nødt til at kunne læse den. Det er uanset om det gælder justeringer, bug fixes eller nye features. Langsigtet maintainability er bare ikke fagligt tilfredsstillende, det er også det bedste værn mod dyre omskrivninger i koden.
Sidst, men ikke mindst, er det et fantastisk forum for videndeling. Det er en oplagt platform for at skabe og vedligeholde institutionel viden og konventioner og for at dele tips og tricks. Vi har stor succes med at sætte juniorudviklere ind på erfarne teams – det er forbavsende så hurtigt de kan levere på samme niveau som udviklere med både 5 og 10 års erfaring. En stor del af hemmeligheden skal findes i vores effektive processer omkring code reviews.

Konklusion

Vi har forhåbentlig slået fast, at code reviews ikke kun handler om bugs. Husk det, når du overvejer om code reviews skal være en del af din udviklingsproces. Det er især en god ide, hvis du:
  • Har brug for at dit team kan levere kvalitetskode, med relativt få bugs, der kan vedligeholdes i mange år.
  • Har en rimelig høj grad af udskiftning på dit team
  • Ofte ansætter folk med begrænset erfaring

En søgbar linksamling til code reviews

Vores seniorarkitekt og partner, Rune, har enorm erfaring med at lave code reviews. Det er som regel ham, der driver vores code review workshops. På et tidspunkt blev han træt af altid at skulle lede efter kilder og informationer om design patterns, principper, praksisser m.m. og byggede derfor en søgbar linksamling, som du kan finde her.
Har du links, du synes hører hjemme i samlingen, hører vi meget gerne fra dig.
Software hvad er software

Hvad er software?

By | Artikler

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 skærm logo artikler om software facilitator

Software som facilitator

By | Artikler

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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

foredrag om microservices artikel om microservices software

Hvad er microservices

By | Artikler

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
Det lyder lovende, ikke?

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.