Од монолити до микросервиси: искуството на M.Video-Eldorado и MegaFon

На 25 април, ние во Mail.ru Group одржавме конференција за облаците и околу - mailto: CLOUD. Неколку нагласувања:

• Главниот Руски провајдери — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center и Yandex.Cloud зборуваа за спецификите на нашиот облак пазар и нивните услуги;
• Колегите од Битрикс24 раскажаа како тие дојде до мултиоблак;
• Интересно дадоа Лерој Мерлин, Откритие, Бургер Кинг и Шнајдер Електрик поглед од потрошувачите на облак — кои задачи ги поставува нивниот бизнис за ИТ и кои технологии, вклучително и оние во облак, ги гледаат како најперспективни.

Можете да ги гледате сите видеа од конференцијата mailto:CLOUD по ссылке, а овде можете да прочитате како помина дискусијата за микросервисите. Александар Деулин, шеф на центарот за истражување и развој на деловни системи МегаФон и Сергеј Сергеев, директор за информатичка технологија на групата М.Видео-Елдорадо, ги споделија своите успешни случаи на ослободување од монолитот. Разговаравме и за прашања поврзани со ИТ стратегија, процеси, па дури и човечки ресурси.

Панелисти

• Сергеј Сергеев, Група ЦИО „М.Видео-Елдорадо“;
• Александар Деулин, раководител на центарот за истражување и развој на деловни системи Мегафон;
• Модератор - Дмитриј Лазаренко, Раководител на насоката PaaS Mail.ru Cloud Solutions.

По говорот на Александар Деулин „Како МегаФон го проширува својот бизнис преку микросервис платформа“ Нему за дискусија му се придружуваат Сергеј Сергеев од М.Видео-Елдорадо и модераторот на дискусија Дмитриј Лазаренко, Mail.ru Cloud Solutions.

Во продолжение ви подготвивме транскрипт од дискусијата, но можете да го погледнете и видеото:

Транзицијата кон микроуслуги е одговор на потребите на пазарот

Дмитриј:

Дали сте имале некое успешно искуство со мигрирање во микросервисите? И воопшто: каде ја гледате најголемата деловна придобивка од користењето на микросервисите или преминувањето од монолити кон микросервисите?

Сергеј:

Ние веќе изминавме одреден начин во транзицијата кон микроуслуги и го користиме овој пристап повеќе од три години. Првата потреба што ја оправда потребата за микроуслуги беше бескрајната интеграција на различни предни производи со задната канцеларија. И секој пат кога бевме принудени да направиме дополнителна интеграција и развој, имплементирајќи ги нашите сопствени правила за работа на оваа или онаа услуга.

Во одреден момент, сфативме дека треба да ја забрзаме работата на нашите системи и излезот од функционалноста. Во тој момент на пазарот веќе постоеја концепти како микросервис и микросервисен пристап и решивме да го пробаме. Ова започна во 2016 година. Потоа беше поставена платформата и првите 10 услуги беа имплементирани од посебен тим.

Една од првите услуги, најтешко натоварена, беше услугата за пресметување на цените. Секогаш кога ќе дојдете на кој било канал, во групата компании M.Video-Eldorado, било да е тоа веб-локација или продавница за малопродажба, изберете производ таму, видете ја цената на веб-страницата или во „Кошница“, трошокот е автоматски пресметано од една услуга. Зошто е ова неопходно: пред ова, секој систем имаше свои принципи за работа со промоции - со попусти и така натаму. Нашиот back office се справува со цените; функционалноста за попуст е имплементирана во друг систем. Ова требаше да биде централизирано и да се создаде единствена, одвојлива услуга во форма на деловен процес што ќе ни овозможи да го имплементираме ова. Прилично така почнавме.

Вредноста на првите резултати беше многу голема. Прво, можевме да создадеме одделни ентитети кои ни овозможуваат да работиме одделно и на збирен начин. Второ, ги намаливме трошоците за сопственост во смисла на интеграција со повеќе системи.

Во текот на изминатите три години, додадовме три системи на првата линија. Беше тешко да се одржуваат со истиот износ на ресурси што компанијата можеше да си ги дозволи. Затоа, се појави задача да се бараат нови продажни места, одговарајќи на пазарот во однос на брзината, во однос на внатрешните трошоци и ефикасноста.

