25. dubna jsme ve skupině Mail.ru uspořádali konferenci o oblacích a okolí - . Několik zajímavostí:
- Hlavní — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center a Yandex.Cloud hovořili o specifikách našeho cloudového trhu a jejich službách;
- Kolegové z Bitrix24 řekli, jak oni ;
- Zajímavé byly Leroy Merlin, Otkritie, Burger King a Schneider Electric — jaké úkoly klade jejich byznys pro IT a jaké technologie, včetně cloudových, vidí jako nejperspektivnější.
Můžete sledovat všechna videa z konference mailto:CLOUD , a zde si můžete přečíst, jak probíhala diskuze o mikroslužbách. Alexander Deulin, vedoucí výzkumného a vývojového centra obchodních systémů MegaFon, a Sergey Sergeev, ředitel informačních technologií skupiny M.Video-Eldorado, se podělili o své úspěšné případy, jak se zbavit monolitů. Diskutovali jsme také o souvisejících otázkách IT strategie, procesů a dokonce i HR.
Panelisté
- Sergej Sergejev, Group CIO "M.Video-Eldorado";
- Alexandr Deulin, vedoucí centra pro výzkum a vývoj podnikových systémů MegaFon;
- Moderátor — Dmitrij Lazarenko, vedoucí PaaS směru Cloudová řešení Mail.ru.
Po projevu Alexandra Deulina K diskusi se k němu připojili Sergey Sergeev z M.Video-Eldorado a moderátor diskuse Dmitrij Lazarenko, Mail.ru Cloud Solutions.
Níže jsme pro vás připravili přepis diskuze, ale můžete se podívat i na video:
Přechod na mikroslužby je reakcí na potřeby trhu
Dmitriy:
Máte nějakou úspěšnou zkušenost s migrací na mikroslužby? A obecně: kde vidíte největší obchodní přínos z používání mikroslužeb nebo přechodu od monolitů k mikroslužbám?
Sergey:
Při přechodu na mikroslužby jsme již ušli kus cesty a tento přístup používáme více než tři roky. První potřebou, která ospravedlňovala potřebu mikroslužeb, byla nekonečná integrace různých front-end produktů s back office. A pokaždé jsme byli nuceni dělat další integraci a vývoj, implementaci vlastních pravidel pro fungování té či oné služby.
V určitém okamžiku jsme si uvědomili, že potřebujeme zrychlit chod našich systémů a výstup funkčnosti. V tu chvíli už na trhu existovaly takové koncepty jako mikroslužby a mikroservisní přístup a my jsme se rozhodli to vyzkoušet. Začalo to v roce 2016. Poté byla platforma položena a prvních 10 služeb bylo implementováno samostatným týmem.
Jednou z prvních služeb, nejvíce zatíženou, byla služba cenové kalkulace. Pokaždé, když přijdete na jakýkoli kanál, do skupiny společností M.Video-Eldorado, ať už jde o webovou stránku nebo maloobchod, vyberete si tam produkt, zobrazíte cenu na webu nebo v „Košíku“, cena je automaticky vypočítané jednou službou. Proč je to nutné: předtím měl každý systém své vlastní zásady pro práci s akcemi - se slevami a tak dále. Cenu řeší naše back office, funkce slev je implementována v jiném systému. To bylo potřeba centralizovat a vytvořit jedinečnou, oddělitelnou službu ve formě obchodního procesu, která by nám to umožnila implementovat. Zhruba tak jsme začali.
Hodnota prvních výsledků byla velmi vysoká. Za prvé jsme byli schopni vytvořit oddělitelné entity, které nám umožňují pracovat odděleně a agregovaně. Za druhé, snížili jsme náklady na vlastnictví z hlediska integrace s více systémy.
Za poslední tři roky jsme přidali tři frontové systémy. Bylo obtížné je udržet se stejným množstvím zdrojů, jaké si společnost mohla dovolit. Vyvstal proto úkol hledat nová odbytiště, reagující na trh z hlediska rychlosti, vnitřních nákladů a efektivity.
Jak měřit úspěšnost migrace na mikroslužby
Dmitriy:
Jak se určuje úspěšnost migrace na mikroslužby? Co bylo „před“ v každé společnosti? Jakou metriku jste použili k určení úspěšnosti přechodu a kdo ji vlastně určil?
Sergey:
Především se zrodila v rámci IT jako aktivátor – „odemykání“ nových schopností. Potřebovali jsme dělat vše rychleji za relativně stejné peníze a reagovat na výzvy trhu. Nyní je úspěch vyjádřen v počtu služeb opakovaně používaných různými systémy, sjednocení procesů mezi sebou. Teď je, ale v tu chvíli to byla příležitost vytvořit platformu a potvrdit hypotézu, že to dokážeme, dá to efekt a spočítá obchodní případ.
Alexander:
Úspěch je spíše vnitřní pocit. Obchod chce vždy víc a hloubka našich nevyřízených věcí je důkazem úspěchu. Zdá se mi to tak.
Sergey:
Ano, souhlasím s tím. Za tři roky už máme více než dvě stovky služeb a nevyřízených věcí. Potřeba zdrojů v týmu jen roste – o 30 % ročně. To se děje, protože lidé cítili: je to rychlejší, je to jiné, existují různé technologie, to vše se vyvíjí.
Mikroslužby přijdou, ale jádro zůstane
Dmitriy:
Je to jako nikdy nekončící proces, kdy investujete do vývoje. Je přechod na mikroslužby pro podnikání již u konce nebo ne?
Sergey:
Je velmi snadné odpovědět. Co si myslíte: výměna telefonů je nekonečný proces? My sami si telefony kupujeme každý rok. A je to tady: dokud bude potřeba rychlost, adaptace na trh, budou nutné nějaké změny. To neznamená, že opouštíme standardní věci.
Ale nemůžeme zakrýt a předělat všechno najednou. Máme starší standardní integrační služby, které existovaly dříve: podnikové sběrnice a tak dále. Existuje však zpoždění a také potřeba. Počet mobilních aplikací a jejich funkčnost roste. Přitom nikdo neříká, že dostanete o 30 % více peněz. To znamená, že na jedné straně jsou vždy potřeby a na druhé straně hledání efektivity.
Dmitriy:
Život je v dobré kondici. (Smích)
Alexander:
Obecně ano. Nemáme revoluční přístupy k odstranění jádrové části z krajiny. Systematicky se pracuje na rozkladu systémů tak, aby byly více konzistentní s architekturou mikroslužeb, aby se snížil vliv systémů na sebe navzájem.
Ale plánujeme zachovat hlavní část, protože v prostředí operátora vždy budou nějaké platformy, které kupujeme. Opět potřebujeme zdravou rovnováhu: neměli bychom spěchat s vyřezáváním jádra. Pokládáme systémy vedle sebe a nyní se ukazuje, že jsme již na vrcholu mnoha základních částí. Dále rozvíjením funkčnosti vytváříme potřebné reprezentace pro všechny kanály, které pracují s našimi komunikačními službami.
Jak prodávat mikroslužby podnikům
Dmitriy:
Také mě zajímá – pro ty, kteří nepřešli, ale plánují to: jak snadné bylo prodat tento nápad firmě a bylo to dobrodružství, investiční projekt? Nebo to byla vědomá strategie: teď jdeme na mikroslužby a je to, nic nás nezastaví. jaké to bylo u vás?
Sergey:
Neprodávali jsme přístup, ale obchodní benefit. V podnikání se vyskytl problém a my jsme se ho snažili vyřešit. V tu chvíli se to projevilo tím, že různé kanály používaly různé principy pro výpočet cen - zvlášť pro akce, pro akce a tak dále. Bylo to náročné na údržbu, docházelo k chybám a naslouchali jsme stížnostem zákazníků. To znamená, že jsme prodávali řešení problému, ale přišli jsme s tím, že potřebujeme peníze na vytvoření platformy. A ukázali obchodní případ na příkladu první etapy investice: jak se nám to bude dále vracet a co nám to umožní.
Dmitriy:
Zaznamenal jste nějak čas první etapy?
Sergey:
Ano jistě. Vyčlenili jsme 6 měsíců na vytvoření jádra jako platformy a testování pilotního projektu. Během této doby jsme se snažili vytvořit platformu, na které bude pilot bruslit. Poté se hypotéza potvrdila, a protože funguje, znamená to, že můžeme pokračovat. Začali replikovat a posilovat tým – přesunuli ho do samostatné divize, která dělá právě to.
Následuje systematická práce založená na obchodních potřebách, příležitostech, dostupnosti zdrojů a všem, na čem se aktuálně pracuje.
Dmitriy:
OK. Alexander, co říkáš?
Alexander:
Naše mikroslužby se zrodily z „mořské pěny“ – kvůli úspoře zdrojů, kvůli některým zbytkům v podobě kapacity serveru a přerozdělení sil v týmu. Původně jsme tento projekt neprodávali. To byl projekt, kde jsme oba zkoumali a podle toho vyvíjeli. Začali jsme na začátku roku 2018 a jednoduše jsme tento směr rozvíjeli s nadšením. Prodej právě začal a my jsme v procesu.
Dmitriy:
Stává se vám, že vám firma umožňuje dělat takové věci jako Google – v jeden volný den v týdnu? Máte takový směr?
Alexander:
Současně s výzkumem jsme se zabývali i obchodními problémy, takže všechny naše mikroslužby jsou řešením obchodních problémů. Pouze na začátku jsme vybudovali mikroslužby, které pokrývaly malou část předplatitelské základny, a nyní jsme přítomni téměř ve všech vlajkových produktech.
A materiální dopad je už jasný – už se s námi dá počítat, rychlost uvádění produktů na trh a ušlé tržby lze odhadnout, kdybychom šli starou cestou. To je to, na čem stavíme případ.
Mikroslužby: humbuk nebo nutnost?
Dmitriy:
Čísla jsou čísla. A výnosy nebo ušetřené peníze jsou velmi důležité. Co když se podíváte na druhou stranu? Zdá se, že mikroslužby jsou trend, humbuk a mnoho firem toho zneužívá? Jak jasně rozlišujete mezi tím, co děláte a co nepřekládáte do mikroslužeb? Pokud dědictví nyní, budete mít dědictví za 5 let? Jaké bude stáří informačních systémů, které fungují ve společnostech M.Video-Eldorado a MegaFon za 5 let? Budou tam deset, patnáct let staré informační systémy nebo to bude nová generace? Jak to vidíš?
Sergey:
Zdá se mi, že je těžké myslet hodně daleko. Když se podíváme zpět, kdo si představoval, že se technologický trh bude vyvíjet tímto způsobem, včetně strojového učení a identifikace uživatelů podle obličeje? Ale když se podíváte na nadcházející roky, zdá se mi, že základní systémy, podnikové systémy třídy ERP ve firmách - fungují už poměrně dlouho.
Naše společnosti jsou dohromady 25 let staré, s klasickým ERP velmi hluboko v systémovém prostředí. Je jasné, že odtamtud některé kusy vytahujeme a snažíme se je agregovat do mikroslužeb, ale jádro zůstane. Je pro mě teď těžké si představit, že tam nahradíme všechny základní systémy a rychle přejdeme na druhou, světlou stránku nových systémů.
Jsem zastáncem toho, že vše, co je blíže klientovi a spotřebiteli, je tam, kde je největší obchodní přínos a hodnota, kde je adaptabilita a zaměření na rychlost, na změnu, na „zkuste, zrušte, znovu použijte, udělejte něco jiného“ potřebná „-tam se krajina změní. A krabicové produkty se tam moc nehodí. Alespoň my to nevidíme. Tam jsou vyžadována ta nejjednodušší a nejjednodušší řešení.
Vidíme tento vývoj:
- základní informační systémy (většinou back office);
- střední vrstvy v podobě mikroslužeb propojují jádro, agregují, vytvářejí cache a tak dále;
- systémy první linie jsou zaměřeny na spotřebitele;
- integrační vrstva, která je obecně integrována do tržišť, jiných systémů a ekosystémů. Tato vrstva je maximálně odlehčená, jednoduchá a obsahuje minimum obchodní logiky.
Ale zároveň jsem zastáncem toho, aby se i nadále používaly staré principy, pokud jsou vhodně používány.
Řekněme, že máte klasický podnikový systém. Nachází se v krajině jednoho dodavatele a skládá se ze dvou modulů, které spolu spolupracují. Nechybí ani standardní integrační rozhraní. Proč to předělat a přinést tam mikroslužbu?
Ale když je v back office 5 modulů, ze kterých se shromažďují informace do obchodního procesu, který pak využívá 8-10 front-line systémů, je přínos okamžitě patrný. Vezmete z pěti back-office systémů a vytvoříte službu, izolovanou, která je zaměřena na obchodní proces. Udělejte službu technologicky pokročilou - tak, aby ukládala informace do mezipaměti a byla odolná proti chybám a také pracovala s dokumenty nebo obchodními subjekty. A integrujete jej podle jediného principu se všemi produkty první řady. Zrušili frontový produkt – jednoduše vypnuli integraci. Zítra musíte napsat mobilní aplikaci nebo udělat malý web a uvést do funkčnosti pouze jednu část - vše je jednoduché: sestavili jste to jako konstruktér. V tomto směru vidím větší vývoj – alespoň u nás.
Alexander:
Sergej úplně popsal náš přístup, děkuji. Řeknu jen, kam rozhodně nepůjdeme – k hlavní části, k tématu online fakturace. To znamená, že hodnocení a nabíjení zůstane ve skutečnosti „velkou“ mlátičkou, která peníze spolehlivě odepíše. A tento systém bude nadále certifikován našimi regulačními orgány. Vše ostatní, co se dívá směrem ke klientům, jsou samozřejmě mikroslužby.
Dmitriy:
Zde je certifikace jeden příběh. Asi větší podpora. Pokud za podporu utrácíte málo nebo systém nevyžaduje podporu a úpravy, je lepší na něj nesahat. Rozumný kompromis.
Jak vyvinout spolehlivé mikroslužby
Dmitriy:
Pokuta. Ale stejně mě to zajímá. Nyní vyprávíte příběh o úspěchu: všechno bylo v pořádku, přešli jsme na mikroslužby, obhájili nápad před firmou a všechno fungovalo. Ale slyšel jsem jiné příběhy.
Před několika lety švýcarská společnost, která investovala dva roky do vývoje nové platformy mikroslužeb pro banky, nakonec projekt uzavřela. Úplně zhroucený. Bylo utraceno mnoho milionů švýcarských franků a nakonec byl tým rozptýlen - nevyšlo to.
Měli jste podobné příběhy? Byly nebo jsou nějaké potíže? Například udržování mikroslužeb a monitorování je také bolestí hlavy v provozních aktivitách společnosti. Koneckonců, počet komponentů se zvyšuje desítkykrát. Jak to vidíte, byly tady neúspěšné příklady investic? A co poradit lidem, aby je takové problémy nepotkaly?
Alexander:
Neúspěšné příklady zahrnovaly podniky měnící priority a rušení projektů. Když byl podnik v dobré fázi připravenosti (ve skutečnosti je MVP připraven), řekl: „Máme nové priority, přecházíme na další projekt a tento uzavíráme.“
U mikroslužeb jsme nezaznamenali žádné globální selhání. Spíme klidně, máme 24/7 směnu, která obsluhuje celý BSS [systém podpory podnikání].
A ještě něco – pronajímáme mikroslužby podle pravidel, která platí pro krabičkové produkty. Klíčem k úspěchu je, že potřebujete zaprvé sestavit tým, který mikroslužbu plně připraví na výrobu. Samotný vývoj je podmíněně 40 %. Zbytek tvoří analytika, metodologie DevSecOps, správné integrace a správná architektura. Zvláštní pozornost věnujeme zásadám budování bezpečných aplikací. Zástupci informační bezpečnosti se účastní každého projektu jak ve fázi plánování architektury, tak během procesu implementace. Spravují také systémy pro analýzu zranitelností kódu.
Řekněme, že nasadíme naše bezstavové služby – máme je v Kubernetes. To umožňuje každému klidně spát díky automatickému škálování a automatickému navyšování služeb a pracovní směna zachycuje incidenty.
Za celou dobu existence našich mikroslužeb došlo pouze k jednomu nebo dvěma incidentům, které se dostaly na naši linku. Nyní nejsou žádné problémy s provozem. My samozřejmě nemáme 200, ale asi 50 mikroslužeb, ale používají se ve vlajkových produktech. Pokud by neuspěli, byli bychom první, kdo by se o tom dozvěděl.
Mikroslužby a HR
Sergey:
Souhlasím s kolegou ohledně převodu na podporu - že je potřeba práci správně organizovat. Ale řeknu vám o problémech, které samozřejmě existují.
Za prvé, technologie je nová. To je humbuk v dobrém slova smyslu a najít specialistu, který tomu bude rozumět a dokáže to vytvořit, je velká výzva. Soutěž o zdroje je šílená, takže odborníci mají cenu zlata.
Za druhé, s vytvářením určitých krajin a rostoucím počtem služeb je třeba neustále řešit problém opětovného použití. Jak vývojáři rádi dělají: „Pojďme sem teď napsat spoustu zajímavých věcí...“ Kvůli tomu systém roste a ztrácí svou efektivitu z hlediska peněz, nákladů na vlastnictví a tak dále. To znamená, že je nutné zahrnout opětovné použití do architektury systému, zahrnout jej do plánu pro zavádění služeb a přenos dědictví do nové architektury.
Dalším problémem – i když je to svým způsobem dobré – je vnitřní konkurence. "Ach, objevili se tu noví módní kluci, mluví novým jazykem." Lidé jsou samozřejmě různí. Jsou tací, kteří jsou zvyklí psát v Javě, a ti, kteří píší a používají Docker a Kubernetes. Jsou to úplně jiní lidé, mluví jinak, používají jiné výrazy a někdy si nerozumí. Problémem je v tomto smyslu i schopnost či neschopnost sdílet praxi, sdílení znalostí.
No, škálování zdrojů. "Skvělé Pojďme! A teď chceme rychleji, víc. co, nemůžeš? Není možné dodat dvakrát tolik za rok? A proč?" Takové růstové bolesti jsou pravděpodobně standardní pro mnoho věcí, mnoho přístupů a můžete je cítit.
Ohledně sledování. Zdá se mi, že služby nebo průmyslové monitorovací nástroje se již učí nebo jsou schopny pracovat s Dockerem i Kubernetes v jiném, nestandardním režimu. Abyste například neskončili s 500 Java stroji, pod kterými to všechno běží, konkrétně se to agreguje. Tyto produkty však stále postrádají zralost, musí tím projít. Téma je opravdu nové, bude se dále rozvíjet.
Dmitriy:
Ano, velmi zajímavé. A to se týká HR. Možná se váš proces HR a značka HR za ty 3 roky trochu změnily. Začal jste nabírat další lidi s různými kompetencemi. A pravděpodobně to má pro i proti. Dříve byly blockchain a datová věda humbukem a specialisté na ně měli hodnotu milionů. Nyní náklady klesají, trh se nasycuje a podobný trend je i v mikroslužbách.
Sergey:
Ano absolutně.
Alexander:
HR se ptá: "Kde je tvůj růžový jednorožec mezi backendem a frontendem?" HR nerozumí tomu, co je mikroslužba. Řekli jsme jim tajemství a řekli jsme jim, že všechno udělal backend a žádný jednorožec neexistuje. HR se ale mění, rychle se učí a nabírá lidi, kteří mají základní IT znalosti.
Vývoj mikroslužeb
Dmitriy:
Když se podíváte na cílovou architekturu, vypadají mikroslužby jako takové monstrum. Vaše cesta trvala několik let. Jiní mají rok, jiní tři roky. Předvídali jste všechny problémy, cílovou architekturu, změnilo se něco? Například u mikroslužeb se nyní opět objevují brány a servisní sítě. Používali jste je na začátku nebo jste změnili samotnou architekturu? Máte takové výzvy?
Sergey:
Již jsme přepsali několik komunikačních protokolů. Nejprve byl jeden protokol, nyní jsme přešli na jiný. Zvyšujeme bezpečnost a spolehlivost. Začínali jsme s podnikovými technologiemi – Oracle, Web Logic. Nyní se v mikroslužbách vzdalujeme od technologických podnikových produktů a přecházíme na open source nebo zcela otevřené technologie. Opouštíme databáze a přecházíme k tomu, co nám v tomto modelu funguje efektivněji. Technologie Oracle již nepotřebujeme.
Začali jsme jednoduše jako služba, aniž bychom přemýšleli, jak moc potřebujeme cache, co budeme dělat, když nebude spojení s mikroslužbou, ale budou potřeba data atd. Nyní vyvíjíme platformu, aby bylo možné popsat architekturu ne v jazyce služeb a v obchodním jazyce posuňte obchodní logiku na další úroveň, když začneme mluvit slovy. Nyní jsme se naučili mluvit písmeny a další úroveň je, když se služby budou shromažďovat do nějakého agregátu, když už je to slovo - například celá produktová karta. Je sestaven z mikroslužeb, ale je to API postavené nad tímto.
Bezpečnost je velmi důležitá. Jakmile začnete být dostupní a máte službu, přes kterou můžete získat spoustu zajímavých věcí, a to velmi rychle, ve zlomku vteřiny, pak je touha získat to ne zrovna nejbezpečnějším způsobem. Abychom se z toho dostali, museli jsme změnit přístupy k testování a monitorování. Museli jsme změnit tým, strukturu řízení dodávek, CI/CD.
Jde o evoluci – stejně jako u telefonů, jen mnohem rychlejší: nejprve byly tlačítkové telefony, pak se objevily chytré telefony. Přepsali a přepracovali produkt, protože trh měl jinou potřebu. Takto se vyvíjíme: první třída, desátá třída, práce.
Iterativně se něco rozloží ročně z pohledu technologie, něco jiného z pohledu nevyřízených věcí a potřeb. Spojujeme jednu věc s druhou. Tým vynakládá 20 % na technický dluh a technickou podporu týmu, 80 % na obchodní subjekt. A pohybujeme se s pochopením toho, proč to děláme, proč děláme tato technologická vylepšení, k čemu povedou. Takhle.
Dmitriy:
Chladný. Co je v MegaFonu?
Alexander:
Hlavní výzvou, když jsme přišli k mikroslužbám, bylo neupadnout do chaosu. Architektonická kancelář MegaFon se k nám okamžitě připojila, dokonce se stala iniciátorem a řidičem – nyní máme velmi silnou architekturu. Jeho úkolem bylo pochopit, do jakého cílového modelu jdeme a jaké technologie je potřeba pilotovat. S architekturou jsme tyto piloty provedli sami.
Další otázka zněla: „Jak toho všeho tedy využít? A ještě jedna: "Jak zajistit transparentní interakci mezi mikroslužbami?" Servisní síť nám pomohla odpovědět na poslední otázku. Pilotovali jsme Istio a výsledky se nám líbily. Nyní jsme ve fázi rozjezdu do produktivních zón. Máme kladný vztah ke všem výzvám – k tomu, že potřebujeme neustále měnit stack, učit se něco nového. Máme zájem vyvíjet, nikoli využívat stará řešení.
Dmitriy:
Zlatá slova! Takové výzvy udržují tým a podnikání ve střehu a vytvářejí budoucnost. GDPR vytvořilo hlavní úředníky pro ochranu dat a současné výzvy vytvářejí hlavní úředníky pro mikroslužby a architekturu. A to potěší.
Hodně jsme diskutovali. Hlavní věc je, že dobrý design mikroslužeb a samotná architektura umožňuje vyhnout se mnoha chybám. Tento proces je samozřejmě iterativní a evoluční, ale je to budoucnost.
Díky všem účastníkům, díky Sergeji a Alexandrovi!
Otázky z publika
Otázka z publika (1):
Sergeji, jak se změnilo řízení IT ve vaší společnosti? Chápu, že když existuje velký zásobník několika systémů, způsob jeho správy je poměrně jasný a logický proces. Jak jste přestavěli správu IT komponenty po integraci velkého množství mikroslužeb v tak krátké době?
Sergey:
Souhlasím se svým kolegou, že architektura je velmi důležitá jako hnací motor změn. Začali jsme tím, že jsme měli architektonickou divizi. Architekti jsou zároveň vlastníky rozložení funkčnosti a požadavků na to, jak se bude jevit v krajině. Působí tedy také jako koordinátoři těchto změn. Výsledkem bylo, že když jsme vytvořili platformu CI/CD, došlo ke konkrétním změnám v konkrétním procesu dodání.
Ale standardní, základní principy vývoje, obchodní analýzy, testování a vývoje nebyly zrušeny. Jen jsme přidali rychlost. Dříve trval cyklus tolik, instalace v testovacích prostředích trvala mnohem více. Nyní byznys vidí přínos a říká: „Proč bychom totéž nemohli udělat i na jiných místech?
Je to v dobrém slova smyslu jako injekce ve formě vakcíny, která ukázala: můžete to udělat tímto způsobem, ale můžete to udělat jinak. Samozřejmě je problém v personálu, v kompetencích, ve znalostech, v odporu.
Otázka z publika (2):
Kritici architektury mikroslužeb říkají, že testování a vývoj jsou obtížné. To je logické tam, kde se věci komplikují. S jakými problémy se váš tým potýkal a jak jste je zvládli? Otázka pro všechny.
Alexander:
Při přechodu z mikroslužeb na platformu existují potíže, ale lze je vyřešit.
Například vyrábíme produkt, který se skládá z 5-7 mikroslužeb. Potřebujeme provést integrační testy napříč celým zásobníkem mikroslužeb, abychom dali zelenou přechodu na hlavní větev. Tento úkol pro nás nebyl nový: dělali jsme to v BSS již dlouho, když nám prodejce dodal již dodaná řešení.
A náš problém je jen v malém týmu. Pro jeden podmíněný produkt je potřeba jeden technik kontroly kvality. A tak dodáváme produkt 5-7 mikroslužeb, z nichž 2-3 mohou být vyvinuty třetími stranami. Máme například produkt, na jehož vývoji se podílí náš prodejce fakturačního systému, Mail.ru Group a MegaFon R&D. Před odesláním do výroby to musíme pokrýt testy. QA inženýr na tomto produktu pracoval měsíc a půl a zbytek týmu zůstal bez jeho podpory.
Tato složitost je způsobena pouze škálováním. Chápeme, že mikroslužby nemohou existovat ve vakuu, absolutní izolace neexistuje. Při změně jedné služby se vždy snažíme zachovat API kontrakt. Pokud se něco změní pod kapotou, zůstává přední služba. Pokud jsou změny fatální, dojde k nějaké architektonické transformaci a přecházíme na zcela jiný datový metamodel, který je zcela nekompatibilní – teprve pak se mluví o tom, že se objeví specifikace API služby v2. Podporujeme první a druhou verzi současně a poté, co všichni spotřebitelé přejdou na druhou verzi, tu první jednoduše zavřeme.
Sergey:
chci přidat. Naprosto souhlasím s komplikacemi - stávají se. Krajina je stále složitější a režijní náklady se zvyšují, zejména na testování. Jak se s tím vypořádat: přejděte na automatizované testování. Ano, budete muset investovat dodatečně do psaní autotestů a jednotkových testů. Aby se vývojáři nemohli zavázat, aniž by prošli testem, nemohli změnit kód. Aby ani tlačítko nefungovalo bez autotestu, testu jednotky.
Je důležité zachovat předchozí funkcionalitu a to je další režie. Pokud přepisujete technologii na jiný protokol, pak ji přepisujete, dokud vše úplně nezavřete.
Někdy neprovádíme end-to-end testování záměrně, protože nechceme zastavit vývoj, i když máme také jednu věc za druhou. Krajina je velmi rozlehlá, složitá, je zde mnoho systémů. Někdy jsou to jen útržky – ano, snížíte bezpečnostní rezervu, objeví se více rizik. Zároveň ale uvolníte zásobu.
Alexander:
Ano, autotesty a testy jednotek vám umožňují vytvořit vysoce kvalitní službu. Jsme pro potrubí, které nelze projít bez jednotkových a integračních testů. Často musíme emulátory a komerční systémy přetahovat do testovacích zón a vývojových prostředí, protože ne všechny systémy lze umístit do testovacích zón. Navíc se jen tak nenamočí – generujeme plnohodnotnou odezvu systému. To je vážná část práce s mikroslužbami a také do toho investujeme. Bez toho vznikne chaos.
Otázka z publika (3):
Pokud jsem pochopil, mikroslužby původně vyrostly ze samostatného týmu a nyní existují v tomto modelu. Jaké jsou jeho klady a zápory?
Máme jen podobný příběh: vznikla jakási továrna na mikroslužby. Nyní jsme koncepčně dospěli k tomu, že tento přístup rozšiřujeme na produkci o streamy a systémy. Jinými slovy, vzdalujeme se centralizovaného vývoje mikroslužeb, modelů mikroslužeb a přibližujeme se systémům.
Podle toho jde i náš provoz do systémů, to znamená, že toto téma decentralizujeme. Jaký je váš přístup a jaký je váš cílový příběh?
Alexander:
Vypustil jste název „továrna na mikroslužby“ přímo z úst – také chceme škálovat. Za prvé, teď máme opravdu jeden tým. Chceme všem vývojářským týmům, které MegaFon má, poskytnout možnost pracovat ve společném ekosystému. Nechceme zcela převzít všechny vývojové funkce, které nyní máme. Lokálním úkolem je škálování, globálním úkolem je vést vývoj všem týmům ve vrstvě mikroslužeb.
Sergey:
Řeknu vám cestu, kterou jsme se vydali. Opravdu jsme začali fungovat jako jeden tým, ale teď v tom nejsme sami. Jsem zastáncem následujícího: musí existovat vlastník procesu. Někdo potřebuje pochopit, řídit, řídit a budovat proces vývoje mikroslužeb. Musí vlastnit zdroje a zapojit se do řízení zdrojů.
Tyto zdroje, které znají technologie, specifika a rozumí tomu, jak budovat mikroslužby, mohou být umístěny v produktových týmech. Máme mix, kde jsou v produktovém týmu, který tvoří mobilní aplikaci, lidé z platformy mikroslužeb. Jsou tam, ale pracují podle procesu oddělení správy mikroservisní platformy se svým vývojovým manažerem. V rámci této divize existuje samostatný tým, který se zabývá technologií. To znamená, že mezi sebou mícháme společný fond zdrojů a rozdělujeme je a dáváme je týmům.
Proces přitom zůstává obecný, řízený, probíhá podle obecných technologických principů, s jednotkovým testováním a tak dále - vše, co je postaveno navrch. Mohou existovat sloupce ve formě zdrojů shromážděných z různých oddělení produktového přístupu.
Alexander:
Sergeyi, ty jsi vlastně vlastníkem procesu, že? Je nevyřízený úkol sdílený? Kdo je zodpovědný za jeho distribuci?
Sergey:
Podívejte: tady je zase mix. Existuje nevyřízené položky, které se tvoří na základě technologických vylepšení – to je jeden příběh. Existuje backlog, který je formulován z projektů, a existuje backlog z produktů. Ale posloupnost zavedení do každého z produktů služby nebo vytvoření této služby je vyvinuto produktovým specialistou. Není v ředitelství IT, byl z něj speciálně odvolán. Ale moji lidé rozhodně pracují podle stejného procesu.
Vlastníkem backlogu v různých směrech – backlogu změn – budou různí lidé. Propojení technologických služeb, jejich organizační princip – to vše bude v IT. Vlastním platformu a zdroje také. Nahoře je to, co se týká nedodělků a funkčních změn a architektury v tomto smyslu.
Řekněme, že firma říká: „Chceme tuto funkci, chceme vytvořit nový produkt – předělat půjčku.“ Odpovídáme: "Ano, předěláme to." Architekti říkají: „Přemýšlejme: kam v půjčce zapíšeme mikroslužby a jak to uděláme? Pak to rozložíme na projekty, produkty nebo technologický stack, rozložíme do týmů a implementujeme. Vytvořili jste produkt interně a rozhodli jste se v tomto produktu využívat mikroslužby? Říkáme: "Nyní musí staré systémy, které jsme měli, nebo systémy první linie, přejít na tyto mikroslužby." Architekti říkají: „Takže: v technologickém zaostávání uvnitř předních produktů – přechod na mikroslužby. Jít". A produktoví specialisté nebo majitelé firem chápou, kolik kapacity je přiděleno, kdy to bude provedeno a proč.
Konec diskuse, ale ne všechny
Byla uspořádána konference mailto:CLOUD .
Děláme i jiné akce - např. @Kubernetes Meetup, kde vždy hledáme skvělé řečníky:
- Sledujte @Kubernetes a další novinky @Meetup na našem kanálu Telegram
- Máte zájem mluvit na jednom ze setkání @Meetups? Zanechte žádost o
Zdroj: www.habr.com