Insight Section | GlobalLogic Ukraine

Archives

Друзі, попереду довгі вихідні! Ми зібрали весняний дайджест наших Блогів, аби було що почитати.  Ми намагались зробити тематику різноманітною: від керування проєктами до мікросервісної архітектури. Сподіваємось, вам сподобається цей список!

Поїхали!

Ми знаємо, що в цьому каналі є менеджери проєктів. Так, ви не сховались. Впевнені, вам буде цікава колонка від Романа Щербака, Manager, Scrum Master, Consultant, GlobalLogic

Від менеджменту перейдемо до коду. Великий та детальний розбір азів мікросервісної архітектури від нашого експерта та спікера Орхана Гасімова, Senior Solution Architect, Consultant, GlobalLogic

Чим живуть сучасні студенти? Як проходить навчання, що їм подбається, а чого – не вистачає? Про це поговорили з Михайлом Бондаренко, студентом-першокурсником Українського католицького університету, факультету прикладних наук.

Все, що має початок, має й кінець. Тому Катерина Васильєва, People Development, Consultant, GlobalLogic розібрала, як правильно проводити exit – інтерв’ю, які є особливості та нюанси цього процесу та як зробити так, аби отримані дані перетворювались в конкретні результати!

Слово – не горобець.

Анастасія Васьків, University Program Coordinator, Consultant, GlobalLogic, розкриває шляхи побудови професійної комунікації та розповідає про спеціальний курс від GlobalLogic, присвячений комунікації.

Традиційно GlobalLogic багато уваги приділяє взаємодії з аудиторією, а саме – ком’юніті. Як ми зробили ще одне, для відпочинку – читайте у колонці Ірини Мудь, Marketing, Consultant, GlobalLogic.

Бажаємо вам приємного читання й нагадуємо, що ми маємо професійні спільноти у Facebook де є багато цікавого контенту:

А на додачу – Telegram-канал з усіма важливими новинами й апдейтами!

Формат інтерв’ю повертається у BlogSpot! Сьогодні розмовляємо не про продукт чи проєкт, а про навчання.

Наш співрозмовник – Михайло Бондаренко, студент-першокурсник Українського католицького університету, факультету прикладних наук. Михайло є стипендіатом, він отримав академічну стипендію від GlobalLogic, яка покриває рік навчання в УКУ.

Ми вирішили розпитати його про навчання, дозвілля, що його цікавить у світі технологій, та яке майбутнє для себе він бачить у світі ІТ. Тож поїхали!

  • Поділись враженнями, як тобі процес навчання? Якби ти б хотів щось додати в процес, що б це могло бути?

Михайло: Додати в процес навчання? Це завжди складні питання, тому що для цього потрібно порівняти з чимось. Я поки не знаю з чим можна порівняти. Я спираюсь на те, що у мене є.

  • Як тобі навчання в період карантину? Як тобі взагалі організація навчального процесу в комбінованому форматі?

Я думаю, що все доволі зручно організовано, рідко бувають випадки коли щось ламається, і хтось не може під’єднатися. Іноді важливо, щоб була змога прийти в офлайн. Наприклад на парах із англійської у нас часто відбуваються різні обговорення і краще бачити цих людей наживо. Онлайн для такого не дуже підходить. А іноді легше під’єднатися онлайн, так зручніше, не витрачаєш час для того, щоб дійти кудись.

  • Розкажи як тобі твій перший семестр? Можливо маєш уже якісь предмети, які тобі сподобалось, як викладали, і якщо так, то що саме?

Навчання дається мені успішно. З кожного предмету я дізнався щось нове. Якщо взяти до прикладу програмування, то я багато чого уже знав сам, адже коли вступав до УКУ, то вже вмів програмувати. Проте коли нещодавно переглядав свої колишні проєкти, щоб вказати посилання в CV, зрозумів який там “мрак” і деякі переписав. Я розумію, що моє вміння писати код суттєво покращилося. І я не бачу зараз тут зайвих предметів, не думаю що вони тут є і в цьому я бачу великий плюс. У школі у мене були погані оцінки, тільки з улюбленими предметами все було добре, а тут у мене з усіх предметів гарні оцінки, тому що всім вони мені здаються потрібними.

  • Ти згадував про те, що вам потрібно було написати CV. Ти почав шукати роботу чи вам потрібно було для якогось проєкту?

В УКУ є лабораторія штучного інтелекту, яка опублікувала інформацію, що вони набирають людей. І я вирішив спробувати, бо колись вивчав тему штучного інтелекту. Подумав, що хоча б побуваю на співбесіді, що теж буде цікавим досвідом для мене. Зібрав свої старі проєкти, зібрав те що я вмію, те що я знаю, написав CV, щоб туди податися. Ще співбесіди не було.

  • Можливо ти вже маєш якісь ідеї чи сфери в яких тобі хотілося далі розвиватися і де ти бачиш себе через 5 років :)?

Так, я планую займатися штучним інтелектом. Я знаю що мені потрібно, розумію основні речі, але не конкретизував це поки. Мені ця тема здається дуже цікавою, за нею майбутнє. З чим планую поєднати ще для себе не конкретизував, можливо це буде маркетинг, можливо це будуть інші речі пов’язані з взаємодією з людьми, щось схоже….

  • А чому саме маркетинг?

Тому що мені цікаві суспільні процеси.

  • Чи займаєшся ти додатково поза навчальною програмою? Чи є якісь курси, чи достатньо тобі цієї інформації, яку дає тобі університет?

Я додатково цікавлюсь деякими речами. Іноді ця цікавість починається з універу. Ось на «дискретці» у нас були комп’ютерні проєкти, де ми вивчали ізоморфічну графіку. Мені стало це цікаво, я вирішив написати не просто банальний алгоритм, а вирішив зробити щось цікаве, почав це гуглити, це було моїм додатковим навчанням. Тобто іноді додаткове навчання, воно починається з університету. Іноді, я можу почати щось вивчати додатково зі сфери штучного інтелекту. Чи от, нещодавно, до мене прийшла ідея зробити файлову систему свого старого телефону на Android схожим на Linux, щоб там працювали звичайні речі. Можливо потім зроблю з цього телефону сервер. Ось такі речі, які мені цікаві я вивчаю додатково.

Ви питали: «Що можна покращити?». Наприклад, на матаналізі доведень мало мені. Але я якщо мені чогось не вистачатиме я пошукаю це в Google. Розумію, що для всіх це може бути оптимальне рішення, такий формат матаналізу, який у нас зараз є, тому й не можу сказати що зараз потрібно щось змінити.

  • А наскільки сам університет пропагує додаткове навчання та курси, лекції, семінари. Наскільки це і чи часто ти цим користуєшся? Знаємо, що УКУ часто дає можливості для лекцій, конференції, тощо.

Так, дуже часто приходять повідомлення про те, що відбудеться конференція або лекція. В деяких я брав участь. Можна було обирати з англійською курси додаткові, я для себе обрав дебати, було цікаво. Ще тут є політклуб в УКУ і я туди приходив. Було цікаво.

  • Ти сам з Харкова, а чому ти прийняв рішення саме переїхати до Львова і не захотів залишитись в Харкові?

По-перше, переїхати кудись це дуже цікава ідея, мені вона завжди дуже подобалася. Харків – це класне місто, але мені здається що коли я знаходжуся в іншому місті, коли поруч зі мною немає людей, які мене знають, я можу робити що завгодно, бути ким завгодно, і це розвиває самостійність, відповідальність. По-друге, у Львові я сам все організовую і набагато продуктивнішим себе відчуваю.

  • Якщо говорити про світ ІТ можливо у тебе є якийсь кумир, чи людина, яка тебе захоплює, чи надихає?

