Є три ключові вимоги при прогнозуванні найбільш важливих технологій програмного забезпечення для підприємств на 2025 рік:

1. Технологія має бути реальною: Лише ті технології, які довели свою цінність у виробничих середовищах, вважаються "реальними" і будуть включені до цього списку.
2. Технологія повинна бути доступною: Для того, щоб технологія стала трендом, вона повинна бути доступною для широкого кола підприємств. Технології, які використовують лише кілька найбільших організацій, не відповідають вимогам.
3. Технологія повинна мати сильний бізнес-імпакт: Найважливіші технологічні тренди повинні впливати на бізнес-рівень. Це зазвичай означає підвищення продуктивності людей, стійкості додатків та інфраструктури, продуктивності або масштабованості.

Ось місця з 1 по 5. Місця з 6 по 10 будуть розглянуті в другій частині цієї статті.

1. Платформна інженерія як ключ до успіху в бізнесі

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

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

Рисунок 1: Основні компоненти та відповідні ролі платформи для розробників

Платформна інженерія є складною дисципліною, оскільки вона передбачає автоматизацію та інтеграцію великої кількості складних процесів і інструментів, які є частиною життєвого циклу розробки додатків (див. рисунок 1). Ідеальна платформа для розробників надає доступ до всього необхідного для оптимальної продуктивності, включаючи вбудоване моніторинг і спостереження, управління секретами, оркестрацію і керування контейнерами, управління зображеннями, безперервне розгортання, управління API та сканування безпеки. Операційні команди сприяють автоматизації інфраструктури обчислювальних потужностей, зберігання, мереж і баз даних як основи для самостійного обслуговування розробників.

Куди слід спрямувати увагу в 2025 році

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

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

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

Рисунок 2: Експертиза, автоматизація та інструменти як обмежувальний фактор для впровадження платформної інженерії (Джерело: Enterprise Strategy Group, 2024)

Бізнес-імпакт: 10/10 — Дуже високий

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

2. Орієнтовані на завдання штучні інтелекти: агенти ШІ співпрацюють для виконання завдань

Після завершення "медового місяця" для ШІ, організації тепер шукають реальні приклади використання, які можуть швидко принести вимірювану цінність. Це вимагає спрощення інструментів ШІ та загальної уваги до прозорості, пояснюваності та загального управління. Як тільки це домашнє завдання буде виконано, "ера ШІ" справді почнеться. Агенти будуть критично важливим компонентом, який допоможе ШІ довести свою цінність стійким чином.

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

Рисунок 3: Агенти ШІ співпрацюють для виконання складного завдання.

Оскільки LLM (large language models) дають найкращі результати, коли їм надається контекст та чіткі інструкції щодо конкретного завдання, має сенс створювати так званих агентів ШІ, які відповідають за виконання лише одного конкретного завдання. Ці агенти можуть координуватися «лідерами команд» (figure 4), які є агентами вищого рівня, що контролюють взаємодію між окремими агентами. Виходячи з цього принципу, можуть існувати кілька рівнів ієрархії агентів та «лідерів команд». Код на рисунку 4 показує визначення «лідера команди» на основі відмінної відкритої фреймворку агентів від phidata.

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

team_lead = Agent(  
 name="Team Lead",  
 model=OpenAIChat(id="gpt-4o"),  
 team=[software_developer_agent, tester_agent, bug_fixer_agent],  
 instructions=[  
 "Coordinate the workflow: first have the Software Developer Agent create the code, then the Tester Agent test it, then the Bug Fixer Agent fix issues if any are found.",  
 "Summarize the final state of the software."  
 ],  
 show_tool_calls=True,  
 debug_mode=True,  
 save_to_file=True,  
)

Важко переоцінити широкий спектр випадків використання, до яких можна застосовувати фреймворки агентів.
Хочете, щоб агенти створювали зручний дайджест новин, що складається з контенту з усіх ваших улюблених новинних сайтів, блогів та інших публікацій? Може, ще один агент для перетворення цього дайджесту в щоденну панель для онлайн-перегляду? Чому б не додати ще одного агента, відповідального за зворотній зв'язок і навчання?

На чому зосередитися у 2025 році

У 2025 році організації повинні зосередитися на тому, щоб робочі процеси агентів було легко створювати, покращувати, управляти ними та використовувати для широкої аудиторії людей з різними рівнями технічної підготовки. Спрощення використання агентів ШІ (AI agents) включає значно більше, ніж просто додавання GUI перед ними, щоб користувач міг самостійно збирати своїх агентів і робочі процеси. Справжня проблема полягає в створенні постійно застосовуваних обмежень з точки зору безпеки, відповідності вимогам, ефективності витрат та точності для забезпечення централізованого управління через численні складні робочі процеси агентів.

