25. apríla sme v skupine Mail.ru usporiadali konferenciu o oblakoch a okolí - . Niekoľko zaujímavostí:
- Hlavný — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center a Yandex.Cloud hovorili o špecifikách nášho cloudového trhu a ich službách;
- Kolegovia z Bitrix24 povedali, ako to robia ;
- Zaujímavé poskytli Leroy Merlin, Otkritie, Burger King a Schneider Electric — aké úlohy kladie ich biznis pre IT a aké technológie, vrátane cloudových, považujú za najsľubnejšie.
Môžete si pozrieť všetky videá z konferencie mailto:CLOUD , a tu si môžete prečítať, ako prebiehala diskusia o mikroslužbách. Alexander Deulin, vedúci výskumného a vývojového centra obchodných systémov MegaFon, a Sergey Sergeev, riaditeľ informačných technológií skupiny M.Video-Eldorado, zdieľali svoje úspešné prípady, ako sa zbaviť monolitov. Diskutovali sme aj o súvisiacich otázkach IT stratégie, procesov a dokonca aj HR.
Panelisti
- Sergej Sergejev, Group CIO "M.Video-Eldorado";
- Alexander Deulin, vedúci centra pre výskum a vývoj podnikových systémov MegaFon;
- moderátor — Dmitrij Lazarenko, vedúci smeru PaaS Cloudové riešenia Mail.ru.
Po prejave Alexandra Deulina Do diskusie sa pripojili Sergey Sergeev z M.Video-Eldorado a moderátor diskusie Dmitrij Lazarenko, Mail.ru Cloud Solutions.
Nižšie sme pre vás pripravili prepis diskusie, ale môžete si pozrieť aj video:
Prechod na mikroslužby je reakciou na potreby trhu
Dmitrij:
Máte nejaké úspešné skúsenosti s migráciou na mikroslužby? A vo všeobecnosti: kde vidíte najväčší obchodný prínos z používania mikroslužieb alebo prechodu od monolitov k mikroslužbám?
Sergey:
Pri prechode na mikroslužby sme už prešli kus cesty a tento prístup používame už viac ako tri roky. Prvou potrebou, ktorá odôvodnila potrebu mikroslužieb, bola nekonečná integrácia rôznych front-end produktov s back office. A zakaždým sme boli nútení robiť ďalšiu integráciu a vývoj, implementovať vlastné pravidlá pre fungovanie tej či onej služby.
V určitom momente sme si uvedomili, že potrebujeme zrýchliť chod našich systémov a výstup funkcionality. V tom momente už na trhu existovali také koncepty ako mikroslužby a mikroservisný prístup a my sme sa rozhodli to vyskúšať. Toto sa začalo v roku 2016. Potom bola platforma položená a prvých 10 služieb bolo implementovaných samostatným tímom.
Jednou z prvých služieb, najviac zaťažených, bola služba cenovej kalkulácie. Zakaždým, keď prídete na akýkoľvek kanál, do skupiny spoločností M.Video-Eldorado, či už ide o webovú stránku alebo maloobchodnú predajňu, vyberiete si tam produkt, zobrazíte cenu na webovej stránke alebo v „Košíku“, cena je automaticky vypočítané jednou službou. Prečo je to potrebné: predtým mal každý systém svoje vlastné princípy práce s propagačnými akciami - so zľavami atď. Cenu zabezpečuje náš back office, funkcionalita zliav je implementovaná v inom systéme. Toto bolo potrebné centralizovať a vytvoriť unikátnu oddeliteľnú službu vo forme obchodného procesu, ktorá by nám to umožnila implementovať. Zhruba takto sme začali.
Hodnota prvých výsledkov bola veľmi veľká. Po prvé, dokázali sme vytvoriť oddeliteľné entity, ktoré nám umožňujú pracovať oddelene a agregovane. Po druhé, znížili sme náklady na vlastníctvo z hľadiska integrácie s viacerými systémami.
Za posledné tri roky sme pridali tri frontové systémy. Bolo ťažké ich udržiavať s rovnakým množstvom zdrojov, aké si spoločnosť mohla dovoliť. Preto vznikla úloha hľadať nové odbytiská, reagujúce na trh z hľadiska rýchlosti, vnútorných nákladov a efektivity.
Ako merať úspešnosť migrácie na mikroslužby
Dmitrij:
Ako sa určuje úspech pri migrácii na mikroslužby? Čo bolo „predtým“ v každej spoločnosti? Akú metriku ste použili na určenie úspešnosti prechodu a kto ju vlastne určil?
Sergey:
V prvom rade sa zrodil v rámci IT ako aktivátor – „odomykanie“ nových možností. Museli sme robiť všetko rýchlejšie za relatívne rovnaké peniaze a reagovať na výzvy trhu. Teraz je úspech vyjadrený v počte služieb opätovne používaných rôznymi systémami, zjednotením procesov medzi sebou. Teraz je, ale v tom momente to bola príležitosť na vytvorenie platformy a potvrdenie hypotézy, že to dokážeme, dá to efekt a vyráta obchodný prípad.
Alexander:
Úspech je skôr vnútorný pocit. Obchod chce vždy viac a hĺbka našich nevybavených vecí je dôkazom úspechu. Mne to tak pripadá.
Sergey:
Áno, súhlasím s tým. Za tri roky máme už viac ako dvesto služieb a nevybavených vecí. Potreba zdrojov v rámci tímu len rastie – o 30 % ročne. Deje sa to preto, lebo ľudia cítili: je to rýchlejšie, je to iné, existujú rôzne technológie, toto všetko sa vyvíja.
Mikroslužby prídu, ale jadro zostane
Dmitrij:
Je to ako nikdy nekončiaci proces, kedy investujete do vývoja. Skončil sa prechod na mikroslužby pre podnikanie alebo nie?
Sergey:
Je veľmi jednoduché odpovedať. Čo si myslíte: výmena telefónov je nekonečný proces? My sami kupujeme telefóny každý rok. A je to tu: kým bude potrebná rýchlosť, prispôsobenie sa trhu, budú potrebné určité zmeny. To neznamená, že sa vzdávame štandardných vecí.
Nemôžeme však zakryť a prerobiť všetko naraz. Máme staré štandardné integračné služby, ktoré existovali predtým: podnikové autobusy a tak ďalej. Existuje však oneskorenie a tiež potreba. Počet mobilných aplikácií a ich funkcionalita rastie. Zároveň nikto nehovorí, že dostanete o 30% viac peňazí. To znamená, že na jednej strane sú vždy potreby a na druhej strane hľadanie efektivity.
Dmitrij:
Život je v dobrom stave. (smiech)
Alexander:
Vo všeobecnosti áno. Nemáme revolučné prístupy k odstráneniu základnej časti z krajiny. Systematicky sa pracuje na rozklade systémov tak, aby boli konzistentnejšie s architektúrou mikroslužieb, aby sa znížil vplyv systémov na seba.
Ale plánujeme si ponechať základnú časť, pretože v prostredí operátora budú vždy nejaké platformy, ktoré kupujeme. Opäť potrebujeme zdravú rovnováhu: nemali by sme sa ponáhľať s vyrezávaním jadra. Umiestňujeme systémy vedľa seba a teraz sa ukazuje, že sme už na vrchole mnohých základných častí. Ďalej rozvíjaním funkčnosti vytvárame potrebné reprezentácie pre všetky kanály, ktoré pracujú s našimi komunikačnými službami.
Ako predávať mikroslužby firmám
Dmitrij:
Tiež ma zaujíma – pre tých, ktorí neprešli, ale plánujú to: aké ľahké bolo predať tento nápad firme a bolo to dobrodružstvo, investičný projekt? Alebo to bola vedomá stratégia: teraz ideme na mikroservisy a to je všetko, nič nás nezastaví. ako ti bolo?
Sergey:
Nepredávali sme prístup, ale obchodný benefit. V podnikaní sa vyskytol problém a my sme sa ho snažili vyriešiť. V tom momente sa to prejavilo v tom, že rôzne kanály používali rôzne princípy na výpočet cien - zvlášť pre akcie, pre akcie atď. Bolo to náročné na údržbu, vyskytli sa chyby a počúvali sme sťažnosti zákazníkov. To znamená, že sme predávali riešenie problému, no prišli sme s tým, že potrebujeme peniaze na vytvorenie platformy. A ukázali obchodný prípad na príklade prvej etapy investície: ako sa nám to bude ďalej splácať a čo nám to umožní.
Dmitrij:
Zaznamenali ste nejako čas prvej etapy?
Sergey:
Áno samozrejme. Vyčlenili sme 6 mesiacov na vytvorenie jadra ako platformy a testovanie pilotnej verzie. Počas tejto doby sme sa snažili vytvoriť platformu, na ktorej bude korčuľovať pilot. Potom sa hypotéza potvrdila a keďže funguje, znamená to, že môžeme pokračovať. Začali replikovať a posilňovať tím – presunuli ho do samostatnej divízie, ktorá robí práve to.
Nasleduje systematická práca založená na obchodných potrebách, príležitostiach, dostupnosti zdrojov a všetkého, na čom sa momentálne pracuje.
Dmitrij:
OK. Alexander, čo povieš?
Alexander:
Naše mikroslužby sa zrodili z „morskej peny“ - kvôli šetreniu zdrojov, kvôli niektorým zvyškom v podobe kapacity servera a prerozdelenia síl v tíme. Pôvodne sme tento projekt nepredávali firme. Bol to projekt, v ktorom sme skúmali a vyvíjali zodpovedajúcim spôsobom. Začali sme začiatkom roka 2018 a jednoducho sme tento smer rozvíjali s nadšením. Predaj práve začal a my sme v procese.
Dmitrij:
Stáva sa, že vám firma umožňuje robiť také veci ako Google – v jeden voľný deň v týždni? Máte taký smer?
Alexander:
Zároveň s výskumom sme sa zaoberali aj biznis problémami, takže všetky naše mikroslužby sú riešením biznis problémov. Len na začiatku sme vybudovali mikroslužby, ktoré pokrývali malú časť predplatiteľskej základne, a teraz sme prítomní takmer vo všetkých vlajkových produktoch.
A materiálny dopad je už jasný – už sme spočítaní, rýchlosť uvedenia produktov na trh a stratené tržby sa dajú odhadnúť, ak by sme išli starou cestou. To je to, na čom staviame prípad.
Mikroslužby: humbuk alebo nevyhnutnosť?
Dmitrij:
Čísla sú čísla. A výnos alebo ušetrené peniaze sú veľmi dôležité. Čo ak sa pozriete na druhú stranu? Zdá sa, že mikroslužby sú trendom, humbukom a mnohé firmy to zneužívajú? Ako jasne rozlišujete medzi tým, čo robíte a čo neprekladáte do mikroslužieb? Ak máte dedičstvo teraz, budete mať dedičstvo aj o 5 rokov? Aký bude vek informačných systémov, ktoré fungujú v M.Video-Eldorado a MegaFon o 5 rokov? Budú desaťročné, pätnásťročné informačné systémy alebo to bude nová generácia? Ako to vidíš?
Sergey:
Zdá sa mi, že je ťažké myslieť veľmi ďaleko. Ak sa pozrieme späť, kto si predstavoval, že sa technologický trh bude vyvíjať týmto spôsobom vrátane strojového učenia a identifikácie používateľov podľa tváre? Ale ak sa pozriete na najbližšie roky, zdá sa mi, že základné systémy, podnikové systémy triedy ERP vo firmách - fungujú už pomerne dlho.
Naše spoločnosti majú spolu 25 rokov a klasické ERP sú veľmi hlboko v systémovom prostredí. Je jasné, že niektoré kúsky odtiaľ vytiahneme a pokúsime sa ich agregovať do mikroslužieb, ale jadro zostane. Teraz je pre mňa ťažké predstaviť si, že tam nahradíme všetky základné systémy a rýchlo prejdeme na druhú, svetlú stránku nových systémov.
Som zástancom toho, že všetko, čo je bližšie ku klientovi a spotrebiteľovi, je tam, kde je najväčší obchodný prínos a hodnota, kde je prispôsobivosť a zameranie na rýchlosť, na zmenu, na „vyskúšaj, zruš, znova použi, urob niečo iné“ potrebné “-tu sa krajina zmení. A krabicové výrobky sa tam veľmi nehodia. Aspoň to nevidíme. Tam sú potrebné tie najjednoduchšie a najjednoduchšie riešenia.
Vidíme tento vývoj:
- základné informačné systémy (väčšinou back office);
- stredné vrstvy vo forme mikroslužieb spájajú jadro, agregujú, vytvárajú vyrovnávaciu pamäť atď.;
- systémy prvej línie sú zamerané na spotrebiteľa;
- integračná vrstva, ktorá je vo všeobecnosti integrovaná do trhovísk, iných systémov a ekosystémov. Táto vrstva je čo najľahšia, jednoduchá a obsahuje minimum obchodnej logiky.
Ale zároveň som zástancom toho, aby sa naďalej používali staré princípy, ak sa používajú primerane.
Povedzme, že máte klasický podnikový systém. Nachádza sa v krajine jedného predajcu a pozostáva z dvoch modulov, ktoré navzájom spolupracujú. Nechýba ani štandardné integračné rozhranie. Prečo to prerobiť a priniesť tam mikroslužbu?
Ale keď je v back office 5 modulov, z ktorých sa zbierajú informácie do obchodného procesu, ktorý potom využíva 8-10 front-line systémov, prínos je okamžite viditeľný. Vyberiete z piatich back-office systémov a vytvoríte službu, izolovanú, ktorá je zameraná na obchodný proces. Urobte službu technologicky pokročilou - aby ukladala informácie do vyrovnávacej pamäte a bola odolná voči chybám a pracovala aj s dokumentmi alebo obchodnými subjektmi. A integrujete ho podľa jediného princípu so všetkými produktmi prvej línie. Zrušili produkt prvej línie – jednoducho vypli integráciu. Zajtra musíte napísať mobilnú aplikáciu alebo spraviť malú webstránku a do funkčnosti dať iba jednu časť - všetko je jednoduché: zostavili ste to ako konštruktér. V tomto smere vidím väčší rozvoj – aspoň u nás.
Alexander:
Sergej úplne opísal náš prístup, ďakujem. Poviem len, kam určite nepôjdeme - k hlavnej časti, k téme online fakturácie. To znamená, že hodnotenie a nabíjanie zostane v skutočnosti „veľkou“ mlátičkou, ktorá peniaze spoľahlivo odpíše. A tento systém bude naďalej certifikovaný našimi regulačnými orgánmi. Všetko ostatné, čo sa pozerá smerom ku klientom, sú samozrejme mikroslužby.
Dmitrij:
Tu je certifikácia jeden príbeh. Pravdepodobne väčšia podpora. Ak na podporu miniete málo alebo systém nevyžaduje podporu a úpravy, je lepšie sa ho nedotýkať. Rozumný kompromis.
Ako rozvíjať spoľahlivé mikroslužby
Dmitrij:
Dobre. Ale aj tak ma to zaujíma. Teraz rozprávate úspešný príbeh: všetko bolo v poriadku, prešli sme na mikroslužby, obhajovali nápad pred podnikom a všetko fungovalo. Ale počul som aj iné príbehy.
Pred niekoľkými rokmi švajčiarska spoločnosť, ktorá investovala dva roky do vývoja novej platformy mikroslužieb pre banky, nakoniec projekt uzavrela. Úplne skolabované. Utratilo sa veľa miliónov švajčiarskych frankov, ale nakoniec bol tím rozptýlený - nevyšlo to.
Mali ste podobné príbehy? Boli alebo sú nejaké ťažkosti? Napríklad udržiavanie mikroslužieb a monitorovanie je tiež bolesťou hlavy v prevádzkových činnostiach spoločnosti. Koniec koncov, počet komponentov sa zvyšuje desaťkrát. Ako to vidíte vy, boli tu neúspešné príklady investícií? A čo poradiť ľuďom, aby sa s takýmito problémami nestretli?
Alexander:
Medzi neúspešné príklady patrili podniky, ktoré menia priority a rušia projekty. Keď bol podnik v dobrej fáze pripravenosti (v skutočnosti je MVP pripravený), povedal: „Máme nové priority, prechádzame na ďalší projekt a tento uzatvárame.“
S mikroslužbami sme nemali žiadne globálne zlyhania. Spíme pokojne, máme 24/7 službu, ktorá obsluhuje celý BSS [systém podpory podnikania].
A ešte niečo – mikroslužby prenajímame podľa pravidiel, ktoré platia pre krabičkové produkty. Kľúčom k úspechu je, že v prvom rade potrebujete zostaviť tím, ktorý kompletne pripraví mikroslužbu na výrobu. Samotný vývoj je podmienečne 40 %. Zvyšok tvorí analytika, metodológia DevSecOps, správne integrácie a správna architektúra. Osobitnú pozornosť venujeme zásadám budovania bezpečných aplikácií. Zástupcovia informačnej bezpečnosti sa podieľajú na každom projekte tak vo fáze plánovania architektúry, ako aj počas procesu implementácie. Spravujú tiež systémy na analýzu zraniteľných miest kódu.
Povedzme, že nasadíme naše bezstavové služby – máme ich v Kubernetes. To umožňuje každému pokojne spať vďaka automatickému škálovaniu a automatickému zvyšovaniu služieb a pracovná zmena zachytáva incidenty.
Za celú existenciu našich mikroslužieb došlo iba k jednému alebo dvom incidentom, ktoré sa dostali na našu linku. Teraz nie sú žiadne problémy s prevádzkou. My, samozrejme, nemáme 200, ale asi 50 mikroslužieb, ale používajú sa vo vlajkových produktoch. Ak by zlyhali, boli by sme prví, kto by o tom vedel.
Mikroslužby a HR
Sergey:
Súhlasím s kolegom ohľadom presunu na podporu - že prácu treba organizovať správne. Ale poviem vám o problémoch, ktoré, samozrejme, existujú.
Po prvé, technológia je nová. Toto je v dobrom slova zmysle humbuk a nájsť odborníka, ktorý tomu bude rozumieť a dokáže ho vytvoriť, je veľká výzva. Súperenie o zdroje je šialené, takže odborníci majú cenu zlata.
Po druhé, s vytváraním určitých oblastí a rastúcim počtom služieb je potrebné neustále riešiť problém opätovného použitia. Ako vývojári radi robia: „Poďme sem teraz napísať veľa zaujímavých vecí...“ Z tohto dôvodu systém rastie a stráca svoju efektivitu z hľadiska peňazí, nákladov na vlastníctvo atď. To znamená, že je potrebné zahrnúť opätovné použitie do architektúry systému, zahrnúť ho do plánu zavádzania služieb a prenosu dedičstva do novej architektúry.
Ďalším problémom – hoci je to svojím spôsobom dobré – je vnútorná konkurencia. "Ach, objavili sa tu noví módni chlapci, hovoria novým jazykom." Ľudia sú, samozrejme, rôzni. Sú takí, ktorí sú zvyknutí písať v Jave, a takí, ktorí píšu a používajú Docker a Kubernetes. Sú to úplne odlišní ľudia, hovoria inak, používajú iné výrazy a niekedy si nerozumejú. Problémom je v tomto zmysle aj schopnosť alebo neschopnosť zdieľať prax, zdieľanie vedomostí.
No, škálovanie zdrojov. „Super, poďme! A teraz chceme rýchlejšie, viac. Čo, nemôžeš? Nie je možné dodať dvakrát toľko za rok? A prečo?" Takéto rastové bolesti sú pravdepodobne štandardom pre veľa vecí, veľa prístupov a môžete ich cítiť.
Čo sa týka monitorovania. Zdá sa mi, že služby alebo priemyselné monitorovacie nástroje sa už učia alebo sú schopné pracovať s Dockerom aj Kubernetes v inom, neštandardnom režime. Aby ste napríklad neskončili s 500 strojmi Java, pod ktorými to všetko beží, konkrétne sa to agreguje. Ale týmto produktom stále chýba zrelosť, musia si tým prejsť. Téma je naozaj nová, bude sa ďalej rozvíjať.
Dmitrij:
Áno, veľmi zaujímavé. A to sa týka HR. Možno sa váš proces HR a značka HR za tie 3 roky trochu zmenili. Začali ste získavať ďalších ľudí s rôznymi kompetenciami. A pravdepodobne existujú výhody aj nevýhody. Predtým boli blockchain a veda o dátach humbuk a špecialisti na ne mali hodnotu miliónov. Teraz náklady klesajú, trh sa nasýti a podobný trend je aj v mikroslužbách.
Sergey:
Áno, jednoznačne.
Alexander:
HR kladie otázku: "Kde je váš ružový jednorožec medzi backendom a frontendom?" HR nechápe, čo je mikroslužba. Povedali sme im tajomstvo a povedali sme im, že backend urobil všetko a žiadny jednorožec neexistuje. Ale HR sa mení, rýchlo sa učí a získava ľudí, ktorí majú základné IT znalosti.
Vývoj mikroslužieb
Dmitrij:
Ak sa pozriete na cieľovú architektúru, mikroslužby vyzerajú ako také monštrum. Vaša cesta trvala niekoľko rokov. Iní majú rok, iní tri roky. Predvídali ste všetky problémy, cieľovú architektúru, zmenilo sa niečo? Napríklad v prípade mikroslužieb sa teraz opäť objavujú brány a servisné siete. Používali ste ich na začiatku alebo ste zmenili samotnú architektúru? Máte takéto výzvy?
Sergey:
Prepísali sme už niekoľko komunikačných protokolov. Najprv bol jeden protokol, teraz sme prešli na iný. Zvyšujeme bezpečnosť a spoľahlivosť. Začínali sme podnikovými technológiami – Oracle, Web Logic. Teraz sa v mikroslužbách vzďaľujeme od technologických podnikových produktov a prechádzame na open source alebo úplne otvorené technológie. Opúšťame databázy a prechádzame k tomu, čo nám v tomto modeli funguje efektívnejšie. Už nepotrebujeme technológie Oracle.
Začali sme jednoducho ako služba, bez toho, aby sme premýšľali o tom, ako veľmi potrebujeme cache, čo by sme robili, keď nebolo spojenie s mikroslužbou, ale boli potrebné dáta atď. Teraz vyvíjame platformu, aby sa dala popísať architektúra nie v jazyku služieb a v obchodnom jazyku posuňte obchodnú logiku na vyššiu úroveň, keď začneme hovoriť slovami. Teraz sme sa naučili hovoriť písmenami a ďalšia úroveň je, keď sa služby budú zhromažďovať do nejakého agregátu, keď už je to slovo - napríklad celá produktová karta. Je zostavený z mikroslužieb, ale je to API postavené na tomto.
Bezpečnosť je veľmi dôležitá. Akonáhle začnete byť dostupní a máte službu, prostredníctvom ktorej môžete získať veľa zaujímavých vecí, a to veľmi rýchlo, v zlomku sekundy, potom je tu túžba získať to nie práve najbezpečnejším spôsobom. Aby sme sa z toho dostali, museli sme zmeniť prístupy k testovaniu a monitorovaniu. Museli sme zmeniť tím, štruktúru riadenia dodávok, CI/CD.
Ide o evolúciu – podobne ako pri telefónoch, len oveľa rýchlejšiu: najskôr boli tlačidlové telefóny, potom sa objavili smartfóny. Prepísali a prepracovali produkt, pretože trh mal inú potrebu. Takto sa vyvíjame: prvá trieda, desiata trieda, práca.
Iteratívne sa niečo rozloží na rok z pohľadu technológie, niečo iné z pohľadu backlogu a potrieb. Spájame jednu vec s druhou. Tím vynakladá 20 % na technický dlh a technickú podporu tímu, 80 % na podnikateľský subjekt. A pohybujeme sa s pochopením toho, prečo to robíme, prečo robíme tieto technologické vylepšenia, k čomu povedú. Ako to.
Dmitrij:
V pohode. Čo je v MegaFone?
Alexander:
Hlavnou výzvou, keď sme prišli k mikroslužbám, bolo neupadnúť do chaosu. Architektonická kancelária MegaFon sa k nám okamžite pripojila, dokonca sa stala iniciátorom a vodičom – teraz máme veľmi silnú architektúru. Jeho úlohou bolo pochopiť, do akého cieľového modelu ideme a aké technológie je potrebné otestovať. S architektúrou sme tieto pilotné projekty viedli sami.
Ďalšia otázka znela: „Ako potom toto všetko využiť? A ešte jedna: "Ako zabezpečiť transparentnú interakciu medzi mikroslužbami?" Servisná sieť nám pomohla odpovedať na poslednú otázku. Istio sme pilotovali a výsledky sa nám páčili. Teraz sa nachádzame v štádiu prechodu do produktívnych zón. Ku všetkým výzvam máme pozitívny vzťah – to, že treba neustále meniť zásobník, učiť sa niečo nové. Máme záujem rozvíjať, nie využívať staré riešenia.
Dmitrij:
Zlaté slová! Takéto výzvy udržujú tím a podnikanie v strehu a vytvárajú budúcnosť. GDPR vytvorilo hlavných úradníkov pre ochranu údajov a súčasné výzvy vytvárajú hlavných úradníkov pre mikroslužby a architektúru. A to poteší.
Veľa sme diskutovali. Hlavná vec je, že dobrý dizajn mikroslužieb a samotná architektúra umožňuje vyhnúť sa mnohým chybám. Samozrejme, tento proces je iteratívny a evolučný, ale je to budúcnosť.
Vďaka všetkým účastníkom, vďaka Sergejovi a Alexandrovi!
Otázky z publika
Otázka z publika (1):
Sergey, ako sa zmenil manažment IT vo vašej spoločnosti? Chápem, že keď existuje veľký zásobník niekoľkých systémov, ako sa to riadi, je pomerne jasný a logický proces. Ako ste prebudovali správu IT komponentu po integrácii veľkého množstva mikroslužieb v tak krátkom čase?
Sergey:
Súhlasím s kolegom, že architektúra je veľmi dôležitá ako hybná sila zmien. Začali sme tým, že sme mali architektonickú divíziu. Architekti sú zároveň vlastníkmi rozloženia funkcionality a požiadaviek na to, ako sa prejaví v krajine. Pôsobia teda aj ako koordinátori týchto zmien. V dôsledku toho došlo pri vytváraní platformy CI/CD k špecifickým zmenám v konkrétnom procese doručovania.
Ale štandard, základné princípy vývoja, obchodnej analýzy, testovania a vývoja neboli zrušené. Len sme pridali rýchlosť. Predtým trval cyklus toľko, inštalácia v testovacích prostrediach trvala oveľa viac. Teraz biznis vidí výhodu a hovorí: „Prečo by sa to nedalo urobiť na iných miestach?
Je to v dobrom slova zmysle ako injekcia vo forme vakcíny, ktorá ukázala: môžete to urobiť takto, ale môžete to urobiť inak. Samozrejme, je problém v personáli, v kompetenciách, vo vedomostiach, v odpore.
Otázka z publika (2):
Kritici architektúry mikroslužieb tvrdia, že testovanie a vývoj sú náročné. To je logické tam, kde sa veci komplikujú. Akým výzvam čelil váš tím a ako ste ich zvládli? Otázka pre každého.
Alexander:
Pri prechode z mikroslužieb na platformu existujú ťažkosti, ale dajú sa vyriešiť.
Napríklad vyrábame produkt, ktorý pozostáva z 5-7 mikroslužieb. Musíme poskytnúť integračné testy naprieč celým zásobníkom mikroslužieb, aby sme dali zelenú prechodu do hlavnej pobočky. Táto úloha pre nás nebola nová: v BSS sme to robili už dlho, keď nám dodávateľ dodal už dodané riešenia.
A náš problém je len v malom tíme. Na jeden podmienený produkt je potrebný jeden technik kontroly kvality. A tak dodávame produkt 5-7 mikroslužieb, z ktorých 2-3 môžu byť vyvinuté tretími stranami. Máme napríklad produkt, na vývoji ktorého sa podieľa náš predajca fakturačného systému, Mail.ru Group a MegaFon R&D. Pred odoslaním do výroby to musíme pokryť testami. QA inžinier pracuje na tomto produkte mesiac a pol a zvyšok tímu zostáva bez jeho podpory.
Táto zložitosť je spôsobená iba škálovaním. Chápeme, že mikroslužby nemôžu existovať vo vákuu, absolútna izolácia neexistuje. Pri zmene jednej služby sa vždy snažíme zachovať API kontrakt. Ak sa niečo zmení pod kapotou, predná služba zostáva. Ak sú zmeny fatálne, dôjde k nejakej architektonickej transformácii a prejdeme na úplne iný dátový metamodel, ktorý je úplne nekompatibilný – až potom hovoríme o tom, že sa objaví špecifikácia API služby v2. Podporujeme prvú a druhú verziu súčasne a keď všetci spotrebitelia prejdú na druhú verziu, prvú jednoducho zatvoríme.
Sergey:
Chcem dodať. Absolútne súhlasím s komplikáciami - stávajú sa. Krajina sa stáva zložitejšou a režijné náklady sa zvyšujú, najmä na testovanie. Ako sa s tým vysporiadať: prejdite na automatizované testovanie. Áno, budete musieť investovať dodatočne do písania autotestov a jednotkových testov. Aby sa vývojári nemohli zaviazať bez absolvovania testu, nemohli zmeniť kód. Aby ani tlačidlo nefungovalo bez autotestu, test jednotky.
Je dôležité zachovať predchádzajúcu funkčnosť, a to je dodatočná réžia. Ak prepíšete technológiu na iný protokol, potom ju prepíšete, kým všetko úplne nezatvoríte.
Niekedy nerobíme komplexné testovanie zámerne, pretože nechceme zastaviť vývoj, aj keď máme jednu vec za druhou. Krajina je veľmi veľká, zložitá, je tu veľa systémov. Niekedy sú to len útržky – áno, znížite bezpečnostnú rezervu, objavia sa ďalšie riziká. Ale zároveň uvoľníte zásobu.
Alexander:
Áno, autotesty a testy jednotiek vám umožňujú vytvoriť vysokokvalitnú službu. Sme za plynovod, ktorý nemožno prejsť bez jednotkových a integračných testov. Často musíme pretiahnuť emulátory a komerčné systémy do testovacích zón a vývojových prostredí, pretože nie všetky systémy je možné umiestniť do testovacích zón. Navyše sa len tak nenamočia – generujeme plnohodnotnú odozvu systému. Ide o vážnu súčasť práce s mikroslužbami a do toho aj investujeme. Bez toho nastane chaos.
Otázka z publika (3):
Pokiaľ som pochopil, mikroslužby pôvodne vyrástli zo samostatného tímu a teraz existujú v tomto modeli. Aké sú jeho plusy a mínusy?
Máme len podobný príbeh: vznikla akási továreň na mikroslužby. Teraz sme koncepčne dospeli k tomu, že tento prístup rozširujeme na produkciu o streamy a systémy. Inými slovami, vzďaľujeme sa od centralizovaného vývoja mikroslužieb, modelov mikroslužieb a približujeme sa k systémom.
Podľa toho ide aj naša prevádzka do systémov, čiže túto tému decentralizujeme. Aký je váš prístup a aký je váš cieľový príbeh?
Alexander:
Názov „továreň na mikroslužby“ ste vypustili priamo z úst – aj my chceme škálovať. Po prvé, teraz máme skutočne jeden tím. Chceme poskytnúť všetkým vývojárskym tímom, ktoré má MegaFon, možnosť pracovať v spoločnom ekosystéme. Nechceme úplne prevziať všetky funkcie vývoja, ktoré teraz máme. Lokálnou úlohou je škálovať, globálnou úlohou je viesť vývoj pre všetky tímy v mikroservisnej vrstve.
Sergey:
Poviem vám cestu, ktorou sme sa vybrali. Naozaj sme začali fungovať ako jeden tím, ale teraz už nie sme sami. Som zástancom nasledujúceho: musí existovať vlastník procesu. Niekto musí pochopiť, riadiť, kontrolovať a budovať proces vývoja mikroslužieb. Musí vlastniť zdroje a zapojiť sa do riadenia zdrojov.
Tieto zdroje, ktoré poznajú technológie, špecifiká a chápu, ako budovať mikroslužby, môžu byť umiestnené v produktových tímoch. Máme mix, v ktorom sú ľudia z mikroservisnej platformy v produktovom tíme, ktorý robí mobilnú aplikáciu. Sú tam, ale pracujú podľa postupu oddelenia správy platforiem mikroservisov so svojím manažérom vývoja. V rámci tejto divízie existuje samostatný tím, ktorý sa zaoberá technológiou. To znamená, že medzi sebou zmiešavame spoločnú zásobu zdrojov, rozdeľujeme ich a dávame ich tímom.
Proces zároveň zostáva všeobecný, riadený, postupuje sa podľa všeobecných technologických princípov, s jednotkovým testovaním a tak ďalej - všetko, čo je postavené navrchu. Môžu existovať stĺpce vo forme zdrojov zhromaždených z rôznych oddelení produktového prístupu.
Alexander:
Sergey, ty si vlastne vlastníkom procesu, však? Je nevybavené úlohy zdieľané? Kto je zodpovedný za jeho distribúciu?
Sergey:
Pozri: tu je opäť mix. Existuje nevybavené veci, ktoré sa tvoria na základe technologických vylepšení – to je jeden príbeh. Existuje backlog, ktorý je formulovaný z projektov, a existuje backlog z produktov. Ale postupnosť zavádzania do každého z produktov služby alebo vytvorenie tejto služby vyvíja produktový špecialista. Nie je na riaditeľstve IT, bol z neho špeciálne odvolaný. Ale moji ľudia určite pracujú podľa rovnakého procesu.
Vlastníkom backlogu v rôznych smeroch – backlogu zmien – budú rôzni ľudia. Prepojenie technologických služieb, ich organizačný princíp – to všetko bude v IT. Vlastním platformu aj zdroje. Na vrchole je to, čo sa týka nevybavených a funkčných zmien a architektúry v tomto zmysle.
Povedzme, že firma povie: „Chceme túto funkciu, chceme vytvoriť nový produkt – prerobiť pôžičku.“ Odpovedáme: „Áno, prerobíme to“. Architekti hovoria: „Premýšľajme: kam v pôžičke napíšeme mikroslužby a ako to urobíme? Potom to rozdelíme na projekty, produkty alebo technologický stack, vložíme do tímov a implementujeme. Vytvorili ste produkt interne a rozhodli ste sa v tomto produkte využívať mikroslužby? Hovoríme: „Teraz staré systémy, ktoré sme mali, alebo systémy prvej línie, musia prejsť na tieto mikroslužby.“ Architekti hovoria: „Takže: v technologickom nevybavení v rámci produktov prvej línie - prechod na mikroslužby. Choď“. A produktoví špecialisti alebo majitelia firiem rozumejú tomu, aká veľká kapacita je pridelená, kedy sa to uskutoční a prečo.
Koniec diskusie, ale nie všetky
Zorganizovala sa konferencia mailto:CLOUD .
Robíme aj iné akcie – napr. @Kubernetes Meetup, kde vždy hľadáme skvelých rečníkov:
- Sledujte @Kubernetes a ďalšie novinky @Meetup na našom kanáli Telegram
- Máte záujem hovoriť na jednom zo stretnutí @Meetups? Zanechajte žiadosť o
Zdroj: hab.com