Inaonekana kwamba kilele cha hype kwa microservices ni nyuma yetu. Hatusomi tena machapisho mara kadhaa kwa wiki "Jinsi nilivyohamisha monolith yangu hadi huduma 150." Sasa nasikia mawazo ya kawaida zaidi: "Sichukii monolith, ninajali tu ufanisi." Tuliona hata uhamiaji kadhaa kutoka kwa huduma ndogo hadi monolith. Unapohama kutoka kwa programu moja kubwa kwenda kwa huduma nyingi ndogo, utalazimika kutatua shida kadhaa mpya. Wacha tuziorodheshe kwa ufupi iwezekanavyo.

Kuweka: kutoka kemia ya msingi hadi mechanics ya quantum

Kuweka hifadhidata ya msingi na matumizi na mchakato wa usuli ulikuwa mchakato wa moja kwa moja. Ninachapisha somo kwenye Github - na mara nyingi baada ya saa moja, saa kadhaa zaidi, kila kitu hufanya kazi, na ninaanza mradi mpya. Kuongeza na kuendesha msimbo, angalau kwa mazingira ya awali, hufanywa siku ya kwanza. Lakini ikiwa tutajitosa katika huduma ndogo, wakati wa uzinduzi wa awali unaongezeka. Ndio, sasa tunayo Docker iliyo na orchestration na nguzo ya mashine za K8, lakini kwa programu ya novice hii yote ni ngumu zaidi. Kwa vijana wengi, huu ni mzigo ambao kwa kweli ni shida isiyo ya lazima.

Mfumo sio rahisi kuelewa

Hebu tuzingatie junior wetu kwa muda. Kwa maombi ya monolithic, ikiwa hitilafu ilitokea, ilikuwa rahisi kuifuatilia na mara moja kuendelea na kufuta. Sasa tuna huduma ambayo inazungumza na huduma nyingine ambayo inapanga foleni kitu kwenye basi la ujumbe ambalo linachakata huduma nyingine - na kisha hitilafu hutokea. Tunapaswa kuweka vipande hivi vyote pamoja ili hatimaye kujua kwamba Huduma A inaendesha toleo la 11, na Huduma E tayari inasubiri toleo la 12. Hii ni tofauti sana na logi yangu ya kawaida iliyounganishwa: kulazimika kutumia terminal/kitatuzi shirikishi kutembea. kupitia mchakato hatua kwa hatua. Utatuzi na uelewa kwa asili umekuwa mgumu zaidi.

Ikiwa haiwezi kutatuliwa, labda tutazijaribu

Ushirikiano unaoendelea na maendeleo endelevu sasa yanakuwa mambo ya kawaida. Programu nyingi mpya ninazoona huunda na kufanya majaribio kiotomatiki kwa kila toleo jipya na zinahitaji majaribio yafanywe na kukaguliwa kabla ya usajili. Hizi ni taratibu nzuri ambazo hazipaswi kuachwa na zimekuwa mabadiliko makubwa kwa makampuni mengi. Lakini sasa, ili kujaribu huduma kweli, lazima nitengeneze toleo kamili la kufanya kazi la programu yangu. Unamkumbuka yule mhandisi mpya aliye na nguzo ya K8 ya huduma 150? Kweli, sasa tutafundisha mfumo wetu wa CI jinsi ya kuleta mifumo hii yote ili kuthibitisha kuwa kila kitu kinafanya kazi kweli. Labda hii ni juhudi nyingi sana, kwa hivyo tutajaribu tu kila sehemu kwa kutengwa: Nina hakika kuwa vipimo vyetu ni vya kutosha, API ni safi, na kutofaulu kwa huduma kumetengwa na haitaathiri wengine.

Maelewano yote yana sababu nzuri. Haki?

Kuna sababu nyingi za kuhamia microservices. Nimeona hili likifanywa kwa kubadilika zaidi, kwa timu za kuongeza viwango, kwa utendakazi, ili kutoa uendelevu bora. Lakini kwa kweli, tumewekeza miongo kadhaa katika zana na mazoea ya kuunda monoliths ambazo zinaendelea kubadilika. Ninafanya kazi na wataalamu katika teknolojia tofauti. Kawaida tunazungumza juu ya kuongeza alama kwa sababu zinaingia kwenye mipaka ya nodi moja ya hifadhidata ya Postgres. Mazungumzo mengi yanahusu kuongeza hifadhidata.

Lakini ninavutiwa kila wakati kujifunza juu ya usanifu wao. Je, wako katika hatua gani ya mpito kwa huduma ndogo? Inafurahisha kuona wahandisi zaidi wakisema wamefurahishwa na matumizi yao ya monolithic. Watu wengi watafaidika na huduma ndogo, na faida zitazidi matuta katika njia ya uhamiaji. Lakini kibinafsi, tafadhali nipe maombi yangu ya monolithic, mahali pa pwani - na nina furaha kabisa.

Chanzo: mapenzi.com