Gå ikke i fælden 'Microservices Are Cool' og ved, hvornår du skal holde dig til monolit i stedet

Monolitter og mikrotjenester er to grundlæggende tilgange til at bygge applikationer. Nogle mennesker anser dem for at være henholdsvis arv og moderne. Men dette er ikke helt rigtigt. At vælge mellem dem er et meget komplekst spørgsmål, hvor begge har deres fordele og ulemper.

De fleste nye applikationer behøver ikke at være mikrotjenester fra begyndelsen. Det er hurtigere, nemmere og billigere at starte som en monolit og skifte til mikrotjenester senere, hvis du finder det gavnligt.

Over tid, efterhånden som monolitapplikationer bliver mindre og mindre vedligeholdelige, beslutter nogle teams, at den eneste måde at løse problemet på er at begynde at refaktorere ved at opdele deres applikation i mikrotjenester. Andre teams træffer denne beslutning, bare fordi "mikrotjenester er seje." Denne proces tager meget tid og medfører nogle gange endnu mere vedligeholdelsesomkostninger. Før du går ind i dette, er det afgørende nøje at overveje alle fordele og ulemper og sikre, at du har nået dine nuværende grænser for monolitarkitektur. Og husk, det er lettere at bryde end at bygge.

I denne artikel skal vi ikke sammenligne monolitter med mikrotjenester. I stedet vil vi diskutere overvejelser, mønstre og principper, der vil hjælpe dig:

• få det bedste ud af din nuværende monolit og potentielt forberede den til at bryde ind i mikrotjenester;
• give problemfri migrering fra monolit til mikrotjenester;
• forstå, hvad der ellers kan ændre sig med migrering af mikrotjenester.

Modulær monolit

Den første ting du skal gøre er at se på din projektstruktur. Hvis du ikke har moduler, anbefaler jeg stærkt, at du overvejer dem. De får dig ikke til at ændre din arkitektur til mikrotjenester (hvilket er godt, fordi vi vil undgå al tilsvarende vedligeholdelse), men tager mange fordele ved dem.

Afhængigt af dit automatiseringsværktøj til projektbygning (f.eks. maven, gradle eller andet), kan du opdele dit projekt i separate, uafhængige moduler. Nogle moduler kan være fælles for andre, mens andre kan indkapsle specifikke domæneområder eller være funktionsspecifikke, hvilket bringer uafhængig funktionalitet til din applikation.

Det vil give dig følgende fordele:

1. Afkoblede dele af din ansøgning.
2. Funktioner kan udvikles uafhængigt, hvilket minimerer konflikter.
3. Det er meget nemmere at ombord på nye mennesker, da de ikke behøver at dykke dybt ned i hele projektet; i stedet kan de starte fra isolerede dele.
4. Forbedret test, for nu kan du teste hvert modul separat.
5. Hvis du skal migrere til mikrotjenester til sidst, har du et meget stærkt grundlag for det.

Som du kan se, er den modulære monolit måden at få det bedste fra begge verdener. Det er som at køre uafhængige mikrotjenester inde i en enkelt monolit, men undgå sikkerhedsstillelse af mikrotjenester overhead. En af de begrænsninger, du måske har – er ikke at kunne skalere forskellige moduler uafhængigt. Du vil have så mange monolit-forekomster, som det kræves af det mest indlæste modul, hvilket kan føre til for stort ressourceforbrug. Den anden ulempe er begrænsningerne ved at bruge forskellige teknologier. For eksempel kan du ikke blande Java, Golang og Python i en modulær monolit, så du er tvunget til at holde fast i én teknologi (som normalt ikke er et problem).

Strangler Fig mønsteret

Tænk på Strangler Fig-mønsteret. Det tager sit navn fra et træ, der slynger sig rundt og til sidst erstatter sin vært. På samme måde foreslår mønsteret, at du erstatter dele af en ældre applikation med nye tjenester én efter én, og moderniserer et gammelt system uden at forårsage væsentlige forstyrrelser.

I stedet for at forsøge en risikabel, alt på én gang eftersyn, opdaterer du systemet stykke for stykke. Denne metode er gavnlig, når man har at gøre med store, komplekse monolitter, der er for uhåndterlige til at udskifte i en enkelt indsats. Ved at anvende Strangler Fig-mønsteret kan teams langsomt udfase det gamle system, mens de fremmer væksten af det nye, minimerer risici og sikrer kontinuerlig levering af værdi.

For at implementere Strangler Fig-mønsteret skal du følge tre trin:

1. Transform. Her identificerer du, hvilken del der skal udtrækkes fra monolitten og implementerer den som en separat mikroservice. Omskriv denne del ved hjælp af moderne teknologier og adresser problemerne med den tidligere implementering. Udnyt din chance for at gøre det bedre.
2. Sameksistere. Når en ny mikroservice er klar til produktion, kører du den i din infrastruktur og beholder den gamle implementering. Du fordeler trafikken i et vist forhold, og flytter gradvist mere og mere trafik til den nye implementering, men du har altid din tidligere version som en rollback.
3. Eliminer. Efter nogen tid, når du mener, at din nye mikrotjeneste er pålidelig nok, skal du flytte al trafik ind i den nye mikrotjeneste og fjerne arven.

