Ласкаво просимо до чергового випуску Microsoft Knowledge Nuggets. Я ваш ведучий Мірко Пітерс. Сьогоднішня тема – це те, про що чули майже всі, але мало хто розуміє – АРІ. Ви, напевно, часто чули цей термін. Це одне з тих технічних слів, які люди використовують, щоб здаватися знавцями справи. Але ось у чому річ – АРІ насправді прості. Це просто спосіб для однієї програми спілкуватися з іншою. Ваш телефон запитує дані у сервера. Сервер надсилає їх назад. Це і є виклик АРІ. Тепер уявіть, що у вас 20, 50 або 100 АРІ. Кожен із них може використовувати різну автентифікацію, ліміти запитів та документацію, якщо вона взагалі є. Раптом те, що починалося як проста розмова між двома програмами, перетворюється на повний хаос. Без централізованого управління кожна команда вигадує велосипед. Одна команда створює свою систему автентифікації, інша – власне логування. Звідусіль виникають прогалини в безпеці.

Розробники плутаються, який АРІ за що відповідає, і ви не маєте єдиного бачення того, що відбувається в усій вашій системі. Azure Ari Management вирішує цю проблему. Він надає вам єдиний центр керування. Сприймайте це як вежу авіадиспетчерської служби для ваших АРІ. До кінця цього випуску ви зрозумієте, що це насправді таке, чому це важливо і як усі елементи поєднуються разом. Беріть каву і почнемо. Проблема – забагато АРІ, жодного контролю. Ось реальність сучасного програмного забезпечення. Десятьох років тому у вас, ймовірно, був один великий застосунок Monolith – одна база даних, один АРІ – просто. Сьогодні той самий застосунок може бути розділений на десятки мікросервісів. Кожен сервіс відповідає за щось одне – облікові записи, платежі, інвентаризацію, сповіщення, і кожен має свій власний АРІ. Раптом у вас з'являється 10, 50, 100 різних точок входу до вашої системи. Тепер уявіть, що ви розробник, який намагається створити щось, що використовує ці АРІ.

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

Ви збираєте метрики з десятків різних панелей керування. Ось у чому річ. Зі зростанням масштабів це не просто приносить незручності. Система ламається. Ви не можете додавати нових розробників, сервіси чи клієнтів без центральної точки контролю. Уявіть це як будівлю. Уявіть, що в кожній кімнаті свій замок. Немає ні стійки реєстрації, ні показчиків. Відвідувачі блукають у пошуках потрібних дверей, дратуються і зрештою здаються. Повний хаос. Це проблема, для вирішення якої було створено АРІ Менеджмент. Що таке Azure АРІ Менеджмент? Це диспетчерська вежа. Отже, що саме таке Azure АРІ Менеджмент? Ось найпростіше визначення. Це керований сервіс, що стоїть між вашими внутрішніми АРІ та програмами, сайтами, пристроями і партнерами, які їх використовують. Але ось у чому суть. Це не просто проксі. Проксі лише пересилає трафік і все. Azure АРІ Менеджмент охоплює повний життєвий цикл ваших АРІ. Публікація, захист, моніторинг і, зрештою, виведення з експлуатації.

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

Це пункт управління, де ви налаштовуєте роботу всієї системи. І ще один компонент – портал розробника. Це сайт самообслуговування, де внутрішні та зовнішні розробники можуть знайти ваші арі, прочитати документацію, отримати ключі підписки і навіть протестувати виклики арі прямо в браузері. Більше ніяких пересилень PDF-файлів поштою. Ось аналогія, яка допоможе. Уявіть сучасний аеропорт. Шлюз – це злітно-посадкова смуга. Кожен літак приземляється там першим. Площина керування – це диспетчерська вежа. Вона спрямовує рух, встановлює правила та контролює все. А портал розробника – це інформаційне табло. Пілоти перевіряють його перед вилітом і знаходять усю необхідну інформацію, ні з ким не спілкуючись. Тепер заглибимося в роботу шлюзу. Це та частина, з якою безпосередньо взаємодіють ваші програми і де відбувається справжня магія. Шлюз – це вхідні двері вашого арі. Давайте поговоримо про шлюз, адже це та частина, з якою ваші програми взаємодіють напряму.

