Tjenestearkitektur er en programvaredesigntilnærming som løser et problem med en rekke autonome tjenester.

Analogi

En rimelig analogi for tjenestearkitektur er en organisasjon som en bank. Banken deler arbeidet inn i en rekke tjenester som kundeservice, IT-tjenester og personaladministrasjonstjenester. Hver tjeneste er uavhengig og kan distribueres til forskjellige kontorer. Kundene til hver tjeneste tilbys en kontrakt som sier hva som kan forventes av tjenesten. For eksempel kan personaladministrasjon hjelpe et team til å rekruttere nytt personale med et skjema som teamet fyller ut for å starte prosessen. Tjenestestrukturen til firmaet bryter ned det komplekse problemet med å drive en bank i små administrasjonsbiter av funksjonalitet.

Services

Services er enheter av programvare som utføre en funksjon. De brukes til å dele komplekse problemer opp i en serie enklere problemer. Tjenester er også designet for å kunne distribueres separat. Dette er en stor fordel, da det lar deg bygge svært skalerbare og elastiske systemer.

Resilience

Resilience er et begrep for programvare som er pålitelig i forhold til den virkelige verden som inkluderer forskjellige belastninger og feil. Tjenestearkitektur er en nyttig teknikk for å bygge systemer som fortsetter å fungere når ting mislykkes. Dette gjøres ved å arkitektere tjenester for å være autonome slik at de ikke er avhengige av hverandre. Tjenester kan deretter distribueres til skyinfrastruktur og skaleres opp og ned etter behov. Når en forekomst mislykkes, er tjenestene smarte nok til å oppdage dette og automatisk finne en forekomst som fungerer.

Tjenester vs komponenter

Tjenester og komponenter er to forskjellige måter å dele arbeidet opp i håndterbare og gjenbrukbare biter. Forskjellen er at tjenester kan distribueres alene. Komponenter distribueres med noe annet og er derfor ikke autonome. Tjenester kan bygges fra komponenter. På samme måte kan komponenter bruke tjenester.

Service Oriented Architecture (SOA)

Service orientert arkitektur var en tidlig betegnelse for servicearkitektur som ble vedtatt og markedsført av mange store IT-leverandører som brukte den til å selge SOA-plattformer og mellomvare. Dette var en stor kjepphest for informasjonsteknologi rundt 2005 som så mange implementeringer ovenfra og ned som involverte å kjøpe en haug med programvare og deretter redesigne eksisterende systemer for å passe inn i et SOA-paradigme. Mye av denne aktiviteten gikk glipp av poenget med SOA, og prosjektfeil var vanlig. Forvirring regnet etter hvert som IT-eksperter promoterte eller kritiserte SOA, ofte ved å gjøre ting så komplekse som mulig.

Microservices

Alt det store tankene og tullet som omringet SOA på toppen av populariteten, hindret ikke dyktige arkitekter i å bruke sine kjerneideer på effektive og lette måter som produserte pålitelige, skalerbare, håndterbare og kostnadseffektive systemer og applikasjoner. Dette utviklet seg til en ny kultur for programvaredesign kjent som mikrotjenester som er organisert rundt et sett med prinsipper for tjenestedesign.

Eksempel

Et teleselskap designer et faktureringssystem som en serie separat distribuerbare tjenester. Hver tjeneste blir sett på som et eget produkt som kan utvikles, vedlikeholdes og administreres av forskjellige mennesker. Tjenestene distribueres i skyen og løses sammen. Når en tjenesteinstans mislykkes, bytter de andre tjenestene automatisk til en forekomst som fortsatt fungerer. Selv om problemet med telekomfakturering er ekstremt komplekst, er ingen tjenester i arkitekturen kompliserte slik at hver av dem er relativt billige å utvikle og administrere. Tjenestene er i det vesentlige selvorganiserende. Hver publiserer en API til de andre tjenestene. Hver vet hva de trenger fra de andre tjenestene og er smart nok til å rute rundt mislykkede tilfeller for å finne tjenester som svarer. Arkitekturen har med andre ord ingen sentral kontroller eller mellomvare.

Oversikt: Tjenestearkitektur
Type
Definisjon	En programvaredesigntilnærming som løser et problem med en rekke autonome tjenester.
Relaterte konsepter