Zdá sa, že vrchol popularity mikroservisov je dávno za nami. Už nečítame niekoľkokrát za týždeň príspevky „Ako som preniesol svoj monolit na 150 služieb“. Teraz častejšie počujem rozumné názory: „Nenávidím monolit, jednoducho dbám na efektivitu“. Svedkami sme dokonca boli niekoľkých migrácií . Pri prechode z jedného veľkého aplikácie na niekoľko menších služieb budete musieť vyriešiť niekoľko nových problémov. Vymenujme ich maximálne stručne.
Nastavenie: od základnej chémie po kvantovú mechaniku
Nastavenie základnej databázy a aplikácie s pozadím bolo pomerne jasným procesom. Zverejňujem readme na Github – a často za jednu hodinu, maximálne pár hodín, všetko funguje a ja začínam nový projekt. Pridávanie a spustenie kódu, aspoň pre počiatočné prostredie, sa dá urobiť v prvý deň. Ale ak sme sa odvážili na mikroservisy, čas potrebný na počiatočné spustenie sa astronomicky zvyšuje. Áno, teraz máme Docker s orchestráciou a klaster strojov K8, ale pre začínajúceho programátora je to oveľa zložitejšie. Pre mnohých juniorov to je bremeno, ktoré je skutočne zbytočnou zložitostí.
Systém nie je jednoduché pochopiť
Na chvíľu sa zastavíme pri našom juniorovi. Pri monolitických aplikáciách bolo v prípade chyby ľahké ju sledovať a okamžite sa pustit' do ladenia. Teraz máme službu, ktorá komunikuje s inou službou, ktorá dáva niečo do fronty na bus správy, ktorá spracováva inú službu – a tam vzniká chyba. Musíme poskladať všetky tieto časti dohromady, aby sme nakoniec zistili, že služba A funguje vo verzii 11, zatiaľ čo služba E už očakáva verziu 12. To sa výrazne líši od môjho štandardného zjednoteného denníka: musím použiť interaktívny terminál/ladenie, aby som prešiel procesom krok za krokom. Ladenie a pochopenie sa v podstate stalo zložitejším.
Ak sa to nedá odľadiť, možno ich otestujeme
Neprerušovaná integrácia a nepretržitý vývoj sa v súčasnosti stávajú samozrejmosťou. Väčšina nových aplikácií, ktoré vidím, automaticky vytvára a spúšťa testy s každým novým vydaním a vyžaduje, aby testy prešli a boli skontrolované pred registráciou. To sú skvelé procesy, od ktorých sa nedá upustiť, stali sa veľkým posunom pre mnohé spoločnosti. Ale teraz, aby som naozaj otestoval službu, musím spustiť plnú pracovnú verziu svojej aplikácie. Pamätáte si toho nového inžiniera s K8 klastrom zo 150 služieb? No, teraz naučíme náš CI systém, ako spustiť všetky tieto systémy, aby sme overili, že všetko naozaj funguje. Pravdepodobne je to príliš veľa úsilia, takže jednoducho otestujeme každú časť izolovane: som si istý, že naše špecifikácie sú dostatočne dobré, API sú čisté a výpadok služby je izolovaný a neovplyvní ostatných.
Všetky kompromisy majú rozumné zdôvodnenie. Je to pravda?
Existuje mnoho dôvodov na prechod na mikroservisy. Vidím, že sa to robí pre väčšiu flexibilitu, na škálovanie tímov, pre výkon, aby sa zabezpečila lepšia odolnosť práce. Ale v skutočnosti sme investovali desaťročia do nástrojov a praktík vývoja monolitov, ktoré naďalej prebiehajú. Pracujem s profesionálmi v rôznych technológiách. Zvyčajne hovoríme o škálovaní, pretože sa stretávajú s obmedzeniami jedného uzla databázy Postgres. Väčšina konverzácie sa venuje .
Ale vždy ma zaujíma ich architektúra. V akom štádiu prechodu na mikroservisy sa nachádzajú? Je zaujímavé sledovať, ako čoraz viac inžinierov hovorí, že sú spokojní so svojou monolitnou aplikáciou. Mnohým mikroservisy prinesú úžitok a výhody prevažujú nad prekážkami na ceste migrácie. Ale osobne, prosím, dajte mi moju monolitnú aplikáciu, miesto na pláži - a som úplne šťastný.
Zdroj: habr.com
