Go to content

Introduktion til moderne it-arkitektur og infrastruktur

Artiklen er en basisindføring i en (ud af mange) moderne arkitekturprincipper. Mange virksomheder, blandt andre en del af Novicells kunder, benytter allerede nedenstående metoder, men vi opfordrer hermed flere til at komme i gang.

Published januar 15, 2020

Lad os starte med et spørgsmål til de it-kyndige:

Hvor ofte idriftsætter I ny kode i form af produkter, features eller systemer i jeres it-setup?

1 gang om året?

1 gang om måneden?

Eller en gang i timen? 

Hvis du ikke ved det, så kan du nok forestille dig, at der er forskel på at lægge et års arbejde ud på en gang - eller at gøre det løbende, måske endda flere gange i timen. Både i forhold til fejlpotentialer og medfølgende fejlfinding, og i forholde til ventetid på udvikling. Der er ingen tvivl om, at de fleste virksomheder foretrækker kontinuerlig fremdrift og tidlige iterationer, som kan kvalitetstestes og forretningstestes ud mod brugerne tidligt i processen.

Men det er ikke alle typer it-arkitektur, der tillader det. Gør din?

I denne guide giver vi dig overblik over fordelene ved at opbygge en fleksibel og fremtidssikret it-arkitektur ved hjælp af microservices. Microservices gør det nemlig nemt for dig at udvikle og optimere din it-arkitektur løbende - i takt med, at virksomhedens behov og omverdenens krav ændrer sig. 

Låser I forretningen med it-arkitekturen?

It-arkitektur er et valg, man tager som virksomhed og som it-ansvarlig. Og det bør tages med åbne øjne. Vælger du en arkitekturtype, som låser virksomheden til en bestemt måde at udbygge it-landskabet på, eller prioriterer du at have et landskab, der kan udvikle sig evolutionært, i takt med at behovet fra forretningen ændrer sig?

Med en microservice-arkitektur kan du gradvist integrere nye systemer. Uanset om det er systemer, der trænger til udskiftning på grund af forældelse, eller nye systemer, der kræves efterhånden som kravene til dit setup ændres. Det kunne fx være, at behovet for et PIM-system (Product Information Management) opstår, efterhånden som din ecommerce-forretning modner. Det kan være dit ERP (Enterprise Resource Planning system) skal udskiftes eller dit CRM (Customer Relationship Management system). Du kan sågar indfase systemet gradvist for at sikre, at overgangen sker så udramatisk som overhovedet muligt.

Lad os tage et kig på, hvad microservices er, og hvilke muligheder/fordele det giver dig, at bygge jeres it-arkitektur op på microservices.

Hvad er microservices?

Microservices er små enkeltstående stykker software med ét mål for eksekvering af kode. Modsat en software-monolit bliver afviklingen af processer brudt ud i små uafhængige stykker software, som hver især har fuld autonomi over sin egen proces og en klar afgrænsning af formålet med den specifikke proces. 

Det giver nogle muligheder, som en software-monolit vil have svært ved at håndtere.

Vi har listet 7 muligheder/fordele herunder, men afhængig af hvad dit formål med arkitekturen er, kan der være flere. Lad os tage dem én ad gangen:

 

1. Microservices tillader teknologi-forskellighed og brug af best practice software

Når du bygger en række uafhængige stykker software, som arbejder sammen, er det muligt at benytte forskellige teknologier side om side. På den måde kan du vælge den optimale teknologi til en given opgave i stedet for at gennemtvinge laveste fællesnævner. Vi ser ofte virksomheder, som prøver at finde en software-fællesnævner for stort set alle systemer. De kører f.eks. SAP ERP, SAP CRM, SAP BW m.v., og hensynet til en fællesnævner vejer tungere end en reel stillingtagen til, om der egentlig er andre systemer, der imødekommer virksomhedens behov bedre.

En microservice it-arkitektur tillader jer at vælge den optimale teknologi ud fra f.eks. krav til performance eller ønske til lagring af data.  Det giver jer også mulighed for at indfase ny teknologi hurtigere og med radikalt nedsat risiko. Vælg f.eks. en lavrisiko-service at teste teknologier af på og til at lære at estimere potentiale og indvirkning på dit it-landskab.

 

2. Byg din it-arkitektur op til at kunne udskifte systemer løbende og med forskelligt tempo

Et IT-landskab ældes med forskellig hastighed, og derfor giver det også mening at bygge en arkitektur, der er optimeret til at kunne udskifte større eller mindre dele af landskabet asynkront. Ser vi igen på elementerne i en webshop, så vil frontend og design nok trænge til et løft efter 1-2 år, dit CMS efter 3 år, din ecommerce platform efter 5 år og dit ERP måske kun hvert 10. år. I grove træk. Hvis du køber ind i en software monolit, der både løser opgaver som CMS, ecommerce og frontend, så vil du stå med aldringsudfordringen efter nogle år, og de afledte udfordringer heraf vil kun vokse med tiden.

 