Како да се измери успехот на миграцијата во микросервисите

Дмитриј:

Како се одредува успехот во мигрирањето во микросервисите? Што беше „пред“ во секоја компанија? Која метрика ја искористивте за да го одредите успехот на транзицијата и кој всушност ја одреди?

Сергеј:

Пред сè, тој се роди во ИТ како овозможувач - „отклучување“ на нови можности. Имавме потреба да направиме сè побрзо за релативно исти пари, одговарајќи на пазарните предизвици. Сега успехот се изразува во бројот на повторно користени услуги од различни системи, обединување на процесите меѓу себе. Сега е, но во тој момент беше можност да се создаде платформа и да се потврди хипотезата дека можеме да го направиме ова, тоа ќе даде ефект и ќе го пресмета бизнис случајот.

Александар:

Успехот е повеќе внатрешно чувство. Бизнисот секогаш сака повеќе, а длабочината на нашето заостаток е доказ за успех. Така ми се чини.

Сергеј:

Да јас се согласувам. За три години веќе имаме повеќе од двесте услуги и заостанати. Потребата за ресурси во тимот само расте - за 30% годишно. Ова се случува затоа што луѓето чувствуваа: побрзо е, поинаку е, има различни технологии, сето ова се развива.

Микросервисите ќе дојдат, но јадрото ќе остане

Дмитриј:

Тоа е како бескраен процес каде што се инвестира во развој. Дали транзицијата кон микроуслуги за бизнис е веќе завршена или не?

Сергеј:

Многу е лесно да се одговори. Што мислите: заменувањето на телефоните е бесконечен процес? Ние самите купуваме телефони секоја година. И еве: се додека има потреба од брзина, за адаптација на пазарот, ќе се бараат некои промени. Тоа не значи дека ги напуштаме стандардните работи.

Но, не можеме да покриеме и повторно да направиме сè одеднаш. Имаме наследство, стандардни услуги за интеграција кои постоеја порано: автобуси за претпријатија и така натаму. Но, има заостаток, а има и потреба. Расте бројот на мобилни апликации и нивната функционалност. Во исто време, никој не вели дека ќе ви дадат 30% повеќе пари. Односно, од една страна секогаш има потреби, од друга страна потрага по ефикасност.

Дмитриј:

Животот е во добра форма. (Се смее)

Александар:

Во принцип, да. Немаме револуционерни пристапи за отстранување на основниот дел од пејзажот. Во тек е систематска работа за разложување на системите за да бидат поконзистентни со микросервисната архитектура, за да се намали влијанието на системите еден врз друг.

Но, планираме да го задржиме основниот дел, бидејќи во пејзажот на операторот секогаш ќе има некои платформи што ги купуваме. Повторно, ни треба здрава рамнотежа: не треба да брзаме со отсекување на јадрото. Ги поставуваме системите рамо до рамо, и сега излегува дека веќе сме на врвот на многу основни делови. Понатаму, развивајќи ја функционалноста, ги создаваме потребните репрезентации за сите канали кои работат со нашите комуникациски услуги.

Како да продавате микроуслуги на бизнисите

Дмитриј:

Исто така, ме интересира - за оние кои не се префрлиле, но планираат: колку беше лесно да се продаде оваа идеја на бизнисот и дали беше авантура, инвестициски проект? Или тоа беше свесна стратегија: сега одиме на микросервис и тоа е тоа, ништо нема да не спречи. Како ти беше?

Сергеј:

Не продававме пристап, туку деловен бенефит. Имаше проблем во бизнисот и се обидовме да го решиме. Во тој момент тоа беше изразено во тоа што различни канали користеа различни принципи за пресметување на цените - посебно за промоции, за промоции итн. Беше тешко да се одржува, се појавија грешки и ги слушавме поплаките на клиентите. Односно, продававме решение за проблем, но дојдовме со фактот дека ни требаа пари за да создадеме платформа. И тие покажаа деловен случај користејќи го примерот на првата фаза на инвестирање: како ќе продолжиме да го враќаме и што ќе ни овозможи тоа да направиме.

Дмитриј:

Дали некако го снимивте времето на првата етапа?