Бізнес-імпакт: 10/10 — Дуже високий

Надання командам агентів ШІ доступу до людського персоналу дозволить технічним та нетехнічним спеціалістам поетапно автоматизувати багато нині часозатратних і болючих рутинних завдань, через які їм доводиться проходити щодня.

3. Kubernetes для всіх

Kubernetes неймовірно масштабований, але операторам і командам DevOps важко адаптуватися до повністю керованого політиками (декларативного) підходу, де все, що є «жорстко закодованим», обмежує майбутню масштабованість. Постачальники програмного забезпечення та хмарних сервісів повинні продовжувати працювати над пропонуванням простих, попередньо інтегрованих та легких для налаштування кластерів Kubernetes.

Замість того, щоб кодувати, розробники часто витрачають надмірну кількість часу на обслуговування, налаштування та керування своїм додатком та оточуючими сервісами Kubernetes та інфраструктурою. Наприклад, при розгортанні на керованому сервісі Kubernetes, такому як AWS EKS, розробники повинні враховувати інтеграції з численними хмарними сервісами, пов'язаними з мережами та безпекою, зберіганням і даними, моніторингом і спостереженням. Графік 4 надає базові уявлення про складність навіть базових середовищ Kubernetes, що ускладнює перехід традиційних ІТ-команд від класичної інфраструктури на базі ВМ до середовищ, що використовують контейнери та кластери Kubernetes для планування.

Рисунок 4: Графік показує складність використання керованих кластерів Kubernetes (за допомогою Amazon EKS) для CI/CD

Nate Ceres та Sean McKenna, обидва старші менеджери з маркетингу продуктів в Microsoft, підсумовують цю проблему в розмові тривалістю 1:27 хвилин (записано на KubeCon 2024 у Солт-Лейк-Сіті).

В двох словах, Nate та Sean розуміють, що їм потрібно спростити провізію, інтеграцію, виконання, безпеку та управління витратами для їх кластерів Kubernetes, щоб дозволити більшому числу організацій запускати додатки Kubernetes.

Jefferey Gregor (Генеральний директор в OVH Cloud) розповідає про важливість вирішення проблеми «дуже високої кривої навчання Kubernetes», надаючи менш досвідченим організаціям можливість використовувати повністю керовані кластери Kubernetes, які зменшують кількість сервісів, з якими розробникам доводиться працювати.

На чому зосередитися у 2025 році

У 2025 році постачальники хмар Kubernetes та платформ на базі Kubernetes повинні полегшити процес розгортання та керування кластерами Kubernetes для широкої аудиторії. Це вимагає надання спектру рішень Kubernetes з різними рівнями попередньої інтеграції та гнучкості.

Бізнес-імпакт: 8/10 — Дуже високий

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

4.

Уніфікований доступ до даних в реальному часі

У 2025 році ми побачимо підйом платформ GraphQL, які пропонуватимуть єдину точку доступу для розробників для запитів до джерел даних по всій організації та за її межами. Це потребує від інженерів платформ докладати зусиль для надання універсального інтерфейсу GraphQL для розробників.

Рисунок 5: Платформи даних на базі GraphQL дозволяють розробникам писати раніше складні запити в одному єдиному запиті.

Розрізнені джерела даних змушують розробників використовувати кілька REST API, прямі запити до баз даних або інші протоколи. Розробники повинні вручну обробляти отримання даних, трансформацію та агрегацію для кожного джерела. Вони покладаються на бекенд API для отримання необхідних даних і повинні робити кілька мережевих запитів для виконання запиту через різні кінцеві точки API. Це може призвести до непослідовностей даних через зміни під час виконання запиту. Відлагодження цих непослідовностей і управління загальною складністю фрагментованого ландшафту REST API в масштабах може швидко стати обтяжливим для розробників.

Рисунок 6: 50–75% менше коду за допомогою лише одного запиту GraphQL (приклад, згенерований GPT-1)

Переваги запитів GraphQL над запитами REST API:

• Єдина точка доступу REST: Замість кількох викликів з боку клієнта ви об'єднуєте все в одному /aggregated-users.
• Прихована складність: Вся обробка даних (два зовнішні API, один запит до бази даних) та логіка агрегації залишаються на сервері.
• Зменшена кількість шаблонного коду: Клієнти просто викликають одну точку доступу та отримують об'єднані дані, замість того, щоб маніпулювати кількома запитами та злиттями.

Наявність єдиного шару ШІ дає переваги не лише в підвищенні продуктивності розробників, оскільки він дозволяє застосовувати централізовану політику безпеки, RBAC, моніторинг та управління кожним API.

Віце-президент з маркетингу продуктів Apollo GraphQL, Субрата Чакрабарті, розповідає про переваги, які GraphQL може надати розробникам додатків (запис з KubeCon 2024 у Солт-Лейк-Сіті).