Це важко. Якщо брати номінанти, то нехай буде Ілон Маск. Проте, я не можу сказати що Ілон Маск надихає мене у всьому. Кожна людина надихає по-своєму. Ілон Маск, наприклад, дуже класно організував свій час, тому що він встигає дуже-дуже багато. У цьому можу сказати що він мій кумир, а в іншому – не знаю, і тому виділити одну людину складно.

  • Уявімо, що ти зараз спілкуєшся з людьми, які думають куди їм вступати, як їм шукати себе, щоб ти їм порадив?

Я порадив, якщо йдете на психологію і здається що це буде вам подобатися, то якось спробуйте доторкнутись до цього світу, аби краще актуалізувати свої побажання та очікування, зрозуміти краще, чого ви хочете.

  • Ніби дізнатися про спеціальність більше?

Так, дізнатися про себе і про спеціальність більше. Ну і потім є топ університетів, і можна дивитися, який з цих університетів найкращий, цілитись туди. А потім уже, як Сковорода говорив: «Дивись на найбільше, візьмеш те, що посередині». Тобто, по-перше, це зрозуміти, чого ти хочеш, зрозуміти яке твоє місце в бажаній спеціальності, більше про неї дізнатися. Друге – це зрозуміти, які є найкращі варіанти. Третє – цілитись на ті результати які дозволять вступити в найкращі варіанти ВУЗів, ну і потім якщо не вийде, можна буде взяти щось нижче. Але сенс в тому що потрібно цілитися на найкращі варіанти і готуватись до ЗНО.

  • Які у тебе плани на найближчий час? Як плануєш перший курс закінчувати?

Михайло: Я збирався працювати десь влітку, думаю це можливо. Залежить від того як складеться все. Наприклад, якщо мене приймуть в цю ML лабораторію, то можливо я буду робити щось пов’язане з нею. Якщо не приймуть, то напевно буду шукати собі реальний проєкт, аби набиратись досвіду. Хочу більше пізнати себе професійно, як я можу виконувати різні завдання.

  • Може, на останок в тебе є якісь питання до нас?

Розкажіть, більше саме про GlobalLogic.

  • З задоволенням! Компанія GlobalLogic входить в топ 3 найбільших ІТ компаній в Україні, у нас є дуже багато різних проєктів з багатьох різних технологій. В Україні у нас є офіси у Львові, один як раз знаходиться біля УКУ. Ще є в Києві, Харкові та Миколаєві. По Machine Learning, яким ти цікавишся, у нас так само є команди, які працюють у Львові. Проте найбільша команда, сфокусована на ML напрямку, знаходиться в Харкові.

  • Якщо говорити про речі, більш дотичні до навчання, то у нас є GlobalLogic Education, напрям, який займається навчанням і розвитком. У нас є GL BaseCamp та GL ProCamp – це спеціальні курси для студентів та фахівців, що прагнуть підвищити свій рівень та потрапити до команди GlobalLogic. Для випускників курсів є можливість доєднатися до команди якщо є відкриті позиції.

Тобто хтось може прийти до вас, навчитися і потім приєднатись до проєкту у цій сфері?

  • Так, це можливо. Всі наші курси є безкоштовними, тому на них є відбір. Потрібно пройти тестові завдання, інтерв’ю і тоді тебе приймають в групу.

Дякую вам за розповідь! Тепер я трохи більше знаю, що буду робити у майбутньому.

  • Дякуємо і тобі. Бажаємо успіхів у навчанні!

Бажаєте ще інтерв’ю?

Тоді пропонуємо звернути уваги на розмову про Manchester City та проєкт, який робить команда GlobalLogic!

Минулого разу у колонці “Все, що ви хотіли знати про роутери та Wi-Fi. Частина І. Обладнання” та “Все, що ви хотіли знати про роутери та Wi-Fi. Частина ІІ. Що таке OpenWrt?” ми поговорили про сучасний стан речей у сфері обладнання: які роутери бувають, які є виклики та тренди у галузі та розробках. Також, розібрали middleware та OpenWT. Прийшов час поговорити взагалі про технологію та її тренди.

Нові функції Wi-Fi

Рік тому був прийнятий новий стандарт – 802.11ax. Для простоти, Wi-Fi Alliance ввів нумерацію Wi-Fi 4/5/6, тож тепер стандарт 802.11ax відповідає Wi-Fi 6.

Його плюси: 

  • Вища швидкість – теоретично майже до приголомшливих 10Гбіт/сек.
  • Більша кількість підтримуваних пристроїв.
  • Збільшення площі покриття.
  • Оптимізація енергоспоживання мобільних пристроїв

Через 6 місяців після появи Wi-Fi 6 американська організація FCC, яка відповідає за розподіл частот, виділила весь діапазон 6 ГГц для Wi-Fi на додачу до чинних діапазонів 2.4 та 5ГГц..

Щоправда, ані виробники, ані організації які стандартизують Wi-Fi, не були до цього готові. Тому Wi-Fi Alliance вніс корективи у стандарт Wi-Fi 6, щоб розширити його та покрити діапазон 6 ГГц. Так з’явився Wi-Fi 6E.

Easy Connect

Easy Connect – це нова функція, що покликана спростити введення довгих та складних паролів. Замість введення символів чи цифр для приєднання нових пристроїв можна буде використовувати QR коди чи мітки NFC. При цьому користувач навіть зможе змінити роутер, але підключені пристрої надалі залишатимуться під’єднаними до мережі.

Wi-Fi Mesh

Ще одним трендом є інтелектуальний Wi-Fi та Mesh. Більшість виробників вже пропонують свої рішення в новий стандарт EasyMesh 2.0 який має шанс набути широкого розповсюдження.

Команда GlobalLogic створила власне рішення в цій області. Спеціальний додаток Wi-Fi Quality of Experience постійно вимірює продуктивність Wi-Fi за різними показниками: на рівні точки доступу, в ефірі, та відносно кожного приєднаного пристрою. Додаток поєднує ці показники з даними про бітрейт пристрою та класифікацією трафіку – це дозволяє оператору відстежувати якість та стан Wi-Fi у клієнтів в реальному часі.

Крім того, програма може сформувати індивідуальні рекомендації для покращення якості роботи для кожного з користувачів та ініціювати набір дій, які покращать загальну якість роботи Wi-Fi.

Можливий набір дій:

  • Динамічну зміну каналу (Dynamic Channel Changing)
  • Динамічний розподіл під’єднаних пристроїв по діапазонах (Band Steering)
  • Управління ефірним часом (Airtime Management)
  • Динамічний вибір ширини смуги пропускання (Dynamic Bandwidth Selection)
  • Повідомлення та сповіщення для користувачів та груп підтримки постачальників послуг інтернету.

Власне, на цьому наша розповідь завершується. Ми перерахували усі основні тренди та проблеми, що існують в галузі на сьогодні. Сподіваємось, ця стаття пролила світло на стан справ у сучасному світі роутерів, Wi-Fi та суміжних галузей.

Бажаєте більше цікавих тем? Читайте наші Блоги. А на додачу – професійні спільноти GlobalLogic, що діють у Facebook:

Дякуємо за увагу!

Минулого разу у колонці “Все, що ви хотіли знати про роутери та Wi-Fi. Частина І.” ми поговорили про сучасний стан речей у сфері обладнання: які роутери бувають, які є виклики та тренди у галузі та розробках.

