Nilitaka kuandika nakala juu ya mada ya usanifu wa huduma ndogo kwa muda mrefu, lakini mambo mawili yaliendelea kunizuia - kadiri nilivyoingia kwenye mada hiyo, ndivyo ilionekana kwangu kuwa kile ninachojua ni dhahiri, na kile ninachofanya. sijui inahitaji kuchunguzwa na kusomwa. Kwa upande mwingine, nadhani tayari kuna kitu cha kujadili kati ya watazamaji wengi. Kwa hivyo maoni mbadala yanakaribishwa.
Sheria ya Conway na uhusiano kati ya biashara, shirika na mfumo wa habari
Kwa mara nyingine tena nitajiruhusu kunukuu:
"Shirika lolote linalounda mfumo (kwa maana pana) litapokea muundo ambao muundo wake unaiga muundo wa timu katika shirika hilo."
- Melvyn Conway, 1967
Kwa maoni yangu, sheria hii ina uwezekano mkubwa wa kuhusiana na uwezekano wa kuandaa biashara, badala ya moja kwa moja kwenye mfumo wa habari. Acha nieleze kwa mfano. Wacha tuseme tunayo fursa thabiti ya biashara na mzunguko wa maisha wa urefu kiasi kwamba inafanya akili kupanga biashara (hii sio typo, lakini napenda sana neno hili ambalo niliiba). Kwa kawaida, mfumo unaounga mkono wa biashara hii. italingana na biashara hii kiuratibu na kiutaratibu.
Mwelekeo wa biashara wa mifumo ya habari
Acha nieleze kwa mfano. Hebu tuseme kuna fursa ya biashara ya kuandaa biashara ya kuuza pizza. Katika toleo la V1 (hebu tuiite habari ya mapema), kampuni ilikuwa pizzeria, rejista ya pesa na huduma ya utoaji. Toleo hili liliishi kwa muda mrefu katika hali ya kutofautiana kwa mazingira ya chini. Kisha toleo la 2 lilikuja kuchukua nafasi yake - ya juu zaidi na yenye uwezo wa kutumia mfumo wa habari kwa msingi wake kwa biashara na usanifu wa monolithic. Na hapa, kwa maoni yangu, kuna dhuluma mbaya tu katika uhusiano na monoliths - usanifu unaodaiwa kuwa wa monolithic haulingani na mtindo wa biashara wa kikoa. Ndiyo, kama hii ingekuwa hivyo, mfumo haungeweza kufanya kazi hata kidogo - kinyume na sheria sawa ya Conway na akili ya kawaida. Hapana, usanifu wa monolithic unafanana kikamilifu na mtindo wa biashara katika hatua hii ya maendeleo ya biashara - mimi, bila shaka, ninamaanisha hatua wakati mfumo tayari umeundwa na kuweka katika uendeshaji. Ni ukweli wa ajabu kabisa kwamba bila kujali mbinu ya usanifu, toleo la 3 la usanifu unaozingatia huduma na toleo la usanifu wa huduma ndogo N litafanya kazi sawa. Nini samaki?
Kila kitu kinapita, kila kitu kinabadilika, au ni microservices njia ya kupambana na utata?
Kabla hatujaendelea, hebu tuangalie baadhi ya dhana potofu kuhusu usanifu wa huduma ndogo ndogo.
Wafuasi wa kutumia mbinu ya huduma ndogo mara nyingi wanasema kuwa kuvunja monolith katika huduma ndogo hurahisisha mbinu ya maendeleo kwa kupunguza msingi wa kanuni za huduma za kibinafsi. Kwa maoni yangu, kauli hii ni upuuzi mtupu. Kwa umakini, mwingiliano dhahiri ndani ya nambari ya monolith na homogeneous inaonekana kuwa ngumu? Ikiwa hii ndio kesi, miradi yote ingejengwa kama huduma ndogo, wakati mazoezi yanaonyesha kuwa uhamiaji kutoka kwa monolith hadi huduma ndogo ni kawaida zaidi. Utata haupotei; inasonga tu kutoka kwa moduli za kibinafsi hadi miingiliano (iwe mabasi ya data, RPC, API, na itifaki zingine) na mifumo ya kupanga. Na hii ni ngumu!
Faida ya kutumia stack tofauti pia ni ya shaka. Sitabishana kuwa hii pia inawezekana, lakini kwa ukweli hutokea mara chache (Kuangalia mbele - hii inapaswa kutokea - lakini kama matokeo kuliko faida).
Mzunguko wa maisha ya bidhaa na mzunguko wa maisha ya huduma
Angalia tena mchoro hapo juu. Sio bahati mbaya kwamba niligundua kupungua kwa mzunguko wa maisha wa toleo tofauti la biashara - katika hali ya kisasa, ni kuongeza kasi ya mpito wa biashara kati ya matoleo ambayo ni maamuzi kwa mafanikio yake. Mafanikio ya bidhaa imedhamiriwa na kasi ya majaribio ya nadharia za biashara ndani yake. Na hapa, kwa maoni yangu, kuna faida muhimu ya usanifu wa microservice. Lakini twende kwa utaratibu.
Wacha tuendelee kwenye hatua inayofuata katika mageuzi ya mifumo ya habari - kwa usanifu unaoelekezwa kwa huduma wa SOA. Kwa hivyo, wakati fulani tuliangazia katika bidhaa zetu huduma za muda mrefu - ya muda mrefu kwa maana kwamba wakati wa kusonga kati ya matoleo ya bidhaa, kuna nafasi kwamba mzunguko wa maisha wa huduma utakuwa mrefu zaidi kuliko mzunguko wa maisha ya toleo la pili la bidhaa. Itakuwa jambo la busara kutozibadilisha hata kidogo - sisi Kilicho muhimu ni kasi ya mpito kwa toleo linalofuata. Lakini ole, tunalazimika kufanya mabadiliko ya mara kwa mara kwa huduma - na hapa kila kitu kinatufanyia kazi, mazoea ya DevOps, uwekaji wa vyombo, na kadhalika - kila kitu kinachokuja akilini. Lakini hizi bado sio huduma ndogo!
Huduma ndogo kama njia ya kukabiliana na utata... usimamizi wa usanidi
Na hapa tunaweza hatimaye kuendelea na jukumu la kufafanua la huduma ndogo - hii ni mbinu ambayo hurahisisha usimamizi wa usanidi wa bidhaa. Kwa undani zaidi, kazi ya kila microservice inaelezea hasa kazi ya biashara ndani ya bidhaa kulingana na mfano wa kikoa - na haya ni mambo ambayo hayaishi katika toleo la muda mfupi, lakini katika fursa ya muda mrefu ya biashara. Na mpito kwa toleo linalofuata la bidhaa hufanyika bila kutambuliwa - unabadilisha / kuongeza huduma ndogo moja, na labda tu mpango wa mwingiliano wao, na ghafla unajikuta katika siku zijazo, ukiacha nyuma washindani wanaolia ambao wanaendelea kuruka kati ya matoleo. monoliths yao. Sasa fikiria kuwa kuna idadi kubwa ya huduma ndogo zilizo na miingiliano iliyoainishwa na uwezo wa biashara. Na unakuja na kujenga muundo wa bidhaa yako kutoka kwa microservices tayari - kwa kuchora tu mchoro, kwa mfano. Hongera - una jukwaa - na sasa unaweza kuvutia biashara kwako mwenyewe. Ndoto Ndoto.
Matokeo
- Usanifu wa mfumo unapaswa kuamua na mzunguko wa maisha ya vipengele vyake. Ikiwa sehemu inaishi ndani ya toleo la bidhaa, hakuna maana katika kuongeza utata wa mfumo kwa kutumia mbinu ya huduma ndogo.
- Usanifu wa huduma ndogo unapaswa kutegemea muundo wa kikoa - kwa sababu fursa ya biashara ndio kikoa cha muda mrefu zaidi
- Mazoea ya uwasilishaji (mazoea ya DevOps) na upangaji ni moja ya muhimu zaidi kwa usanifu wa huduma ndogo - kwa sababu ongezeko la kiwango cha mabadiliko ya vifaa huweka mahitaji ya kuongezeka kwa kasi na ubora wa utoaji.
Chanzo: mapenzi.com