Хмарні обчислення розвиваються, один API за раз

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

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

Це серйозна проблема для вашої наступної програми.

Вам може бути представлений RESTful API, але чи отримуєте ви належний рівень обслуговування для своєї програми? З’єднання з основною програмою потрібно обробляти інакше, ніж з однією збіркою, щоб відповідати потребам відділу. Хоча це не є проблемою для служб, які були створені, щоб бути тим, що стає відомим як «функціональний PaaS», це все ще те, що вам потрібно контролювати - якщо не для продуктивності, то, звичайно, для управління виставлення рахунків.

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

У зв’язку з тим, що під керівництвом Дайан Грін Google активно просувається на ринок корпоративних хмарних технологій, її придбання Apigee має великий сенс. Завдяки інструментам для контролю та керування використанням API за межами корпоративних кордонів (керування як публікацією API, так і споживанням) це добре підходить для компанії прагнучи покращити корпоративний доступ до багатьох API. Майкрософт придбала подібну компанію рік або близько того, інтегрувавши її у свої пропозиції Azure.

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

Okta, мабуть, найвідоміша завдяки своїй хмарній службі єдиного входу, яка перетворилася на ефективний менеджер ідентифікації та службу каталогів. На нещодавньому заході Oktane компанія оголосила про нову послугу, яка має допомогти заповнити одну з прогалин в управлінні API. Його інструменти керування доступом до API дозволять ІТ-відділам взяти наявну службу ідентифікації та використовувати її як основа політик доступу до API, використовуючи OAuth 2.0 для керування з’єднаннями з API та рішеннями для керування API, такими як Apigee і MuleSoft.

Це підхід, який відходить від ключа API (і означає, що ви з меншою ймовірністю випадково залишите ключ у сховищі Github). Прив’язавши доступ до ідентичності користувача, ви можете керувати тим, хто отримує доступ і як, залучаючи також контекстні моделі безпеки. Якщо ви створили програму, яка має використовуватися лише в корпоративній мережі, ви можете використовувати контекст користувача щоб переконатися, що вони можуть використовувати програму, лише коли мають корпоративну IP-адресу та ввійшли в систему свого користувача рахунок.

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

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

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

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

Більше про хмарні обчислення

7 основ добре підключених гібридних хмар

Підключена хмарна ера потребує кращих мереж

Згідно з новим звітом VMware, гібридна інфраструктура зростає для розгортання EUC (TechRepublic)

Oracle виділяє 9,3 мільярда доларів на піонера хмарних додатків NetSuite (CNET)