Платформна інженерія (Platform Engineering) — майбутнє розробки програмного забезпечення?

Платформна інженерія є одним з головних технологічних трендів 2024 року. За оцінками Gartner, до 2026 року 80% компаній-розробників матимуть внутрішні платформні сервіси та команди для підвищення ефективності розробки.

Що таке платформна інженерія (Platform Engineering)?

Це процес проектування та створення платформ, які надають інфраструктуру, інструменти та сервіси для підтримки різноманітних додатків та сервісів. Основною метою платформної інженерії є створення потужної та універсальної платформи, яка може підтримувати різні процеси розробки та експлуатації додатків.

Платформа надає розробникам, операторам та іншим зацікавленим сторонам зручний інтерфейс та набір інструментів для спрощення та прискорення процесу розробки, розгортання та обслуговування/підтримки додатків.

Ефективність розробки

Впровадження підходів Agile, DevOps та TeamFirst, а також стрімкий розвиток хмарних технологій та інструментів розгортання призвели до вибухового зростання обсягів розробки програмного забезпечення в усіх сегментах економіки. Компанії почали активно нарощувати власну розробку, намагаючись підвищити власну ефективність та зайняти нові ринкові ніші.

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

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

Технічні фахівці та бізнес, як правило, стикаються з наступними типовими проблемами, притаманними командам незалежно від їхніх завдань і сфери діяльності:

• Ефективність розробки напряму залежить від того, скільки часу команда приділяє розробці цінної для бізнесу функціональності програмного забезпечення. У той же час, команди мають обов'язкову діяльність, яка не має нічого спільного зі створенням цінності для бізнесу: онбординг нових співробітників, налаштування сервісів моніторингу продукту, побудова пайплайнів CI/CD. На всі ці дії команда зазвичай витрачає багато часу та ресурсів, відволікаючи їх від розробки. При цьому допустимий обсяг когнітивного навантаження на команду обмежений (в першу чергу через обмежену кількість членів команди).
• Для бізнесу важливо, щоб час виходу на ринок розроблених рішень і функцій був мінімальним. Але на практиці команда розробників залежна від фахівців з інших відділів: складно досягти повної автономії в постачанні та підтримувати високу ефективність, оскільки складність програмного забезпечення та підтримка умов його виробництва і експлуатації постійно зростають.
• Команди розробників за замовчуванням мають багато рутини, яка часто не тільки впливає на продуктивність команди з точки зору доставки продукту (що призводить до затримок релізів), але й знижує якість наданих рішень. Якщо проблему рутини не вирішити, можна отримати ситуацію з постійною понаднормовою роботою і, як наслідок, падінням морального духу, вигоранням та апатією. Все це має значні негативні наслідки для продукту та бізнесу.

Ключове завдання — позбавити технічний персонал рутини, штучних обмежень і залежностей.

Платформна інженерія та внутрішня платформа розробки

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

Одним із прикладів платформного підходу є створення внутрішньої платформи розробки (IDP), за допомогою якої команда розробників може вирішувати всі непрофільні питання в режимі самообслуговування — від запиту інфраструктури та середовищ до доступу до сервісів Observability, необхідних інструментів розробки та використання типових конвеєрів збірки та розгортання.

Внутрішня платформа розробки (IDP) слугує універсальною платформою для розробників:

1. Максимізує досвід розробників;
2. Забезпечує єдину точку входу, спрощуючи процес приєднання до команди;
3. Зменшує когнітивне навантаження на команди розробників, тим самим підвищуючи їхню продуктивність.

Таким чином, чим краще і повніше реалізована бекенд-платформа, тим вища ефективність команд розробників.

Розглянемо детальніше реалізацію платформного підходу на прикладі IDP.

Генезис внутрішніх платформ розробки (IDP)

Тенденція створення внутрішніх платформ розробки (IDP) є відносно новою, але індустрія рухається до них вже досить давно.

Ранні ознаки потреби у IDP

Ще на ранніх етапах цифрової трансформації (2012-2015 роки) стали очевидними три ключові моменти:

