Zdi se, da je vrhunec navdušenja nad mikrostoritvami za nami. Ne beremo več objav večkrat na teden "Kako sem svoj monolit preselil na 150 storitev." Zdaj slišim več zdravorazumskih misli: "Ne sovražim monolita, skrbi me le učinkovitost." Opazili smo celo več selitev . Pri prehodu z ene velike aplikacije na več manjših storitev boste morali rešiti več novih težav. Naj jih naštejemo čim bolj na kratko.
Dogajanje: od osnovne kemije do kvantne mehanike
Nastavitev osnovne baze podatkov in aplikacije s postopkom v ozadju je bil dokaj preprost postopek. Readme objavim na Githubu - in pogosto v eni uri, največ nekaj urah, vse deluje in začnem nov projekt. Dodajanje in izvajanje kode, vsaj za začetno okolje, se izvede prvi dan. Toda če se lotimo mikrostoritev, začetni čas zagona skokovito naraste. Da, zdaj imamo Docker z orkestracijo in gručo strojev K8, vendar je za programerja začetnika vse to veliko bolj zapleteno. Za marsikaterega mladinca je to breme, ki je res nepotrebno kompliciranje.
Sistema ni enostavno razumeti
Za trenutek se osredotočimo na našega podmladka. Če je pri monolitnih aplikacijah prišlo do napake, jo je bilo enostavno izslediti in takoj preiti na odpravljanje napak. Zdaj imamo storitev, ki se pogovarja z drugo storitvijo, ki postavlja nekaj v čakalno vrsto na sporočilnem vodilu, ki obdeluje drugo storitev – in potem pride do napake. Vse te dele moramo združiti, da na koncu ugotovimo, da storitev A uporablja različico 11, storitev E pa že čaka na različico 12. To se zelo razlikuje od mojega standardnega konsolidiranega dnevnika: za hojo je treba uporabiti interaktivni terminal/razhroščevalnik skozi postopek korak za korakom. Odpravljanje napak in razumevanje sta sama po sebi postala težja.
Če ne bo mogoče odpraviti napak, jih bomo morda preizkusili
Nenehno povezovanje in nenehen razvoj postajata nekaj običajnega. Večina novih aplikacij, ki jih vidim, samodejno ustvari in izvede teste z vsako novo izdajo ter zahteva, da se testi opravijo in pregledajo pred registracijo. To so odlični procesi, ki jih ne bi smeli opustiti in so bili velik premik za številna podjetja. Ampak zdaj, da resnično preizkusim storitev, moram prikazati polno delujočo različico svoje aplikacije. Se spomnite tistega novega inženirja z gručo K8 s 150 storitvami? No, zdaj bomo naš sistem CI naučili, kako priklicati vse te sisteme, da preveri, ali vse res deluje. To je verjetno preveč truda, zato bomo preizkusili vsak del ločeno: prepričan sem, da so naše specifikacije dovolj dobre, API-ji čisti, napaka storitve pa je izolirana in ne bo vplivala na druge.
Vsi kompromisi imajo dober razlog. Prav?
Razlogov za prehod na mikrostoritve je veliko. Videl sem, da je to narejeno za večjo prilagodljivost, za povečanje ekip, za uspešnost, za zagotavljanje boljše trajnosti. Toda v resnici smo desetletja vložili v orodja in prakse za razvoj monolitov, ki se še naprej razvijajo. Delam s strokovnjaki na področju različnih tehnologij. Običajno govorimo o skaliranju, ker naletijo na omejitve enega samega vozlišča baze podatkov Postgres. Večina pogovorov je o .
Vedno pa me zanima njihova arhitektura. Na kateri stopnji prehoda na mikrostoritve so? Zanimivo je videti več inženirjev, ki pravijo, da so zadovoljni s svojo monolitno aplikacijo. Veliko ljudi bo imelo koristi od mikrostoritev, koristi pa bodo odtehtale neravnine na poti selitve. Osebno pa prosim, dajte mi mojo monolitno aplikacijo, mesto na plaži - in popolnoma sem srečen.
Vir: www.habr.com