Сьогодні ми продовжимо розповідь та перейдемо з теми обладнання до теми проміжного забезпечення, а саме – OpenWRT. Що це таке, навіщо потрібно та з чого складається? Відповіді – нижче!

Що таке OpenWrt?

Домашні роутери складаються з двох частин: апаратного та програмного забезпечення.

Апаратне забезпечення – це процесори, флеш-карти, оперативна пам’ять, мережеві карти, тощо. На всіх цих пристроях працює програмне забезпечення, яке і надає потрібні сервіси. Виникає питання, що знаходиться між апаратним та програмним забезпеченням?

Проміжне програмне забезпечення часто плутають з операційною системою. Різниця ось у чому: операційна система (ОС) дозволяє налаштувати апаратне чи запустити програмне забезпечення, а от налаштуванням ОС якраз і займається проміжне програмне забезпечення. Прикладом є OpenWrt.

Архітектура OpenWrt?

Кілька тез щодо архітектури:

  • Базується на Linux та містить BusyBox
  • Комунікація сервісів відбувається через UBUS (аналог DBUS)
  • Конфігурація зберігається на UCI (база даних у текстовому форматі)
  • Стандартним веб-інтерфейсом є LuCI (Lua Configuration Interface), який використовує UCI для отримання даних про систему та внесення змін в її конфігурацію.

Для кращого розуміння пропонуємо завантажити Git репозиторій, який називається OpenWrt, який містить buildroot. Там є посилання на так звані «фіди», які зберігають посилання на всі пакети, необхідні для того, щоб зібрати образ під конкретні пристрої.

Труднощі у роботі з OpenWrt

Звісно, не обходиться без труднощів. 

  • Попри популярність системи, важко знайти актуальну документацію. Її значна частина застаріла, та описує функціональність не так, як вона працює насправді.
  • Немає чіткої інструкції, як повинні виглядати нові елементи, які ми додаємо до системи. Існує багато профілів, які були додані, але зараз не обслуговуються. Відповідно, з кожним наступним оновленням системи близько сотні пакетів зникає.

Це основна інформація про стан OpenWrt. У наступній колонці ми поговоримо про загальні тренди розвитку Wi-Fi. До зустрічі через тиждень!

Бажаєте більше?

До вашої уваги – ще більше технічних статей плюс професійні спільноти GlobalLogic, що діють у Facebook:

Приєднуйтесь!

На вашу думку, без чого сьогодні складно уявити життя та ефективну роботу? Смартфони? Соцмережі? Додатки? Так, але це все не має сенсу без домашнього інтернету та Wi-Fi!

Ми розпочинаємо цикл публікацій, де ми розберемо сучасний стан речей у галузі, проаналізуємо тренди, визначимо, чого слід очікувати користувачам у близькому майбутньому та чим може похвалитись на цьому полі GlobalLogic.

Поїхали!

Розділ І. Обладнання

У першій колонці ми поговоримо про обладнання: яке буває, чим відрізняється та які виклики зараз існують на ринку.

Сьогодні на ринку є величезна кількість роутерів від різних виробників. В Україні користувач звик або самостійно обирати роутер для покупки, або це робить комп’ютерний майстер, який встановлює інтернет.

З цього витікає наступне: коли сталась якась несправність, чи треба змінити налаштування мережі або роутера, в користувача не так багато варіантів. Можна запросити того ж комп’ютерного майстра або звернутись до оператора, який надає послугу інтернет-зв’язку. І все одно він відправить до користувача додому фахівця, який буде все це налаштовувати руками.

Проте є інший шлях існує! Окрім роутерів, які можна придбати у магазинах, є ще керовані роутери – це роутери, які телеком-оператор надає своїм абонентам. В Україні це рідке явище, проте в інших країнах це популярне рішення.

Чим такі роутери відрізняються від тих, що можна купити у магазині?

  • Роутери від оператора є інтегральною частиною мережі провайдера. Це означає, що провайдер має до них віддалений доступ, відповідає за сервіс, налаштування та заміну. Як правило сам роутер є частиною пакету послуг і надається безкоштовно або за невелику абонентську плату.
  • Автоматичне налаштування. Інженер, який встановлює роутер, вводить певний код або сканує QR код, і всі подальші налаштування, разом з оновленням програмного забезпечення, відбуваються автоматично.
  • Вони мають опцію автоматичного оновлення програмного забезпечення.
  • Розширений функціонал. Оператор має доступ до функцій, які користувач через веб-інтерфейс просто не бачить.
  • Тісна інтеграція між провідним та мобільним інтернетом. Є багато моделей, які мають мобільний резервний канал: 3G, 4G, 5G. Є моделі, які розраховані виключно на мобільне використання. Мобільні оператори намагаються використати це як перевагу для покращення якості та стабільності сервісу.
  • Мають інтегровані рішення з безпеки та батьківського контролю.

    Підтримка інших послуг оператора як то IPTV, відео на вимогу чи елементи розумного будинку.

Виклики

Звісно, що є ряд труднощів та викликів. Втім, будь-які виклики розробники програмного забезпечення намагаються перетворити на нові сервіси.

Основними викликами на сьогодні є:

  • Кількість даних, які передаються, збільшується вдвічі кожного року, а плата за послуги росте набагато повільніше.
  • Більшість користувачів оцінюють якість послуг оператора виключно за якістю Wi-Fi.
  • Часто один оператор використовує десятки моделей пристроїв від різних виробників. Тож, коли в нього виникає потреба внести якусь зміну, йому потрібно замовляти цю зміну кожного з виробників, а пізніше провести тестування кожної моделі. Саме тому оператори намагаються зменшити модельний ряд пристроїв, які вони підтримують та уніфікувати його.
  • У період глобальних обмежень багато користувачів перейшли на віддалений режим роботи з дому. Суттєво зросли очікування щодо якості домашнього інтернету та підтримки бізнес функцій таких як, наприклад VPN.
Тренди

Сьогодні на ринку існують такі тренди:

  • Перехід на уніфіковане програмне забезпечення. Це полегшить впровадження нових моделей та перенесення сервісів з однієї моделі на іншу, а також зменшить витрати на розробку. Тут найдалі просунулися проєкти з відкритим кодом RDK-B та OpenWrt/prpl (про це докладніше ми поговоримо в наступній публікації).
  • Mesh-мережі для Wi-Fi. Це інтелектуальні системи, що складаються з роутера та ретрансляторів, які разом централізовано керують Wi-Fi мережею.
  • Хмарні рішення. Існує багато моделей, які керуються виключно з хмарного інтерфейсу. Клієнт може налаштувати свою мережу, переглянути статистику, рахунки, тарифні плани прямо на сайті оператора.
  • Домашня автоматизація. Тут бракує єдиного стандарту, проте є хороші напрацювання у сфері безпеки, а також інтеграція зі штучним інтелектом. Це дозволяє впроваджувати домашню автоматизацію, використовуючи наявну інфраструктуру.
  • Гігабіт. Провідні оператори вже сьогодні пропонують гігабітні пакети. Через деякий час це стане стандартом де-факто. В розробці є моделі, які підтримують 2.5 Гб, очікуємо появу 10 Гб в недалекому майбутньому.

Стисло – це все про сучасний стан речей у темі роутерів та обладнання. У наступній колонці ми поговоримо про OpenWrt. Не перемикайтесь!

Бажаєте більше?

До вашої уваги – ще більше технічних статей плюс професійні спільноти GlobalLogic, що діють у Facebook:

Приєднуйтесь!

