Од монолита до микросервиса: искуство М.Видео-Елдорадо и МегаФона

25. априла смо у Маил.ру Гроуп одржали конференцију о облацима и око - маилто:ЦЛОУД. Неколико нагласака:

• Главни руски провајдери — Маил.ру Цлоуд Солутионс, #ЦлоудМТС, СберЦлоуд, Селецтел, Ростелецом Дата Центер и Иандек.Цлоуд говорили су о специфичностима нашег тржишта облака и својих услуга;
• Колеге из Битрикс24 испричале су како су дошао у мултицлоуд;
• Занимљиво су дали Лерои Мерлин, Откритие, Бургер Кинг и Сцхнеидер Елецтриц поглед од потрошача облака — које задатке њихово пословање поставља за ИТ и које технологије, укључујући и оне у облаку, виде као најперспективније.

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

Панелисти

• Сергеј Сергејев, Група ЦИО "М.Видео-Елдорадо";
• Александар Деулин, руководилац центра за истраживање и развој пословних система МегаФон;
• Модератор — Дмитриј Лазаренко, шеф ПааС смера Маил.ру Цлоуд Солутионс.

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

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

Прелазак на микроуслуге је одговор на потребе тржишта

Дмитриј:

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

Сергеј:

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

У неком тренутку смо схватили да морамо да убрзамо рад наших система и излаз функционалности. У том тренутку на тржишту су већ постојали концепти као што су микросервис и микросервисни приступ и ми смо одлучили да то испробамо. Ово је почело 2016. Затим је постављена платформа и првих 10 услуга је имплементирао посебан тим.

Једна од првих услуга, најоптерећенија, била је услуга обрачуна цена. Сваки пут када дођете на било који канал, у групу компанија М.Видео-Елдорадо, било да се ради о сајту или малопродаји, тамо изаберете производ, видите цену на сајту или у „Копи“, цена се аутоматски обрачунава једна служба. Зашто је то потребно: пре тога, сваки систем је имао своје принципе за рад са промоцијама - са попустима и тако даље. Наша позадинска служба управља ценама, а функција попуста је имплементирана у другом систему. Ово је требало централизовати и креирати јединствену, одвојиву услугу у облику пословног процеса који би нам омогућио да ово имплементирамо. Тако смо отприлике почели.

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

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

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

Дмитриј:

Како се одређује успех у преласку на микросервисе? Шта је било „пре” у свакој компанији? Коју метрику сте користили да одредите успех транзиције и ко је то заправо одредио?

Сергеј:

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

Aleksandar:

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

Сергеј:

Да, слажем се. За три године имамо већ више од две стотине услуга и заостатака. Потреба за ресурсима унутар тима само расте – за 30% годишње. То се дешава јер су људи осетили: брже је, другачије је, постоје различите технологије, све се то развија.

Микросервис ће доћи, али језгро ће остати

Дмитриј:

То је као бескрајни процес у коме улажете у развој. Да ли је прелазак на микросервисе за пословање већ завршен или није?

Сергеј:

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

Али не можемо покрити и поновити све одједном. Имамо застареле, стандардне услуге интеграције које су постојале раније: пословне аутобусе и тако даље. Али постоји заостатак, а постоји и потреба. Број мобилних апликација и њихова функционалност расте. Истовремено, нико не каже да ће вам бити дато 30% више новца. То јест, с једне стране увек постоје потребе, а са друге потрага за ефикасношћу.

Дмитриј:

Живот је у добром стању. (смех)

Aleksandar:

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

Али планирамо да задржимо основни део, јер ће у окружењу оператера увек постојати неке платформе које купујемо. Опет, потребна нам је здрава равнотежа: не треба журити са исецањем језгра. Системе постављамо један поред другог и сада се испоставило да смо већ на врху многих кључних делова. Даље, развијајући функционалност, креирамо неопходне репрезентације за све канале који раде са нашим комуникационим сервисима.

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

Дмитриј:

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

Сергеј:

Нисмо продавали приступ, већ пословну корист. Постојао је проблем у пословању и ми смо покушали да га решимо. У том тренутку се то изражавало у чињеници да су различити канали користили различите принципе за обрачун цена – посебно за промоције, за промоције и тако даље. Било је тешко одржавати, дешавале су се грешке и слушали смо жалбе купаца. Односно, продавали смо решење проблема, али смо дошли са чињеницом да нам је потребан новац за креирање платформе. И приказали су пословни случај на примеру прве фазе инвестиције: како ћемо наставити да је надокнађујемо и шта ће нам то омогућити.

Дмитриј:

Јесте ли некако забележили време прве етапе?

Сергеј:

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

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

Дмитриј:

ОК. Александре, шта кажеш?

Aleksandar:

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

Дмитриј:

Да ли се дешава да вам предузеће дозвољава да радите такве ствари као што је Гугл - једног слободног дана у недељи? Имате ли такав правац?

