Veci sa môžu rýchlo zamotať pri rozbíjaní monolitov do distribuovaných mikroslužieb. Dvaja skúsení softvéroví inžinieri diskutujú o radostiach a bolestiach...
Už roky je to mantra tohto odvetvia: monolity sú nemotorné, nepružné zvieratá, ktoré zastavujú všetky inovácie. Mnohé spoločnosti však majú monolity v tej či onej podobe, ktoré sa snažia rozbiť – ako napríklad tradičné ERP a MRP systémy alebo rozsiahle transakčné systémy.
Verte tomu alebo nie, o monolitoch sa dá povedať niekoľko dobrých vecí. Napríklad Ellen Körbes, manažérka vzťahov s developermi v Garden, nedávno upozornila prezentácia že "je niečo, čo sme mali s monolitmi kvôli tejto jednoduchosti, kúzlo programovania tam bolo." Spomína si, že s monolitmi je ľahké naučiť sa systém na prvýkrát. Máte jeden veľký systém, takže máte jeden programovací jazyk, máte jednu sadu pravidiel, jednu sadu konvencií a máte jeden veľký príkaz na zostavenie."
Samozrejme, Körbes nevidí v žiadnej budúcnosti monolitické systémy a ponúka open-source platformu na rozbitie a prestavbu architektúry mikroslužieb.
V samostatnom prezentáciaKelly Sutton, technický manažér v spoločnosti Gusto, diskutoval o dôsledkoch rozbíjania monolitov – najmä tých, ktoré boli postavené na Ruby on Rails -- ale jeho rady sa dajú aplikovať na mnohé programovacie jazyky a rámce, ktoré sa príliš rozrástli zlyhať.
Pre začiatočníkov je problémom presunu funkčnosti z monolitu do mikroslužieb to, že obe verzie bude potrebné udržiavať a aktualizovať, zdôrazňuje Sutton. "V skutočnosti sme vytvorili problém, ktorý je horší, ako sme mali," vysvetľuje. „V našom systéme sme doslova vytvorili kmeňové znalosti. Kedykoľvek teraz chceme nájsť koncept HR, musíme sa niekoho opýtať: „Hej, je to HR v2 alebo je to v starom HR dodatku, ktorý len tak trčí?“
Problémy narastajú s pribúdaním aplikácií alebo služieb. Pri rozhodovaní o vyčlenení funkcie ako služby, ako sú personálne mená, adresy a osobné údaje identifikačné čísla, údaje a funkcie môžu byť stále zdieľané medzi novými a starými aplikáciami -- HR v1 a HR v2.
Sutton ilustruje, aké problémy vznikajú, keď sa monolity rozpadnú:
„Vymenúvame všetky veci, ktoré dnes robí HR v1. Povedzme, že je to ako 14 vecí, a potom to pomaly začneme pripájať späť k hlavnej aplikácii, dôsledne postupujeme jednu po druhej a posúvame tých 14 správaní. Ale zvyčajne sa to asi v polovici stane pre niekoho prácou na plný úväzok, len aby povedal: 'dobre, čo je v HR v2 a čo v HR v1.' Choďte trochu ďalej a stále sa dostanete hlásenia chýb v starom HR systéme, takže teraz hovoríte: „Dobre, takže myslím, že sme opravili chybu v starom HR systéme, ale musíme ju znova vytvoriť v novom a potom opraviť tam."
Nasledujú odporúčania na rozbitie monolitov bez toho, aby sa veci ďalej skomplikovali:
Vyhnite sa kruhovým závislostiam. Ako možno rozdeliť monolitický systém a vyvinúť architektúru založenú na mikroslužbách? „Odpoveď je ‚bolestne‘,“ hovorí Körbes, ktorý poznamenáva, že monolitické závislosti sa vymieňajú za inú formu závislostí. „Zvládanie závislosti od služieb je náročné. Ak zmením svoju zásielkovú službu, možno budem musieť aktualizovať službu objednávok, a ak zmením službu objednávok, možno budem musieť aktualizovať službu front-end, pretože veci sa striedajú. Nemôžem zmeniť len jednu vec a očakávať, že tam nebude." Rozdiel oproti monolitickým aplikáciám je "máte kompilátor a kompilátor by mohol urobiť graf závislosti za vás.".
Použite hodnotové objekty na riešenie problémov s mierkou. Ako príklad Sutton hovorí: „Máme triedu služieb alebo objekt, ktorý rieši „čo by sa malo stať, keď spoločnosť sa zaregistruje v našej aplikácii?“ Pošleme e-mail a navýšime nejakého trénera štatistík počítadlo. Toto vyzerá dosť neškodne. Malé aplikácie to dokážu. Ale to, čo sme v skutočnosti urobili, je navždy prepojiť náš firemný mailer v našom sledovači štatistík so štruktúrou nášho firemného modelu. Pravdepodobne to nie je až taký problém, ale ako sa naša aplikácia rozrastá, môže byť veľmi, veľmi ťažké ju rozmotať. Namiesto toho z týchto bohatých aktívnych záznamových objektov odlupujeme len hodnoty, ktoré potrebujeme, a premieňame ich na hodnoty. možno dať tie zväzky hodnôt a potom ich len odovzdať akejkoľvek ďalšej triede alebo metóde, ktorú potrebujú na správne vykonávanie svojej práce."
Pohybujte sa pomaly. Rozdelenie monolitov na distribuované služby si bude vyžadovať dôkladné zváženie. „Máte veľkú hromadu kódu a rozdelíte ho na 20 rôznych častí a vložíte do nej nejaké výplne a niektoré z týchto častí sú teraz odlišným programovacím jazykom,“ hovorí Körbes. Keď idete do mikroslužieb, pridávate do nich veci, takže to bude pomalšie." Navyše, sú s tým spojené možno stovky ďalších programovacích hodín, hovorí Sutton. „Musíte si sadnúť so svojimi produktovými tímami a povedať: Dobre, urobíme toto a veci sa časom zrýchlia, ale zatiaľ sa nič nezmení. Ideme refaktorovať správne. Musíte vytvoriť silný obchodný prípad, ako vám to pomôže urýchliť a pomôže vám vyvinúť bezpečnejší softvér bez ohľadu na to, aký zlý je súčasný kód.“