Det virker som om toppen af hypen omkring mikrotjenester er passeret. Vi læser ikke længere indlæg som "Hvordan jeg flyttede mit monolit til 150 tjenester" flere gange om ugen. Jeg hører nu oftere rationelle overvejelser: "Jeg hader ikke monolitken, jeg bekymrer mig bare om effektivitet." Vi har endda været vidne til flere migrationer . Når man går fra ét stort program til flere mindre tjenester, skal man tackle flere nye problemer. Lad os liste dem så kort som muligt.
Installation: fra basal kemi til kvantemekanik
Konfigurationen af den grundlæggende database og applikationen med en baggrundsproces var en ret klar proces. Jeg publicerer readme på Github – og ofte efter en time, maks. et par timer, fungerer det hele, og jeg går i gang med et nyt projekt. At tilføje og køre koden, i det mindste for startmiljøet, kan lade sig gøre på den første dag. Men hvis vi tør tage skridtet til mikrotjenester, stiger den initiale opsætnings tid til himmels. Ja, vi har nu Docker med orkestrering og et klynge af K8-maskiner, men for en nybegynders programmerer er alt dette meget mere kompliceret. For mange juniorer er det en byrde, der virkelig er unødvendig kompleks.
Systemet er ikke let at forstå
Lad os tage et øjeblik for at fokusere på vores junior. Med monolitiske applikationer var det let at spore en fejl og straks gå til fejlsøgning. Nu har vi en tjeneste, der kommunikerer med en anden tjeneste, der sætter noget i kø på en meddelelsesbus, som behandler en tredje tjeneste—og her opstår fejlen. Vi skal samle alle disse dele, for til sidst at finde ud af, at tjeneste A kører på version 11, mens tjeneste E allerede venter på version 12. Det adskiller sig markant fra min standard konsoliderede log: jeg skal bruge et interaktivt terminal/debugger for at gennemgå processen trin for trin. Fejlsøgning og forståelse er i bund og grund blevet sværere.
Hvis det ikke kan debuggeres, kan vi muligvis teste dem
Kontinuerlig integration og kontinuerlig udvikling er nu blevet almindelig praksis. De fleste nye applikationer, jeg ser, bygger og kører test automatisk med hver nye version og kræver, at testene består og gennemgås, før registrering. Det er fremragende processer, som man ikke kan forsømme; de har været en stor ændring for mange virksomheder. Men nu, for virkelig at teste servicen, skal jeg sætte den fulde version af min applikation op. Kan du huske den nye ingeniør med K8-klusteret bestående af 150 tjenester? Nå, nu vil vi lære vores CI-system at sætte alle disse systemer op til at kontrollere, at alt faktisk fungerer. Sandsynligvis er det for stort et arbejde, så vi vil bare teste hver del isoleret: Jeg er sikker på, at vores specifikationer er gode nok, API'erne er rene, og tjenesteudfaldet er isoleret og ikke vil påvirke de andre.
Alle kompromiser har en god grund. Rigtigt?
Der er mange grunde til at skifte til mikrotjenester. Jeg har set, at det gøres for større fleksibilitet, for at skalere teams, for ydeevne, for at sikre bedre driftsstabilitet. Men i virkeligheden har vi investeret årtier i værktøjer og praksis til udvikling af monolitter, som fortsætter med at udvikle sig. Jeg arbejder med fagfolk i forskellige teknologier. Normalt taler vi om skalerbarhed, fordi de støder på grænserne for en enkelt Postgres-databaseknude. Størstedelen af samtalerne handler om .
Men jeg er altid nysgerrig efter at lære om deres arkitektur. På hvilket stadium af overgangen til mikrotjenester befinder de sig. Det er interessant at se, at flere og flere ingeniører siger, at de er tilfredse med deres monolitiske applikation. For mange vil mikrotjenester være til gavn, og fordelene vil opveje forhindringerne på migrationsvejen. Men personligt ville jeg gerne have min monolitiske applikation, et sted på stranden - og jeg er fuldstændig glad.
Kilde: habr.com