Ved at tage disse tre trin vil du gradvist bryde en monolit op i mikrotjenester.

De vigtigste fordele ved at bruge Strangler Fig-mønsteret er:

• Gradvis migration. I stedet for at bryde dårligt og starte en rettidig, overvældende og risikabel komplet systemoverhaling, giver mønsteret dig mulighed for at skifte trin for trin. Du kan langsomt opdatere dit system og synkronisere denne transformation med funktionsudviklingsplaner. For eksempel kan du finde en del af den monolit, som en del funktionsudvikling vil påvirke alvorligt, og vælge den som en kandidat til mikroservicemigrering.
• Kontinuerlig levering. Denne fordel kommer fra den tidligere erklæring. Moderniseringsprocessen blokerer ikke dit team for løbende at levere nye funktioner. Mens et team udvikler nye funktioner, refaktorerer et andet uafhængige moduler.
• Risikobegrænsning. Strangler Fig-mønsteret hjælper teamet med at fokusere på at modernisere specifikke dele af systemet. Dette fokus gør det muligt for teamet at være mere opmærksom på detaljer i specifikke områder, finde potentielle problemer tidligere og minimere den overordnede indvirkning på applikationen.

Problemstillinger og overvejelser

Når du anvender Strangler Fig-mønsteret, bør du planlægge migrationsstrategien omhyggeligt. Det omfatter identifikation af, hvilke komponenter der skal udskiftes først, sikring af korrekt integration mellem gamle og nye dele og vedligeholdelse af konsistente datamodeller. Teams bør også etablere klare kommunikationskanaler og overvågningssystemer for at spore fremskridtene og virkningen af hver udskiftning.

Virkninger på migration af mikrotjenester

Som vi diskuterede tidligere, giver overgangen til mikrotjenester fordele. Det gør dog også mange andre ting sværere og dyrere.

For eksempel kan QA- og Dev-teams stå over for en situation, hvor de ikke længere kan teste på lokale maskiner, fordi muligheden for at køre flere mikrotjenester lokalt er begrænset. Eller dine logfiler kan blive mindre indsigtsfulde, fordi i stedet for at én tjeneste behandler et enkelt flow, behandler flere tjenester det nu. Som følge heraf skal du implementere korrekt instrumentering og sporing for at se den komplette logsekvens.

Lad os diskutere et par afgørende aspekter, du bør overveje og måske planlægge, før din transformation af mikrotjenester starter.

Implementering og infrastruktur

Monolith og mikrotjenester har forskellige minimale infrastrukturkrav.

Når du kører en monolitapplikation, kan du normalt vedligeholde en enklere infrastruktur. Valgmuligheder som virtuelle maskiner eller PaaS-løsninger (såsom AWS EC2) vil være tilstrækkelige. Du kan også håndtere meget af skaleringen, konfigurationen, opgraderingerne og overvågningen manuelt eller med simple værktøjer. Som et resultat kan du undgå komplekse infrastrukturopsætninger og stole på udviklere eller supportingeniører uden at kræve omfattende DevOps-ekspertise.

Ved at vedtage en mikroservicearkitektur ændres denne dynamik. Efterhånden som antallet af tjenester vokser, bliver en manuel, praktisk tilgang hurtigt upraktisk. For effektivt at orkestrere, skalere og administrere flere tjenester har du brug for specialiserede platforme som Kubernetes eller i det mindste en administreret containertjeneste, der introducerer et nyt lag af kompleksitet og operationelle krav.

Platform lag

At vedligeholde en monolitapplikation er relativt ligetil. Hvis der opstår en CVE, opdaterer du den berørte afhængighed ét sted. Har du brug for at standardisere ekstern servicekommunikation? Implementer en enkelt wrapper og genbrug den i hele kodebasen.

I et mikroservicemiljø bliver disse simple opgaver meget mere komplekse. Hvad der tidligere var trivielt, involverer nu koordinering af ændringer på tværs af flere uafhængige tjenester, hver med sin livscyklus og afhængigheder. Den ekstra kompleksitet øger omkostningerne i både tid og ressourcer. Og situationen forværres, når man har mange hold og mange forskellige tjenester.

Derfor introducerer mange organisationer et dedikeret platformlag, typisk styret af et platformsteam. Målet er at skabe et fundament, som alle mikrotjenester kan arve: håndtering af fælles afhængigheder, implementering af standardiserede mønstre og levering af færdige indpakninger. Ved at forene disse elementer på platformsniveau forenkler du vedligeholdelsen betydeligt og fremmer sammenhæng på tværs af hele systemet.

Konklusion

At bryde en monolit op i mikrotjenester er en betydelig arkitektonisk transformation, der kræver omhyggelig overvejelse og planlægning.

I denne artikel har vi diskuteret trin, du kan tage for at forberede dig på det og gennemgå processen gnidningsløst. At holde sig til Strangler Fig-mønsteret vil give dig den trinvise proces og sikre systemstabilitet gennem hele transformationen. Den modulære monolit kan ikke kun være et nyttigt forberedelsestrin, men kan også medføre fordele, der kan få dig til at genoverveje din beslutning om mikroservicetransformation og undgå tilsvarende operationel kompleksitet.