Кожен запит із мобільного додатка, веб-сайту чи адпристрою спочатку потрапляє на шлюз, а не прямо на ваш сервер. У цьому й полягає головна мета. Шлюз стоїть попереду і діє як єдина точка входу. Шлюз може застосовувати політики перед пересилкою запиту. Політики – це правила, які ви пишете в XML або JSON, наприклад, обмеження швидкості, фільтрація IP, перезапис заголовків та перевірка автентифікації. Усе це без зміни жодного рядка вашого серверного коду. Ось конкретний приклад. Припустімо, у вас є безкоштовний і преміальний рівні доступу до арі. За допомогою політики можна обмежити безкоштовних користувачів п'ятьма запитами на хвилину, тоді як преміум-користувачі отримують 100. Ваш сервер навіть не знає про цю різницю. Він просто обробляє запити. Шлюз бере на себе контроль за дотриманням правил. Шлюз також відповідає за кешування. Якщо дані запитуються знову і знову, як от список товарів, що рідко змінюється, шлюз може кешувати відповідь і надавати її безпосередньо.

Немає потреби взагалі турбувати ваш сервер, що означає швидші відповіді та менше навантаження на обладнання. Він також може трансформувати дані. Ваш сервер може повертати XML, але мобільний додаток очікує JSON. Шлюз може конвертувати їх на льоту. Вашому серверу не потрібно нічого змінювати, як і вашому додатку. Шлюз виконує цю трансформацію. Крім того, він записує кожен виклик, кожен запит, кожну відповідь і кожну помилку. Ви отримуєте повний аудиторський слід, хто, що, коли викликав і що сталося. Саме це вже є вагомою причиною для відповідності стандартам. Якщо у вас глобальна аудиторія, ви можете розгорнути шлюз у кількох регіонах. Трафік автоматично спрямовується до найближчого, що знижує затримку та покращує роботу. І ще одне – шлюз приховує справжню URL-адресу вашого сервера. Клієнти бачать лише адресу шлюзу. Ваші серверні потужності залишаються прихованими від інтернету. Це величезна перевага в безпеці одразу з коробки.

Політики – це рушій, який контролює все. Тож, що це за політики, про які я згадував? Вони є рушієм, який робить API-M справді потужним. Політика змінює поведінку запиту чи відповіді, не змушуючи вас торкатися серверного коду. Уявіть це як оболонку навколо вашого арі. Коли трафік проходить крізь неї, вона може автоматично додавати, видаляти або змінювати певні речі. Політики можуть працювати в чотирьох точках життєвого циклу запиту. Вхідні – інбаунд на шляху до сервера, перед тим, як запит досягне вашої системи. Вихідні – автбаунд на шляху назад, перед тим, як відповідь надійде клієнту. Серверні – бекенд безпосередньо перед тим, як запит потрапляє до сервісу. І під час помилки, коли щось йде не так. До типових вхідних операцій належить перевірка JWT-токенів для підтвердження особи, перевірка ARR-ключів, переписування URL-адрес та обмеження за IP-адресою.

Ви можете кешувати відповіді, щоб повторні запити не навантажували ваш бекенд. Можна навіть видаляти заголовки, що розкривають внутрішню інформацію. Ось конкретний приклад. Припустімо, ваш ARR-повертає описи продуктів, де всюди вживається слово «синій». Ви хочете провести ребрендинг і використовувати замість нього «жовтий». Замість зміни коду бекенду ви додаєте одну вихідну політику. Знайти «синій» замінити на «жовтий». І готово. Ваш бекенд залишається незмінним. Політики обмеження швидкості та квот захищають ваш бекенд від зловживань. Якщо чийсь додаток починає надсилати 10 тисяч запитів до ARR за секунду, політика втручається і каже «уповільніться». Ваш бекенд залишається працездатним. Потрібна розширена логіка. Ви можете писати власні сі вирази всередині політик. Вони компілюються для продуктивності. Отже, немає жодних витрат ресурсів під час виконання. Ви можете шукати ролі користувачів, обчислювати динамічні ліміти або умовно змінювати відповіді на основі заголовків запитів.

Головний висновок такий. Політики дозволяють керувати поведінкою ARR, не торкаючись коду, на якому вони працюють. Це означає швидші зміни, меншу кількість розгортань та менший ризик. Продукти та підписки – пакування ARR для споживачів. Тепер ваші ARR визначені, політики налаштовані, а шлюз стабільно працює. Але як надати різним клієнтам доступ до різних ресурсів? Саме тут стають у пригоді продукти та підписки. В APIM ви групуєте ARR у так званий продукт. Розглядаєте це як пакет послуг. Ви можете мати безкоштовний рівень продукту, що включає лише базові ARR. Можливо, лише доступ для читання, а потім преміум-продукт, що включає все, зокрема, операції, запису та адміністративні ендпоїнти. Розробники підписуються не на окремі ARR, а на продукт. Коли вони підписуються, вони отримують ключ підписки. Насправді два ключі, щоб ви могли змінювати один без зупинки роботи. Цей ключ – їхній пропуск до будь-якого ARR у складі продукту.