1. Команди всередині компанії проходять однаковий процес адаптації: Це включає в себе отримання доступу до інструментів та ресурсів для створення та розгортання коду тощо.
2. Команди використовують схожі процеси CI/CD для створення та розгортання продуктів, а також ідентичні методи моніторингу. Більше того, багато команд вирішують однакові архітектурні проблеми, такі як створення відмовостійкого PostgreSQL або розробка Stateless мікросервісів.
3. Швидкість розробки часто сповільнюється відділами ІТ та інформаційної безпеки (IS). Ці відділи стали вузькими місцями на шляху до делівері продукту. У той час як команди розробників змогли адаптуватися до швидких змін і розгортання, відділи ІТ та IS часто відставали. Багато операцій у цих відділах виконувалися вручну, а процеси були повільними і не масштабованими.

Потреба в рішенні

Компаніям потрібно було мінімізувати дублювання роботи та обійти ці обмеження без шкоди для безпеки. Рішенням стала ідея консолідації всіх кращих архітектурних практик, шаблонів конфігурацій, вбудовування вимог IS в робочий процес розгортання інфраструктури та автоматизації розподілу інструментів розробки, з подальшим наданням всього цього за моделлю "як послуга" (aaS).

Як зʼявилися IDPs

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

Особливості впровадження внутрішніх платформ розробки

Сьогодні майже всі великі компанії або розглядають, або вже використовують IDP.

В корпоративному сегменті IDP-платформи часто будуються на базі хмарних оркестраторів (HP CSA, VMware vRA, OpenStack тощо), які надають "конструктор" ІТ-сервісів та широкий стек плагінів для швидкого створення порталів самообслуговування з каталогом послуг. Як правило, компаніям корпоративного сегменту в цьому допомагають інтегратори, які володіють необхідними компетенціями.

У той же час, багато компаній створюють платформи розробки з нуля, не використовуючи готові рішення. Зазвичай це роблять компанії з високим рівнем культури розробки, які мають чітке уявлення про те, що вони хочуть отримати від платформи, і готові інвестувати значні ресурси в її створення і підтримку. Це дозволяє їм інтегрувати в IDP власні кастомні інфраструктурні сервіси (Observability, IaM тощо), інструменти CI/CD та інші рішення.

Іншими словами, IDP в таких компаніях спеціально заточені під внутрішні бізнес-процеси розробки.

Чому платформна інженерія в тренді

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

Серед позитивних результатів використання платформної інженерії можна виділити наступні:

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

Зменшення розпорошеності технологій: Побудова IDP дозволяє розробити уніфікований набір інструментів, що використовуються в компанії. Це дає можливість скоротити стек за рахунок усунення непотрібних і дублюючих рішень (наприклад, коли різні відділи компанії використовують різні інструменти з ідентичним функціоналом). Відхід від розростання технологій спрощує підтримку стека, його адміністрування та зменшує витрати на ліцензування. Водночас зростає експертиза команди підтримки IDP з цього інструментарію, оскільки не потрібно розпорошувати ресурси на вивчення різних продуктів і рішень.

Обмін знаннями: Створення платформи IDP передбачає розробку детальної документації, яка проведе користувачів через типові кейси — від побудови конвеєра CI/CD до розгортання у продакшні. Це забезпечує безперервність експертизи та гарантує, що команда зможе продовжувати працювати з інструментами, навіть якщо хтось із співробітників-експертів звільниться. Ефект бас-фактору (bus factor) зведено до мінімуму.

Підвищення безпеки: Платформа IDP — це, по суті, єдина точка доступу до інструментів. Це дає можливість інтегрувати рішення з безпеки в ланцюжок "користувач-інструмент" — наприклад, для перевірки прав доступу та виконання процедур затвердження. Користувачі IDP також можуть використовувати ІТ-ресурси та сервіси, які вже були схвалені співробітниками служби безпеки.

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

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

Швидке та небюрократичне придбання ресурсів: платформа інженерія дозволяє легко отримати доступ до обчислювальних ресурсів через попередньо узгоджений каталог ІТ-сервісів (від відділу безпеки та ІТ-відділу), в якому публікуються адаптовані для компанії сервіси IaaS і PaaS. У цьому випадку на отримання необхідних ресурсів витрачається кілька хвилин, а не тижнів.

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

Бар'єри на шляху до впровадження та розвитку внутрішньої платформи розробки

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

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