Сергеј:

Да секако. Одвоивме 6 месеци за да го создадеме јадрото како платформа и да го тестираме пилотот. За тоа време, се обидовме да создадеме платформа на која ќе го лизгаме пилотот. Тогаш хипотезата беше потврдена, а бидејќи функционира, тоа значи дека можеме да продолжиме. Почнаа да се реплицираат и го зајакнаа тимот - го преместија во посебна дивизија што го прави токму тоа.

Следува систематска работа заснована на деловните потреби, можности, достапност на ресурси и сè што е моментално во работа.

Дмитриј:

ДОБРО. Александар, што велиш?

Александар:

Нашите микросервиси се родени од „морската пена“ - поради заштеда на ресурси, поради некои остатоци во форма на капацитет на серверот и прераспределба на силите во тимот. Првично, овој проект не го продадовме на бизнисот. Ова беше проект каде и двајцата истражувавме и развивавме соодветно. Почнавме на почетокот на 2018 година и едноставно ја развивме оваа насока со ентузијазам. Продажбата штотуку започна и ние сме во процес.

Дмитриј:

Дали се случува некој бизнис да ви дозволи да правите такви работи како Google - на еден слободен ден во неделата? Дали имате таков правец?

Александар:

Истовремено со истражувањето, се занимававме и со деловни проблеми, така што сите наши микроуслуги се решенија за деловните проблеми. Само на почетокот изградивме микросервиси кои покриваа мал дел од претплатничката база, а сега сме присутни во речиси сите водечки производи.

А материјалното влијание е веќе јасно - веќе може да се изброиме, брзината на лансирањето на производите и изгубените приходи може да се проценат доколку сме го следеле стариот пат. На ова го градиме случајот.

Микроуслуги: возбуда или потреба?

Дмитриј:

Броевите се броеви. И приходите или заштедените пари се многу важни. Што ако погледнете на другата страна? Се чини дека микроуслугите се тренд, возбуда и многу компании го злоупотребуваат тоа? Колку јасно правите разлика помеѓу она што го правите и не го преведувате во микроуслуги? Ако наследство сега, ќе имате ли наследство за 5 години? Која ќе биде староста на информациските системи кои работат во М.Видео-Елдорадо и МегаФон за 5 години? Дали ќе има информациски системи стари десет, петнаесет години или ќе биде нова генерација? Како го гледате ова?

Сергеј:

Ми се чини дека е тешко да се размислува многу далеку. Ако погледнеме наназад, кој замислил дека технолошкиот пазар ќе се развива на овој начин, вклучувајќи машинско учење и идентификација на корисникот преку лице? Но, ако ги погледнете следните години, ми се чини дека основните системи, системите од ERP класа на претпријатија во компаниите - тие работат доста долго време.

Нашите компании се колективно стари 25 години, со класичен ERP многу длабоко во системскиот пејзаж. Јасно е дека вадиме некои парчиња од таму и се обидуваме да ги агрегираме во микросервиси, но јадрото ќе остане. Сега ми е тешко да замислам дека таму ќе ги замениме сите основни системи и брзо ќе преминеме на другата, светла страна на новите системи.

Јас сум поддржувач на фактот дека сè што е поблиску до клиентот и потрошувачот е таму каде што е најголемата деловна придобивка и вредност, каде што се приспособливоста и фокусирањето на брзината, на промените, на „обидете се, откажете, повторно употребете, направете нешто поинаку“ потребно е „-таму ќе се промени пејзажот. И производите во кутии не се вклопуваат таму многу добро. Барем не го гледаме. Таму се бараат најлесните, наједноставните решенија.

Го гледаме овој развој:

• основни информациски системи (најчесто back office);
• средните слоеви во форма на микросервиси го поврзуваат јадрото, агрегираат, создаваат кеш и така натаму;
• системите од предната линија се насочени кон потрошувачот;
• слој на интеграција кој е генерално интегриран во пазари, други системи и екосистеми. Овој слој е што е можно полесен, едноставен и содржи минимум деловна логика.

Но, во исто време, јас сум поддржувач да се продолжи со користење на старите принципи доколку тие се користат соодветно.