Продовжуємо розбиратись з мікросервісною архітектурою! У минулій статті ми розглянули терміни, без яких неможливо зробити перші кроки в цій галузі.

Загалом архітектура мікросервісів досить проста. Це лише паттерн, який веде нас через процес застосування інших архітектурних паттернів відповідно до best practice та принципів. Однак сама реалізація вимагає знання деяких тем, які слід мати на увазі ще до початку розробки. Ми не будемо заглиблюватися в деталі, оскільки ці теми вимагають глибокого занурення, і їх неможливо висвітлити в одній статті. Натомість ви можете самотужки дізнатись про них більше, якщо ви знаєте що та де шукати.

Міжсервісна комунікація
Стратегія

Комунікаційні та мережеві аспекти – це перше, про що нам слід подумати, коли ми потрапляємо в область розробки розподілених систем. Зокрема ми поговоримо про міжвідомче комунікацію, що відрізняється від міжпроцесорної комунікації.

Основні стратегії комунікацій

Існують різні мережеві протоколи високого та низького рівня, які можна використовувати як разом, так і окремо. Однак насамперед слід визначити загальну комунікаційну стратегію. Основні комунікаційні стратегії діляться на чотири типи, продемонстровані на схемі вище.

Це:

  • Блокуючий та синхронний
  • Блокуючий та асинхронний
  • Неблокуючий та синхронний
  • Неблокуючий та асинхронний

Якщо взяти усі доступні технології, нанести їх на схему вище, отримаємо візуальний інструмент, який підкаже, які технології нам підходять, а які ні. Достатньо лише видалити зі схеми всі технології, що нам не підходять.

API

В рамках вибору комунікаційної стратегії, REST/HTTP та GraphQL – це базові протоколи, які зазвичай використовуються для надання високорівневих API для web. В будь-якому випадку дизайн високорівневих API вимагає чіткого розуміння best practice щодо API Management.

Для новачків важливим є розуміння концепцій API Gateway та версіонування API. Розуміння паттерну API-Led Connectivity – це відправна точка для глибокого занурення в організацію низькорівневих API та підсистем.

Відмовостійкість

В архітектурі мікросервісів відмовостійкість не сильно відрізняється від загальноприйнятих практик розподілених систем. Однак я вважаю, що варто почати з питань відстеження затримок (latency) та обробка помилок й виключних ситуацій.

Тут варто подумати про:

  • Timeout – щоб гарантувати час відповіді
  • Retry – для автоматизації повторних спроб у випадку деградації мережі
  • Circuit Breaker – для контролю у випадку виникнення каскадних помилок
  • Deadline – для контролю довгих запитів, що залежать від багатьох сервісів
  • Rate Limiter – для контролю навантаження згідно з SLA (Service Layer Agreement)
Консистентність даних

На відміну від моноліту, у нас також немає єдиної бази даних. Робота з кількома джерелами даних вимагає механізму керування розподіленими транзакціями. Але зазвичай розподілені транзакції не використовуються в архітектурі мікросервісів. Причина полягає в тому, що

а) використання існуючих рішень обмежує нас за підтримуваними технологіями;
б) побудова власної системи обробки розподілених транзакцій може бути дуже складною, і знову ж буде обмежена в підтримці технологій і може вимагати значних зусиль з технічного обслуговування.

Натомість мікросервіси використовують подієво-орієнтований підхід доступний для імплементації у двох моделях: оркестрація та/або хореографія.

Транзакції

Перш за все, перестаньте думати про транзакції у базах даних. Подумайте про бізнес транзакції. В економічних організаціях транзакції бізнес-процесів виконуються у подієво-орієнтованій манері. Приклад.

Коли ви купуєте чашку кави, у цьому процесі, транзакції з базою даних не беруть участь. Ви платите гроші і чекаєте в черзі, поки не отримаєте повідомлення про те, що ваша кава готова. Якщо щось піде не так, ви просите компенсацію і або отримуєте вашу каву або повертаєте гроші. Іншими словами, це архітектура, керована подіями (Event-Driven Architecture).

Події

Існує дві логічні сутності: події та повідомлення. Вони відрізняються логічно так же, як шина подій (event bus) від черги повідомлень (message queue). Треба розрізняти логічну різницю між цими термінами.

Повідомлення (message) є частиною систем, заснованих на брокерах повідомлень (message broker), де повідомлення відправляється в чергу/топік, враховуючи, що отримувач (consumer) отримає його та щось зробить. Ця модель називається “fire and forget”.

Події дещо відрізняються від повідомлень. Повідомлення може бути чим завгодно (число, текст, JSON тощо). Події, своєю чергою, є логічно закінченою контекстною інформацією і повинні мати чітко визначену структуру (наприклад, JSON). Події також можна зберігати в системі до конкретного часу для повторного використання (event replay) або аудиту.

Шини подій зазвичай відповідають за зберігання/стрімінг/обробку подій, саме цим вони відрізняються від брокерів повідомлень. Наприклад, Kafka проти RabbitMQ.

Паттерни

Існують загально вживані паттерни, які використовуються для імплементації подієво-орієнтованих мікросервісних систем.

Наприклад:

  • Event Sourcing – для збереження стану програми в серії подій
  • CQRS – щоб скористатися перевагами розділенням моделей читання та запису
  • SAGA – для забезпечення глобальної консистентності даних використовуючи послідовність локальних транзакцій
  • Event Streaming – для застосування принципів обробки потоків до подій
Інфраструктура

Мікросервісна архітектура може стати дуже складною, тому керування інфраструктурою та застосування DevOps best practices є важливими на всіх етапах розробки.

Розробка масштабованого (scalable) та високодоступного (high-available) мікросервісного рішення може потребувати багато зусиль. В тому числі складно підтримувати систему де є сотні мікросервісів.

Event-driven domain-based decoupling

Одним зі шляхів подолання такої ситуації є застосування домено-орієнтованого декаплінгу, який базується на групуванні мікросервісів по бізнес-домену (контексту). Такі системи поділяються на менші ділові домени (контексти), які взаємодіють через шину подій. Усередині кожного домену (контексту) сервіси можуть взаємодіяти між собою або через API, або через шину подій. Однак сервіси не мають прямого доступу до API сервісів інших доменів, вони можуть спілкуватися з ними лише через шину подій. Як результат, побудовані підсистеми менше за розміром і є більш керованими в сенсі підтримки та обслуговування.

У будь-якому випадку (багатодоменний або ні), в мікросервісній архітектурі вам доведеться мати справу з такими темами, як:

  • Code Repositories — mono-repo проти multi-repo
  • Deployment Strategies — включаючи топологію оточення (dev, qa, uat, prod) та deployment стратегії (blue-green, canary, тощо).
  • Автоматизація – включаючи оркестрацію кластера, Service Mesh, CI/CD.
  • Загальні проблеми (Common Concerns) – контейнеризація, оркестрація, конфігурація, безпека, моніторинг, логування, трейсінг, кешування, комунікації тощо.
  • Тестування – e2e, інтеграційне, contract-driven тощо.
Висновок

Як бачите, концепція мікросервісної архітектури має багато тем для вивчення. Ми побачили лише верхівку айсберга. Залежно від типу вашого додатку, можливо, вам буде корисно дізнатись також про:

  • best practices рефакторінгу монолітів до мікросервісів
  • платформ обробки даних (Data Platform, Data Lake)
  • різні event-driven архітектури

Тож не соромтесь, задавайте питання, співпрацюйте та підтримуйте зв’язок! Де та як?  До вашої уваги – професійні спільноти GlobalLogic, що діють у Facebook:

