Har du brugt dine microservices i dag?

Infrastruktur

05/08/2019 09:15

Per Roholt

Med microservices kan man starte med at flytte en enkelt microservice over på den nye teknologi og teste effekten.

I en microservice-arkitektur er der tydelige API'er mellem de enkelte microservices, og det er underordnet for en microservice, hvad de andre microservices gør inde bag deres API'er.

Hvorfor har så mange førende virksomheder et godt øje til microservices?

Jeg vil forsøge at besvare spørgsmålet ved at fortælle om nogle af de kæmpestore fordele, som disse virksomheder får ved at bruge microservices.

1: Markant reduceret time-to-market

Sequoia Capital fortæller, at virksomheder som Airbnb, Dropbox og Twitter har nedbragt deres time-to-market for nye funktioner med hele 75 %, efter at de gik over til microservices.

Disse topvirksomheder fra Silicon Valley var allerede verdensmestre i udvikling, inden de gik over til microservices, så hvordan kunne de alligevel nedbringe deres time-to-market så markant?

En af de vigtigste egenskaber ved microservices er, at de kan udrulles enkeltvis. Det betyder, at i stedet for at samle alle moduler i en stor release kan man have en separat udrulning for de enkelte moduler og lave mange små releases.

I illustrationen herover ses to grupper af opgaver (til to moduler i en forsikringsapplikation) med funktioner af forskellig størrelse.

I en monolitisk applikation samler man de to grupper af opgaver og laver en stor release til sidst. Det betyder, at alle de små funktioner i gruppen af anmeldelsesopgaver ikke bliver frigivet, før den store funktion i gruppen af policeopgaver er færdigudviklet.

I en microservice-arkitektur er de to moduler derimod uafhængige af hinanden, så man ikke behøver at samle dem i én release. I stedet kan man udrulle en ny version af et modul, så snart en funktion i opgavegruppen er færdig, og dermed kan brugerne få glæde af funktionen meget før.

Læs artikel på SamfundsDesign: Strategisk vagtplanlægning kræver tydelige prioriteringer

2: Udnyt fordelene ved cloud computing

IDC Research vurderer, at regningen for systemnedetid når op på 1.000.000 dollars pr. time for en virksomhed i Fortune 1000-indekset, og jeg vil gætte på, at den vil blive ved med at vokse, eftersom virksomhederne fortsætter deres digitalisering.

Selvom et system ikke teknisk set er nede, men bare svarer langsomt på grund af en enorm belastning, viser undersøgelser, at en responstid på mere end 10 sekunder har samme virkning på brugerne som et system, der er gået ned – de fleste brugere har for længst givet op.

Heldigvis kan man gøre sit system både robust og skalerbart ved at kombinere microservices og cloud computing.

For eksempel vil man i en forsikringsapplikation se en pludselig stigning i aktiviteten i forsikringsanmeldelsesmodulet efter en kraftig storm, fordi mange kunder skal anmelde skader. Hvis det værste skulle ske, får den ekstra belastning anmeldelsesmodulet til at gå ned, og da det kører på den samme server som resten af applikationen, tager det alle de andre moduler med i faldet.

I en microservice-arkitektur kan microservicen til anmeldelser køre på sin egen server, hvilket gør, at hvis den går ned, tager den ikke resten af systemet med i faldet. Det betyder, at selvom microservicen til anmeldelser er gået ned, kan man fortsat sælge nye forsikringspolicer, fordi microservicen til policer stadig kører.

Man kan også benytte sig af autoskalering i skyen for at gøre microservicen til anmeldelser i stand til at håndtere ekstreme belastningssituationer, idet der automatisk vil blive tilføjet flere servere, efterhånden som belastningen øges. Når så belastningen af systemet er normal igen, fjerner autoskalingen automatisk de ekstra servere.

Denne lette adgang til ekstra datakraft er den sande styrke ved cloud computing. I sin tid gjorde cloud computing det faktisk muligt for Instagram, en iværksættervirksomhed startet af tre personer, at gå fra 0 til 100.000.000 brugere på under to år uden nævneværdig nedetid på grund af problemer med skalerbarheden.

Læs artikel på SamfundsDesign: Intelligent vagtplanlægning vil gøre Danmark sundere

3: Indførelse af it med lav risiko


Hvis man i en monolitisk arkitektur ønsker at flytte over på en NoSQL-database som eksempelvis MongoDB, er man sandsynligvis nødt til at starte et risikobetonet it-migreringsprojekt, hvor alt flyttes til den nye database.

I en microservice-arkitektur er der tydelige API'er mellem de enkelte microservices, og det er underordnet for en microservice, hvad de andre microservices gør inde bag deres API'er – det er blot en detalje ved implementeringen.

Det betyder, at man med en microservice-arkitektur kan starte med at flytte en enkelt microservice over på den nye teknologi – uden at skulle ændre nogen af de andre microservices – og se, om de forventede fordele ved teknologien viser sig at holde i praksis, inden man ruller den ud til andre microservices. 

Hvis der opstår en showstopper (fx pga. NoSQLs begrænsede understøttelse af ad hoc-forespørgsler eller revisionsproblemer med en database, der ikke er ACID-kompatibel), kan man – med stil, og uden at det koster karrieren – rulle microservicen tilbage og bruge en relationsdatabase.

Eftersom der er så mange lovende, men uprøvede, teknologier (eksempelvis kommunikationsgrænseflader, robotter og machine learning), er det en stor fordel at kunne afprøve dem i et realistisk setup, men med forholdsvis lav risiko, inden man satser hele butikken på dem.

Læs artikel på SamfundsDesign: Sundhedssystemer skal formes af danskerne selv

4: Skab nye indtægtskilder med API'er

Når en virksomhed skifter til microservices, følger der automatisk API'er med, fordi microservices bruger API'er til at tale sammen. Man kan tage en delmængde af disse API'er og give tredjepartsudviklere adgang til dem via en API-gateway.

Da LinkedIn eksempelvis gik over til microservices, greb virksomheden chancen og gjorde et offentligt API tilgængeligt. Det populære kinesiske sociale netværk WeChat besluttede at bruge dette API til at integrere til LinkedIn, og på den måde blev der skruet op for LinkedIns eksponering på det lukrative kinesiske marked.

API'er bruges dog ikke kun på sociale netværk.

Da Amazon valgte at gøre sin interne it-infrastruktur tilgængelig via et offentligt API (Amazon Web Services), skabte virksomheden ved et tilfælde en ny indtægtskilde, der genererede milliarder, og endte med at dominere markedet for cloud computing foran konkurrenter som Microsoft og Google.

Inden for virksomhedssoftware kan Harvard Business Review endda fortælle, at online-CRM-systemet Salesforce.com henter halvdelen af sin omsætning fra API'er.

Selvom det er de offentlige API'er, der får mest opmærksomhed, er det faktiske de private API'er mellem samarbejdspartnere (fx et forsikringsselskab og en nystartet forsikringssoftwarevirksomhed), der skaber den største omsætning i API-økonomien.

Det var så mit bud på de fire største fordele ved microservices. Jeg håber, at mit indlæg har givet jer en fornemmelse af, hvorfor så mange virksomheder er positive over for microservice-arkitekturen.

Tilmeld dig Samfundsdesigns nyhedsbrev med nyt om offentlig digitalisering.

Læs artikel på SamfundsDesign: Skal jeg mon sælge mine persondata til Mogens?

Læs mere på EG: Regioner skaber sammenhæng med digitalisering

Mest Læste

Annonce