Zdi se, da je vrhunec zanimanja za mikrostoritve mimo. Že ne beremo več objav 'Kako sem svoj monolit preselil v 150 storitev' večkrat na teden. Zdaj pogosteje slišim razumne misli: 'Ne sovražim monolita, preprosto mi je mar za učinkovitost.' Predvsem smo opazili nekaj migracij Ko prehajate iz enega velikega aplikacije na več manjših storitev, se boste morali spopasti z več novimi problemi. Naštejmo jih čim bolj na kratko.
Namestitev: od osnovne kemije do kvantne mehanike
Nastavitev osnovne baze podatkov in aplikacije s procesom v ozadju je bila precej jasen proces. Objavim readme na Githubu – in pogosto v eni uri, največ v dveh, vse deluje in začnem nov projekt. Dodajanje in zagon kode, vsaj v začetnem okolju, poteka na prvi dan. Ampak, če se podamo v mikrostoritve, se čas začetnega zagona eksponentno poveča. Da, zdaj imamo Docker z orkestracijo in klaster K8, vendar je vse to za začetnega programerja precej zapleteno. Za mnoge junijore je to breme, ki je resnično odvečna kompleksnost.
Sistem ni enostavno razumeti.
Malo se ustavimo pri našem junijoru. Pri monolitnih aplikacijah je bilo v primeru napake enostavno slediti in takoj preiti na odpravljanje napak. Zdaj imamo storitev, ki komunicira z drugo storitvijo, ki postavi nekaj v vrsto na sporočilni vod, ki obdeluje drugo storitev – in tukaj nastane napaka. Vse te dele moramo sestaviti skupaj, da na koncu ugotovimo, da storitev A deluje v različici 11, medtem ko storitev E že čaka na različico 12. To se močno razlikuje od mojega standardnega konsolidiranega dnevnika: treba je uporabiti interaktivni terminal/debbuger, da gremo skozi proces korak za korakom. Odpravljanje napak in razumevanje sta po esencialnosti postala težja.
Če ne moremo odpraviti napak, jih bomo morda testirali.
Neprekinjena integracija i neprekinjena razvojna praksa postaju sve uobičajenije. Većina novih aplikacija koje vidim automatski generiše i pokreće testove sa svakim novim izdanjem i zahtevaju da se testovi prođu i pregledaju pre nego što se registruju. To su odlični procesi od kojih ne treba odustati, predstavljaju veliki pomak za mnoge kompanije. No, sada, da bi stvarno proverio uslugu, moram da pokrenem punu radnu verziju svoje aplikacije. Sećate li se onog novog inženjera sa K8 klasterom od 150 usluga? Pa, sada ćemo poučiti naš CI sistem kako da podigne sve te sisteme da bismo proverili da li sve zaista funkcioniše. Verovatno je to previše napora, pa ćemo jednostavno izolovano testirati svaku komponentu: siguran sam da su naše specifikacije dovoljno dobre, API su čisti, a usluga koja ne radi je izolovana i neće uticati na ostale.
Svaki kompromis ima svoje opravdanje. Zar ne?
Postoji mnogo razloga za prelazak na mikroservise. Video sam da se to radi radi veće fleksibilnosti, za skaliranje timova, zbog performansi i da se obezbedi bolja otpornosti. Ali u stvarnosti, uložili smo decenije u alate i prakse razvoja monolita koje se i dalje razvijaju. Radim sa profesionalcima u raznim tehnologijama. Obično govorimo o skaliranju, jer se suočavaju sa ograničenjima jednog čvora baze podataka Postgres. Većina razgovora je o .
Ali uvek me zanima da saznam o njihovoj arhitekturi. U kojoj fazi su prelaska na mikroservise. Zanimljivo je posmatrati kako sve više inženjera kaže da su zadovoljni svojim monolitnim aplikacijama. Mnogim mikroservisi će doneti koristi, a dobit će nadvladati prepreke na putu migracije. No, lično, molim vas, dajte mi moj monolitni uređaj, mesto na plaži - i potpuno sam srećan.
Izvor: habr.com
