Split din monolit op i services
Sidder du og udvikler på en monolit, og drømmer om at bryde den op i services? Vi har samlet fire gode grunde til at komme i gang.
At have en servicebaseret arkitektur koster. I udviklingstimer og i overvågning af systemet. Men det kan være tid givet rigtig godt ud for mange virksomheder. Her tager vi fat i nogle af de grunde, vi har set hos vores kunder, og går lidt mere i dybden med, hvordan microservices kan hjælpe.
Uafhængig skalering
Ordet skalering er over det hele for tiden, så før vi går i gang, definerer vi, hvad vi mener med skalering. I denne sammenhæng betyder skalering ”forøgelse af kapacitet”.
Lad os tage en fiktiv virksomhed, der har en musikstreamingtjeneste. Platformen er bygget op i services, fordi det giver fleksibilitet for de enkelte funktioner i platformen. Der er blandt andet loginfunktion, betalingssystem, playlistetjeneste, en service der laver anbefalinger og en masse andre funktioner, der er relativt veldefinerede i deres ansvarsområder.
Der skal ikke meget fantasi til at forestille sig, at der i særlige perioder, kan være ekstra belastning på specifikke services. Det kan være særlig belastning på den service, der styrer playlister nytårsdag, når mange forbereder sig til den store fest. Det kan også være brugeroprettelsessystemet under særlige reklamefremstød. Enkelte dele af applikationen kan også have begrænsede krav – albuminformation og billeder af album for eksempel. De oprettes en gang og opdateres kun i særlige tilfælde – og bliver brugt markant mindre end resten af tjenesten. En monolit kører på en maskine, og derfor har alle dele i monolitten samme infrastruktur at arbejde med.
Og så er der selvfølgelig også det forhold, at nogle dele af applikationen kræver øjeblikkelig respons, mens andre ikke har helt så stejle krav til performance. Afspilning af musik skal for eksempel være noget nær øjeblikkelig, mens de fleste ting omkring betaling og fakturering, typisk sagtens kan vente minutter eller måske endda timer.
Forskellige teknologistakke
Selvom både C# og F# er rigtig gode sprog, der dækker stort set alle behov, kan der alligevel være situationer, hvor det kan give mening med andre teknologier. Der kan også være behov for at bruge forskellige typer databaser til forskellige dele af applikationen. I takt med at data (og big data) begynder at fylde mere og mere i virksomhederne, kan det være relevant med en service, der har en ikke-relationel database og er skrevet i et sprog, der er særligt godt til at behandle data. I en monolit er du i langt højere grad bundet teknologisk.
Der er mange fordele ved polyglotte microservices. For eksempel: Frihed til kreativitet hos udviklerne, autonomi og udviklingshastighed. Men det er ikke kun lyserødt – der kan også være nogle problemer med det. Polyglotte microservices øger kompleksiteten af et allerede komplekst system. Både på den tekniske side og på personalesiden.
Skalering kan også give lidt udfordringer. At standardisere services på tværs af flere forskellige sprog kræver en del arbejde. Der kan potentielt også være ekstra arbejde i at sikre at tests og infrastruktur hænger sammen og følger de overordnede retningslinjer for applikationen.
Bedre udviklingshastighed end en monolit
Fordi microservices ikke kræver fulde builds og deployments hver gang ny kode skal i produktion er det markant hurtigere at udvikle og deploye i en microservice arkitektur.
Men der er også en anden grund til, at det bliver meget hurtigere at udvikle på microservices end monolitter. Du kan være mange flere om at udvikle kodebasen. Så længe de enkelte services overholder de indbyrdes aftaler for kommunikation, så kan du frit udvikle på dem. Det gør det noget nemmere at være flere teams på samme applikation end hvis i har en monolit. På grund af monolittens arkitektur, vil du i nogen grad være nødt til at udvikle på en ting af gangen.
Skulle der være behov for det, er det også nemmere at outsource dele af udviklingen. Igen – så længe aftalerne for kommunikation mellem services bliver overholdt, sikrer arkitekturen at de enkelte teams kan udvikle og deploye uafhængigt.
2+ ”kunder”
Så snart en softwareapplikation har to ”kunder”, så kan det være en fordel at kigge på en microservice arkitektur. Grunden til at kunder står i citationstegn er, at det ikke nødvendigvis behøver at være en betalende kunde fra en anden virksomhed. Det kan også være en intern kunde.
Med en monolitisk arkitektur kan der opstå modstridende interesser – den ene kunde har måske en bug i en funktion, der er meget vigtig for dem, mens den anden ikke har lyst til den downtime og risiko et fix og en deployment medfører.
Med microservices kan dine kunder adaptere nye funktioner, når det passer ind i deres forretning. Det kræver naturligvis, at du opretholder baglæns kompatibilitet.
Er microservices smart?
Det korte svar er ja, men ikke til alt. I takt med at flere og flere tjenester og applikationer bliver tilgængelige som SaaS er det svært at undgå en distribueret applikation. Og selvom der følger omkostninger med en microservicebaseret arkitektur, så er det bedre, billigere og mere konkurrencedygtigt end alternativet.