Да речеме дека имате класичен систем на претпријатија. Се наоѓа во пределот на еден продавач и се состои од два модула кои работат еден со друг. Постои и стандарден интерфејс за интеграција. Зошто да го повторите и да донесете микросервис таму?

Но, кога има 5 модули во задната канцеларија, од кои делови од информации се собираат во деловен процес, кој потоа се користи од 8-10 системи од предната линија, користа е веднаш забележлива. Земате од пет back-office системи и создавате услуга, изолирана, која е фокусирана на деловниот процес. Направете ја услугата технолошки напредна - така што кешира информации и е толерантна за грешки, а исто така работи со документи или деловни субјекти. И вие го интегрирате според единствен принцип со сите производи од првата линија. Тие го откажаа производот од првата линија - едноставно ја исклучија интеграцијата. Утре треба да напишете мобилна апликација или да направите мала веб-страница и да ставите само еден дел во функционалност - сè е едноставно: сте ја составиле како конструктор. Гледам повеќе развој во оваа насока - барем кај нас.

Александар:

Сергеј целосно го опиша нашиот пристап, благодарам. Само ќе кажам каде дефинитивно нема да одиме - до суштинскиот дел, до темата за наплата преку Интернет. Односно, оценувањето и наплатата ќе останат, всушност, „голема“ млачка која сигурно ќе отпише пари. И овој систем ќе продолжи да биде сертифициран од нашите регулаторни органи. Сè друго што гледа кон клиентите, се разбира, се микроуслуги.

Дмитриј:

Овде сертификацијата е една приказна. Веројатно поголема поддршка. Ако трошите малку на поддршка или системот не бара поддршка и модификација, подобро е да не го допирате. Разумен компромис.

Како да се развијат сигурни микросервиси

Дмитриј:

Добро. Но сепак ме интересира. Сега раскажувате успешна приказна: сè беше во ред, се префрливме на микроуслуги, ја одбранивме идејата за бизнисот и сè излезе. Но, имам слушнато и други приказни.

Пред неколку години, швајцарска компанија која инвестираше две години во развој на нова платформа за микросервис за банките, на крајот го затвори проектот. Целосно пропадна. Многу милиони швајцарски франци беа потрошени, а на крајот тимот беше растурен - не успеа.

Дали сте имале слични приказни? Дали имало или има потешкотии? На пример, одржувањето на микросервисите и мониторингот е исто така главоболка во оперативните активности на компанијата. На крајот на краиштата, бројот на компоненти се зголемува десетици пати. Како гледате на тоа, имало ли тука неуспешни примери на инвестиции? И што можете да ги советувате луѓето за да не наидат на такви проблеми?

Александар:

Неуспешните примери вклучуваат бизниси кои ги менуваат приоритетите и откажуваат проекти. Кога е во добра фаза на подготвеност (всушност, МВП е подготвен), бизнисот рече: „Имаме нови приоритети, продолжуваме кон друг проект и го затвораме овој“.

Немавме глобални неуспеси со микросервисите. Спиеме мирно, имаме смена 24/7 што го опслужува целиот BSS [систем за деловна поддршка].

И уште нешто - издаваме микроуслуги според правилата што важат за производите во кутии. Клучот за успехот е што треба, прво, да соберете тим кој целосно ќе го подготви микросервисот за производство. Самиот развој е, условно, 40%. Остатокот е аналитика, методологија на DevSecOps, правилни интеграции и вистинска архитектура. Посебно внимание посветуваме на принципите на градење безбедни апликации. Претставниците за безбедност на информациите учествуваат во секој проект и во фазата на планирање на архитектурата и во текот на процесот на имплементација. Тие, исто така, управуваат со системи за анализа на кодот за пропусти.

Да речеме дека ги распоредуваме нашите услуги без државјанство - ги имаме во Кубернетес. Ова им овозможува на сите да спијат мирно поради автоматско скалирање и автоматско подигање на услугите, а дежурната смена открива инциденти.

Во целото постоење на нашите микросервиси, имаше само еден или два инциденти кои стигнаа до нашата линија. Сега нема проблеми со работењето. Ние, се разбира, немаме 200, туку околу 50 микросервиси, но тие се користат во водечки производи. Ако не успеаја, ние први ќе дознаеме за тоа.

Микроуслуги и човечки ресурси