На чому зосередитися у 2025 році

Існують п'ять ключових напрямів, на яких організаціям потрібно зосередитися у 2025 році:

1. Створити універсальний шлюз GraphQL, який об'єднує дані з кількох джерел, таких як REST API, бази даних, зовнішні сервіси, за допомогою однієї центральної точки доступу GraphQL.
2. Інвестувати в інженерію платформ для централізації процесів аутентифікації, авторизації та відповідності вимогам для нового шару GraphQL.
3. Оркеструвати отримання даних, трансформацію та агрегацію на стороні сервера, замість того, щоб обтяжувати розробника написанням коду для виконання цього завдання.
4. Забезпечити можливості в реальному часі для того, щоб розробники могли підписуватися на самостійно визначені потоки даних.
5. Централізувати спостережуваність та управління шаром GraphQL для забезпечення стійкості та оптимізації розподілу ресурсів.

Бізнес-імпакт 10/10

Платформи даних GraphQL є розширенням платформ для розробників, і тому вони мають ту ж саму мету: економити час розробників. Водночас, платформи GraphQL є відмінною основою для впровадження LLM (Large Language Models), оскільки вони уніфікують доступ до даних під єдиним шаром запитів і дозволяють гнучко отримувати контекст, необхідний LLM — зрештою, спрощуючи те, як будуються, тестуються та підтримуються рішення на базі ШІ по всій організації.

5. Bare Metal, ВМ, контейнери додатків та контейнеризація WASM співіснуватимуть

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

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

Рисунок 7: Порівняння між персонажами, залученими в управління операціями Kubernetes, і традиційним управлінням, орієнтованим на ВМ (Джерело: GPT 4o).

Кальян Раманатан, віце-президент з маркетингу, і Пракаш Раті, директор з маркетингу продуктів у Portworx, розповідають про необхідність єдиного набору корпоративних сервісів даних для ефективної та послідовної доставки баз даних, резервного копіювання та відновлення, відновлення після катастроф, архівації, аналітики даних, інтеграції даних, каталогів даних тощо. Застосування одного послідовного набору сервісів даних до будь-якого додатка, незалежно від того, чи працює він на bare metal, ВМ, контейнерах додатків або контейнерах WASM, може значно знизити операційну складність, підвищити послідовність даних і ефективність витрат, а також оптимізувати безпеку та відповідність вимогам.

Кальян Раманатан і Пракаш Раті з Portworx розповідають про єдині корпоративні сервіси даних.

Ден Черулі, лідер продукту в Nutanix, розповідає про Nutanix Enterprise AI як про їхню нову платформу, яка спрощує впровадження можливостей ШІ для віртуалізованих і контейнеризованих додатків.

Ден Черулі з Nutanix представляє нову платформу Nutanix Enterprise AI.

Бізнес-імпакт: 8/10

Запуск робочих навантажень на bare metal, ВМ, контейнерах додатків і контейнерах WASM на одній платформі може принести низку ключових переваг:

1. Зменшення операційних силосів може призвести до консолідації співробітників, інструментів і процесів.
2. Послідовні сервіси даних сприяють передбачуваній продуктивності, підвищеній цілісності даних і покращеному використанню ресурсів.
3. Наявність єдиної платформи управління дозволяє розробникам і операторам зосередитися на інноваціях, замість того, щоб витрачати час на надлишкові завдання.
4. Команди DevOps можуть вибирати оптимальний варіант розгортання для кожного проєкту без збільшення операційної складності.
5. Наявність єдиної платформи для управління спрощує впровадження можливостей ШІ завдяки значно зменшеним вимогам до інтеграції.

На чому зосередитися у 2025 році

У 2025 році організації інвестуватимуть у уніфікацію, стандартизацію та автоматизацію операцій платформи:

1. Вибір спільного набору інструментів для моніторингу, спостереження, оркестрації та автоматизації робочих навантажень на bare metal, ВМ, контейнерах додатків і контейнерах WASM стає критичним.
2. Організації зосередяться на створенні централізованих політик безпеки та відповідності вимогам для будь-якого типу стеку додатків.
3. Орієнтація на стандартні процеси та інструментальні ланцюги дозволить спростити модернізацію додатків без тиску на необхідність міграції від застарілих платформ.
4. Розробники потребуватимуть уніфікованих пайплайнів та єдиного каталогу самообслуговування, що працює в різних типах середовищ.
5. ШІ та машинне навчання будуть використовуватися для оптимізації розподілу ресурсів і забезпечення стійкості уніфікованих середовищ.

Висновок для Частини 1

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

Частина 2: Очікуйте на початку січня.

Перекладено з: Top 10 Enterprise Technology Trends in 2025: Platform Engineering and AI Agents Lead the Charge (Part 1)