Приєднуйтесь!

Минуло досить багато часу з моменту останнього оновлення в Scrum Guide (а ось тут – українська версія).  І ось воно! Нова версія, яка з’явилася у листопаді 2020 року, принесла цікаві зміни. На мій погляд, ці нововведення вносять більше гнучкості в процес. У цій колонці пропоную покроковий огляд оновлень.

Ще менш наказовий

З роками посібник зі Scrum почав ставати дедалі жорсткішим, тобто вказував, ЩО робити і ЯК. Версія 2020 року має на меті повернути Scrum до попередньої гнучкости шляхом вилучення або пом’якшення наказового тону. Наприклад, було видалено щоденні запитання Scrum, пом’якшено настанови щодо атрибутів PBI в product backlog, пом’якшено настанови щодо елементів з ретроспективи у backlog спринту, скорочено розділ стосовно скасування спринту, тощо.

Що це означає?

Фактично, зараз існує стільки ж імплементацій scrum, скільки й продуктів, які використовують цей фреймворк як основний підхід до розробки продуктів. Вищезгадані зміни роблять фреймворк гнучкішим. Як саме? Розбираємось нижче:

  • Використання щоденних запитань Scrum не є обов’язкове. Важливо, щоб люди чули одне одного, ділилися думками та звертались за допомогою, якщо це потрібно. Є багато шляхів побудувати бесіду в команді, і ми не повинні обмежуватися питаннями “Що я зробив”, “Що я буду робити” та “Які в мене перешкоди”.
  • Якщо ми говоримо про Product Backlog Items (PBI), то це завжди гарна ідея мати достатній рівень деталізації, естімейтів, важливості для бізнесу тощо. Однак важливо, щоб це відповідало потребам бізнесу та сферам діяльності. Як результат, PBI можуть містити згадані атрибути, але не бути обмеженими ними. Пом’якшення атрибутів PBI – це розширення гнучкості та уникнення заклику до жорстких порядків.
  • Ретро-елементи зараз є більш абстрактні. Автори повідомляють нам лише те, над якими ключовими аспектами слід працювати під час ретроспективної зустрічі. Існують десятки інструментів, які дозволяють нам обрати найкращий підхід до ретроспективи, роблячи цю церемонію найефективнішою для команди. Загалом це призводить до зменшення рекомендацій щодо того, хто що повинен робити, і більшого зосередження на результатах.
  • Скорочення інших частин у Scrum Guide надає більшої прозорості та не перевантажує опис процесу з очевидними наслідками, якщо сталася якась дія, наприклад “Скасування спринту”.
Єдина Команда фокусується на Єдиній Меті

Метою було усунення концепції “команди в команді”, яка призводить до поведінки “проксі” або “ми й вони” між Власником Продукту та Командою Розробників. Зараз є лише одна Scrum Команда, яка зосереджена на єдиній меті, з трьома різними рівнями відповідальності: Власник Продукту, Scrum Master та Розробники.

Що це означає?

У попередній версії не було виокремлено жодної підгрупи і лише розробників винесли в підгрупу, і нарешті цей підхід додано на рівень всієї команди Scrum. Найперша ліквідація поведінки “ми й вони” відбулася у 2011 році, коли вилучили посилання на концепт курей та свиней. І зараз це логічне продовження скасування поділу Product Owner та Dev Team (Власник Продукту та Команди розробників). Розмір команди зараз відноситься до Scrum Team, а не лише до розробників. Окрім того, версія 2020 року радить, але не обмежує наявність до 10 людей у ​​Scrum Team, пояснюючи чому маленькі команди працюють краще.

Такі зміни повинні забезпечити більше контролю над процесом та продуктом Scrum командою. Чим тісніше працює Scrum команда, тим краща співпраця аби створити справді круті продукти.

Впровадження Цілі Продукту

Посібник зі Scrum 2020 запроваджує концепцію Цілей Продукту, щоб забезпечити фокус Scrum Команди задля досягнення більшої мети. Кожен спринт повинен наближати продукт до його фінальної цілі.

Що це означає?

Мабуть, найважливішою зміною є введення цілі продукту в загальну концепцію структури. У наш час Scrum застосовується в багатьох сферах, які вийшли далеко за межі розробки програмних продуктів, де він сягає своїм корінням. Також продукт може бути послугою, фізичним товаром або чимось більш абстрактним, і, залежно від очікуваних результатів, у багатьох підходах це може розглядатися як проміжний результат для тих продуктів, які випускаються й доповнюються поступово.

“Ціль продукту” описує його майбутній стан. Дуже важливо дотримуватися визначеної мети, щоб постійно перевіряти, чи команда Scrum розробляє продукт який очікуєтьсяТакож Scrum команда може обрати неправильний шлях і приректи продукт на провал, якщо не буде звірятися з кінцевими цілями.

Місце для Цілей спринту, Визначення Готової Роботи та Цілей Продукту

Попередні посібники зі Scrum описували Ціль спринту та Визначення Виконаної Роботи (Definition of Done), не даючи їм справжньої ідентичності. Вони були не зовсім артефактами, але були дещо пов’язані з артефактами. Завдяки тому, що було додано Ціль Продукту, версія 2020 надає більше ясності. Кожен із трьох артефактів тепер містить „зобов’язання” щодо них: для product backlog ‐ Ціль Продукту, для backlog спринту ‐ Ціль спринту, а для Інкременту – Визначення Виконаної Роботи. Вони існують для забезпечення прозорості та зосередженості на прогресі кожного артефакту. 

Що це означає?

Зобов’язання – це готовність наполегливо та енергійно працювати та віддавати час на роботу чи діяльність. Створення артефакту повинно диктуватися бажанням досягти конкретних цілей. І завдяки “зобов’язанню” ми можемо провести одну лінію від Product Backlog Item до бажаного стану нашого продукту.

Самокерування та Самоорганізація

Попередні посібники зі Scrum називали Команди Розробників (Dev Team) самоорганізованими, вони могли обирати хто і як виконує роботу. Версія посібника зі Scrum 2020 року з фокусуванням на Scrum Команді підкреслює, що саме ціла Scrum Команда здатна до самоврядування, та може обирати хто, як і над чим буде працювати.

Що це означає?

Залучення Product Owner та розробників до єдиної команди Scrum надає можливість згладити всі рівні розробки продукту, покращуючи процес планування того, що потрібно враховувати під час майбутньої розробки.

Три речі до Планування Спринту

На додаток до “Що” та “Як” у Плануванні спринту, посібник зі Scrum 2020 акцентує на третій речі “Чому”, посилаючись на Ціль спринту.

Що це означає?

Ідея проста. Під час планування спринту Product Owner пропонує, як товар може збільшити свою цінність у поточному спринті. Потім вся команда Scrum співпрацює для визначення цілі спринту, яка відповідає питанню чому цей спринт цінний для зацікавлених сторін.

Порядок планування спринту: Чому -> Що -> Як

Насправді це ще одна можливість переконатись, що поточна ціль спринту спрямована на те, аби зробити продукт ще крутішим. Також такий тип планування поєднує точки між ціллю спринту та ціллю продукту.

Висновки

Загальне спрощення мови для ширшої аудиторії. У посібнику зі Scrum 2020, акцент зроблено на усуненні зайвих та складних тверджень, а також на усуненні специфіки роботи в ІТ (наприклад: тестування, система, дизайн, вимоги, тощо). Зараз посібник зі Scrum складається з менш ніж 13 сторінок (в оригіналі).