Ви керуєте тим, як працюють підписки. Продукти можуть потребувати схвалення. Ви можете вручну підтверджувати кожного підписника або дозволити самостійне оформлення. Будь-хто може зареєструватися і отримати миттєвий доступ. Ви також можете додати юридичні умови, які користувачі мають прийняти перед підпискою. Це важливо, якщо ваші ARR працюють із конфіденційними даними. Ось як можна монетизувати ARR. Безкоштовний продукт із низькими лімітами – 5 запитів на хвилину. Платний продукт із вищими лімітами чи більшою кількістю ендпоінтів – 100 запитів на хвилину плюс доступ до преміум-функцій. Вашому беккенду це байдуже. Шлюз застосовує обмеження залежно від того, на який продукт підписався користувач. Ось реальний приклад. Уявіть, що ви створюєте додаток для конференції. Ви створюєте продукт для відвідувачів з ARR для розкладу сесій, біографії спікерів та карти місця проведення. Потім спонсорський продукт, який також включає ARR для залучення лідів.

Спонсори можуть сканувати байді відвідувачів та отримувати контактну інформацію. Один і той самий беккенд, різні продукти, різні рівні доступу. Ці два ключі-підписки призначені для ротації. Якщо ключ скомпрометовано, ви генеруєте новий. Другий ключ дозволяє переключитися без переривання сервісу. Згенеруйте новий ключ, оновіть свій додаток, скасуйте старий. Безшовний процес. Портал розробника – самообслуговування для споживачів ARR. Отже, ви налаштували свої ARR продукти. Тепер розробники мають знайти їх. Це завдання порталу розробника. Портал розробника – це веб-сайт, вбудований у кожен екземпляр APIM. Розробники використовують його для перегляду ваших ARR, читання документації та тестування ендпинтів інтерактивно прямо в браузері. Жодних налаштувань і довгих переписок електронною поштою. Але є нюанс – за замовчуванням він не опублікуваний. Коли ви вперше створюєте екземпляр APIM, портал існує, але його ніхто не бачить.

Спершу його потрібно налаштувати та опублікувати. Це зроблено навмисно. Ви ж не хочете показувати світові недопрацьований портал. Ви можете налаштувати кольори бренду, логотипи та навіть вбудувати контент WordPress для блогу поруч із вашою документацією ARR. Він повністю адаптується під стиль вашої компанії. Справжня цінність – це самообслуговування. Розробники реєструються, автоматично отримують ключі підписки та одразу починають викликати ARR. Жодних ручних листів, очікувань на схвалення чи тікетів у підтримку з питанням, як отримати ключ. Вони роблять це самі, що значно знижує навантаження на підтримку. Ви також можете публікувати журнали змін та примітки до релізів. Коли ви оновлюєте ARR, розробники бачать це на порталі без жодних сюрпризів. Доступ може бути публічним для всіх, хто має URL, або ви можете обмежити його лише користувачами вашого орендаря EntraID, щоб лише люди з вашої організації могли переглядати портал.

Обидва варіанти існують для різних потреб. Портал розробника – це те, що робить ваше ARR управління повноцінною платформою. Вважайте це вітреною для ваших ARR. Без нього розробникам довелося б шукати документацію та постійно запитувати в інших. З ним вони знаходять усе необхідне і починають розробку. Безпека, автентифікація, авторизація та секрети. Уся ця потужність марна, якщо безпека не на належному рівні. Тож давайте поговоримо про те, як APIM працює з ідентифікацією, доступом та секретами. APIM підтримує декілька методів автентифікації. Найпростіший – це ключі підписки, про які ми згадували раніше. Але для продуктивних систем вам потрібно щось надійніше, як от OOT 2.0, JWT-токени, сертифікати клієнтів або IP-фільтрація. Ви комбінуєте їх залежно від того, наскільки конфіденційним є ваш ARR. Для продуктивного середовища найкращою практикою є використання OOT 2.0 з EntraID. Ось як це працює.

Клієнтський додаток отримує токен від EntraID і надсилає його разом із запитом до ARR. APIM перевіряє токен, звіряючи підпис, видавця, аудиторію та термін дії. Якщо він дійсний, APIM пересилає запит до вашого бекінда разом із токеном. Ваш бекінд довіряє йому, оскільки APIM уже виконав перевірку, тому бекінду не потрібно повторно валідувати. Це ще одна річ, якою не потрібно займатися кожному окремому сервісу. Тепер поговоримо про секрети. ARR-ключі, рядки підключення, сертифікати – ви не повинні жорстко прописувати їх у файлах, політик чи системі контролю версій. APIM має функцію під назвою іменовані значення – named values. Ви зберігаєте секрети централізовано в APIM і посилаєтеся на них за назвою у своїх політиках. Фактичне значення ніколи не з'являється у коді ваших політик. Ба більше, ви можете підключити іменовані значення до Azure Key Vault. Секрети залишаються зашифрованими в Key Vault, а APIM отримує їх під час виконання.