Aleksandar:

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

А материјални утицај је већ јасан – већ можемо да се пребројимо, може се проценити брзина лансирања производа и изгубљени приход да смо ишли старим путем. Ово је оно на чему градимо случај.

Микроуслуге: хипе или неопходност?

Дмитриј:

Бројеви су бројеви. А приход или уштеђени новац су веома важни. Шта ако погледате са друге стране? Чини се да су микросервисе тренд, хипе и многе компаније то злоупотребљавају? Колико јасно правите разлику између онога што радите и онога што не преводите у микроуслуге? Ако сте сада наслеђени, да ли ћете и даље имати наслеђе за 5 година? Колико ће бити стари информациони системи који раде у М.Видео-Елдорадо и МегаФону за 5 година? Да ли ће постојати десетогодишњи, петнаестогодишњи информациони системи или ће то бити нова генерација? Како видите ово?

Сергеј:

Чини ми се да је тешко размишљати веома далеко. Ако погледамо уназад, ко је замислио да ће се технолошко тржиште развијати на овај начин, укључујући машинско учење и идентификацију корисника лицем? Али ако погледате наредне године, чини ми се да основни системи, системи ЕРП класе предузећа у компанијама – функционишу већ дуже време.

Наше компаније су колективно старе 25 година, са класичним ЕРП-ом веома дубоко у системском пејзажу. Јасно је да неке делове вадимо одатле и покушавамо да их агрегирамо у микросервисе, али језгро ће остати. Сада ми је тешко да замислим да ћемо тамо заменити све основне системе и брзо прећи на другу, светлу страну нових система.

Залажем се за то да је све што је ближе клијенту и потрошачу тамо где је највећа пословна корист и вредност, где су прилагодљивост и фокус на брзину, на промене, на „пробај, откажи, поново употреби, уради нешто другачије“ потребно „—тамо ће се пејзаж променити. А производи у кутијама се ту не уклапају баш добро. Бар ми то не видимо. Ту су потребна најлакша, најједноставнија решења.

Видимо овај развој:

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

Али у исто време, ја сам присталица да се и даље користе стари принципи ако се користе на одговарајући начин.

Рецимо да имате класичан систем предузећа. Налази се у пејзажу једног добављача и састоји се од два модула који раде један са другим. Постоји и стандардни интерфејс за интеграцију. Зашто то поновити и довести микросервис тамо?

Али када у позадинској канцеларији постоји 5 модула, из којих се информације прикупљају у пословни процес, које затим користи 8-10 фронт-лине система, корист је одмах приметна. Узимате из пет бацк-оффице система и креирате услугу, изоловану, која је фокусирана на пословни процес. Учините услугу технолошки напредном – тако да кешира информације и да буде отпорна на грешке, а да ради и са документима или пословним субјектима. И интегришете га по једном принципу са свим производима на првој линији. Укинули су фронт-лине производ - једноставно су искључили интеграцију. Сутра треба да напишете мобилну апликацију или направите мали веб-сајт и само један део ставите у функционалност – све је једноставно: саставили сте га као конструктор. Видим више развоја у овом правцу – бар код нас.

Aleksandar:

Сергеј је у потпуности описао наш приступ, хвала. Рећи ћу само где дефинитивно нећемо ићи - на суштину, на тему онлајн наплате. Односно, рејтинг и наплата ће остати, у ствари, „велика“ вршалица која ће поуздано отписивати новац. И овај систем ће и даље бити сертификован од стране наших регулаторних органа. Све остало што гледа ка клијентима, наравно, су микросервис.

Дмитриј:

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

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

Дмитриј:

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

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

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

Aleksandar:

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

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

И још нешто – микросервисе изнајмљујемо по правилима која важе за производе у кутијама. Кључ успеха је у томе што је потребно, пре свега, да окупите тим који ће у потпуности припремити микросервис за производњу. Сам развој је, условно, 40%. Остало је аналитика, ДевСецОпс методологија, праве интеграције и права архитектура. Посебну пажњу посвећујемо принципима изградње сигурних апликација. Представници информационе безбедности учествују у сваком пројекту како у фази планирања архитектуре тако и током процеса имплементације. Они такође управљају системима за анализу кода за рањивости.

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

За све време постојања наших микросервиса, било је само један или два инцидента који су доспели на нашу линију. Сада нема проблема са радом. Ми, наравно, немамо 200, већ око 50 микросервиса, али се они користе у водећим производима. Да нису успели, ми бисмо први сазнали за то.

Микросервис и ХР

Сергеј:

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

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