У новій версії мова є менш наказовою, оскільки, виходячи із сучасних реалій та широкого використання Scrum, основні елементи Scrum повинні бути контекстно-залежними та залежати від конкретних продуктів чи умов, а не працювати як комплексне рішення, яке може не відповідати іншим продуктам.

Бажаєте дізнатись про Scrum більше? Пропонуємо переглянути цикл статей про Ролі у Scrum від Андрія Кульшана, Business Analyst, Product Owner, Consultant, GlobalLogic та Олександри Скібіної, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic!

  1. Ролі у SCRUM: Епізод І. Сходження Product Owner’а
  2. Ролі у SCRUM: Епізод II. Повернення Scrum Master’а

Гарного читання!

Одним з етапів процесу завершення співпраці є проведення exit-інтерв’ю. Для того, щоб цей HR інструмент був ефективним та сприяв впровадженню позитивних змін в компанії, важливо знати, як правильно проводити exit – інтерв’ю, які є особливості та нюанси та що робити далі, щоб зібрані дані перетворювались в конкретні результати. Щоб отримати відповіді на всі ці питання – читайте нижче!

Що таке exit – інтерв’ю?

Одним з фінальних кроків в employee journey (шлях співробітника від початку співпраці до її завершення) є проведення exit –  інтерв’ю. Exit – інтерв’ю – це зустріч, яку проводить HR менеджер зі спеціалістом, який прийняв рішення припинити співпрацю з компанією.

Цілі exit – інтерв’ю та чому важливо їх проводити?

Exit – інтерв’ю мають кілька цілей:

  • Можливість отримати чесний фідбек від фахівця і зрозуміти справжню причину розриву співпраці. Офіційна причина часто може відрізнятися від справжніх мотивів. Побудувавши правильно розмову й ставлячи правильні питання (нижче обговоримо їх список), HR менеджер може отримати правдиву й чесну відповідь, що саме змусило людини прийняти рішення піти.
  • Виявити, що можна поліпшити в процесах компанії, де є вузькі місця, що змушують людей приймати рішення про припинення співпраці й зменшити кількість подібних ситуацій в майбутньому.
  • Exit – інтерв’ю дає не тільки можливість проаналізувати, де компанія може поліпшити свої процеси, а й отримати рекомендації та зібрати цінні ідеї від спеціаліста, як це можна виправити.
  • Знизити емоційне напруження в настрої спеціаліста й створити фундамент для можливої співпраці в майбутньому.
  • Іноді рішення може бути спонтанним і емоційним, тому exit – інтерв’ю може дати можливість змінити намір людини. Якщо ж рішення все-таки остаточне, то в ході інтерв’ю варто обговорити перспективи подальшої співпраці – запрошення в alumni спільноту, можливість повернутися в компанію. У разі ж негативного настрою, exit-інтерв’ю дозволяє вирівняти емоційне напруження і розійтись, не спалюючи мости.
  • Отримати фідбек про ефективність безпосереднього менеджера. Цей фідбек дозволяє компаніям зміцнювати і заохочувати менеджерів, орієнтованих на розвиток і виявляти тих, чия поведінка не відповідає культурі компанії.
  • Узгодити фінальні зобов’язання обох сторін. З боку компанії – це можуть бути гарантії належних компенсацій, надання рекомендацій, для спеціаліста – дотримання договору конфіденційності, положень про інтелектуальну власність і т.д.
  • Вивчення пропозицій (пакета компенсацій, бонусів, тощо) інших компаній. Ця додаткова інформація дозволяє проаналізувати, наскільки компанія є конкурентна стосовно інших гравців на ринку.
  • Отримати рекомендації в пошуку заміни. Якщо людина припиняє співпрацю з компанією в позитивному настрої, то, цілком ймовірно, що він також буде готовий порекомендувати когось зі знайомих або друзів на вакантну позицію.
Хто проводить інтерв’ю?

Як уже згадувалося, exit – інтерв’ю проводяться, як правило, HR менеджерами.

Коли є сенс залучити інших спеціалістів? Іноді залучають сторонніх експертів – це варто робити, коли ви співпрацюєте з компаніями, які надають послугу з аутплейсменту. Ще один варіант – коли таке інтерв’ю може проводити особисто генеральний директор або керівник, на рівень вище безпосереднього менеджера.

Водночас проведення exit – інтерв’ю за участю безпосереднього менеджера зустрічається рідше, але така розмова може не дати можливість отримати об’єктивну інформацію через наявність прихованих інтересів обох сторін, конфліктів та інших аспектів.

Як проводити?

Exit-інтерв’ю рекомендується проводити, коли рішення припинити співрацю вже прийнято і процес вже запущений, але не пізніше, ніж за тиждень до останнього дня співпраці. Це дасть можливість знизити емоційність в настрої, але при цьому розмова все ще буде актуальною. На ринку є практики, коли exit-інтерв’ю проводять через місяць або більше після виходу фахівця з компанії. Такий підхід створює максимально комфортні умови та дає можливість отримати чесний та повний фідбек від фахівця.

На думку більшості експертів, найбільш ефективний формат, що дозволяє налагодити контакт з людиною – це особиста зустріч, але можливе й телефонне exit-інтерв’ю. Вибір структурованої зустрічі або вільної розмови залежить від компетенції фахівця, проведеного інтерв’ю, характеру розриву співпраці та інших чинників, бо структуровані питання можуть не підсвітити несподівані й корисні деталі, які можуть спливти при вільному спілкуванні.

Що важливо не забути запитати на exit – інтерв’ю?

Наведемо кільки можливих питань для exit – інтерв’ю:

  • Чому ви йдете з компанії?
  • Що спонукало шукати пропозиції в інших компаніях?
  • Чого не вистачило в нашій компанії?
  • Що нам варто поліпшити?
  • Чи є у вас якісь ідеї / пропозиції, як можна це покращити?
  • Як складалися відносини з безпосереднім керівником / колегами?
  • Чи було чітке розуміння, як можна розвиватися всередині компанії?
  • Якби ви могли залишитися, що б змінили в процесах?
  • Що могло б спонукати вас повернутися в компанію?
  • Що також тримати в фокусі?
Підготовка

Як і до будь-якого виду інтерв’ю, до exit-інтерв’ю варто готуватися – вивчити профайл людини, зібрати попередню інформацію від безпосереднього керівника і колег, розуміти контекст припинення співпраці.

  • Атмосфера та етика. Перш за все, завдання інтерв’юера створити комфортну атмосферу для спілкування. Активне слухання, увага, чесність та відкритість допоможуть сформувати позитивний хід інтерв’ю. Не треба намагатись переконати або спростувати аргументи співрозмовника.
  • Слухайте, ставте питання і знову слухайте. Якщо під час інтерв’ю потрібно робити позначки, важливо попередити людини для чого і що ви збираєтеся записувати.
  • Конфіденційність. Exit – інтерв’ю повинно бути строго конфіденційним й співрозмовник повинен бути впевнений в цьому.
  • Спеціаліст має право відмовитися від участі, але якщо exit – інтерв’ю відбулося, подякуйте людини за час, співпрацю й готовність надати фідбек.
  • Крім самого exit – інтерв’ю, можливе використання також анкетування та збору додаткової інформації за допомогою анкети зворотного зв’язку. Формат таких опитувань не завжди однаковий – від автоматизованих анонімних питань через спеціальні програми (наприклад, Glint) до стандартних Google – форм.
А що робити далі? Як використовувати дані exit-інтерв’ю?