Сергеј:

Се согласувам со мојот колега за трансферот на поддршка - дека работата треба правилно да се организира. Но, јас ќе ви кажам за проблемите што, се разбира, постојат.

Прво, технологијата е нова. Ова е возбуда на добар начин, а да се најде специјалист кој ќе го разбере и ќе може да го создаде ова е голем предизвик. Конкуренцијата за ресурси е луда, па експертите вредат злато.

Второ, со создавањето на одредени пејсажи и се поголем број услуги, проблемот со повторната употреба мора постојано да се решава. Како што сакаат да прават програмерите: „Ајде да напишеме многу интересни работи овде сега...“ Поради ова, системот расте и ја губи својата ефикасност во однос на пари, трошоци за сопственост итн. Односно, неопходно е да се вклучи повторна употреба во архитектурата на системот, да се вклучи во патоказот за воведување услуги и пренесување на наследството во нова архитектура.

Друг проблем - иако ова е добро на свој начин - е внатрешната конкуренција. „О, тука се појавија нови модни момци, тие зборуваат нов јазик“. Луѓето, се разбира, се различни. Има оние кои се навикнати да пишуваат на Јава, и оние кои пишуваат и користат Docker и Kubernetes. Тоа се сосема различни луѓе, зборуваат поинаку, користат различни термини и понекогаш не се разбираат. Способноста или неспособноста да се споделат практиката, споделувањето знаење, во оваа смисла е исто така проблем.

Па, скалирање ресурси. „Одлично, ајде да одиме! И сега сакаме побрзо, повеќе. Што, не можеш? Зарем не е можно да се испорача двојно повеќе за една година? И зошто?" Ваквите болки во растењето се веројатно стандардни за многу работи, многу пристапи и можете да ги почувствувате.

Во однос на мониторингот. Ми се чини дека услугите или индустриските алатки за следење веќе учат или се способни да работат и со Docker и со Kubernetes во различен, нестандарден режим. За, на пример, да не завршите со 500 Java машини под кои сето ова работи, имено, се собира. Но, овие производи сè уште немаат зрелост, тие мора да поминат низ ова. Темата е навистина нова, ќе продолжи да се развива.

Дмитриј:

Да, многу интересно. И ова се однесува на човечки ресурси. Можеби вашиот процес на човечки ресурси и брендот за човечки ресурси се променија малку во текот на овие 3 години. Почнавте да регрутирате други луѓе со различни компетенции. И веројатно има и добри и лоши страни. Претходно, блокчејнот и науката за податоци беа возбуда, а специјалистите во нив вредеа милиони. Сега трошокот паѓа, пазарот станува заситен, а сличен тренд има и кај микросервисите.

Сергеј:

Да, апсолутно.

Александар:

HR го поставува прашањето: „Каде е вашиот розов еднорог помеѓу задниот дел и предниот дел? HR не разбира што е микросервис. Им ја кажавме тајната и им кажавме дека бекендот направил се, а нема еднорог. Но, HR се менува, брзо учи и регрутира луѓе кои имаат основно знаење за ИТ.

Еволуцијата на микросервисите

Дмитриј:

Ако ја погледнете целната архитектура, микросервисите изгледаат како такво чудовиште. Вашето патување траеше неколку години. Други имаат една година, други три години. Дали ги предвидовте сите проблеми, целната архитектура, дали нешто се промени? На пример, во случајот со микросервисите, портите и сервисните мрежи сега се појавуваат повторно. Дали ги користевте на почетокот или ја променивте самата архитектура? Дали имате такви предизвици?

Сергеј:

Веќе преработивме неколку протоколи за комуникација. Отпрвин имаше еден протокол, сега се префрливме на друг. Ја зголемуваме безбедноста и доверливоста. Почнавме со технологии за претпријатија - Oracle, Web Logic. Сега се оддалечуваме од производите на технолошките претпријатија во микроуслугите и преминуваме на отворен код или целосно отворени технологии. Ги напуштаме базите на податоци и преминуваме кон она што ни функционира поефикасно во овој модел. Повеќе не ни се потребни Oracle технологиите.

