Задача
У 2016 році Booking.com перейшла на платформу OpenShift, що надало розробникам продуктів швидший доступ до інфраструктури. Але через те, що Kubernetes був абстрагований від розробників, команда інфраструктури стала "вузьким місцем знань", коли виникали проблеми. Масштабувати цю підтримку стало неможливо.
Рішення
Після року роботи з OpenShift, команда платформи вирішила створити власну платформу на базі стандартного Kubernetes і попросити розробників вивчити Kubernetes для її використання. "Це не магічна платформа", каже Бен Тайлер, провідний розробник треку B Platform. "Ми не стверджуємо, що ви можете використовувати її з закритими очима. Розробники повинні навчитися, і ми зробимо все можливе, щоб вони мали доступ до цих знань."
Вплив
Попри складність навчання, нова платформа Kubernetes отримала велику популярність серед користувачів. Раніше створення нового сервісу могло займати кілька днів, якщо розробники розуміли Puppet, або тижні, якщо ні. На новій платформі це може займати всього 10 хвилин. За перші 8 місяців на платформі було створено близько 500 нових сервісів.
Технологія справила на них враження, але через потребу в корпоративних можливостях на їхньому масштабі, сайт обробляє понад 1,5 мільйона бронювань номерів на добу в середньому, команда вирішила перейти на платформу OpenShift.
Ця платформа, що була загорнута в інтерфейс командного рядка у стилі Heroku, "була дуже популярною серед наших розробників продуктів", каже Бен Тайлер, провідний розробник треку B Platform. "Ми надали їм швидший доступ до інфраструктури."
Але, додає він, "кожного разу, коли щось йшло не так, розробники не мали жодних знань, необхідних для підтримки себе."
І після року роботи з цією платформою команда інфраструктури виявила, що вона стала "вузьким місцем знань", каже він. "Більшість розробників, які її використовували, не знали, що це Kubernetes під капотом. Збій застосунку та збій платформи виглядали як збої цього інструменту в стилі Heroku."
Масштабування необхідної підтримки не здавалося можливим чи стійким, тому команді платформи потрібне було нове рішення. Знання Kubernetes, яке вони отримали, працюючи з платформою OpenShift, дало їм впевненість у створенні власної платформи на базі стандартного Kubernetes і налаштуванні її під потреби компанії.
"Для входу в середовище OpenShift був дуже корисним", каже Едуард Якобоая, старший системний адміністратор треку B Platform. "Він показує, на що здатна технологія, і робить її легкою у використанні. Після деякого часу ми зрозуміли, що нам потрібно краще вивчити Kubernetes, щоб повністю використовувати його потенціал. У той момент ми вирішили створити власну платформу Kubernetes. Ми безумовно отримуємо довгострокову вигоду від цього кроку та вкладеного часу в отримання цих знань."
Команда Якобоая налаштувала багато інструментів OpenShift, щоб вони працювали в Booking.com, і "ті інтеграційні точки були досить крихкими", каже він. "Ми витратили набагато більше часу на розуміння всіх компонентів Kubernetes, як вони працюють, як взаємодіють один з одним." Це дослідження призвело до того, що команда перейшла з вбудованих у OpenShift Ansible playbooks на розгортання за допомогою Puppet, які використовуються для решти інфраструктури Booking. Панель управління також було перенесено зсередини кластера на фізичні сервери, оскільки компанія використовує десятки тисяч фізичних серверів і велику інфраструктуру для запуску застосунків на фізичних серверах. (Booking використовує Kubernetes у кількох кластерах у різних дата-центрах у різних регіонах, де вона має обчислювальні потужності.) "Ми вирішили залишити все якомога простішим і також використовувати інструменти, які ми знаємо найкраще", каже Якобоая.
Ще однією великою зміною стало те, що розробники продуктів повинні були навчитися Kubernetes для початку роботи. "Це не магічна платформа", каже Тайлер. "Ми не стверджуємо, що ви можете використовувати її з закритими очима. Розробники повинні навчитися, і ми зробимо все можливе, щоб вони мали доступ до цих знань." Це включає тренінги, блоги, відео та курси на Udemy.
Попри складність навчання, нова платформа Kubernetes отримала велику популярність серед користувачів. "Я думаю, що причина, чому нам вдалося досягти цієї угоди успішно, полягає в тому, що ми не просимо їх вивчати пропрієтарну систему застосунків", каже Тайлер. "Ми просимо їх вивчити щось, що є відкритим кодом, де знання передаються. Вони інвестують у власну карʼєру, вивчаючи Kubernetes."
Одним із чітких ознак того, що ця стратегія була успішною, є те, що в каналі підтримки, коли користувачі мають питання, інші розробники продуктів втручаються, щоб відповісти. "Я не бачив такого рівня взаємодії спільноти навколо певного продукту платформи всередині компанії раніше", каже Тайлер. "Це дуже допомагає, що вона є видимим стандартом екосистеми за межами компанії, тому люди відчувають цінність в інвестуванні у ці знання і діляться ними з іншими, що є дійсно дуже потужним."
Є й інші кількісні докази: Раніше створення нового сервісу могло займати кілька днів, якщо розробники розуміли Puppet, або тижні, якщо ні. На новій платформі це займає 10 хвилин. "У нас є підручник. Ви слідуєте підручнику. Ваш код працює. Потім настає час для бізнес-логіки", каже Тайлер. "Час доступу до ресурсів зменшився значно." За перші 8 місяців на платформі було створено близько 500 нових сервісів, з сотнями релізів на день.
Платформа пропонує різні "рівні контрактів, так би мовити", каже Тайлер. "На самому базовому рівні це просто Kubernetes. Якщо ви професійний користувач Kubernetes, ось вам API Kubernetes, такий самий, як ви отримуєте від GKE або AKS. Ми намагаємося бути постачальником на тому ж рівні. Але вся наша робота в компанії полягає в тому, щоб надати більше цінності, ніж просто базову інфраструктуру, тому ми надаємо набір базових образів для наших основних стеків, Perl і Java."
І "як тільки наші користувачі вивчають Kubernetes і стають більш досвідченими користувачами, вони тиснуть на нас, щоб забезпечити кращий, більш нативний досвід роботи з Kubernetes, що чудово", каже Тайлер. "Це дуже здоровий динамічний процес."
Платформа також включає інші технології CNCF, такі як Envoy, Helm та Prometheus. Більшість критичного трафіку сервісів для Booking.com маршрутизуються через Envoy, а Prometheus використовується головним чином для моніторингу компонентів інфраструктури. Helm споживається як стандарт пакування. Команда також розробила і випустила інструмент з відкритим кодом Shipper, розширення для Kubernetes, яке додає складніші стратегії розгортання та оркестрування в багатьох кластерах.
Безумовно, були внутрішні дискусії про доцільність створення платформи Kubernetes з нуля. "Це не зовсім наша основна компетенція — Kubernetes і подорожі, вони досить далекі один від одного, чи не так?" каже Тайлер. "Але ми зробили кілька ставок на компоненти CNCF, які дуже добре спрацювали для нас. Envoy і Kubernetes, зокрема, були дуже корисні для нашої організації. Ми змогли налаштувати їх, або тому, що мали доступ до вихідного коду, або тому, що вони мали точки розширення, і ми змогли отримати з них користь дуже швидко, не змінюючи жодних парадигм всередині компанії."