Роботу з результатами можна розділити на два напрямки:

  • Зворотний зв’язок безпосередньому менеджеру – показати, де є вузькі місця, можливі проблеми в команді або з менеджментом, звернути увагу на ризики, які можуть спровокувати розрив співпраці в майбутньому. При цьому також варто відзначити, що було позитивного з точки зору фахівця, які сильні сторони компанії / проєкту.

  • Збір інформації для поліпшення процесів компанії в цілому – ґрунтуючись на даних з анкет exit-інтерв’ю та інформації, отриманої в ході самих зустрічей, HR команда може ініціювати перегляд і коригування тих чи інших процесів. Аналіз таких даних важливо проводити з певною регулярністю (раз на місяць, квартал і т.д.) для того, щоб вчасно реагувати на наявні проблеми в компанії.

Як зробити інтерв’ю ще ефективнішим?

10 порад і підказок, як можна поліпшити практику проведення exit-інтерв’ю. Усе, що проговорили вище у вигляді списку порад, аби ви могли легко перевірити себе перед інтерв’ю.

  1. Чесно проговорити мету зустрічі й чому важливий ця бесіда.
  2. Конфіденційність.
  3. Проговорити про цінність зустрічі для фахівця – залишити позитивний настрій на майбутнє, приєднатися в alumni спільноту або навіть можливість поновити співпрацю.
  4. Важливо систематизувати, обробити й використати отримані дані. Перетворюючи отриману інформацію в цифри, HR менеджери можуть ефективно аргументувати необхідність впровадження змін в процесах компанії й розмовляти з менеджментом на “мові цифр”.
  5. Помилкою буде вважати, що HR знає справжню причину припинення відносин з компанією.
  6. В ході інтерв’ю не намагайтеся запевнити, що виправите проблему і прийміть якісь заходи. Натомість – запитайте фахівця, яке його пропозицію, як можна поліпшити наявну проблему.
  7. Для великих компанії з представництвами в різних локаціях для стандартизації збору даних краще використовувати єдину анкету для exit-інтерв’ю для всіх локацій.
  8. Додатковим інструментом, який можна використовувати для збору даних від спеціалістів – анкети зворотного зв’язку для тих, хто повторно почав співпрацювати з компанією. Це дасть можливість отримати фідбек, що в компанії стало краще/гірше з моменту розриву співпраці, а що можна поміняти/поліпшити зараз.
  9. В ході інтерв’ю, особливо в конфліктних і складних ситуаціях, завжди зберігайте етичний підхід спілкування.
  10. Дійте позитивно, дайте спеціалісту зрозуміти, що ви відкриті для співпраці в майбутньому.

Головне – пам’ятати, що успіх роботи будь-якого інструменту залежить від вмілого та правильного його використання. Сподіваюсь, стаття допомогла розібратись з основними аспектами та нюансами при провадженні практики exit – інтерв’ю.

Бажаємо вам змістовних та продуктивних інтерв’ю!

Хочете дізнатись більше про інтерв’ю? Тоді пропонуємо вам переглянути такі статті:

    1. Як успішно пройти інтерв’ю з клієнтом? Поради менеджера

Автор: Олександра Cкібіна, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic Ukraine

Сьогодні багато компаній в Україні та Європі надають послуги за моделлю outsource. А це означає, що крім технічного інтерв’ю з рекрутерами і фахівцями компанії, вас може чекати ще й спілкування безпосередньо з менеджментом і технічними експертами на стороні клієнта. Ця колонка містить рекомендації, як успішно подолати цей етап!

  1. Always put your best foot forward, або Як Trainee пройти перше в житті інтерв’ю — 10 порад

Автор: Катерина Сич, Associate Recruiter, Consultant, GlobalLogic Kharkiv

Для багатьох процес інтерв’ю може бути бентежним, особливо – якщо ви Trainee у пошуках першого реального проєкту. У цій статті ми зібрали 10 основних моментів, на які слід звернути увагу, аби уникнути непорозумінь під час першого важливого етапу у кар’єрі.

Традиційно GlobalLogic багато уваги приділяє взаємодії з аудиторією, а саме – ком’юніті. Наприклад, професійні спільноти, які ми створили у Facebook минулого року:

Крім того, що це майданчик для цікавого, корисного та комфортного спілкування професіоналів різного рівня, це ще й джерело авторського контенту, яким ми з задоволенням ділимось з нашими читачами. Наприклад, стаття-гайд CI/CD для JS розробників. Чи поради з технічного інтерв’ю з Java-інженерами.

З чого все почалось

Проте, інколи хочеться не занурюватись у технологічні чи професійні питання, а просто обговорити якісь новини чи провести весело час разом. Для цього існує безліч внутрішніх спільнот, від поціновувачів моделювання до геймерів. Саме про останніх ми хочемо розказати сьогодні – це гарна історія, як люди, які прагнули чогось, зуміли дуже швидко самоорганізуватись та досягти своєї мети.

Як будь-яка магічна історія, ця бере свій початок напередодні новорічних свят. В одного із консультантів GlobalLogic Lviv Сергія Горошка, Test Engineer, Quality Assurance, Consultant, виникла ідея створити спільноту, яка об’єднає усіх любителів комп’ютерних ігор.

Пандемія внесла свої корективи у повсякденне життя людей. Насамперед нема змоги зустрітись великою спільнотою офлайн. То що робити? Треба знайти майданчик для онлайн спілкування! Навколо ідеї об’єднались представники менеджменту, команди маркетингу та People Team. Всього за 10 днів було створено GL Game Community та проведено першу гру напередодні Нового Року.

Слово ініціатору та ідеологу цієї справи, Сергію Горошко, Test Engineer, Quality Assurance, Consultant:

  • Ідея говорила сама за себе ще за часів першої гри в L4D, під час якої я знайшов однодумців. Ми почали спілкуватися, грати, потім дружити. Community – хороший спосіб знайти новий інтерес чи поділитися досвідом, можливо чогось навчитися. Спільнота насправді може більше, тому що її будують люди! – Сергій Горошко, ініціатор та лід GL Game Community у Львові.
Чому вдалось зібрати людей так швидко?

Як годиться, все почалось з оцінки та планування. Ідеологи спільноти провели дослідження серед консультантів львівської локації GlobalLogic, та проаналізували результати  щодо їх зацікавленості та вподобань у геймінгу. Після того – провели спеціальну комунікацію щодо створення ком’юніті разом з анонсом першої колективної гри. Критична маса геймерів зібралась, під’єдналась до сервера та чудово провела час.

Сьогодні GlobalLogic Game Community – спільнота, яка налічує близько 200 учасників та функціонує на платформі Discord. Спільнота побудована з п’яти основних розділів:

  • привітальна частина з правилами та загальним описом;
  • новини, де публікуються останні зміни чи майбутні події;
  • основний блок з кімнатами за інтересами, де кожен може поділитися своїм досвідом чи поставити питання до спільноти;
  • секція з ігровими чатами, які розділені на жанри та платформи;
  • ігрові голосові чати, які мають мітинг-кімнати.

На цей час спільнота продовжує ділитися цікавими ідеями та планує зібрати більше охочих за інтересами.Також було додано можливість local events де кожний охочий може зібрати свій захід власноруч.

Чому ми навчились завдяки GlobalLogic Game Community?

Ця історія, на перший погляд, може здаватись доволі простою. Проте, вона свідчить про те, що створити спільноту за інтересами не важко, для цього не завжди потрібні якісь спеціальні люди чи досвідчені модератори. Якщо ви маєте тему, яка цікавить та об’єднує багатьох людей, то важливо зробити перший крок – визначитись з аудиторією. А потім – лише сформулювати вірний меседж до неї! А спільнота людей – це сила, повторімо ще раз тезу Сергія Горошко.