Започнавме едноставно како сервис, без да размислуваме колку ни треба кеш, што ќе правиме кога нема врска со микросервис, туку се потребни податоци итн. Сега развиваме платформа за да може да се опише архитектурата не на јазикот на услугите, а на деловен јазик, подигнете ја деловната логика на следното ниво кога ќе почнеме да зборуваме со зборови. Сега научивме да зборуваме со букви, а следното ниво е кога услугите ќе се соберат во некаков агрегат, кога ова е веќе збор - на пример, цела картичка на производот. Склопен е од микросервиси, но тоа е API изграден на врвот на ова.

Безбедноста е многу важна. Штом почнете да ви биде достапен и имате услуга преку која можете да добиете многу интересни работи, и тоа многу брзо, во дел од секундата, тогаш се појавува желба да ја добиете на не најсигурен начин. За да се извлечеме од ова, моравме да го промениме пристапот кон тестирање и следење. Моравме да го промениме тимот, структурата за управување со испораката, CI/CD.

Ова е еволуција - како кај телефоните, само многу побрзо: прво имаше телефони со копчиња, а потоа се појавија паметни телефони. Тие го преработија и редизајнираа производот бидејќи пазарот имаше поинаква потреба. Така еволуираме: прво одделение, десетто одделение, работа.

Итеративно, нешто се поставува годишно од гледна точка на технологијата, нешто друго од гледна точка на заостатокот и потребите. Ние поврзуваме една работа со друга. Тимот троши 20% за технички долг и техничка поддршка за тимот, 80% за деловниот субјект. И ние се движиме со разбирање зошто го правиме тоа, зошто ги правиме овие технолошки подобрувања, до што ќе доведат тие. Како тоа.

Дмитриј:

Кул. Што има во МегаФон?

Александар:

Главниот предизвик кога дојдовме до микросервисите беше да не паднеме во хаос. Архитектонското биро на МегаФон веднаш ни се придружи, дури стана иницијатор и двигател - сега имаме многу силна архитектура. Неговата задача беше да разбере кон кој целен модел одиме и кои технологии треба да се пилотираат. Со архитектура, самите ги спроведовме овие пилоти.

Следното прашање беше: „Тогаш како да се искористи сето ова?“ И уште едно: „Како да се обезбеди транспарентна интеракција помеѓу микросервисите? Сервисната мрежа ни помогна да одговориме на последното прашање. Го пилотиравме Истио и ни се допаднаа резултатите. Сега сме во фаза на префрлање во продуктивни зони. Имаме позитивен став кон сите предизвици - фактот дека треба постојано да го менуваме оџакот, да учиме нешто ново. Ние сме заинтересирани да развиваме, а не да ги искористуваме старите решенија.

Дмитриј:

Златни зборови! Ваквите предизвици го одржуваат тимот и бизнисот на нивните прсти и ја создаваат иднината. GDPR создаде главни службеници за заштита на податоци, а актуелните предизвици создаваат главни службеници за микросервис и архитектура. И радува.

Многу разговаравме. Главната работа е дека добриот дизајн на микросервисите и самата архитектура ви овозможуваат да избегнете многу грешки. Се разбира, процесот е итеративен и еволутивен, но тоа е иднината.

Благодарност до сите учесници, благодарност до Сергеј и Александар!

Прашања од публиката

Прашање од публиката (1):

Сергеј, како се промени ИТ менаџментот во вашата компанија? Разбирам дека кога има голем куп од неколку системи, начинот на кој се управува е прилично јасен и логичен процес. Како го обновивте управувањето со ИТ компонентата откако за толку кратко време беа интегрирани многу голем број микросервиси?

Сергеј:

Се согласувам со мојот колега дека архитектурата е многу важна како двигател на промените. Почнавме со архитектонска поделба. Архитектите се истовремено и сопственици на распределбата на функционалноста и барањата за тоа како таа ќе се појави во пејзажот. Така и тие дејствуваат како координатори на овие промени. Како резултат на тоа, имаше специфични промени во специфичен процес на испорака кога создадовме платформа CI/CD.

Но, стандардот, основните принципи на развој, деловна анализа, тестирање и развој не се откажани. Само додадовме брзина. Претходно, циклусот траеше толку многу, инсталацијата на средини за тестирање траеше многу повеќе. Сега бизнисот ја гледа користа и вели: „Зошто не можеме да го правиме истото на други места?

