Med en microservice-arkitektur kan man starte med at flytte en enkelt microservice over på den nye teknologi og se, om de forventede fordele ved teknologien viser sig at holde i praksis, inden man ruller den ud til andre microservices.
Kenneth Lange arbejder som Engeneering Manager for TIA Technologies, det vil sige, at han arbejder med arkitektur og udvikling af kerneteknologien i et enterprisesystem til forsikringsvirksomheder.
På det organisatorisk niveau har han blandt været med til at indføre arbejde i agile teams, DevOps og god praksis. På det teknologiske niveau har han deltaget i arbejdet med at modernisere arkitekturen med REST APIs, cloud computing, microservices, og en større teknologisk opgradering.
Kontakt og følg Kenneth Lange
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 har ved at bruge microservices.
Fordel nr. 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.
Fordel nr. 2: Udnyt fordelene ved cloud-computing
IDC Research vurderer, at regningen for systemnedetid når op på $ 1.000.000 pr. time for en virksomhed i Fortune 1000-indekset, og jeg vil gætte på, at den vil blive ved 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.
Fordel nr. 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 nogle 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.
Fordel nr. 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 de 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.
Men API'er bruges ikke kun på sociale netværk.
Da Amazon valgte at gøre deres interne it-infrastruktur tilgængelig via et offentligt API (Amazon Web Services), skabte de ved et tilfælde en ny indtægtskilde, der genererede milliarder, og de 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.