Друго, стварањем одређених пејзажа и све већим бројем услуга, проблем поновне употребе мора се стално решавати. Као што програмери воле да раде: „Хајде да сада напишемо много занимљивих ствари...“ Због тога систем расте и губи своју ефикасност у смислу новца, трошкова поседовања и тако даље. Односно, неопходно је укључити поновну употребу у архитектуру система, укључити је у мапу пута за увођење сервиса и преношење наслеђа у нову архитектуру.

Други проблем - иако је то добро на свој начин - је унутрашња конкуренција. „Ох, овде су се појавили нови модерни момци, говоре нови језик. Људи су, наравно, различити. Има оних који су навикли да пишу у Јави, и оних који пишу и користе Доцкер и Кубернетес. То су потпуно различити људи, различито говоре, користе различите изразе и понекад се не разумеју. Способност или немогућност дељења праксе, размене знања, у овом смислу такође представља проблем.

Па, скалирање ресурса. "Супер, хајде да идемо! А сада желимо брже, више. Шта, не можеш? Зар није могуће испоручити дупло више за годину дана? И зашто?" Такви болови раста су вероватно стандардни за многе ствари, многе приступе, и можете их осетити.

Што се тиче праћења. Чини ми се да услуге или алати за индустријско праћење већ уче или су у стању да раде са Доцкер-ом и Кубернетес-ом у другачијем, нестандардном режиму. Тако да, на пример, не завршите са 500 Јава машина под којима све ово ради, наиме, агрегира се. Али овим производима и даље недостаје зрелост; они морају да прођу кроз ово. Тема је заиста нова, развијаће се даље.

Дмитриј:

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

Сергеј:

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

Aleksandar:

ХР поставља питање: „Где је ваш ружичасти једнорог између позадине и фронтенда?“ ХР не разуме шта је микросервис. Рекли смо им тајну и рекли им да је бекенд све урадио, а једнорог нема. Али ХР се мења, брзо учи и регрутује људе који имају основно ИТ знање.

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

Дмитриј:

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

Сергеј:

Већ смо преписали неколико комуникационих протокола. Прво је постојао један протокол, сада смо прешли на други. Повећавамо сигурност и поузданост. Почели смо са пословним технологијама - Орацле, Веб Логиц. Сада се удаљавамо од технолошких производа предузећа у микроуслугама и прелазимо на опен соурце или потпуно отворене технологије. Напуштамо базе података и прелазимо на оно што нам је ефикасније у овом моделу. Више нам нису потребне Орацле технологије.

Почели смо једноставно као сервис, не размишљајући о томе колико нам је потребан кеш, шта бисмо радили када није било везе са микросервисом, али су били потребни подаци итд. Сада развијамо платформу како би архитектура могла да се опише не језиком услуга, већ пословним језиком, подигните пословну логику на виши ниво када почнемо да причамо речима. Сада смо научили да говоримо словима, а следећи ниво је када ће услуге бити сакупљене у неку врсту агрегата, када је ово већ реч - на пример, цела картица производа. Састављен је од микросервиса, али је АПИ изграђен на врху овога.

Сигурност је веома важна. Чим почнете да будете приступачни и имате сервис преко којег можете да добијете много занимљивих ствари, и то врло брзо, у делићу секунде, онда се јавља жеља да то добијете на не баш најбезбеднији начин. Да бисмо побегли од овога, морали смо да променимо приступ тестирању и праћењу. Морали смо да променимо тим, структуру управљања испоруком, ЦИ/ЦД.

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

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

Дмитриј:

Хладан. Шта је у МегаФону?

Aleksandar:

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

Следеће питање је било: „Како онда све ово искористити?“ И још једно: „Како обезбедити транспарентну интеракцију између микросервиса?“ Сервисна мрежа нам је помогла да одговоримо на последње питање. Пробали смо Истио и свидели смо се резултати. Сада смо у фази преласка у продуктивне зоне. Имамо позитиван став према свим изазовима - чињеници да треба стално да мењамо стек, учимо нешто ново. Заинтересовани смо да развијамо, а не да искоришћавамо стара решења.

Дмитриј:

Златне речи! Такви изазови држе тим и посао на ногама и стварају будућност. ГДПР је створио главне службенике за заштиту података, а тренутни изазови стварају главне службенике за микросервисе и архитектуру. И прија.

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

Хвала свим учесницима, хвала Сергеју и Александру!

Питања из публике

Питање из публике (1):

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

Сергеј:

Слажем се са колегом да је архитектура веома важна као покретач промена. Почели смо тако што смо имали архитектонско одељење. Архитекте су истовремено и власници дистрибуције функционалности и захтева како ће се она појавити у пејзажу. Дакле, они такође делују као координатори ових промена. Као резултат тога, дошло је до специфичних промена у специфичном процесу испоруке када смо креирали ЦИ/ЦД платформу.

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

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

Питање из публике (2):

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

Aleksandar:

Постоје потешкоће при преласку са микросервиса на платформу, али оне се могу решити.