Тоа е како, на добар начин, инјекција во форма на вакцина која покажа: можете да го направите тоа на овој начин, но можете да го направите на друг начин. Секако дека има проблем во кадрите, во компетенциите, во знаењето, во отпорот.

Прашање од публиката (2):

Критичарите на микросервисната архитектура велат дека тестирањето и развојот се тешки. Ова е логично каде работите се комплицираат. Со какви предизвици се соочи вашиот тим и како ги надминавте? Прашање за сите.

Александар:

Има потешкотии при преминување од микросервис на платформа, но тие можат да се решат.

На пример, правиме производ кој се состои од 5-7 микросервиси. Треба да обезбедиме тестови за интеграција низ целиот оџак на микроуслуги за да дадеме зелено светло за преместување во главната гранка. Оваа задача не беше нова за нас: тоа го правевме долго време во BSS, кога продавачот ни снабдуваше со веќе испорачани решенија.

А нашиот проблем е само во малиот тим. Потребен е еден инженер за QA за еден условен производ. И така, испраќаме производ од 5-7 микроуслуги, од кои 2-3 можат да бидат развиени од трети страни. На пример, имаме производ во чиј развој учествуваат нашиот продавач на системот за наплата, Mail.ru Group и MegaFon R&D. Треба да го покриеме ова со тестови пред да го испратиме до производство. Инженерот за QA работи на овој производ месец и половина, а остатокот од тимот останува без неговата поддршка.

Оваа сложеност е предизвикана само од скалирање. Ние разбираме дека микросервисите не можат да постојат во вакуум; апсолутна изолација не постои. Кога менуваме една услуга, секогаш се трудиме да го зачуваме договорот за API. Ако нешто се смени под хаубата, предниот сервис останува. Ако промените се фатални, се случува некаква архитектонска трансформација и се префрламе на сосема поинаков метамодел на податоци, кој е целосно некомпатибилен - дури тогаш зборуваме да се појави спецификацијата на API на услугата v2. Ние ги поддржуваме првата и втората верзија истовремено, и откако сите потрошувачи ќе се префрлат на втората верзија, ние едноставно ја затвораме првата.

Сергеј:

Сакам да додадам. Апсолутно се согласувам за компликации - тие се случуваат. Пејзажот станува покомплексен, а режиските трошоци се зголемуваат, особено за тестирање. Како да се справите со ова: префрлете се на автоматско тестирање. Да, дополнително ќе треба да инвестирате во пишување автотестови и единечни тестови. Така што програмерите не можеа да се посветат без да го поминат тестот, не можеа да го променат кодот. Така што дури и копчето за притискање не работи без автоматско тестирање, единица тест.

Важно е да се одржи претходната функционалност, а тоа е дополнително оптоварување. Ако преработите технологија на друг протокол, тогаш ја препишувате додека не затворите сè целосно.

Понекогаш не правиме намерно тестирање од крај до крај, затоа што не сакаме да го запреме развојот, иако имаме и едно по друго. Пејзажот е многу голем, сложен, има многу системи. Понекогаш тоа се само никулци - да, ја намалувате безбедносната маржа, се појавуваат повеќе ризици. Но, во исто време го ослободувате снабдувањето.

Александар:

Да, автоматските тестови и единиците ви овозможуваат да креирате висококвалитетна услуга. Ние сме за гасовод што не може да се помине без единечни и интеграциски тестови. Честопати мораме да ги влечеме емулаторите и комерцијалните системи во тест зони и развојни средини, бидејќи не сите системи можат да се стават во тест зони. Покрај тоа, тие не само што се навлажнуваат - ние генерираме целосен одговор од системот. Ова е сериозен дел од работата со микросервисите, а ние исто така инвестираме во тоа. Без ова, ќе настане хаос.

Прашање од публиката (3):

Колку што разбрав, микросервисите првично пораснаа од посебен тим и сега постојат во овој модел. Кои се неговите добрите и лошите страни?

Само имаме слична приказна: се појави еден вид фабрика за микросервис. Сега концептуално дојдовме до точка дека го прошируваме овој пристап кон производството по струи и системи. Со други зборови, ние се оддалечуваме од централизираниот развој на микросервисите, моделите на микросервис и стануваме поблиску до системите.

