У межах програми раннього доступу компанія з розробки програмного забезпечення Ngrok зробила доступним шлюз API, який можна використовувати як послугу. Про це повідомляє DevOps.com.
Замість того, щоб самостійно розгортати, підтримувати та захищати шлюзи API, команди розробників застосунків за допомогою однієї команди або виклику функції тепер можуть маршрутизувати трафік API, автентифікувати й авторизувати доступ, а також застосовувати політики обмеження швидкості.
Генеральний директор Ngrok Алан Шрив сказав, що цей підхід також спрощує ІТ-командам уніфікацію керування входом у той час, коли керування мережею застосунків стає все складнішим. Замість того, щоб залежати від команди ІТ-операцій, він дає розробникам більш прямий контроль над API.
Сьогодні більшість доступу до API надається після того, як розробник вперше створить запит на заявку на платформі керування IT-сервісами (ITSM), зазначив Шрив.
Крім того, шлюз ngrok спрощує доступ до API, що охоплює кілька хмар і локальних ІТ-середовищ, таким чином, що дозволяє організаціям реалізувати стратегію багатохмарних обчислень. Сьогодні багато організацій заблоковані на одній платформі, оскільки вони залежать від служб API-шлюзу, які надає їхній постачальник хмарних послуг.
Організаціям потрібно буде платити лише за послугу шлюзу API на основі фактичного використання, а не нести витрати на придбання шлюзу заздалегідь.
Раніше Ngrok надавав набори для розробки програмного забезпечення (SDK) для забезпечення програмованого доступу до свого API-шлюзу. Варіант «як послуга», який пропонується зараз, є наступним логічним продовженням цих зусиль.
Загалом більше інфраструктури, ніж будь-коли, використовується як послуга, тому надання служби API-шлюзу є лише останнім прикладом цієї більшої тенденції.
Кожна організація, виходячи із загальної вартості, природно повинна буде вирішити, коли буде найбільш економічно доцільно використовувати ІТ-інфраструктуру як послугу. Оскільки мережа застосунків стає дедалі складнішою в управлінні в той час, коли кількість ІТ-спеціалістів з таким досвідом залишається обмеженою. Покладаючись на службу, ви можете отримати життєздатну альтернативу для керування сотнями API, що охоплюють розподілене обчислювальне середовище.
Поки що неясно, які саме команди в ІТ-організації беруть на себе відповідальність за роботу в мережі застосунків, але оскільки рівні 4-7 мережевого стеку стають більш програмованими, більшу відповідальність за роботу в мережі можуть взяти на себе DevOps і групи інженерів платформи. Існуючі мережеві команди тим часом продовжують керувати фізичними мережевими основами, які використовуються для маршрутизації мережевого трафіку.
Раніше ProIT повідомляв, що F5 оптимізує мережеві програми NGINX: тепер вони доступні за єдиною ліцензією.
Також ми розповідали, яким був 2023 рік для DevOps: огляд стану ринку.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
