25 квітня ми в Mail.ru Group провели конференцію про хмари і навколо. . Декілька хайлайтів:
- На одній сцені зібралися основні - про специфіку нашого хмарного ринку та своїх сервісів говорили Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, "Ростелеком - ЦОД" та "Яндекс.Хмара";
- Колеги з «Бітрікс24» розповіли, як вони ;
- "Леруа Мерлен", "Відкриття", Burger King та Schneider Electric надали цікавий — які завдання їхній бізнес ставить перед IT і які технології, у тому числі хмарні, бачаться найбільш перспективними.
Усі відео з конференції mailto:CLOUD можна переглянути А тут можна почитати, як пройшла дискусія про мікросервіси. Своїми — успішними — кейсами порятунку від монолітів поділилися Олександр Деулін, керівник центру дослідження та розробки бізнес-систем «Мегафона», та Сергій Сергєєв, директор з інформаційних технологій групи «М.Відео-Ельдорадо». Також обговорили близькі питання IT-стратегії, процесів та навіть HR.
Учасники дискусії
- Сергій Сергєєв, директор з інформаційних технологій групи «М.Відео-Ельдорадо»;
- Олександр Деулін, керівник центру дослідження та розробки бізнес-систем «Мегафону»;
- Модератор Дмитро Лазаренко, керівник PaaS-напрямку Mail.ru Cloud Solutions.
Після виступу Олександра Деуліна до нього приєднуються для дискусії Сергій Сергєєв із «М.Відео-Ельдорадо» та модератор дискусії Дмитро Лазаренко, Mail.ru Cloud Solutions.
Нижче ми підготували для вас розшифрування дискусії, але також можна переглянути відео:
Перехід на мікросервіси – реакція на потреби ринку
Дмитро:
Чи був у вас успішний досвід переходу на мікросервіс? І взагалі: де ви бачите найбільшу користь у бізнесі від застосування мікросервісів чи переходу від монолітів до мікросервісів?
Сергій:
Ми пройшли вже деякий шлях переходу на мікросервіси і використовуємо такий підхід більше трьох років. Першою потребою, яка обґрунтувала необхідність мікросервісів, була нескінченна інтеграція різних фронтових продуктів із бек-офісом. І щоразу ми вимушено робили додаткову інтеграцію, розробку, реалізовуючи свої правила роботи того чи іншого сервісу.
У якийсь момент ми зрозуміли, що нам потрібне прискорення роботи наших систем та виведення функціональності. На той час на ринку вже існували такі поняття як мікросервіси, мікросервісний підхід, і ми вирішили спробувати. Почалося це у 2016 році. Тоді було закладено платформу та реалізовано перші 10 сервісів, силами окремої команди.
Одним з перших сервісів, найбільш навантажених, став сервіс розрахунку ціни. Щоразу, коли ви приходите в будь-який канал, в групу компаній «М.Відео-Ельдорадо», будь то сайт чи роздрібний магазин, підбираєте там товар, бачите ціну на сайті або в «Кошику», вартість автоматично розраховує один сервіс. Навіщо це потрібно: до цього кожна система мала свої принципи роботи з промо — зі знижками і так далі. Ціноутворенням у нас займається бек-офіс, функціонал знижок реалізований в іншій системі. Це потрібно було централізувати і створити такий унікальний сервіс у вигляді бізнес-процесу, який дозволяв би нам це реалізувати. Приблизно так ми стартували.
Цінність перших результатів була дуже великою. По-перше, ми змогли робити сутності, що відокремлюються, які дозволяють окремо, агреговано працювати. По-друге, ми знизили вартість володіння з погляду інтеграції з великою кількістю систем.
За останні три роки у нас додалися три фронтові системи. Їх було складно підтримувати у тому обсязі ресурсів, які могла дозволити собі компанія. Тому постало завдання шукати нові виходи, відповідаючи на ринок з точки зору швидкості, з точки зору внутрішніх витрат та ефективності.
Як оцінити успішність переходу на мікросервіси
Дмитро:
Як визначається успішність у переході на мікросервіси? Що було «до» у кожній компанії? Яку метрику ви використовували визначення успішності переходу, хто її визначав насправді?
Сергій:
Насамперед це народилося всередині IT як enabler — «розлочення» нових можливостей. Ми мали потребу робити все швидше за умовно ті ж гроші, відповідаючи на виклики ринку. Нині успішність виявляється у кількості сервісів, перевикористаних різними системами, уніфікація процесів між собою. Зараз так, а в той момент це була можливість створення платформи та підтвердження гіпотези, що ми можемо це зробити, це дасть ефект та розрахунок бізнес-кейсу.
Олександр:
Успішність – це, швидше, внутрішнє відчуття. Бізнес завжди хоче більше, і глибина нашого backlog'а — це підтвердження успішності. Мені так здається.
Сергій:
Так згоден. За три роки у нас вже більше двохсот сервісів та backlog. Потреба в ресурсах усередині команди лише зростає щорічно на 30%. Так відбувається тому, що люди відчули: це швидше, інакше інші технології, все це розвивається.
Мікросервіси прийдуть, але core залишиться
Дмитро:
Це схоже на нескінченний процес, де ви інвестуєте у розробку. Сам перехід на мікросервіси для бізнесу вже скінчився чи ні?
Сергій:
Дуже просто відповісти. Ви як вважаєте: заміна телефонів – це нескінченний процес? Ми ж самі купуємо телефони щороку. І тут так: поки існує потреба у швидкості, адаптації до ринку, будуть потрібні якісь зміни. Це не означає, що ми відмовляємось від стандартних речей.
Але ми не можемо відразу все охопити та переробити. Ми маємо legacy, стандартні інтеграційні сервіси, які були до цього: шини enterprise і так далі. Але є backlog і потреба теж є. Кількість мобільних програм та їх функціонал приростають. При цьому ніхто не говорить про те, що вам видадуть на 30% більше грошей. Тобто постійно з одного боку є потреби, з другого — пошук ефективності.
Дмитро:
Життя у тонусі. (Сміється)
Олександр:
Загалом, так. Ми не маємо революційних підходів до видалення з ландшафту core-частини. Йде планомірна робота з декомпозиції систем, щоб ті більше відповідали мікросервісної архітектури, зменшення впливу систем один на одного.
Але ми плануємо зберегти core-частину, тому що у ландшафті оператора завжди будуть якісь платформи, які ми купуємо. Знову ж таки, потрібен здоровий баланс: ми не повинні кидатися в «випилювання» core. Ми ставимо системи поруч, а зараз виявляється, що вже і над багатьма core-частинами. Далі, розвиваючи функціонал, робимо потрібні уявлення всім каналів, які працюють із нашими послугами зв'язку.
Як продати мікросервіси бізнесу
Дмитро:
Мені ще цікаво — для тих, хто не перейшов, але збирається: наскільки легко було продати цю ідею бізнесу і чи це була авантюра, інвестпроект? Або це було усвідомленою стратегією: зараз ми йдемо в мікросервіси і все, нас нічого не зупинить. Як це було?
Сергій:
Ми продавали не підхід, а бізнес-вигоду. Була проблематика у бізнесі, і ми її намагалися зняти. На той час вона виражалася в тому, що в різних каналах використовувалися різні принципи розрахунку ціни — окремо для промо, для акцій тощо. Це було складно підтримувати, виникали помилки, ми вислуховували нарікання клієнтів. Тобто, ми продавали усунення проблеми, але приходили з тим, що нам потрібні гроші на створення платформи. І показували бізнес-кейс на прикладі першого етапу інвестування: як ми далі його окупатимемо і що це дозволить нам робити.
Дмитро:
А ви якось фіксували час першого етапу?
Сергій:
Так звичайно. Ми відводили 6 місяців на створення core як платформи та перевірку пілота. За цей час ми намагалися створити платформу, де відкатали пілот. Далі підтвердили гіпотезу, а якщо вона працює — отже, можна продовжувати. Почали тиражувати та посилили команду — вивели її до окремого підрозділу, який тільки цим і займається.
Далі йде планомірна робота, що виходить із потреб бізнесу, можливостей, доступності ресурсів та всього того, що є зараз у роботі.
Дмитро:
Окей. Олександре, що скажете?
Олександр:
У нас мікросервіси народилися з «піни морської» — за рахунок економії ресурсів, за рахунок якихось залишків у вигляді серверних потужностей та перерозподілу сил усередині команди. Спочатку ми не продавали цей проект бізнесу. Це був проект, де ми й досліджували та розробляли відповідно. Ми стартували на початку 2018 року і просто на ентузіазмі розвивали цей напрямок. Продаж тільки що почався, і ми в процесі.
Дмитро:
А чи буває, що бізнес дозволяє займатися такими справами за принципом Google — в один вільний день на тиждень? У вас є такий напрямок?
Олександр:
Одночасно з дослідженнями ми займалися і бізнес-завданнями, тому всі наші мікросервіси - це рішення бізнес-завдань. Тільки спочатку ми будували мікросервіси, які охоплюють невелику частину абонентської бази, а зараз ми є практично у всіх флагманських продуктах.
І вже зрозумілий матеріальний вплив — нас уже можна порахувати, оцінити швидкість виведення продуктів та недоотриманий виторг, якби ми йшли старим шляхом. На цьому ми й будуємо кейс.
Мікросервіси: хайп чи необхідність?
Дмитро:
Цифри є цифри. І виручка чи заощаджені гроші — це дуже важливо. А якщо подивитися на інший бік? Здається, що мікросервіси це тренд, хайп і багато компаній зловживають цим? Наскільки чітко ви розмежуєте, що ви перекладаєте та не перекладаєте на мікросервіси? Якщо legacy зараз, то чи залишиться у вас legacy через 5 років? Яким буде вік інформаційних систем, які працюють у «М.Відео-Ельдорадо» та в «Мегафоні» через 5 років? Чи будуть там десятирічні, п'ятнадцятирічні інформаційні системи, чи це буде нове покоління? Як це ви бачите?
Сергій:
Мені здається, що дуже складно загадувати. Якщо повернутись назад, то хто припускав, що так розвиватиметься ринок технологій і того ж машинного навчання, ідентифікації користувачів по обличчю? Але якщо подивитися найближчими роками, мені здається, що core-системи, enterprise-системи класу ERP у компаніях вони працюють досить давно.
Нашим компаніям сукупно 25 років, у них класичний ERP знаходиться дуже глибоко у ландшафті систем. Зрозуміло, що ми виносимо звідти якісь шматки і намагаємось їх агрегувати у мікросервіси, але core залишиться. Мені складно зараз уявити, що ми там замінимо всі core-системи і швидко перейдемо на інший, світлий бік нових систем.
Я прихильник того, що все, що знаходиться ближче до клієнта і споживача, там, де найбільша бізнес-вигода і цінність, де потрібна адаптивність і орієнтація на швидкість, на зміни, спробувати, скасувати, перевикористовувати, зробити щось інше »- Ось там ландшафт зміниться. І туди не дуже добре вбудовуються коробки. Принаймні ми цього не бачимо. Там потрібні максимально легкі, прості рішення.
Ми бачимо такий розвиток:
- core інформаційних систем (переважно бек-офіс);
- middle-шари у вигляді мікросервісів пов'язують core, агрегують, створюють кеш і так далі;
- фронтові системи спрямовані на споживача;
- інтеграційний шар, який взагалі інтегрований у маркетплейси, інші системи та екосистеми. Цей шар є максимально легким, простим, у ньому мінімум бізнес-логіки.
Але я прихильник того, щоб продовжувати використовувати старі принципи, якщо вони використовуються до місця.
Допустимо, у вас є класична enterprise-система. Вона знаходиться в ландшафті одного вендора, складається з двох модулів, які працюють. Також є стандартний інтеграційний інтерфейс. Навіщо це переробляти та приносити туди мікросервіс?
А от коли є 5 модулів у бек-офісі, з яких збираються шматки інформації в бізнес-процес, яким потім користуються 8-10 фронтових систем — тут одразу помітна вигода. Ви забираєте із п'яти бек-офісних систем, створюєте сервіс, причому ізольований, який орієнтований на бізнес-процес. Сервіс робите технологічним — щоб він кешував інформацію і був стійким до відмови, а також працював з документами або бізнес-сутностями. І інтегруєте його за єдиним принципом із усіма фронтовими продуктами. Скасували фронтовий продукт – просто вимкнули інтеграцію. Завтра вам потрібно написати мобільний додаток або зробити маленький сайт і лише одну частину приземлити у функціонал – все просто: ви зібрали це як конструктор. Я більше в такий бік бачу розвиток, принаймні у нас.
Олександр:
Сергій повністю описав наш підхід, дякую. Я тільки скажу, куди ми точно не підемо — до core-частини, до теми онлайн-тарифікації. Тобто рейтинг і чарджинг залишиться, власне, «сишою» молотилкою, яка надійно списуватиме гроші. І ця система, як і раніше, сертифікуватиметься нашими контролюючими органами. Все інше, що дивиться у бік клієнтів, звичайно це мікросервіси.
Дмитро:
Тут саме сертифікація — це одна історія. Напевно, ще підтримка. Якщо ви витрачаєте на підтримку трохи або система не потребує підтримки та доопрацювання, краще її не чіпати. Розумний компроміс.
Як розробляти надійні мікросервіси
Дмитро:
Добре. А ось мені ще цікаво. Зараз ви розповідаєте success story: все було добре, ми перейшли на мікросервіси, захистили ідею перед бізнесом і все вийшло. Але я чув інші історії.
Кілька років тому одна швейцарська компанія, яка інвестувала два роки у розробку нової мікросервісної платформи для банків, у результаті закрила цей проект. Повністю згорнула. Було витрачено багато мільйонів швейцарських франків, а зрештою розігнали команду — не пішло.
У вас були подібні історії? Чи були чи є якісь складності? Наприклад, обслуговування мікросервісів, той самий моніторинг — теж біль голови в операційній діяльності компанії. Адже кількість компонентів збільшується у десятки разів. Як ви бачите, чи були невдалі приклади інвестицій тут? І що можна порадити людям, щоб вони не стикалися із подібними проблемами?
Олександр:
Невдалі приклади були в тому, що бізнес змінював пріоритети та скасовував проекти. Коли на хорошому етапі готовності (фактично готовий MVP) бізнес говорив: "У нас нові пріоритети, йдемо в інший проект, а цей закриваємо".
Глобальних фейлів із мікросервісами у нас не було. Ми спокійно спимо, ми маємо чергову зміну 24/7, яка обслуговує весь BSS [business support system].
І ще ми здаємо мікросервіси за правилами, за якими здаються коробкові продукти. Запорука успіху в тому, що потрібно, по-перше, зібрати команду, яка повністю готуватиме мікросервіс до продакшену. Сама технологія — це, умовно, 40%. Решта – аналітика, методологія DevSecOps, правильні інтеграції та правильна архітектура. Особливу увагу приділяємо принципам побудови безпечних програм. У кожному проекті беруть участь представники ІБ як у етапі планування архітектури, і у процесі реалізації. Ще вони управляють системами аналізу коду на вразливості.
Припустимо, ми деплоїмо свої сервіси stateless - у нас вони в Kubernetes. Це дозволяє всім спати спокійно за рахунок автомасштабування та автопідняття сервісів, а чергова зміна підхоплює інциденти.
За весь час існування наших мікросервісів був лише один або два інциденти, які дійшли до нашої лінії. Наразі проблем з експлуатацією немає. У нас, звичайно, не 200, а близько 50 мікросервісів, але вони використовуються у флагманських продуктах. Якби вони збоїли, ми дізналися б про це першими.
Мікросервіси та HR
Сергій:
Згоден із колегою про передачу на підтримку — що потрібно правильно організовувати роботу. Але скажу про проблеми, які, звичайно, є.
По-перше, технологія нова. Це в хорошому сенсі хайп, і знайти фахівця, який розбиратиметься і зможе створювати це велика складність. Конкуренція за ресурси божевільна, відповідно, експерти на вагу золота.
По-друге, при створенні певних ландшафтів та зростаючій кількості сервісів має постійно вирішуватися завдання з перевикористанням. Як люблять робити розробники: «Давайте зараз понапишемо тут багато цікавого…» Через це система розростається і втрачає свою ефективність з погляду грошей, вартості володіння і так далі. Тобто потрібно закладати перевикористання в архітектуру систем, включати в road map впровадження сервісів та перекладу legacy на нову архітектуру.
Ще одна проблема — хоч це по-своєму та добре — це внутрішня конкуренція. «О, нові модні хлопці з'явилися у нас, розмовляють новою мовою». Люди, звісно, різні. Є ті, хто звик писати на Java, і ті, хто пише та використовує Docker та Kubernetes. Це абсолютно інші люди, вони по-різному розмовляють, використовують інші терміни та інколи один одного не розуміють. Вміння чи невміння ділитися практикою, знання sharing, у цьому сенсі теж проблема.
Та й масштабування ресурсів. «Здорово, поїхали! А тепер хочемо швидше, більше. А що, не можете? Хіба вдвічі більше поставити за рік не можна? А чому?" Такі проблеми зростання стандартні, напевно, для багатьох речей, багатьох підходів, і вони відчуваються.
Щодо моніторингу. Мені здається, що сервіси чи промислові інструменти моніторингу вже навчаються або вміють працювати і з Docker, і Kubernetes в іншому, нестандартному режимі. Щоб у вас, наприклад, не з'явилося 500 Java-машин, під якими це запущено, а саме агрегує. Але цим продуктам ще не вистачає зрілості, їм належить це пройти. Тема справді нова, вона ще розвиватиметься.
Дмитро:
Так дуже цікаво. І це стосується HR. Можливо, ваш НR-процес і HR-бренд трохи змінилися за ці три роки. Ви стали набирати інших людей, з іншою компетенцією. І тут є, мабуть, і плюси, і мінуси. Раніше хайповими були blockchain і data science, і фахівці з них коштували просто мільйони. Зараз вартість спадає, ринок насичується, і в мікросервісах схожий тренд.
Сергій:
Так, абсолютно.
Олександр:
HR ставить питання: «Де ж ваш рожевий єдиноріг між backend'ом і frontend'ом?» HR не розуміють, що таке мікросервіс. Ми відкрили їм секрет і сказали, що це backend все зробив і там немає єдинорога. Але HR змінюються, швидко навчаються та підбирають у рекрутинг людей, які володіють базовими IT-знаннями.
Еволюція мікросервісів
Дмитро:
Якщо подивитися на цільову архітектуру, то мікросервіси виглядають таким собі монстром. Ваш шлях зайняв кілька років. В інших рік, у третіх – три роки. Ви передбачали всі проблеми, цільову архітектуру, чи щось змінювалося? Наприклад, у разі мікросервісів зараз з'являються знову gateways, service mesh'и. Ви використовували їх на початку чи змінювали саму архітектуру? Чи є такі дзвінки у вас?
Сергій:
Ми вже переписали кілька протоколів взаємодії. Спочатку один протокол зараз перейшли на інший. Підвищуємо безпеку та надійність. Починали з enterprise-технологій – Oracle, Web Logic. Тепер уникаємо технологічних enterprise-продуктів у мікросервісах і переходимо на open source або на зовсім відкриті технології. Відмовляємося від баз даних, переходимо на те, що більш ефективно працює для нас у цій моделі. Технології Oracle нам стали непотрібними.
Ми починали просто як сервіс, не замислюючись про те, наскільки нам потрібен кеш, що ми робитимемо, коли немає зв'язку з мікросервісом, а дані потрібні, і т.д. Зараз розвиваємо платформу, щоб архітектуру можна було описати не мовою сервісів, а на бізнес-мові, перекласти бізнес-логіку на наступний рівень, коли ми почнемо розмовляти словами. Зараз ми навчилися розмовляти літерами, а наступний рівень — коли сервіси збиратимуться в якийсь агрегат, коли це вже слово — наприклад, картка товару цілком. Вона збирається з мікросервісів, але це такий надбудований над цим API.
Безпека є дуже важливою. Як тільки ви починаєте бути доступними і у вас є сервіс, по якому можна багато чого цікавого отримати, і дуже швидко, за частки секунд, виникає бажання отримати це не найбезпечнішим чином. Щоб від цього піти, довелося змінювати підходи до тестування та моніторингу. Довелося змінювати команду, структуру керування постачанням, CI/CD.
Це еволюція — як із телефонами, тільки набагато швидше: спочатку були телефони, потім з'явилися смартфони. Переписали, переробили продукт тому, що на ринку з'явилася інша потреба. Так і ми еволюціонуємо перший клас, десятий клас, робота.
Ітеративно на рік закладається щось із погляду технологій, ще щось — з погляду backlog'а та потреб. Ми з'єднуємо одне з одним. Команда витрачає 20% на техборг та технічне забезпечення команди, 80% — на бізнес-сутність. І рухаємо, з розумінням, навіщо робимо, чому робимо ці технологічні покращення, до чого вони приведуть. Приблизно так.
Дмитро:
Круто. А що у «Мегафоні»?
Олександр:
Основний виклик під час нашого приходу в мікросервіси – не впасти у хаос. До нас одразу підключився, навіть став ініціатором та драйвером архітектурний офіс «Мегафону» — тепер ми маємо дуже сильну архітектуру. Його завданням було зрозуміти, в яку цільову модель ми йдемо та які технології потрібно пілотувати. З архітектурою ми проводили ці пілотування.
Наступне питання було: "А як потім це все експлуатувати?". І ще одне: «Як забезпечити прозору взаємодію між мікросервісами?». На останнє запитання нам допоміг відповісти на службу mesh. Ми пропілотували Istio, і результати нам сподобалися. Зараз ми знаходимося на етапі розкочування у продуктивні зони. До всіх викликів ми ставимося позитивно — до того, що потрібно постійно змінювати стек, вивчати щось нове. Нам цікаво розвиватись, а не експлуатувати старі рішення.
Дмитро:
Золоті слова! Такі виклики тримають у тонусі команду та бізнес та створюють майбутнє. GDPR створив chief data protection officers, а нинішні виклики створюють головних з мікросервісів та архітектури. І це радує.
Ми багато обговорили. Головне — гарне опрацювання мікросервісів і самої архітектури дозволяє уникнути багатьох помилок. Звичайно, процес це ітеративний та еволюційний, але за ним майбутнє.
Дякую всім учасникам, дякую Сергію та Олександру!
Питання із зали
Питання із зали (1):
Сергію, як змінився IT-менеджмент у вашій компанії? Я розумію, коли є великий стек із кількох систем, тут він управляється — це досить зрозумілий і логічний процес. Як ви перебудовували менеджмент в IT-складнику після того, як дуже велика кількість мікросервісів була інтегрована в такий короткий термін?
Сергій:
Я приєднаюся до колеги, що дуже важливою є архітектура як драйвер змін. Ми розпочали з того, що у нас з'явився архітектурний підрозділ. Архітектори одночасно є власниками розподілу функціональності та вимог до того, як це виглядатиме у ландшафті. Тож вони ж виступають і координаторами цих змін. В результаті відбулися конкретні зміни у конкретному процесі постачання, коли ми створили платформу CI/CD.
Але стандартні, базові принципи розробки, бізнес-аналіз, тестування та розробку ніхто не скасовував. Ми просто додали швидкість. Раніше цикл займав стільки, установка на тестові середовища - ще стільки. Зараз бізнес бачить вигоду та каже: «А чому в інших місцях не можна так само зробити?».
Це як у хорошому сенсі ін'єкція у вигляді вакцини, яка показала: можна ось так, а можна і по-іншому. Звичайно, є проблема у персоналі, у компетенціях, у знаннях, у опорі.
Питання із зали (2):
Критики мікросервісної архітектури кажуть, що виникають складнощі із тестуванням та розробкою. Це логічно там, де щось ускладнюється. З якими складнощами зіткнулася ваша команда та як ви їх побороли? Запитання до всіх.
Олександр:
Складнощі є при переході від мікросервісів до платформи, але вони вирішуються.
Наприклад, ми робимо продукт, який складається із 5-7 мікросервісів. Нам потрібно забезпечити інтеграційні тести по всьому скоупу мікросервісів, щоб дати зелене світло до переходу в майстер-гілку. Це завдання було для нас не новим: ми довго займалися цим у BSS, коли вендор постачав нам вже відвантажені рішення.
І наша проблема лише у нечисленній команді. Один умовний продукт потрібен один QA-инженер. І ось, ми відвантажуємо продукт із 5-7 мікросервісів, з яких 2-3 можуть бути розроблені сторонніми людьми. Наприклад, у нас є продукт, у розробці якого бере участь наш вендор білінгової системи, Mail.ru Group та R&D «Мегафона». Нам потрібно покрити це тестами перед тим, як відвантажити у прод. Півтора місяці QA-інженер займається цим продуктом, і решта команди залишається без підтримки.
Ця складність викликана лише масштабуванням. Ми розуміємо, що мікросервіси не можуть існувати у вакуумі, абсолютної ізоляції не існує. Змінюючи один сервіс, ми обов'язково намагаємось зберегти API-контракт. Якщо щось змінюється під капотом, front сервіс залишається. Якщо зміни фатальні, йде якась архітектурна трансформація і ми переходимо взагалі на іншу метамодель даних, яка є повністю несумісною — тільки тоді ми говоримо про те, що з'являється API-специфікація сервісу v2. Ми підтримуємо одночасно першу та другу версії, а після переходу всіх споживачів на другу версію першу просто закриваємо.
Сергій:
Я хочу доповнити. Абсолютно згоден на ускладнення — вони відбуваються. Ландшафт ускладнюється, зростають накладні витрати, особливо на тестування. Як із цим боротися: переходити на автотестування. Так, доведеться додатково інвестувати в написання автотестів та unit-тестів. Щоб розробники не могли комити без проходження тесту, не могли змінювати код. Щоб навіть кнопка push не працювала без автотесту, unit-тесту.
Важливо підтримувати попередній функціонал, а це додаткові витрати. Якщо переписувати технологію на інший протокол, то переписуєш доти, доки не закриєш усе.
Ми іноді спеціально не робимо end-to-end тестування, тому що не хочемо зупиняти розробку, хоча в нас одне за інше теж чіпляється. Ландшафт дуже великий, складний, багато систем. Іноді просто заглушки - так, ви знижуєте кордон безпеки, з'являється більше ризиків. Але при цьому постачання випускаєте.
Олександр:
Так, автотести та unit-тести дозволяють зробити якісний сервіс. Ми за пайплайн, який не можна пройти без unit- та інтеграційних тестів. Доводиться часто тягнути в тестові зони і в середовищі розробки емулятори, системи з прода, тому що не всі системи можна розмістити в тестових зонах. Причому вони не просто мокаються – ми генеруємо повноцінну відповідь від системи. Це серйозна частина роботи з мікросервісами, і ми в неї також вкладаємось. Без цього настане хаос.
Питання із зали (3):
Наскільки я розумію, спочатку мікросервіси росли з окремої команди і зараз існують у цій моделі. Які у неї плюси та мінуси?
Просто ми маємо схожу історію: виникла якась фабрика мікросервісів. Зараз ми концептуально підійшли до того, що цей підхід ми поширюємо на виробництво за стримами та системами. Іншими словами, ми уникаємо централізованої розробки саме мікросервісів, моделей мікросервісів, і стаємо ближче до систем.
Відповідно, експлуатація у нас теж йде до систем, тобто ми децентралізуємо цю тему. Який у вас підхід та яка цільова історія для вас?
Олександр:
Назву "фабрика мікросервісів" ви як з мови зняли - ми теж хочемо відмасштабуватися. По-перше, у нас справді зараз одна команда. Всім командам розробки, які є в МегаФоні, ми хочемо надати можливість працювати в загальній екосистемі. Ми не хочемо повністю забирати на себе весь функціонал розробки, який є зараз. Завдання локальне – відмасштабуватися, завдання глобальне – вести розробку всім командам у мікросервісному шарі.
Сергій:
Розкажу, який шлях ми пройшли. Ми справді починали працювати однією командою, але зараз вона не одна. Я прихильник наступного: маю бути власник процесу. Хтось повинен розуміти, керувати, контролювати та будувати процес розробки по мікросервісах. Він має володіти ресурсами та займатися ресурс-менеджментом.
Ці ресурси, які знають технології, специфіку та розуміють, як будувати мікросервіси, можуть перебувати у продуктових командах. У нас мікс, де люди з мікросервісної платформи знаходяться у продуктовій команді, яка робить мобільний додаток. Вони там знаходяться, але працюють у процесі відділу з управління мікросервісної платформи зі своїм керівником розробки. Усередині цього підрозділу є окрема команда, яка займається технологіями. Тобто ми міксуємо між собою загальний пул ресурсів та поділяємо їх, віддаючи їх усередину команд.
При цьому процес залишається загальним, контрольованим, він протікає за загальними технологічними принципами, з unit-тестуванням і так далі — усім, що надбудовано зверху. Тут може бути колони як ресурсів, зібраних із різних підрозділів продуктового підходу.
Олександр:
Сергію, ви фактично є власником процесу, так? Backlog задач загальний? Хто займається його розподілом?
Сергій:
Дивіться тут знову мікс. Є backlog, який формується, виходячи з технологічних покращень – це одна історія. Є backlog, який формулюється з проектів, і є backlog із продуктів. Але послідовність виведення всередину кожного з товарів сервісу чи створення цього розробляє продуктолог. Його немає в ІТ-дирекції, він спеціально з неї виведений. Але мої люди точно працюють за одним процесом.
Власником backlog'а в різних напрямках - backlog'а змін - будуть різні люди. Пов'язаність технологічних сервісів, їхнього принципу організації — все це перебуватиме в ІТ. Платформою я володію, ресурсами — теж. Зверху знаходиться те, що стосується backlog'а і функціональних змін, і архітектура в цьому сенсі.
Припустимо, бізнес каже: «Хочемо таку функцію, хочемо створити новий продукт — переробити кредит». Ми відповідаємо: "Так, переробимо". Архітектори кажуть: "Давайте подумаємо: де в кредиті впишемо мікросервіси і як це зробимо?" Далі розкладаємо це на проекти, продукти чи на технологічний стек, опускаємо у команди та реалізуємо. Чи створили всередині продукт і вирішили в цьому продукті використовувати мікросервіси? Говоримо: "Тепер legacy-системи, які у нас були, або фронтові, повинні переходити на ці мікросервіси". Архітектори кажуть: «Так: у технологічний backlog усередину фронтових продуктів перехід на мікросервіси. Поїхали». І продуктологи чи власники від бізнесу розуміють, скільки відведено capacity, коли це буде зроблено і чому.
Кінець дискусії, але ще не все
Конференція mailto:CLOUD була організована .
Ми також робимо інші заходи – наприклад, @Kubernetes Meetup, куди завжди шукаємо класних спікерів:
- Слідкуйте за новинами @Kubernetes та інших @Meetup у нашому Telegram-каналі
- Бажаєте виступити на одному з @Meetup? Залишіть заявку на
Джерело: habr.com