На пример, правимо производ који се састоји од 5-7 микросервиса. Морамо да обезбедимо интеграцијске тестове за цео стек микросервиса да бисмо дали зелено светло за прелазак на главну грану. Овај задатак за нас није био нов: то смо радили већ дуже време у БСС-у, када нам је добављач снабдевао већ испоручена решења.

А наш проблем је само у малом тиму. За један условни производ потребан је један КА инжењер. И тако, испоручујемо производ од 5-7 микроуслуга, од којих 2-3 могу да развију трећа лица. На пример, имамо производ у чијем развоју учествују наш добављач система наплате, Маил.ру Гроуп и МегаФон Р&Д. Морамо ово покрити тестовима пре него што га пошаљемо у производњу. КА инжењер је на овом производу радио месец и по дана, а остатак тима је остао без његове подршке.

Ова сложеност је узрокована само скалирањем. Разумемо да микроуслуге не могу постојати у вакууму; апсолутна изолација не постоји. Када мењамо једну услугу, увек покушавамо да сачувамо АПИ уговор. Ако се нешто промени испод хаубе, остаје предњи сервис. Ако су промене фаталне, долази до неке врсте архитектонске трансформације и прелазимо на потпуно другачији метамодел података, који је потпуно некомпатибилан – тек тада говоримо о појави АПИ спецификације в2 сервиса. Подржавамо прву и другу верзију истовремено, а након што сви корисници пређу на другу верзију, једноставно затварамо прву.

Сергеј:

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

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

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

Aleksandar:

Да, аутотестови и тестови јединица вам омогућавају да креирате услугу високог квалитета. Ми смо за цевовод који се не може проћи без јединичних и интеграционих тестова. Често морамо да превлачимо емулаторе и комерцијалне системе у тестне зоне и развојна окружења, јер се не могу сви системи поставити у тест зоне. Штавише, они се не поквасе само - ми генеришемо пун одговор система. Ово је озбиљан део рада са микросервисима и у то улажемо. Без тога ће настати хаос.

Питање из публике (3):

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

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

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

Aleksandar:

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

Сергеј:

Рећи ћу вам пут којим смо ишли. Заиста смо почели да радимо као један тим, али сада нисмо сами. Ја сам заговорник следећег: мора постојати власник процеса. Неко треба да разуме, управља, контролише и изгради процес развоја микросервиса. Мора да поседује ресурсе и да се бави управљањем ресурсима.

Ови ресурси, који познају технологије, специфичности и разумеју како да изграде микросервисе, могу се налазити у тимовима производа. Имамо мешавину где су људи са микросервисне платформе у тиму производа који прави мобилну апликацију. Они су ту, али раде према процесу одељења за управљање микросервисном платформом са својим менаџером развоја. У оквиру ове дивизије постоји посебан тим који се бави технологијом. То јест, ми мешамо заједнички фонд ресурса између себе и делимо их, дајући их тимовима.

Истовремено, процес остаје општи, контролисан, одвија се по општим технолошким принципима, са јединичним тестирањем и тако даље – све што се гради на врху. Могу постојати колоне у облику ресурса прикупљених из различитих одељења приступа производа.

Aleksandar:

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

Сергеј:

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

Власник заостатка у различитим правцима - заостатак промена - биће различити људи. Повезивање технолошких услуга, њихов принцип организације - све ће то бити у ИТ-у. Поседујем и платформу и ресурсе. На врху је оно што се тиче заосталих и функционалних промена, и архитектуре у том смислу.

Рецимо да предузеће каже: „Желимо ову функцију, желимо да направимо нови производ - преправимо кредит.“ Одговарамо: "Да, поновићемо." Архитекте кажу: „Хајде да размислимо: где ћемо у кредиту написати микросервисе и како ћемо то урадити?“ Затим га разбијамо на пројекте, производе или технолошку групу, стављамо у тимове и имплементирамо. Да ли сте интерно креирали производ и одлучили да користите микроуслуге у овом производу? Кажемо: „Сада наслијеђени системи које смо имали, или системи на првој линији, морају се пребацити на ове микроуслуге.“ Архитекте кажу: „Дакле: у технолошком заостатку унутар производа на првој линији - прелазак на микроуслуге. Иди". А стручњаци за производе или власници предузећа разумеју колики је капацитет додељен, када ће то бити урађено и зашто.

Крај дискусије, али не све

Организована је конференција маилто:ЦЛОУД Маил.ру Цлоуд Солутионс.

Радимо и друге догађаје – нпр. @Кубернетес Меетуп, где увек тражимо одличне звучнике:

• Пратите @Кубернетес и друге @Меетуп вести на нашем Телеграм каналу т.ме/к8с_маил
• Заинтересовани сте да говорите на једном од @Меетуп-ова? Оставите захтев за мцс.маил.ру/спеак

Извор: ввв.хабр.цом