Бажаємо  успіхів у побудові!

Автор: Орхан Гасімов, Senior Solution Architect, Consultant, GlobalLogic

Мікросервісна архітектура існує вже деякий час. Проте є багато людей, які шукають матеріали, з яких можна почати та дізнатися про неї більше. Попри велику кількість доступних книг та статей, важко знайти стартову точку для швидкого старту. Ввідний матеріал для менеджера, інженера чи архітектора, будь-кого. Саме тому я вирішив написати цю статтю, в якій я наведу список базових принципів і торкнуся тем, які вам потрібно вивчити якщо ви хочете отримати поглиблене розуміння мікросервісної архітектури.

Що таке мікросервіс?

Мікросервіс – це найпростіша одиниця, сервіс, який приймає вхідні запити для здійснення дії. Це може бути бекенд сервіс, який доступний цілодобово та без вихідних, або функція, яка викликається, коли відбувається подія. Простими словами, функція або набір функцій, доступних через певний API через мережу. Отже, це бекенд служба, розгорнута на сервері. У якомусь сенсі це монолітний додаток. Однак він не несе в собі всю функціональність системи, а лише меншу частинку логіки. На відміну від моноліту, отриманий додаток побудований як набір відносно невеликих незалежних служб, що називаються «мікросервісами», які комунікують через комп’ютерну мережу. Можна сказати, мікросервіси – це ті самі логічні модулі монолітного додатка, які розподілені через комп’ютерну мережу, замість того, щоб працювати в рамках одного процесу (пристрою).

Типова довідкова архітектура мікросервісного веб-додатку

Мікросервіси зазвичай структуровані ярусами. Не існує правил щодо того, скільки і яких ярусів має бути, однак, є найкращі практики. На діаграмі вище можна побачити найпоширеніші яруси, що використовуються в подібних архітектурах. Назви можуть відрізнятися, але структура дуже схожа на класичну багатоярусну архітектуру. Логічні яруси, які ми бачимо:

Front-End — Client Application, Static Content
Back-End — API Gateway, Experience Microservices, Domain Microservices
Data & Integration — Data Stores, Integration Interfaces / Connectors

Розглянемо кожен ярус і опишемо, за що він відповідає.

Логічні яруси
  • Клієнтська програма

У випадку веб-програми, клієнтом, як правило, є веб-браузер. Дехто вважає, що клієнт – це UI, але це не так. Браузер – це клієнт, який завантажує статичний контент із віддаленого сервера і рендерить UI всередині себе. І він же є клієнтом, що обробляє фізичні HTTP запити ща надходять до сервера. Важливо розрізняти клієнт та контент. Особливо, якщо ви розробляєте micro-app frontend.

Клієнт (веб-браузер) взаємодіє з Backend, щоб рендерити UI та викликати API.

  • Статичний контент

Найкраща практика – розділити відповідальність шляхом роз’єднання логічних компонентів, щоб жоден компонент не відповідав за все. З цієї причини рекомендується подавати статичний контент через окремий серверний компонент. Це дозволяє відокремлювати статичний контент від API. Кілька важливих принципів, на які потрібно звернути увагу, – це server-side rendering, кешування та контроль доступів.

  • API Gateway

API Gateway – це центральні двері для всіх публічних API. Це єдина точка входу для так званих Experience APIs, доступних для клієнтських програм, і є важливою складовою найкращих практик управління API (API Management). По суті, він передає запити реальним бекенд сервісам та здатен приймати рішення. Частіше за все, API Gateway відповідає за такий функціонал, як:


  • Request handling
  • Upstream (або downstream) data transfer (або transformation)
  • Access control
  • Security policies
  • Throttling
  • Rate limiting
  • Analytics
  • Caching

  • Experience мікросервіси

У неструктурованому розподіленому середовищі дуже легко втратити контроль над множиною мікросервісів. З цієї причини рекомендується контролювати мікросервіси, структуруючи їх за ярусами. Існують різні архітектурні шаблони, які можуть допомогти. Загальним для цих шаблонів є те, що всі вони зосереджені на experience.

Experience сервіси покладаються на доменні сервіси, що знаходяться на нижчому ярусі.

Уявіть набір мікросервісів, які надають API вищого рівня, орієнтовані на клієнтський досвід, повторно використовуючи низкорівневі гранулярні API, доступні в системі. Наприклад, різні продукти, що постачаються для веб- і мобільних клієнтів (Experience), можуть використовувати різний набір experience API, представлених незалежними мікросервісами за API шлюзом (API gateway).

Ці мікросервіси утворюють experience ярус, який логічно відокремлений від інших ярусів. Він може бути керований та налаштований (масштабований, налаштований, захищений тощо) незалежно. Зверніться до архітектурних паттернів API-Led Connectivity та Backend For Frontend, щоб глибоко заглибитися у зв’язані концепції.

  • Доменні мікросервіси

Доменні мікросервіси – це більш нижчий ярус, що відповідає за бізнес-логіку та від якого залежать experience сервіси.

Таким чином experience сервіси сфокусовані на користувачі та продукті, в той час, коли доменні мікросервіси відповідають за дані та ресурси, що знаходяться під їх управлінням. Тож, доменні мікросервіси постачають гранулярні API нижчого рівня, які дають можливість створювати різни experience сервіси, повторно використовуючи доступну доменну логіку.

В результаті маємо ситуацію, що додавання кожного нового experience сервісу не потребує додаткових витрат часу на повторну розробку доменної логіки.

  • Бази даних

Best practice полягає в тому, що база даних повинна належати лише одному мікросервісу. Жодні інші сервіси не повинні мати можливості безпосереднього доступу до бази даних, лише через API сервіса-власника. Це дозволяє кожному сервісу керувати консистентністю та структурою бази даних, якою він володіє. Також це дозволяє обирати найбільш відповідну базу даних для конкретних цілей без будь-якої залежності від вимог системи в цілому. Наприклад, один сервіс може використовувати нормалізовану базу даних SQL, тоді як інший може отримати вигоду з бази даних NoSQL. Однак один мікросервіс може керувати кількома базами даних.

Сервіс може мати безпосередній доступ до бази даних, лише якщо він є власником. В іншому випадку він повинен використовувати API мікросервіса-власника і ніколи не мати безпосередній доступ до бази даних інших сервісів.

Спільне використання бази даних може потенційно призвести до анти-паттерна Distributed Monolith. Якщо вам потрібно надати загальний доступ до даних, зверніться до таких концепцій централізованих сховищ, як :

  • DWH (Data Warehouse), 
  • DFS (Distributed File System) 
  • Data Lake. 

Рекомендується застосовувати правильні схеми та підходи з самого початку, тому що потім все одно доведеться це зробити. 

  • Інтеграційні інтерфейси та конектори

Окрім внутрішніх джерел даних, програмі може знадобитися доступ до інших підсистем та сторонніх API. Корисна практика – розділяти інтеграційний ярус, запровадивши окремі сервіси-конектори.

Підіб’ємо підсумки. Мікросервісна архітектура по суті є патерном який вчить застосовувати різні (чи інші) архітектурні патерни, стилі та підходи в рамках єдиного додатка, розподіленого в мережі. У цій статті ми розглянули лише верхівку айсберга, так звану high-level архітектуру. В наступній частині, ми проаналізуємо набір більш низькорівневих підходів та патернів, які заслуговують на увагу при подальшому зануренні в тему.

Тож не перемикайтесь!