Час підвищення рівня для команд IT-платформи
ВИРОБНИЦТВО – 30 березня 2022 р., Баден-Вюртемберг, Ротвайль: складені дерев'яні піддони лежать у сталевому … [+] цеху. Фото: Сайлас Стайн/dpa (фото Сайласа Стайна/picture alliance через Getty Images)
dpa/picture alliance через Getty Images
Програмне забезпечення — це командна гра. «Цехи» розробки додатків корпоративного програмного забезпечення (мила назва, яку інженери іноді люблять використовувати для позначення відділу програмування та допоміжних операцій) складаються з кількох професіоналів, кожен із власними спеціалізаціями та областями досконалості.
Навіть коли так зване програмне забезпечення для любителів створюється окремими особами, багато розробників, які працюють у таких середовищах, взаємодітимуть із групами користувачів в Інтернеті, колективами проектів із особливим інтересом або справді зонами та сховищами програмного забезпечення з відкритим кодом, де фактором спільноти є сама команда.
Як ми знаємо, в епоху хмар і епоху масивних центрів обробки даних програмне забезпечення часто стає складнішим і заплутанішим, тому сьогодні з’явилося так багато фахівців з оркестровки та постачальників технологій спостереження. Це означає переміщення на одну (або, можливо, кілька) сходинок нижче, до платформи, яка використовується для живлення та керування програмами, що створюються, і тепер ми формуємо команди, які зосереджені на роботі в цьому просторі як на спеціальній функції.
Це зростання команди програмної платформи.
Розгляд того, що робить команда програмної платформи, як функціонують її робочі процеси, де це може бути ефективним і як воно має обслуговувати ширші елементи стеку ІТ, є основною діяльністю та інтересом для компанії з автоматизації інфраструктури Puppet.
Останній аналіз компанії DevOps (розробники та операційні команди, що працюють разом) фактично постачається як спеціальне видання Platform Engineering Edition. Упустивши можливість опублікувати спеціальне різдвяне видання чи іншу форму новорічного звіту, Puppet натомість вирішив спробувати продемонструвати, що відбувається у відділах платформи.
Офіційно відома як Puppet від Perforce (Perforce придбала Puppet навесні минулого року), компанія припускає, що поки ІТ-лідери інвестують у свою команду платформи та вдосконалюють своє мислення щодо продукту, розробка платформи допоможе їм відкрити шанс прискорити програмне забезпечення. поставки та зменшити тиск розвитку. Раніше ми розглядали розробку платформ і зауважили, що цей сектор стеку ІТ зосереджений на таких сферах, як безсерверні обчислення та автоматизоване забезпечення — крім того, ми говоримо про програмовані інфраструктури та інфраструктуру як код (IaC), тож що Puppet вважає, що нам потрібно зосередитися на динаміці команди платформи?
У цьому дослідженні досліджується зростаюча популярність розробки платформи та її переваги. 93% респондентів повідомили, що впровадження команди платформи є кроком у правильному напрямку. Раніше компанія припускала, що командний підхід до платформи є все більш успішним шляхом до успіху DevOps у масштабі. Це цілком логічно, тобто масштабування програмної системи полягає в вертикальному зростанні, горизонтальному розширенні та висоті на 360 градусів у всіх напрямках – було б нерозумно підходити до будь-якого проекту збільшення масштабу, не знаючи, якими є ваші основи… і це те, що платформа Інженерна команда готова.
Що таке розробка платформи?
Компанія визначає розробку платформи як технологічну дисципліну проектування та створення можливостей самообслуговування для мінімізації когнітивного навантаження для розробників і забезпечення швидкої доставки програмного забезпечення. Команди платформ надають спільні інфраструктурні платформи внутрішнім користувачам, відповідальним за створення потоку цінностей – як правило, розробникам програмного забезпечення та інженерам, які розглядають свою платформу як продукт для своїх користувачів, а не просто ІТ-проект.
Існує кілька основних атрибутів сучасного інженерного підходу до платформи. Найважливішим є мислення про продукт, під яким ми маємо на увазі, що платформа розглядається як набір продуктів самообслуговування, які постійно розвиваються, щоб задовольнити потреби розробників. Платформа має на меті зменшити когнітивне навантаження розробників і забезпечує швидкий потік доставки програмного забезпечення, коли команди, відповідальні за створення потоків цінності, можуть надавати цінність своїм споживачам, не вимагаючи прямої взаємодії з іншими командами.
Для ІТ-платформ цей підхід починається з надання базових інфраструктурних послуг як продукту самообслуговування, яким користуються команди розробників (або «потік цінностей»). Дизайн і еволюція платформи повинні ґрунтуватися на спільній організаційній навчальній практиці, а використання платформи всередині країни має керуватися внутрішньою євангелізацією, а не через мандат зверху вниз.
Збільшення складу платформи
«[Наша аналітична робота тут] показує, що розробка платформи може принести значні переваги для всієї організації та забезпечити успіх DevOps для підприємства. Однак керівництво має постійно інвестувати в команду платформи, забезпечувати функціональні цикли зворотного зв’язку з користувачами та розвивати навички керування продуктами в команді, щоб забезпечити швидку передачу потоків і постійне зниження когнітивного навантаження для розробників», – сказав Найджел Керстен, технічний директор Puppet by Виконати. «Оскільки фірми збільшують наймання для команд платформ, вони повинні віддавати пріоритет навичкам управління продуктами, а не лише основним інженерам».
Загалом, ми можемо зробити висновок, що корпоративна організація не обов’язково повинна мати команду розробників платформи, але якщо ця компанія хоче мати можливість розвивати свій ІТ-стек за допомогою ефективної (спільної, об’єднуючої, ефективної) команди DevOps, яка може безпечно підтримувати ІТ-проект з масштабування… тоді це начебто так.
«Поява розробки платформ — це тема, за якою ми стежимо з кількома командами та організаціями через нашу спільноту «Жінки в DevOps», — сказала Сабріна Баттістон, керівник спільноти «Жінки в DevOps». , зокрема про те, як команди платформи беруть на себе відповідальність за практики DevOps і дають змогу командам розробників – і звітують про результати нашій спільноті, яка потім може передати їх відповідним організаціям».
Команда розробників платформи не так сильно турбується про сферу графічних інтерфейсів користувача (GUI) і про те, чи можна безперебійно використовувати веб-службу в Android, Apple iOS і Linux або Windows – хоча хороша ДНК у Рівень платформи зазвичай підвищує ймовірність успіху «останньої милі» програми або цифрового сервісу — натомість більше уваги приділяється таким сферам, як надійність системи, продуктивність розробника та загальна швидкість доставки програмного циклу.
Платформа, це велике запитання
Команда платформи повинна володіти навичками розробки, операцій, управління продуктами та маркетингу продуктів, незалежно від фактичних посад у команді. Безперечно, це велике запитання.
Що може стати відносно суттєвою зміною мислення для багатьох підприємств, команда платформи повинна мати досвід ІТ-операцій, але вони не керують програмами на самій платформі. Вони відповідають за створення надійної та стійкої платформи, яка дає змогу командам потоку створення цінності створювати, випускати та керувати власними програмами.
Оскільки ми будуємо наступні 7 років корпоративних технологій від сьогодні до кінця цього десятиліття, гра на платформі ставатиме все більш важливою. Ігри на платформі, можливо, почалися з Donkey Kong і Super Mario Brothers, але тепер вони, безперечно, закінчуються в хмарному центрі обробки даних.
Дякую, Маріо, твій квест закінчено – принаймні зараз.
