Din forretning online

IT arkitektur

IT med forretningsfokus

Novicells IT arkitekter rådgiver for at skabe sammenhæng mellem kundens forretningsvision og teknologien, der skal bringe forretningen og organisationen derhen. Arkitekterne holder målrettet fokus på, hvad det digitale landskab skal løse, og er en vigtig ressource for bæredygtig og agil IT udvikling.

Vores IT arkitekter arbejder metodisk med at analysere processer fra flere vinkler og som del af en helhed. De

  • skaber overblik over omfanget af et IT projekt
  • nedbryder forretningsprocesser i opgaver, som kan håndteres af teknologi
  • bidrager med at værdisætte IT beslutninger.

Novicells IT arkitekter

Værdisætter IT beslutninger

Sikrer at IT udvikling og ændringer sker med baggrund i at skabe værdi for forretningen.

Prioriterer, dokumenterer og integrerer teknologi

Identificerer systemer i brug, og beslutter om de skal integreres ind i IT landskabet, erstattes med anden teknologi eller pensioneres.

Optimerer performance for systemer

Analyser flows og optimeringsmuligheder for at skabe hurtigst mulige dataflows til færrest mulige penge.

Definerer datamodeller og behov

Identificerer datakilder og dataformater, og vurderer dem i forhold til forretningens behov.

Identificerer sikkerhedsbehov

Sikrer at sikkerhedsstandarder overholdes og vedligeholdes på tværs af alle IT løsninger.

Sikrer compliance

Etablerer processer og ejerskab for nye processer ved ændring af lovgivning, markedskrav eller konkurrencevilkår.

Nedbryder siloerne

Konsoliderer data centralt og gør datadeling mellem systemer og projekter muligt.

Sådan bygger du et dynamisk IT-landskab med microservice arkitektur

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?

Låser I forretningen med arkitekturen?

Evolutionær arkitektur og microservice arkitektur

Med en evolutionær tilgang til IT-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 ændrer sig. Det kunne f.eks. 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 enterprise resource planning system (ERP) eller customer relationship management system skal udskiftes. Du kan sågar indfase systemer gradvist for at sikre, at overgangen sker så udramatisk som overhovedet muligt.

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

Se en video om hvordan Novicell laver arkitektur til ecommerce

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 identificeret 7 muligheder/fordele her, men afhængigt af hvad dit formål med arkitekturen er, kan der være flere. Men lad os tage dem én ad gangen:

7 fordele ved microservice arkitektur

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. 

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

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 og 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-arkitektur tillader virksomheden at vælge den optimale teknologi ud fra f.eks. krav til performance eller ønske til lagring af data. Det giver dig 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 arkitektur op til at kunne udskifte systemer løbende og i forskelligt tempo

Et IT-landskab ældes med forskellig hastighed. Derfor giver det også mening at bygge en arkitektur, der er optimeret til, at at du kan 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.

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, hvis ERP er offline i kortere eller længere perioder på grund af opdatering. Det giver en robusthed og en dataintegritet i setuppet, som sikrer, 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øves at blive presset. Performance-optimeringen kan du skabe ved 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 specifikt i forskellige regioner, så et internationalt setup kan optimeres differentieret 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 idræftsat, så kan den fejl isoleres til den givne service, og et simpelt roll back kan løse problemet.

Det giver en lavere barriere for at sætte ny kode. Og du kan få nye features 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. 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 intent 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 f.eks. 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 façade, som ligner et hvilket som helst andet API, kan du servere indhold til en række forskellige interfaces og præsentationsteknologier. Din 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.

 

Sådan erstatter du legacy software med microservice arkitektur trin for trin

 

 “Almost all the successful microservice stories have started with a monolith that got too big and was broken up.”

Martin Fowler

en af verdens ledende kompetencer på microservices og en fremtrædende forfatter på området

Fra legacy software til microservice arkitektur

I de fleste virksomheder findes der et stykke software, som ingen tør røre ved. Det er elefanten i IT-afdelingen. Den varme kartoffel på direktionsgangen. Men også hængelåsen til den magiske port, de kalder digital transformation og automatisering i stor skala. Det er software-monolitten, der bare er vokset og vokset indtil ingen ved præcis, hvad den indeholder. Og endnu mindre hvordan den nogensinde skal kunne udfases. Årsagen er typisk en eller flere af følgende:

  • Den kan være vagt dokumenteret fra start og de 3 udviklere bag løsningen har for længst forladt organisationen.
  • Den er skrevet i et kodesprog, der sidenhen er dødt.
  • Den kører på hardware, der nåede end of life for en generation siden, og derfor ikke længere bliver vedligeholdt af leverandøren.
  • Den er blevet overmåde kompleks gennem årene, mens forskellige udviklere har lagt kodelinje på kodelinje ind i en voksende pukkel af teknisk gæld.