Страх, що доведеться скорочувати персонал. Часто розвиток внутрішньої платформи розробки гальмується на рівні співробітників, в тому числі DevOps, які переживають, що залишаться без роботи. Але це помилкова думка. Концепція Platform Engineering передбачає не скорочення персоналу, а просто зміщення його фокусу на вирішення інших завдань.

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

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

Передавши розробку IDP-платформи на аутсорс, компанія може пом'якшити деякі недоліки і прискорити впровадження концепції платформної інженерії.

Графік впровадження та оцінка ефективності

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

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

Безпосередньо оцінити економічну ефективність реалізації таких проектів складно. Тому концептуально при визначенні раціональності інвестицій до уваги беруть кілька критеріїв.

Співвідношення розробників до DevOps-інженерів. Наприклад, якщо до впровадження платформи IDP на 10 команд розробників було потрібно 10 DevOps-спеціалістів, то після впровадження рішення, при трикратному збільшенні масштабу розробки, кількість DevOps-інженерів зросте несуттєво - наприклад, до 15 осіб (без платформи було б майже пропорційне зростання).

Частота релізів. Завдяки зменшенню кількості погоджень, перевірок і другорядних завдань, а також поліпшенню взаємодії між командами розробників, скорочується і час виходу на ринок (Time-to-market). Це дозволяє збільшити кількість релізів без втрати якості та без значного збільшення навантаження на розробників.

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

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

Ось кілька додаткових моментів, які слід врахувати:

• Зрілість практики DevOps в організації. Організації з більш зрілою культурою DevOps будуть краще підготовлені до впровадження та ефективного використання платформи IDP.
• Рівень підтримки з боку вищого керівництва. Успіх ініціативи IDP залежить від рівня підтримки з боку вищого керівництва.
• Наявність ресурсів. Впровадження та використання платформи IDP вимагає таких ресурсів, як час, гроші та люди.

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

Платформна інженерія проти DevOps та SRE: Відмінності у сфері застосування, фокусі та цілях

Платформна інженерія, DevOps та SRE (Site Reliability Engineering) — це три концепції та методології, що використовуються в інформаційних технологіях для оптимізації процесів розробки та підтримки програмного забезпечення. Хоча вони мають спільні принципи та цілі, вони відрізняються за сферою застосування, масштабом та основними завданнями. Залежно від контексту роботи та потреб, сучасні компанії можуть покладатися на інженерів-платформерів, інженерів DevOps та SRE для забезпечення досконалості своїх продуктів та послуг.

Сфера відповідальності:

• Платформна інженерія зосереджена на розробці та створенні платформ для підтримки додатків.
• DevOps та SRE зосереджуються на процесах та методологіях розробки та експлуатації програмного забезпечення.

Масштаб:

• Платформна інженерія часто спрямована на створення високомасштабованих і гнучких платформ.
• DevOps і SRE працюють на рівні процесів і операцій в рамках конкретного масштабу системи.

Цілі та завдання:

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

Фокус роботи:

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

DevOps охоплює ширший спектр сфер, поєднуючи розробку, експлуатацію та забезпечення безперервного розвитку і вдосконалення додатків.

Процеси та методології:

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

DevOps охоплює ширший спектр методологій та процесів, таких як CI/CD (безперервна інтеграція та делівері), автоматизація тестування та контейнеризація.

Зона відповідальності:

• Платформна інженерія фокусується на архітектурі та інфраструктурі внутрішньої платформи.
• DevOps відповідає за інтеграцію розробки та експлуатації додатків.

Платформна інженерія та SRE:

Фокус роботи:

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

SRE в першу чергу відповідає за забезпечення стабільної та надійної роботи продукту або послуги. Їхнє головне завдання — підтримувати високу доступність і швидко реагувати на проблеми у виробничому середовищі.

Культура та методологія:

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

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

Зона відповідальності:

• Платформна інженерія фокусується на архітектурі та інфраструктурі внутрішньої платформи.
• SRE відповідає за операційну сторону продукту або послуги.

Основні висновки зі статті:

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

Створення IDP-платформ дає бізнесу конкурентні переваги в епоху цифрової трансформації та допомагає обігнати конкурентів на ходу за рахунок максимальної ефективності.

Сьогодні компаніям не потрібно занурюватися в розробку IDP-платформи з нуля: вони можуть обрати готові рішення та партнерів, які мають досвід та експертизу в побудові IDP.