Як це — працювати над розробкою онлайн-платформи для контенту в інтерактивних форматах, яка може похвалитися 6 мільярдами відстежуваних подій, 500 мільйонами переглядів сторінок, та 300 мільйонами активних користувачів на місяць?
Playbuzz — саме така платформа.
Щохвилини близько 50 тисяч людей користуються сервісом або взаємодіють з контентом, створеним з допомогою Playbuzz. Це онлайн-тести, вікторини, списки, відео, опитування тощо. Платформою користуються звичайні користувачі та великі медіакорпорації. За останні 6 років такі великі бренди як Huffpost, ESPN, Unilever, Major League Baseball, Netflix та багато інших стали постійними користувачами сервісу.
Мало хто знає, що технічну частину платформи розробляють в Ізраїлі та в Україні, в Intellias.
Редакція Codeguida поспілкувалися з українською частиною команди, щоб дізнатися більше про деталі розробки продукту, особливості розподілу задач, впровадження складних технічних рішень та інші тонкощі роботи на проекті.
Як почалась співпраця Intellias з Playbuzz?
Playbuzz був заснований у 2012 в Ізраїлі й незадовго після того був названий одним з найбільш проривних медіабізнесів у світі. Плануючи розширення центру розробки, наші ізраїльські партнери ретельно вивчили ринок і врешті зупинили свій вибір на нашій компанії. Intellias відповідав вимогам щодо технічного рівня спеціалістів. А розташування команд в одному часовому поясі стало ще однією перевагою на користь ефективності у співпраці. Компанія стала R&D-партнером Playbuzz в Україні з лютого 2017 року.
На якому стеці розробляється платформа?
В роботі над продуктом використовується такий перелік технологій:
- JavaScript (React, Node.js, Angular.js)
- Redis, MongoDB, CowDB
- Sass, Webpack
- AWS, EC2
- Apache Spark
- Jenkins
- Docker, CDN, Kibana, Grafana
На бекенді використовується Node.JS в якості основної платформи. Є старий моноліт на .NET, який поступово переписується на мікросервіси. На фронтенді — Angular.JS i React. Редактор матеріалів написаний на Angular.js, а компонент, який відповідає за їх рендеринг, — на React.
Основна причина використання React — підтримка SSR. Коли користувач заходить на сайт, він відразу бачить зображення, яке відмальоване на бекенді. Воно ще неклікабельне, але вже знайомить користувача з контентом. І поки він читає, розглядає, решта підвантажується — картинка стає клікабельною та інтерактивною. Це особливо важливо для мобільних користувачів.
Час завантаження є критично важливим для проекту, адже чим швидше завантажується контент, тим швидше користувач побачить інформацію. Тут кожна доля секунди впливає на те, чи буде закрито вкладку із сайтом, чи ні. Також можливість рендерити на сервері допомагає з SEO-отпимізацією.
За яку частину роботи відповідає українська команда? Як відбувається взаємодія між командами?
У нас однаковий список обов'язків з командою замовника, що в Ізраїлі. Ми працюємо з ними пліч-о-пліч, ніхто нікому не підпорядковується. Це, можливо, дещо незвично, як для аутсорсу. Ми відповідаємо за ту ж частину роботи, що й вони. Підкоманди у нас змішані. Наприклад, зі сторони Intellias на проекті Playbuzz є тім-ліди, і їм підпорядковуються спеціалісти зі Львова та з офісу замовника. Те саме стосується тім-лідів з ізраїльської частини команди.
Які особливості роботи над продуктом?
Кожен день у нас відбуваються статус-мітинги. Через те, що ми в одному часовому поясі з Ізраїлем, різниці у часі немає — дві команди в один час починають і закінчують роботу. П'ятниця в Ізраїлі — вихідний, неділя — робочий. Відповідно, в української команди п'ятниця — єдиний день без мітингів. Проте, наприкінці дня ми пишемо звіт, щоб команда в Тель-Авіві розуміла, що зроблено. А в понеділок ізраїльська команда, відповідно, розказує, що зроблено за неділю.
Чи можете пропонувати свої ідеї, а потім їх впроваджувати?
Нові фічі у вигляді задач доносять розробникам product-менеджери, які збирають інформацію з маркетингових досліджень — що саме цікаво користувачам.
Мені імпонує, як менеджмент зі сторони клієнта ставиться до пропозицій. Я можу запропонувати певний шлях розв'язання проблеми, як я бачу це можна зробити, і мені довіряють, не потрібно переконувати команду, що я знаю, як краще. Playbuzz відбирає у свою команду професіоналів, людей високого рівня. Я розумію чому так. Ти довіряєш кожному з команди й знаєш, що вони точно зроблять свою частину роботи якнайкраще
Крім того, у Playbuzz є крута традиція — внутрішній хакатон. Він відбувається двічі на рік, де кожен може запропонувати свою ідею для покращення продукту. Буває так, що в життя втілюються ідеї, які не посіли призові місця. У кожній команді є квота на кількість розробників, решта команди заповнюється людьми, які не мають відношення до розробки ПЗ. Отже, команда презентує proof of concept і може виграти від замовника крутий приз — поїздку в Іспанію, наприклад. Минулого разу виграла команда, у якій один з учасників був з української частини команди Playbuzz.
Які технічні рішення було важко реалізувати? Як це вдалося?
Рік тому до львівської команди приєднався перший DevOps-інженер на проекті, через півроку взяли ще одного спеціаліста, в Ізраїлі, на підмогу. Уся інфраструктура була розгорнута мануально і вносити будь-які зміни було дуже боляче. Ми розпочали описувати наявну інфраструктуру кодом, і оскільки здебільшого працюємо з AWS, то для автоматизації розгортання ресурсів вирішили використовувати CloudFormation.
Було декілька випадків, коли доводилося дописувати функціонал, який відсутній у CloudFormation за допомогою AWS Lambda. Це сталось тому, що на проекті стараємося все робити без зайвої надлишковості. Було вирішено за допомогою одного шаблону розгорнути всі стеки, макросервіси, яких у на той момент у нас було близько 60, і це тільки на production. Згодом, це дозволило досягти стандарту в розгортанні мікросервісів та середовищ.
Та так сталось, що одна із функцій CloudFormation не підтримувала автоінкременту при створенні нових стеків, і кожен новий стек мав бути мануально модифікований. Тобто від сервісу до сервісу потрібно було змінювати лише одну цифру, і зберігати шаблон окремо для кожного із них. На будь-якому іншому проекті з цим, напевно, би змирились, але це не про Playbuzz. Ми занурились в CloudFormation настільки глибоко, наскільки це можливо. І так автоматизували цей, здавалось би, простий, але не передбачений інженерами AWS, процес. Уся мікросервісна інфраструктура і всі — на цей момент це 70 мікросервісів — розгортаються всього лиш трьома шаблонами. Один мікросервіс розгортається одним мікросервіс-стеком, за допомогою універсального шаблону. Кожен зі стеків параметризується і дозволяє розгорнути нове середовище з нуля за лічені хвилини.
Дехто скаже, що всі ці зусилля є невиправданими, а дехто запитає, що це нам дало? Раніше time to production займав близько 2 годин, зараз він займає 5 хвилин. Можливість людської помилки близька до нуля. І вся наша інфраструктура — просто код, який може бути, в разі потреби, розгорнутий на новому акаунті. Зараз я згадую ті часи й ні разу не шкодую, що ми витратили трохи більше часу і зусиль.
Як розв'язуєте питання однотипних завдань?
Хоча на проекті панує атмосфера легкості, ми дорослі та свідомі люди, які розуміють, що всі задачі мають бути виконані, навіть ті, які не приносять задоволення. Поки однотипність не є критичною, задачі просто виконуються. Коли ж ситуація загрожує професійному розвитку, члени команди мають можливість вийти на ротацію в проекті, змінити задачі та команду. Менеджмент Playbuzz цінує бажання і прагнення своїх інженерів, тому завжди й швидко реагує на потреби змін.
Як часто українську команду відряджають в офіси клієнта? Куди саме? Які цілі та результати таких зустрічей?
Ми та наші ізраїльські колеги радо відвідуємо офіси один одного — в Тель-Авіві та Львові відповідно — та прагнемо зустрічатись мінімум раз на півроку. Звичайно, є відрядження за потребою: навчання, впровадження нових систем, зустрічі. Але також є відрядження з метою просто побути з командою, попрацювати тиждень-два в одному приміщенні, провести час разом поза роботою, познайомитись ближче. Як результат — покращення стосунків, сприйняття представниками обох офісів наші центри розробки як єдиний.
Спробуйте продукт команди в дії, пройшовши тест на знання front-end:
Ще немає коментарів