3. Robusthed – én fejl vælter ikke læsset

I en monolit vil hele systemet fejle, hvis processen fejler. Det er selvfølgelig muligt at køre monolitten fra flere maskiner for at nedsætte risikoen for nedbrud, men potentielt også dyrt.

I en microservice-arkitektur kan du skære funktionaliteten ned til det minimale ved en fejl. Med afgrænsede services, der arbejder sammen gennem klart definerede snitflader, kan en fejl adskilles fra de øvrige services og omdirigeres til den samme proces på en af backup-serverne. Eller til en decideret fallback-service, så processen kan fungere eller afvikles i alternativ form selv ved en fejl.

Lad mig give et eksempel: Hvis microservices omkring eksempelvis kvitteringsafsendelse i virksomhedens ecommerce-platform fejler, kan de øvrige services stadig afvikles, og kvitteringerne kan samles op i et køsystem og afvikles, når det er oppe igen. Det samme gør sig gældende med opdatering af bagvedliggende systemer som eksempelvis SAP opdateringer, som kan vare hele dage.

Det giver en robusthed og en dataintegritet i setuppet. Og du er sikret, at systemet som helhed består, og data ikke mistes ved nedbrud. 

 

4. Performance-optimering og skalérbarhed - og kun, hvor det er nødvendigt

Modsat en software-monolit, så kan microservices performance optimeres helt ned på den enkelte service. Det gør det muligt at ”booste” en service, der potentielt kunne blive en flaskehals. Et eksempel på dette kan være CMS og produktvisninger, der er hårdt belastede, hvorimod en check-ud service ikke behøver at blive presset. Performance-optimeringen kan du skabe ved at skalere den samme service ud på flere servere, så presset fordeles, og flaskehalsen elimineres, uden at resten af løsningen bliver skaleret unødvendigt op med tilsvarende omkostninger til følge.

Tilsvarende kan setuppet også boostes individuelt i forskellige regioner, så et internationalt setup kan optimeres forskelligt i forskellige områder af verden alt efter pres på systemet.

 

5. Hurtig idriftsættelse af ny kode og nye features

Med microservices kan du deploye den enkelte service selvstændigt. Det betyder, at du minimerer risikoen for, at et deploy påvirker andre dele af systemet. Du kan idriftsætte koden, efterhånden som den er testet klar. Du kan endda automatisere idriftsættelse af kode, såkaldt continuos delivery. Skulle der opstå en fejl, når koden er idriftsat, kan den fejl isoleres til den givne service, og et simpelt roll back kan hurtigt løse problemet.

Det giver en lavere barriere for at idriftsætte ny kode, og du sikrer, at nye features kommer hurtigere ud til kunderne og organisationen. Kort og godt, det højner dine muligheder for at eksperimentere mere med forretningen uden den store risiko.

 

6. Organisationsombrydning til mindre og mere effektive teams

Med store systemer følger ofte store teams. Og hvis teamet tilmed er spredt ud over flere kontorer eller lande, kan samarbejdsprocesserne blive ganske komplekse og langtrukne. Med microservices kan du naturligt dele forretningsområder eller features ud på teams, så mindre teams kan have hånds- og halsret over den enkelte service eller hele feature-sets og løse opgaver fra udvikling til deploy. Det giver en usammenlignelig agilitet og fleksibilitet i samarbejdet. Både internt i teamet og mellem teams. 

 

7. Genbrug af services på tværs af løsninger

Uafhængige stykker software gør det muligt at få de enkelte microservices til at udføre opgaver for flere løsninger parallelt. Med en software monolit-har du få indgange til afvikling af forespørgsler. Med microservices har du omvendt mulighed for at lade forskellige løsninger afvikle forespørgsler i den samme arkitektur. Det kan lyde fortænkt, men det giver mening, hvis du tænker over den hastighed nye devices og brugerflader vokser frem med.

Ved at lade de enkelte microservices afvikle forespørgsler gennem en facade, som ligner et hvilket som helst andet API, kan du servere indhold til en række forskellige præsentationsteknologier og interfaces. Din it-arkitektur kan med andre ord servere indhold optimeret til den specifikke frontend, – uanset om det er en webshop, et interface i dine produktionsmaskiner eller en mobilapp.

Vil du vide mere om microservices eller infrastruktur?

Du må også meget gerne kontakte mig, hvis du vil vide mere om microservices eller infrastruktur