Legacy softwaren er på én gang forretningskritisk og samtidig en blokering for forretningsudvikling. Den dræner jeres dyre IT-ressourcer og tynger tungt på jeres konkurrencekraft.

Men hvad gør du ved det? Først kigger vi på, hvad der kendetegner en legacy software-monolit og derefter på, hvordan du kan arbejde dig ud af den.

Hvad er en software-monolit?

En software-monolit er en softwareløsning, der udfører flere processer omkring et eller flere forretningsdomæner. Monolit er afledt af et geologisk udtryk for en stor massiv klippe. Det henviser til, at softwaren fungerer som en stor massiv enhed. Typisk vil software-monolitten være et stykke skræddersyet software eller et stykke kommerciel (licenstungt) standardsoftware, der er tilpasset til at løse større eller mindre dele af virksomhedens forretningslogik. Det kan f.eks være

  • ERP-systemet (Enterprise Resource Planning)
  • Ecommerce-platformen
  • CRM-platformen (Customer Relationship Management)
  • CMS (content management system)
  • eller et hav af branche- og forretningsspecifikke systemer.

Men forretningslogik er dynamisk. Logik i softwaren er typisk statisk.

Når du videreudvikler dit IT-landskab for at bevare et 1-1 forhold mellem forretningsprocesser og processer i softwaren, der løser dem, opstår der teknisk gæld. Teknisk gæld er quick fix løsninger, som laves i systemet, som gør det sværere og dyrere at lave større omlægninger og opdateringer af systemer fremadrettet.

Det er en naturlig udvikling, når forretningen vokser og udvikler sig. Men videreudvikling på større software systemer er komplekst. Og tilhørende teknisk gæld kan give en række følgeudfordringer, som kan være svære for forretningen at leve med. Derfor er legacy software-monolitter ofte en barriere i mange virksomheder.

Legacy software-monolitter har ulemper:

1.      Lang time- to-market på nye features, produkter og processer

Hvis du laver en kodeændring i en software-monolit, skal hele løsningen deployes, uanset hvor lille ændringen er. Da deploys til større systemer altid vil være store deploys på grund af omfanget af kode der skal deployes, vil det ofte involvere et vist element af risiko og potentiel nedetid. Det betyder i praksis, at der i mange organisationer vil være langt mellem deploys for at minimere risici. Men med længere tid mellem deploys vil der også være flere og større ændringer, der skal deployes. Det betyder større risiko for modstridende kodelinjer og dermed fejl.

Mange store software-monolitter får kun deployed ny kode 1-4 gange om året. Det er fordi hele monolittens kode skal deployes hver gang, og det kan betyde nedetid på et stort forretningskritisk system. Desuden er det svært at fejlfinde, når mange nye kodelinjer lægges ind med hvert deploy og potentielt påvirker hinanden, når de lægges i drift.

2.      Langsom adoption af ny teknologi

Med en monolit er det svært at idriftsætte og teste et nyt kodesprog, databasetype eller framework, fordi en ændring i systemet påvirker hele systemet. Det låser ikke bare din adoption af ny teknologi og nye systemer, men kan også være en hindring for rekruttering af IT-kompetencer, hvis du sidder med en monolit, der er kodet på en døende teknologi. Vi vender tilbage til, hvordan du i praksis bygger teknologi-heterogenitet ind i landskabet.

3.      Det er svært og dyrt at performanceoptimere en software monolit

Det er ikke muligt fokuseret at skalere performance på de elementer af løsningen, der har behov for det, da hele monolitten skal skaleres, når der er brug for øget performance. Ellers opstår der flaskehalse i systemet og mulige nedbrud eller datatab. Det kan være særligt kritisk for ecommerce-applikationer, som oplever meget stærke trafikstigninger i forbindelse med Black Friday og andre kampagner, som kan forårsage nedbrud på hele løsningen. Selvsagt vil de automatiserede skaleringsmuligheder, der ligger i Amazon Web Services eller Microsoft Azure, være svære eller umulige at udnytte optimalt med et sådant setup.

Desuden kan licenstunge systemer risikere at koste urimeligt mange ekstraudgifter med flere parallelle installationer kørende på flere servere. Det kan derfor være dyrt både på serversiden og på licenssiden at drifte en software monolit, der altid skal kunne yde til et højt niveau og have en oppetid på mange 9-taller efter kommaet.

Nem integration af nye systemer med en microservice arkitektur

Idriftsættelse af ny kode eller et nyt system bør være så udramatisk, at det ikke kræver opmærksomhed.

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, du får brug for, efterhånden som kravene til dit setup ændres. Det kan være, at behovet for et PIM-system (Product Information Management) opstår, efterhånden som din ecommerce-forretning modner. Du kan sågar indfase systemet gradvist for at sikre, at overgangen sker så udramatisk som overhovedet muligt.