Ніхто, навіть ваша DevOps-команда, не бачить реального значення секрету. Коли потрібно оновити ключ, ви змінюєте його в Key Vault, і APIM автоматично підхоплює зміни. APIM також підтримує керовані ідентифікатори Managed Identities. Це дозволяє APIM автентифікуватися в інших сервісах Azure, таких як Key Vault або Arie Backend, не зберігаючи жодних облікових даних. Azure керує ідентифікацією, тому вам потрібно лише надати відповідні дозволи. А для мережової ізоляції ви можете розгорнути APIM всередині віртуальної мережі. Це рівень преміум. Або розмістити Azure Front до суть у тому, що ваші бекенд-сервіси ніколи не повинні бути напряму відкриті в інтернеті. APIM – це єдине, що бачить зовнішній світ. Такий багаторівневий підхід забезпечує глибокий захист. Автентифікація на шлюзі, секрети у сховищі, мережова ізоляція навколо бекендів. Кожен рівень посилює наступний. Тарифні плани, який з них підходить вам.

Отже, яка вартість? Давайте розглянемо ці рівні. Рівень споживання – consumption. Оплата за виклик Arie без фіксованої щомісячної вартості. Ідеально для невеликих обсягів або епізодичних навантажень, наприклад, під час створення прототипів. Якщо ви ще не впевнені, що саме вам потрібно, почніть з цього. Рівень для розробників Davelop пропонує фіксовану низку щомісячну плату близько 50 доларів. Повний набір функцій, але без SLA. Ідеально для середовищ розробки та тестування. Ви отримуєте все те саме, що й у преміум, але не можете використовувати це для продуктивних цілей. Базовий рівень Basic – це початковий рівень для продуктивного використання. Менша пропускна здатність, відсутність підтримки віртуальних мереж, але ви отримуєте справжній SLA. Підходить для внутрішніх інструментів або малих проєктів, де приватна мережа не є критичною. Більшість компаній обирають стандартний рівень. Він включає підтримку віртуальних мереж SLA 99,95% та високу пропускну здатність.

Якщо ви використовуєте критично важливі ARRI, швидше за все, ви зупинитеся на цьому. Рівень преміум призначений для глобальних корпорацій, яким потрібна максимальна надійність і приватні мережі. Розгортання в багатьох регіонах, власний шлюз SLA 99,99% та повна інтеграція з віртуальними мережами. Ціна стартує приблизно від 2700 на місяць за одиницю. Майкрософт також представила рівні V2, Basic V2, Standard V2 та Premium V2. Вони спрощують ціноутворення завдяки включеним квотам запитів та оплаті за кожен мільйон понад ліміт. Замість відстеження багатьох метрик, ви отримуєте чіткий обсяг запитів і платите за додаткове використання простими частинами. Ось як зробити вибір. Починайте з Davelope для тестування. Переходьте на Standard для виробничого середовища. Обирайте Premium, якщо вам потрібен глобальний масштаб або приватна мережа. І пам'ятайте, ви завжди можете змінити рівень пізніше. Починайте з малого і зростаєте в міру зміни потреб.

Ось що ми розглянули. Керування ARRI впорядковує хаос багатьох ARRI, об'єднуючи їх у єдиний центр керування шлюзами, політиками, безпекою та розробкою. Головний висновок – це не просто проксі. Сприймайте це як мозок і нервову систему вашої ARRI-екосистеми. Без нього кожна команда створює власну автентифікацію, логування та обмеження швидкості. Ви отримуєте неузгодженість, прогалини в безпеці та відсутність цілісного бачення того, що відбувається. З ним ви отримуєте послідовність, безпеку та масштабованість, не ви находячи велосипед для кожної служби. Ось проста вправа. Згадайте один ARRI, який ви зараз надаєте напряму. Можливо, це кінцева точка функції або сервіс програми. Як розміщення ARRI-менеджмент перед ним змінить ваш стан безпеки та можливість відстежувати використання. Навіть просте обдумування цієї вправи покаже вам цінність. Наступний крок – підпишіться на канал. У наступних епізодах ми покажемо, як імпортувати ARRI, застосувати першу політику та моніторити використання в реальному часі.

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