Duket se kulmi i entuziazmit për mikroshërbimet ka kaluar. Tani nuk lexojmë më disa herë në javë postime si "Si e transferova monolitin tim në 150 shërbime". Tani dëgjoj shpesh mendime të arsyeshme: "Nuk e urrej monolitin, thjesht më intereson efikasiteti". Madje kemi vërejtur disa migraion nga mikroshërbimet përsëri në monolit. Kur kaloni nga një aplikacion të madh në disa shërbime më të vogla, do t'ju duhet të zgjidhni disa probleme të reja. Le të i përmendim ato sa më shkurt të jetë e mundur.

Instalimi: nga kimia e bazës në mekanikën kuantike

Konfigurimi i bazës së të dhënave dhe aplikacionit me një proces të prapambetur ishte një proces mjaft i qartë. Publikoj readme në Github — dhe shpesh brenda një ore, maksimumi dy orë, gjithçka funksionon, dhe unë filloj një projekt të ri. Shtimi dhe nisja e kodit, të paktën për ambientin fillestar, bëhet në ditën e parë. Por nëse ne kemi guximin të kalojmë në mikroshërbime, koha e nisjes fillestare rritet në mënyrë drastike. Po, tani kemi Docker me orkestrimin dhe një grumbull makinash K8, por për një programues të ri, gjithçka është shumë më e ndërlikuar. Për shumë juniorë, kjo është një barrë që është vërtet një kompleksitet i panevojshëm.

Sistemi nuk është i lehtë për t'u kuptuar

Le të ndalemi për një moment te juniori ynë. Me aplikacionet monolitike, në rast se ndodhte një gabim, ishte e lehtë ta ndjehje dhe menjëherë të kalosh në debuggim. Tani kemi një shërbim që komunikon me një shërbim tjetër, që shton diçka në radhë mbi njësinë e mesazheve, që përpunon një tjetër shërbim — dhe këtu ndodh një gabim. Duhet të përmbledhim të gjitha këto pjesë, për të mësuar përfundimisht se shërbimi A funksionon në versionin 11, ndërsa shërbimi E tashmë pret versionin 12. Kjo është shumë ndryshe nga logun tim tradicional të konsoliduar: më duhet të përdor një terminal interaktiv/debugger për të kaluar nëpër procesin hap pas hapi. Debugimi dhe të kuptuarit në thelb janë bërë më të vështira.

Nëse nuk mund ta debuguar, ndoshta do t'i testohet ato

Integrimi dhe zhvillimi i vazhdueshëm po bëhen tani një zakon. Shumica e aplikacioneve të reja që shoh, me çdo lëshim të ri, krijojnë dhe ekzekutojnë automatikisht teste dhe kërkojnë që testet të kalohen dhe shqyrtohen para se të regjistrohen. Këto janë procese të shkëlqyera, të cilat nuk duhet t'i anashkalojmë, ato kanë sjellë një ndryshim të madh për shumë kompani. Por tani, për të vërtetuar shërbimin, duhet të ngre një versione të plotë të aplikacionit tim. A e mbani mend inxhinierin e ri me grumbullin K8 prej 150 shërbimesh? Mirë, tani do ta mësojmë sistemin tonë CI se si të ngrejë të gjithë këto sisteme për të verifikuar që gjithçka funksionon vërtet. Më duket se është shumë punë, prandaj thjesht do t'i testohemi secilën pjesë izoluar: jam i sigurt që specifikimet tona janë mjaft të mira, API-të janë të pastër, dhe dështimi i shërbimit është izoluar dhe nuk do të ndikojë te të tjerët.

Të gjitha kompromise kanë një arsye të fortë. Ajo është e vërtetë?

Ka shumë arsye për të kaluar në mikroshërbime. Kam parë që ata e bëjnë këtë për fleksibilitet më të madh, për të shkallëzuar ekipet, për performancën, për të siguruar një qëndrueshmëri më të mirë të funksionimit. Por në realitet, ne kemi investuar dekada në mjete dhe praktika zhvillimi të monoliteve, të cilat vazhdojnë të zhvillohen. Punoj me profesionistë në teknologji të ndryshme. Zakonisht flasim për shkallëzimin, sepse ata përballen me kufijtë e një nodi të vetëm të bazës së të dhënave Postgres. Një pjesë e madhe e bisedave i kushtohet shkallëzimit të BDs.

Por gjithmonë më intereson të mësoj rreth arkitekturës së tyre. Në cilin fazë të kalimit në mikroshërbime ndodhen. Është interesante të shohësh se gjithnjë e më shumë inxhinierë thonë se janë të kënaqur me aplikacionin e tyre monolitik. Shumë mikroshërbime do të sjellin përfitime, dhe përfitimet do të kalojnë pengesat në rrugën e migrimit. Por personalisht, më jepni aplikacionin tim monolitik, një vend në plazh — dhe unë do të jem krejtësisht i lumtur.

Burimi: habr.com