Hvordan indfaser du ny software i dit IT-landskab med microservices?

Lad os tage ovennævnte eksempel med et PIM-system, der skal indfases i et ecommerce setup som det centrale system for alle produktdata. Tricket her er IKKE at integrere direkte til det nye PIM-system, men lave en såkaldt facade, som definerer kaldet. Med en facade kommunikerer det øvrige IT-landskab med PIM-systemet via facaden. Det giver et fast element, som services kan integrere op imod, uanset hvad der ligger bag facaden.

Det giver mulighed for at fjerne så meget logik som muligt fra integrationen og lave en løs kobling mellem services og systemer. Den ene service er så at sige ligeglad med, hvor facaden dirigerer kaldet hen, og hvordan det afvikles, så længe svaret passer ind i et fast defineret endpoint, som er facaden. Det er en klar styrke, fordi du bygger din infrastruktur op på en måde, så den er optimeret til afvikling og udvikling. Det kaldes evolutionary architecture.

Det ser således ud:

Hvordan udfaser du legacy software med microservices?

Der er flere variationer af nedenstående metode, men for at gøre forklaringen simpel, så lad os holde os til det overordnede princip for udskiftning af en service eller et stykke software. Metoden som vi gennemgår her kaldes strangler fig (kvælerfigentræ) metoden. Det kommer af en figensort, der kendetegnes ved at vokse tæt omkring en værtsplante. Figentræet bruger værten til at kravle op ad for at komme op i lyset over trækronerne. Mens planten vokser, omfavner eller ”kvæler” den sin værtsplante, hvoraf navnet er opstået. Nogle værtsplanter lever i symbiose med kvælerfignen, mens andre dør, fordi figentræet gradvist tager lyset fra værtsplanten. Det kan lede til en figenplante, der står tilbage som et hylster, fordi værtsplanten er rådnet væk i midten. Det er her navnet stammer fra, og nu skal du høre hvorfor.

Trin 1: Byg en facade

Første skridt i strangler fig metoden er at bygge en facade, der kan tage imod og dirigere kald til services bag facaden. De fleste kald vil i starten gå til monolitten, som så vil afvikle kaldet. Ved at etablere en facade i stedet for blot at kalde servicen direkte, kan der være to eller flere parallelle services, som kan tage imod kald. Software-monolitten er nu ”vært”, som du kan begynde at etablere en strangler fig arkitektur omkring, for nu at holde os til symbolikken.

Nu kan du begynde at flette forretningsprocesser ud af din legacy software og etablere dem som selvstændige services. Det kan være mere eller mindre komplekst, og det kan være hensigtsmæssigt at starte med en service, der ikke er bundet ind i alt for mange andre processer, da det vil være mindst risikofyldt. Selvom værdien af at flette en mere indviklet proces ud er mere åbenlys, kan det være gavnligt at gøre det i trin fra mindre komplekst til mere komplekst. Det giver dig mulighed for at prøve strangler fig metoden og microservices af på lavrisikoprocesser. 

Ved at gøre det sådan, kan du risikofrit etablere en service i dit produktionsmiljø uden at forbinde den til noget. Således kan du begynde at afvikle testkald til den nye service, og du får sikkerhed for, at servicen opfører sig som den skal i produktionsmiljøet.

Trin 2: Omdirigér kald til den nye microservice

Når du har sikret dig, at servicen løser en afgrænset opgave i monolitten tilfredsstillende, kan du omdirigere relevante kald i facaden fra legacy softwaren og afvikle produktionskald til den nye service i stedet.

Trin 3: Forsæt med at etablere selvstændige microservices

Og sådan fortsætter du. En proces ad gangen, som du flytter ud af din legacy software og etablerer som en selvstændig microservice.

Måske er dit mål helt at udfase legacy software og lade den nye strangler fig-arkitektur stå alene. Det kan også være, at du lader legacy softwaren stå tilbage på lige fod med den nye arkitektur. Så den blot fungerer som én service blandt mange. Det er ikke et mål i sig selv at bevæge sig væk fra en monolitisk infrastruktur. Det er ofte et ønske, der opstår som følge af en række prioriteringer, som ikke kan løses med en tæt koblet infrastruktur. Hvis du bevæger dig frem som beskrevet her, er du godt på vej til at bygge et IT-landskab, der giver dig en eller flere af de unikke fordele, som en microservice-arkitektur tilbyder.

Få 5 artikler om digital transformation

Novicells IT arkitekter arbejder tæt sammen med vores strateger for at udvikle kundernes forretning. I denne artikelserie har vi identificeret vores kunders største barrierer for digital transformation. Brug de 5 artikler til at skabe det rigtige fundament for jeres egen transformation.

 

Læs artikelserien

Vil du høre mere om, hvad Novicell kan tilbyde indenfor IT arkitektur, så kontakt mig.