Според тоа, нашето работење оди и на системи, односно ја децентрализираме оваа тема. Кој е вашиот пристап и која е вашата целна приказна?

Александар:

Веднаш од устата го исфрливте името „фабрика за микроуслуги“ - ние исто така сакаме да се размериме. Прво, сега навистина имаме еден тим. Сакаме да им обезбедиме на сите развојни тимови што ги има МегаФон да работат во заеднички екосистем. Не сакаме целосно да ги преземеме сите развојни функционалности што ги имаме сега. Локалната задача е да се размери, глобалната задача е да го води развојот до сите тимови во слојот на микросервис.

Сергеј:

Ќе ви го кажам патот по кој тргнавме. Навистина почнавме да работиме како еден тим, но сега не сме сами. Јас сум поборник на следново: мора да има сопственик на процесот. Некој треба да го разбере, управува, контролира и изгради процесот на развој на микросервисите. Тој мора да поседува ресурси и да се вклучи во управувањето со ресурсите.

Овие ресурси, кои ги знаат технологиите, спецификите и разбираат како да градат микроуслуги, може да се лоцираат во тимовите на производи. Имаме микс каде што луѓето од микросервис платформата се во тимот на производи што ја прави мобилната апликација. Тие се таму, но работат според процесот на одделот за управување со платформа за микросервис со нивниот менаџер за развој. Во рамките на оваа дивизија има посебен тим кој се занимава со технологија. Односно, мешаме заеднички фонд на ресурси меѓу себе и ги делиме, давајќи им ги на тимови.

Во исто време, процесот останува општ, контролиран, се одвива според општите технолошки принципи, со тестирање на единици и така натаму - сè што е изградено одозгора. Може да има колони во форма на ресурси собрани од различни оддели на пристапот на производот.

Александар:

Сергеј, ти си всушност сопственик на процесот, нели? Дали е споделена заостанатата задача? Кој е одговорен за неговата дистрибуција?

Сергеј:

Погледнете: еве го миксот повторно. Има заостаток што се формира врз основа на технолошки подобрувања - ова е една приказна. Има заостаток, кој е формулиран од проекти и има заостаток од производи. Но, редоследот на воведување во секој од услужните производи или создавањето на оваа услуга го развива специјалист за производи. Не е во Дирекцијата за ИТ, специјално е отстранет од неа. Но, моите луѓе дефинитивно работат според истиот процес.

Сопственик на заостанатите насоки во различни насоки - заостанати промени - ќе бидат различни луѓе. Поврзувањето на технолошките услуги, нивниот принцип на организирање - сето тоа ќе биде во ИТ. Ја поседувам и платформата и ресурсите. На врвот е она што се однесува на заостанатите и функционалните промени, и архитектурата во оваа смисла.

Да речеме дека некој бизнис вели: „Ја сакаме оваа функција, сакаме да создадеме нов производ - да направиме заем“. Ние одговараме: „Да, ќе го повториме“. Архитектите велат: „Ајде да размислиме: каде во заемот ќе пишуваме микроуслуги и како ќе го направиме тоа? Потоа го разложуваме на проекти, производи или технолошки оџак, го ставаме во тимови и го имплементираме. Дали создадовте производ внатрешно и одлучивте да користите микросервис во овој производ? Ние велиме: „Сега наследните системи што ги имавме, или системите на првата линија, мора да се префрлат на овие микроуслуги“. Архитектите велат: „Значи: во технолошкиот заостаток во производите од првата линија - транзицијата кон микроуслуги. Оди“. И специјалистите за производи или сопствениците на бизниси разбираат колку капацитет е доделен, кога ќе се направи и зошто.

Крај на дискусијата, но не сите

Беше организирана конференцијата mailto:CLOUD Mail.ru Cloud Solutions.

Правиме и други настани - на пр. @Kubernetes Meetup, каде што секогаш бараме одлични звучници:

• Следете ги @Kubernetes и другите вести на @Meetup на нашиот Телеграмски канал t.me/k8s_mail
• Заинтересирани сте да зборувате на еден од @Meetups? Оставете барање за mcs.mail.ru/speak

Извор: www.habr.com