Частина 2 з Топ-10 прогнозів на 2025 рік (першу частину можна знайти тут) зосереджена на технологіях та тенденціях, які спрямовані на радикальне спрощення життєвого циклу розробки програмного забезпечення. Теми варіюються від революційних нових концепцій, таких як інфраструктура як код (IfC), до «старих друзів» з новим поворотом, таких як спостережуваність для розробників та операційників.
6. Складові додатки через WebAssembly
WebAssembly (WASM) переходить від технології, що тільки з’явилася, до універсальної платформи додатків з розширеною кількістю випадків використання. У 2025 році популярність WASM швидко зростатиме, оскільки більше команд розробників усвідомлюють переваги написання платформонезалежного коду, який без модифікацій працює будь-де. Ця портативність робить WASM контейнери відмінними будівельними блоками для складувальних додатків, концепції, що дозволяє розробникам просто вставляти шаблонний код замість того, щоб постійно переписувати однаковий код для стандартних функцій. Думки про це йдуть ще далі: постачальники програмного забезпечення можуть використовувати WASM для створення модульних додатків, де клієнти можуть придбати та підключати нову функціональність у будь-який час.
Складові додатки використовують WASI (WebAssembly System Interface) для додавання функціональних модулів до основного бізнес-додатку. Для додаткової інформації про WASI дивіться нижче.
WASI критично важливий для успіху WASM
Успіх WASM залежить від випуску фінальної версії WASI (WebAssembly System Interface), стандарту, що визначає, як контейнери WASM можуть взаємодіяти зі своїм середовищем. Це включає в себе широкий спектр базових вимог до API, таких як доступ до файлової системи, мережеве спілкування, змінні середовища, управління пам’яттю, веб-сервер, обмін повідомленнями, SQL і навіть USB. Інтеграція з USB, наприклад, ще тільки на початковому етапі. Надання доступу до USB для контейнерів WASM означає забезпечення доступу до апаратного забезпечення багатьох різних пристроїв на рівні ядра операційної системи. Це вимагає ретельного визначення, які типи пристроїв дозволені та які привілеї їм надаються. Водночас важливо не уповільнити загальну пропускну здатність шини USB. Хоча ми вже бачимо реалізації концепцій USB, для забезпечення стабільної роботи через різні середовища та пристрої необхідний WASI. Та ж ситуація і з SQL, де ми знаходимо кастомні інтеграції без офіційного стандартизованого інтерфейсу. Тут WASI має вирішити низькорівневі завдання, такі як певні можливості зберігання і мережевого зв’язку, багатозадачність та контроль безпеки, які досі частково відсутні і необхідні для роботи з базами даних.
WASI надає додаткам WebAssembly доступ до ресурсів, необхідних для їх роботи (SQL, файлові системи, мережі, потоки, сховище тощо).
WASI 1.0 має на меті забезпечити, щоб додатки отримували однакові API для різних середовищ виконання, таких як WasmTime, Wasmer, WasmEdge, Wasm3, Wazero тощо. На цьому етапі парадигма «написати код один раз, розгорнути де завгодно» буде досяжна.
Вплив на бізнес: 10/10 — дуже високий
Передача коду у вигляді бінарних файлів, що надійно працюють як на місцевих серверах, так і в хмарних та крайових локаціях, значно зменшує час, який розробники витрачають на написання інфраструктурного коду для конкретних хмар, орієнтування в складних багатокучових CI/CD пайплайнах та налагодження специфічних для хмарного середовища проблем. При цьому забезпечується тестування, орієнтоване на конкретне середовище, і забезпечується стабільна продуктивність на великій шкалі.
Вплив на бізнес від концепції «написав код один раз і розгорнув будь-де» важко переоцінити, і це може зробити WASM наступною великою річчю в розгортанні додатків.
Що очікувати в 2025 році
Прогрес у WASI: Хоча ми не зможемо побачити WASI 1.0 у 2025 році, буде значний прогрес у розвитку нових можливостей виконання, що є критичними для ключових випадків використання в науці про дані, периферійних обчисленнях та безпеці. Недавнє оголошення про підтримку популярного фреймворку машинного навчання PyTorch на базі Python є одним із прикладів заголовків, які можна очікувати від WASI в 2025 році.
Покращена підтримка Python: Якщо коротко, WASM має полегшити розробникам Python написання та розгортання їхніх додатків. Це включає підтримку популярних pip-встановлених модулів (наприклад, Streamlit), підтримку стану додатка, підтримку багатоядерних процесорів тощо.
WASM на Kubernetes: Для WASM критично важливо працювати на Kubernetes, пліч-о-пліч з традиційними контейнерами Linux. Хоча така можливість існує вже сьогодні, для великих виробничих розгортань важливо побачити, як підприємства почнуть використовувати WASM на Kubernetes.
Matt Butcher, CEO компанії Fermyon, вважає, що WebAssembly — це наступний великий крок в еволюції обчислювальних технологій, оскільки воно може суттєво змінити економіку операцій додатків і розробки додатків одночасно.
7. Спрощене з’єднання як ключове
У 2025 році ми очікуємо, що продукти для хмарних мереж і з’єднань зосередяться на єдиній, заснованій на ідентичності, політиках автоматизації підключення мікросервісів. Продукти прагнутимуть запропонувати мапування залежностей в реальному часі, поєднане з рівнем потоку спостережуваності на рівні додатка для швидкого аналізу причин. Велику увагу приділятимуть можливості команд продуктів створювати власні мережеві політики в межах корпоративних стандартів. Вбудоване балансування навантаження, шлюзи для виходу з високою доступністю, а також детальні метрики продуктивності та сповіщення стануть стандартом.
Мікросервіси та хмарна інфраструктура сприяють єдиній автоматизації, що дозволяє покращити спостережуваність, розширити можливості команд та реалізувати вдосконалені мережеві функції, що в сукупності покращує безпеку, масштабованість, усунення неполадок та ефективність роботи при вирішенні проблем із впровадженням.
Вплив на бізнес: 10/10 — дуже високий
З’ясування того, як оптимально підключити свій код до внутрішніх і зовнішніх API, стало одним з найбільших витрат часу для розробників додатків. Оскільки мікросервіси часто залежать від численних мережевих з’єднань, розробники повинні розуміти, розгортати та управляти різними типами методів автентифікації та протоколів, одночасно забезпечуючи оптимальну продуктивність додатка в різних умовах мережі. Це означає, що кожне з’єднання вимагає ретельної конфігурації та моніторингу для підтримки надійності. Помилки або зниження продуктивності одного мікросервісу можуть вплинути на додаток таким чином, що важко буде знайти причину. Налаштування мережі, політики безпеки та правила маршрутизації можуть змінюватися, що вимагає від розробників значного часу для оновлення та підтримки цих конфігурацій, особливо в багатокучових середовищах, де різні постачальники можуть мати різні вимоги та обмеження.
Заміна цієї складності на підхід, заснований на політиках для підключення мікросервісів, дозволить значно заощадити час розробників.
Що очікувати в 2025 році
Політики самообслуговування: Дозволити командам продуктів визначати власні мережеві політики в межах корпоративних стандартів є критично важливим для продуктивності та автономії розробників.
Автоматизація, заснована на політиках: Рішення для з’єднання будуть орієнтовані на політики як код, використовуючи ідентичність як основу для всієї комунікації між сервісами.
Мапування залежностей в реальному часі: Автоматизоване мапування залежностей стане стандартом, оскільки воно є критичним для розуміння та налагодження поведінки додатків.
Liz Rice, головна спеціалістка з відкритого коду в компанії Isovalent, витрачає 1 хвилину, щоб розповісти про нові можливості Isovalent щодо з’єднання кластерів Kubernetes і робочих навантажень, використовуючи eBPF (Tetragon) для забезпечення безпеки виконання.
8. Об’єднана та спільна спостережуваність
У 2025 році ми побачимо прискорене об’єднання платформ спостережуваності та моніторингу, щоб зменшити операційну складність, дозволити розробникам полегшити процес поліпшення та налагодження своїх додатків, а також надати команді безпеки єдине місце для звітності та забезпечення відповідності політикам.
За даними Enterprise Strategy Group, середня організація наразі використовує більше 11 платформ для спостережуваності та інструментів моніторингу. Часто розробники, оператори та інженери з безпеки не використовують одну й ту ж платформу для спостережуваності, а мають свої індивідуальні інструменти та платформи.
Розробники, оператори та команди безпеки часто мають свої улюблені інструменти для спостережуваності та моніторингу. Це швидко призводить до утворення інформаційних силосів.
- Розробники зазвичай обирають інструменти, які забезпечують глибоке бачення коду додатка, трасування транзакцій та аналіз помилок. Їхньою метою є швидке діагностування проблем та оптимізація користувацького досвіду.
- Оператори зазвичай зосереджуються на надійності системи та стані ресурсів, використовуючи інструменти, що об’єднують логи та метрики з усієї інфраструктури.
У нашому світі швидкої архітектурної децентралізації це стало непідтримуваною моделлю операцій, оскільки є занадто багато рухомих частин (мікросервісів), щоб проактивно оптимізувати операції додатків та інфраструктури, одночасно прискорюючи цикл випусків та покращуючи безпеку.
Вплив на бізнес від об’єднаної спостережуваності: 10/10 — дуже високий
OpenTelemetry стандартизує збір і експорт логів, метрик і трас, щоб як розробники, так і оператори могли покладатися на єдиний, послідовний формат даних замість того, щоб жонглювати кількома власними агентами. Об’єднуючи спосіб збору даних, команди можуть вибирати найкращі бекенди для спостережуваності та інструменти для аналітики для своїх потреб, при цьому зберігаючи загальну основу для телеметрії.
Морган МакЛін, один із співзасновників OpenTelemetry, та Гаган Сінгх з Elastic коротко пояснюють, як їхні відповідні платформи спостережуваності дозволяють підприємствам отримувати користь від інструментів OpenTelemetry.
Генеральний директор Chronosphere, Мартін Мао, розповідає про важливу роль досвіду розробників, включаючи відповідність політикам через SLO (Цілі рівня обслуговування) (Service Level Objectives) та автоматизовану диференціальну діагностику платформ спостережуваності, що дозволяє розробникам і операторам ефективно співпрацювати.
Кейла Бонді з Dynatrace розповідає про важливість сприяння співпраці між розробниками та операторами і зростаючу роль ШІ та автоматизації для максимізації бізнес-ефекту від спостережуваності.
Що очікувати в 2025 році
Насамперед, можна очікувати, що в платформах для розробників та CI/CD пайплайнах буде інтегровано постійну спостережуваність. Постачальники спостережуваності спростять інструментування, розгортання та управління телеметричними даними, одночасно пропонуючи прогнозовані ціни. У 2025 році необхідно побачити кінець того, що команди DevOps повинні будуть вирішувати, чи варто реалізовувати моніторинг повного стеку для додатка, оскільки моніторинг повного стеку є основою для прив'язки додатків до бізнес-пріоритетів.
Тренд 9: Додатки визначають свою інфраструктуру
Постійне створення, розгортання та управління інфраструктурою як кодом (IaC) виявилося складним для більшості компаній. Розробники часто витрачають занадто багато часу на те, щоб зрозуміти, як створити оптимальну інфраструктуру для свого коду, і стикаються з труднощами при визначенні того, як ці вимоги змінюються між хмарами або для додатків, які повинні працювати локально. У 2025 році очікується зростання рішень, які вирішують ці ключові проблеми через інтелектуальну автоматизацію, яка може надавати необхідні ресурси інфраструктури без складності IaC.
Інфраструктура як код складна і важка для управління та керування.
Інфраструктура з коду
Щоб спростити і прискорити визначення та управління інфраструктурним кодом, StackGen намагається автоматично надавати, налаштовувати і управляти серверами, мережами та сховищами на основі автоматичного аналізу вимог додатка до коду. StackGen називає це "інфраструктурою з коду", на відміну від інфраструктури як код, щоб підкреслити автоматизоване створення інфраструктури безпосередньо з коду додатка та можливість постійно коригувати інфраструктуру на основі змін коду.
Арунв Саркар, Pre/Post Sales у StackGen, пояснює концепцію Інфраструктури з коду та як це відрізняється від Інфраструктури як коду.
Повторювана інфраструктура для життєвого циклу розробки програмного забезпечення
Codiac забезпечує консистентність інфраструктури для оптимальної масштабованості, дозволяючи командам DevOps визначати, налаштовувати і управляти середовищами додатків однаково по всьому підприємству. Розробники можуть вводити налаштування на основі своїх вимог до коду, а Codiac відстежує і контролює ці зміни, щоб підтримувати консистентність у всіх екземплярах одного середовища та також по всьому підприємству.
Ця повна консистентність розгортання та конфігурації відкриває шлях до масштабованості, необхідної для швидкого і детального надання нових можливостей програмного забезпечення без збільшення витрат на розробку.
Марк Фрейдл, генеральний директор і засновник Codiac, пояснює концепцію повторюваної інфраструктури для команд релізу як передумову для оптимальної масштабованості.
Бізнес-ефект: 9/10 — Дуже високий
Зробити управління життєвим циклом інфраструктури простим і повторюваним без створення величезного адміністративного навантаження є критично важливим фундаментом для того, щоб зробити розробку додатків гнучкою, масштабованою та економічно ефективною.
Що очікувати в 2025 році
У 2025 році ми побачимо сильний тренд на спрощення та стандартизацію інфраструктурного коду на основі автоматизації, керованої політиками. Це дозволить постійну реалізацію відповідності політикам, безпеки, ефективності витрат і надійності, одночасно звільняючи розробників та інженерів DevOps від необхідності писати, управляти, консолідувати, конфігурувати та оновлювати складний інфраструктурний код.
10. ШІ як частина платформи для розробників
У 2025 році ми побачимо, як платформи для розробників дозволять розробникам додатків експериментувати з можливостями ШІ та машинного навчання простим і економічно ефективним способом. Не ставши частковими дата-сайентістами, розробники зможуть обирати відповідні технології ШІ для наступного спринту і також пропускати ці можливості через CI/CD пайплайн, де IT-оператори можуть взяти на себе управління та підтримку цих нових можливостей.
Розробники часто стикаються з труднощами у визначенні ситуацій, коли використання можливостей ШІ має сенс. Це зазвичай зумовлено відсутністю грамотності в ШІ в поєднанні з труднощами отримання необхідних даних, інтеграції та управління середовищем виконання ШІ, а також постійного управління підкладеним ШІ-моделлю для досягнення бажаної продуктивності.
Кевін Штроумайєр, керівник відділу маркетингу Tanzu в Broadcom, розповідає про платформу Tanzu 10, яка має на меті надання вбудованого середовища виконання ШІ та майданчика для розробників для вибору з переліку перевірених ШІ-моделей з легким доступом до необхідних даних.
На KubeCon 2024 Джастін Кормак, CTO компанії Docker, оголосив про запуск Docker Hub AI Catalog, щоб спростити і стандартизувати робочі процеси розробки ШІ на платформі Docker, надаючи попередньо налаштовані компоненти ШІ.
Nutanix представив Nutanix Enterprise AI (NAI), щоб спростити розгортання і управління LLM та GenAI додатками на своїй платформі. Тут варто зазначити, що NAI можна розгорнути на будь-якій платформі Kubernetes, а не лише на власній дистрибуції Nutanix. NAI поставляється з інтеграцією для NVIDIA NIM і Hugging Face та з власним інтерфейсом користувача та ШІ.
Бізнес-ефект: 10/10 — Дуже високий
Це часто упускається факт, що розробка на основі традиційно закодованих правил і функцій з одного боку та розробка програмних можливостей на основі інференсу ШІ з іншого — це два принципово різні підходи. Без настанов і автоматизації розробники ризикують вибрати неправильні випадки для ШІ/МЛ. Окрім незадовільних результатів, це також може призвести до створення нового виду технічного боргу, оскільки управління життєвим циклом ШІ-моделей повинно бути враховано в поточних витратах на проект. Рішення цих питань шляхом надання платформам для розробників можливості автоматично розгортати можливості ШІ/МЛ є критично важливим для розкриття бізнес-потенціалу ШІ/МЛ.
Що очікувати в 2025 році
Створення стандартизованих та керованих політиками "ШІ-автоматів" стане пріоритетом для інженерії платформ у 2025 році. Одночасно управління життєвим циклом можливостей ШІ, що надаються цими "автоматами", має стати частиною платформи.
Це призведе до об'єднання процесів і інструментів DevOps та MLOps, оскільки окреме управління життєвим циклом коду та ШІ-моделей ніколи не буде ефективним. Це є очевидним, оскільки сучасні додатки можуть надавати бажану цінність для клієнтів лише тоді, коли код і ШІ-моделі працюють разом безшовно. Кінцеві користувачі байдужі до технологій, що стоять за їхніми додатками; вони просто хочуть, щоб усе працювало належним чином.
Висновок
Усі 10 передбачень цього року зосереджені на зменшенні тертя для розробників, одночасно дозволяючи операційним командам і командам безпеки забезпечити рамки для масштабованості, надійності, продуктивності та безпеки. В кінцевому підсумку всі ці технології мають на меті дозволити підприємствам будувати, управляти та експлуатувати спільну платформу, яка дозволяє різним ролям у організації оптимально співпрацювати для надання цінності клієнтам. Це захоплюючі новини для операційних ролей, оскільки вони будуть визнані більше, ніж просто допоміжний персонал для розробників додатків. Інженери платформ, хмарні інженери, SRE (Site Reliability Engineers), традиційні оператори та інженери з безпеки — це нові співзірки, які створюють тканину та основу для технологічного успіху бізнесу.
Перекладено з: Top 10 Enterprise Technology Trends in 2025 (Part 2): Simplifying the Software Development Lifecycle