WEBVTT 00:00:00.060 --> 00:00:02.660 Ласкаво просимо до чергового випуску Microsoft Knowledge Nuggets. 00:00:02.820 --> 00:00:04.400 Я ваш ведучий Мірко Пітерс. 00:00:04.640 --> 00:00:08.440 Сьогоднішня тема – це те, про що чули майже всі, але мало хто розуміє – АРІ. 00:00:08.580 --> 00:00:10.580 Ви, напевно, часто чули цей термін. 00:00:10.720 --> 00:00:14.800 Це одне з тих технічних слів, які люди використовують, щоб здаватися знавцями справи. 00:00:14.920 --> 00:00:17.080 Але ось у чому річ – АРІ насправді прості. 00:00:17.220 --> 00:00:19.860 Це просто спосіб для однієї програми спілкуватися з іншою. 00:00:20.020 --> 00:00:21.700 Ваш телефон запитує дані у сервера. 00:00:21.860 --> 00:00:23.100 Сервер надсилає їх назад. 00:00:23.280 --> 00:00:24.320 Це і є виклик АРІ. 00:00:24.320 --> 00:00:26.960 Тепер уявіть, що у вас 20, 50 або 100 АРІ. 00:00:27.100 --> 00:00:31.800 Кожен із них може використовувати різну автентифікацію, ліміти запитів та документацію, якщо вона взагалі є. 00:00:31.940 --> 00:00:36.140 Раптом те, що починалося як проста розмова між двома програмами, перетворюється на повний хаос. 00:00:36.300 --> 00:00:39.300 Без централізованого управління кожна команда вигадує велосипед. 00:00:39.420 --> 00:00:42.740 Одна команда створює свою систему автентифікації, інша – власне логування. 00:00:42.920 --> 00:00:44.820 Звідусіль виникають прогалини в безпеці. 00:00:44.820 --> 00:00:50.260 Розробники плутаються, який АРІ за що відповідає, і ви не маєте єдиного бачення того, що відбувається в усій вашій системі. 00:00:50.380 --> 00:00:52.340 Azure Ari Management вирішує цю проблему. 00:00:52.540 --> 00:00:54.360 Він надає вам єдиний центр керування. 00:00:54.580 --> 00:00:57.780 Сприймайте це як вежу авіадиспетчерської служби для ваших АРІ. 00:00:57.920 --> 00:01:03.680 До кінця цього випуску ви зрозумієте, що це насправді таке, чому це важливо і як усі елементи поєднуються разом. 00:01:03.860 --> 00:01:05.340 Беріть каву і почнемо. 00:01:05.600 --> 00:01:08.120 Проблема – забагато АРІ, жодного контролю. 00:01:08.280 --> 00:01:10.620 Ось реальність сучасного програмного забезпечення. 00:01:10.620 --> 00:01:16.120 Десятьох років тому у вас, ймовірно, був один великий застосунок Monolith – одна база даних, один АРІ – просто. 00:01:16.340 --> 00:01:19.980 Сьогодні той самий застосунок може бути розділений на десятки мікросервісів. 00:01:20.100 --> 00:01:25.720 Кожен сервіс відповідає за щось одне – облікові записи, платежі, інвентаризацію, сповіщення, і кожен має свій власний АРІ. 00:01:25.860 --> 00:01:29.280 Раптом у вас з'являється 10, 50, 100 різних точок входу до вашої системи. 00:01:29.360 --> 00:01:32.700 Тепер уявіть, що ви розробник, який намагається створити щось, що використовує ці АРІ. 00:01:32.700 --> 00:01:35.720 Вам потрібно знайти кожен із них і розібратися з автентифікацією для кожного. 00:01:35.900 --> 00:01:38.740 Деякі використовують ключі АРІ, деякі ООД, деякі взагалі нічого. 00:01:38.900 --> 00:01:41.880 Вам потрібно вручну керувати лімітами запитів, інакше ви ризикуєте отримати блокування. 00:01:42.020 --> 00:01:44.520 Вам потрібно розуміти формат даних, який очікує кожен із них. 00:01:44.640 --> 00:01:45.480 Це виснажливо. 00:01:45.680 --> 00:01:47.900 Із погляду операційної діяльності стає ще гірше. 00:01:48.040 --> 00:01:51.740 Без центрального шлюзу кожна команда повинна вручну додавати безпеку та логування до свого сервісу. 00:01:51.740 --> 00:01:54.360 Одні команди роблять це добре, інші забувають логувати помилки. 00:01:54.540 --> 00:01:56.320 Деякі взагалі не перевіряють вхідні дані. 00:01:56.440 --> 00:01:59.520 Це непослідовно і схильно до помилок, справжній кошмар у сфері безпеки. 00:01:59.660 --> 00:02:01.520 Дотримання вимог стає майже неможливим. 00:02:01.640 --> 00:02:03.720 Потрібно довести, хто і коли отримував доступ. 00:02:03.860 --> 00:02:07.720 Успіхів зі збором аудиторських журналів із 20 різних сервісів, кожен з яких має власний формат логування. 00:02:07.860 --> 00:02:11.060 Потрібно дізнатися, скільки АРІ запитів обробила ваша система минулого місяця. 00:02:11.060 --> 00:02:13.740 Ви збираєте метрики з десятків різних панелей керування. 00:02:13.900 --> 00:02:14.700 Ось у чому річ. 00:02:14.880 --> 00:02:17.000 Зі зростанням масштабів це не просто приносить незручності. 00:02:17.140 --> 00:02:18.060 Система ламається. 00:02:18.240 --> 00:02:21.380 Ви не можете додавати нових розробників, сервіси чи клієнтів без центральної точки контролю. 00:02:21.520 --> 00:02:22.640 Уявіть це як будівлю. 00:02:22.780 --> 00:02:24.640 Уявіть, що в кожній кімнаті свій замок. 00:02:24.800 --> 00:02:26.840 Немає ні стійки реєстрації, ні показчиків. 00:02:27.040 --> 00:02:30.880 Відвідувачі блукають у пошуках потрібних дверей, дратуються і зрештою здаються. 00:02:31.060 --> 00:02:31.920 Повний хаос. 00:02:31.920 --> 00:02:35.020 Це проблема, для вирішення якої було створено АРІ Менеджмент. 00:02:35.240 --> 00:02:36.860 Що таке Azure АРІ Менеджмент? 00:02:37.020 --> 00:02:38.340 Це диспетчерська вежа. 00:02:38.480 --> 00:02:40.620 Отже, що саме таке Azure АРІ Менеджмент? 00:02:40.820 --> 00:02:42.260 Ось найпростіше визначення. 00:02:42.400 --> 00:02:45.460 Це керований сервіс, що стоїть між вашими внутрішніми АРІ та програмами, 00:02:45.600 --> 00:02:48.180 сайтами, пристроями і партнерами, які їх використовують. 00:02:48.260 --> 00:02:49.200 Але ось у чому суть. 00:02:49.340 --> 00:02:50.260 Це не просто проксі. 00:02:50.420 --> 00:02:52.260 Проксі лише пересилає трафік і все. 00:02:52.420 --> 00:02:55.220 Azure АРІ Менеджмент охоплює повний життєвий цикл ваших АРІ. 00:02:55.220 --> 00:02:58.240 Публікація, захист, моніторинг і, зрештою, виведення з експлуатації. 00:02:58.400 --> 00:02:59.820 Це повноцінний центр керування. 00:03:00.000 --> 00:03:01.740 Розділімо його на три основні компоненти. 00:03:01.880 --> 00:03:03.240 Перший – це шлюз, гейтвей. 00:03:03.380 --> 00:03:04.320 Це вхідні двері. 00:03:04.460 --> 00:03:07.340 Кожен вхідний запит від програми чи сайту спершу потрапляє на шлюз, 00:03:07.420 --> 00:03:08.480 а не напряму на ваш сервер. 00:03:08.640 --> 00:03:11.280 Шлюз обробляє запит, застосовує налаштовані політики, 00:03:11.400 --> 00:03:14.320 збирає метрики, а потім пересилає його до потрібного сервісу. 00:03:14.440 --> 00:03:16.400 Уявіть його як регулювальника трафіку. 00:03:16.640 --> 00:03:18.060 Далі – площина керування. 00:03:25.220 --> 00:03:30.780 Це пункт управління, де ви налаштовуєте роботу всієї системи. 00:03:30.860 --> 00:03:32.820 І ще один компонент – портал розробника. 00:03:32.980 --> 00:03:35.620 Це сайт самообслуговування, де внутрішні та зовнішні розробники 00:03:35.620 --> 00:03:37.700 можуть знайти ваші арі, прочитати документацію, 00:03:37.800 --> 00:03:41.000 отримати ключі підписки і навіть протестувати виклики арі прямо в браузері. 00:03:41.140 --> 00:03:43.260 Більше ніяких пересилень PDF-файлів поштою. 00:03:43.400 --> 00:03:44.740 Ось аналогія, яка допоможе. 00:03:44.900 --> 00:03:46.160 Уявіть сучасний аеропорт. 00:03:46.320 --> 00:03:47.740 Шлюз – це злітно-посадкова смуга. 00:03:47.740 --> 00:03:49.500 Кожен літак приземляється там першим. 00:03:49.500 --> 00:03:51.540 Площина керування – це диспетчерська вежа. 00:03:51.660 --> 00:03:54.260 Вона спрямовує рух, встановлює правила та контролює все. 00:03:54.420 --> 00:03:56.540 А портал розробника – це інформаційне табло. 00:03:56.660 --> 00:03:59.740 Пілоти перевіряють його перед вилітом і знаходять усю необхідну інформацію, 00:03:59.840 --> 00:04:00.760 ні з ким не спілкуючись. 00:04:00.880 --> 00:04:02.540 Тепер заглибимося в роботу шлюзу. 00:04:02.680 --> 00:04:05.260 Це та частина, з якою безпосередньо взаємодіють ваші програми 00:04:05.260 --> 00:04:06.660 і де відбувається справжня магія. 00:04:06.840 --> 00:04:08.760 Шлюз – це вхідні двері вашого арі. 00:04:08.920 --> 00:04:11.080 Давайте поговоримо про шлюз, адже це та частина, 00:04:11.080 --> 00:04:13.100 з якою ваші програми взаємодіють напряму. 00:04:13.240 --> 00:04:15.840 Кожен запит із мобільного додатка, веб-сайту чи адпристрою 00:04:15.840 --> 00:04:18.160 спочатку потрапляє на шлюз, а не прямо на ваш сервер. 00:04:18.300 --> 00:04:19.860 У цьому й полягає головна мета. 00:04:20.000 --> 00:04:22.560 Шлюз стоїть попереду і діє як єдина точка входу. 00:04:22.680 --> 00:04:25.460 Шлюз може застосовувати політики перед пересилкою запиту. 00:04:25.620 --> 00:04:27.940 Політики – це правила, які ви пишете в XML або JSON, 00:04:28.160 --> 00:04:30.080 наприклад, обмеження швидкості, фільтрація IP, 00:04:30.260 --> 00:04:32.120 перезапис заголовків та перевірка автентифікації. 00:04:32.120 --> 00:04:34.780 Усе це без зміни жодного рядка вашого серверного коду. 00:04:34.960 --> 00:04:36.120 Ось конкретний приклад. 00:04:36.240 --> 00:04:39.120 Припустімо, у вас є безкоштовний і преміальний рівні доступу до арі. 00:04:39.260 --> 00:04:41.320 За допомогою політики можна обмежити безкоштовних користувачів 00:04:41.320 --> 00:04:43.660 п'ятьма запитами на хвилину, тоді як преміум-користувачі отримують 100. 00:04:43.800 --> 00:04:45.560 Ваш сервер навіть не знає про цю різницю. 00:04:45.720 --> 00:04:47.040 Він просто обробляє запити. 00:04:47.240 --> 00:04:49.140 Шлюз бере на себе контроль за дотриманням правил. 00:04:49.260 --> 00:04:51.020 Шлюз також відповідає за кешування. 00:04:51.200 --> 00:04:53.840 Якщо дані запитуються знову і знову, як от список товарів, 00:04:53.840 --> 00:04:57.500 що рідко змінюється, шлюз може кешувати відповідь і надавати її безпосередньо. 00:04:57.620 --> 00:04:59.400 Немає потреби взагалі турбувати ваш сервер, 00:04:59.540 --> 00:05:02.220 що означає швидші відповіді та менше навантаження на обладнання. 00:05:02.400 --> 00:05:04.000 Він також може трансформувати дані. 00:05:04.160 --> 00:05:07.340 Ваш сервер може повертати XML, але мобільний додаток очікує JSON. 00:05:07.700 --> 00:05:09.440 Шлюз може конвертувати їх на льоту. 00:05:09.620 --> 00:05:12.620 Вашому серверу не потрібно нічого змінювати, як і вашому додатку. 00:05:12.780 --> 00:05:14.480 Шлюз виконує цю трансформацію. 00:05:14.480 --> 00:05:18.040 Крім того, він записує кожен виклик, кожен запит, кожну відповідь і кожну помилку. 00:05:18.180 --> 00:05:21.460 Ви отримуєте повний аудиторський слід, хто, що, коли викликав і що сталося. 00:05:21.640 --> 00:05:24.340 Саме це вже є вагомою причиною для відповідності стандартам. 00:05:24.500 --> 00:05:28.140 Якщо у вас глобальна аудиторія, ви можете розгорнути шлюз у кількох регіонах. 00:05:28.260 --> 00:05:32.780 Трафік автоматично спрямовується до найближчого, що знижує затримку та покращує роботу. 00:05:32.940 --> 00:05:35.980 І ще одне – шлюз приховує справжню URL-адресу вашого сервера. 00:05:36.100 --> 00:05:37.800 Клієнти бачать лише адресу шлюзу. 00:05:37.800 --> 00:05:40.340 Ваші серверні потужності залишаються прихованими від інтернету. 00:05:40.440 --> 00:05:42.760 Це величезна перевага в безпеці одразу з коробки. 00:05:42.880 --> 00:05:45.060 Політики – це рушій, який контролює все. 00:05:45.240 --> 00:05:47.280 Тож, що це за політики, про які я згадував? 00:05:47.420 --> 00:05:50.040 Вони є рушієм, який робить API-M справді потужним. 00:05:50.160 --> 00:05:54.160 Політика змінює поведінку запиту чи відповіді, не змушуючи вас торкатися серверного коду. 00:05:54.360 --> 00:05:56.460 Уявіть це як оболонку навколо вашого арі. 00:05:56.620 --> 00:06:00.660 Коли трафік проходить крізь неї, вона може автоматично додавати, видаляти або змінювати певні речі. 00:06:00.660 --> 00:06:03.640 Політики можуть працювати в чотирьох точках життєвого циклу запиту. 00:06:03.800 --> 00:06:07.260 Вхідні – інбаунд на шляху до сервера, перед тим, як запит досягне вашої системи. 00:06:07.360 --> 00:06:10.420 Вихідні – автбаунд на шляху назад, перед тим, як відповідь надійде клієнту. 00:06:10.600 --> 00:06:13.560 Серверні – бекенд безпосередньо перед тим, як запит потрапляє до сервісу. 00:06:13.660 --> 00:06:15.540 І під час помилки, коли щось йде не так. 00:06:15.700 --> 00:06:19.340 До типових вхідних операцій належить перевірка JWT-токенів для підтвердження особи, 00:06:19.420 --> 00:06:22.860 перевірка ARR-ключів, переписування URL-адрес та обмеження за IP-адресою. 00:06:30.660 --> 00:06:35.260 Ви можете кешувати відповіді, щоб повторні запити не навантажували ваш бекенд. 00:06:35.420 --> 00:06:38.300 Можна навіть видаляти заголовки, що розкривають внутрішню інформацію. 00:06:38.440 --> 00:06:39.520 Ось конкретний приклад. 00:06:39.660 --> 00:06:43.160 Припустімо, ваш ARR-повертає описи продуктів, де всюди вживається слово «синій». 00:06:43.160 --> 00:06:46.160 Ви хочете провести ребрендинг і використовувати замість нього «жовтий». 00:06:46.160 --> 00:06:49.400 Замість зміни коду бекенду ви додаєте одну вихідну політику. 00:06:49.580 --> 00:06:51.740 Знайти «синій» замінити на «жовтий». 00:06:51.740 --> 00:06:54.280 І готово. Ваш бекенд залишається незмінним. 00:06:54.280 --> 00:06:57.540 Політики обмеження швидкості та квот захищають ваш бекенд від зловживань. 00:06:57.640 --> 00:07:00.920 Якщо чийсь додаток починає надсилати 10 тисяч запитів до ARR за секунду, 00:07:01.020 --> 00:07:03.120 політика втручається і каже «уповільніться». 00:07:03.120 --> 00:07:04.900 Ваш бекенд залишається працездатним. 00:07:05.060 --> 00:07:06.340 Потрібна розширена логіка. 00:07:06.560 --> 00:07:08.840 Ви можете писати власні сі вирази всередині політик. 00:07:08.940 --> 00:07:10.460 Вони компілюються для продуктивності. 00:07:10.600 --> 00:07:12.660 Отже, немає жодних витрат ресурсів під час виконання. 00:07:12.820 --> 00:07:15.480 Ви можете шукати ролі користувачів, обчислювати динамічні ліміти 00:07:15.480 --> 00:07:18.000 або умовно змінювати відповіді на основі заголовків запитів. 00:07:18.100 --> 00:07:19.340 Головний висновок такий. 00:07:19.460 --> 00:07:21.600 Політики дозволяють керувати поведінкою ARR, 00:07:21.680 --> 00:07:23.840 не торкаючись коду, на якому вони працюють. 00:07:23.980 --> 00:07:27.540 Це означає швидші зміни, меншу кількість розгортань та менший ризик. 00:07:27.680 --> 00:07:30.740 Продукти та підписки – пакування ARR для споживачів. 00:07:30.900 --> 00:07:35.040 Тепер ваші ARR визначені, політики налаштовані, а шлюз стабільно працює. 00:07:35.180 --> 00:07:38.280 Але як надати різним клієнтам доступ до різних ресурсів? 00:07:38.440 --> 00:07:40.820 Саме тут стають у пригоді продукти та підписки. 00:07:40.820 --> 00:07:43.780 В APIM ви групуєте ARR у так званий продукт. 00:07:43.940 --> 00:07:45.540 Розглядаєте це як пакет послуг. 00:07:45.700 --> 00:07:49.180 Ви можете мати безкоштовний рівень продукту, що включає лише базові ARR. 00:07:49.380 --> 00:07:52.180 Можливо, лише доступ для читання, а потім преміум-продукт, 00:07:52.280 --> 00:07:55.780 що включає все, зокрема, операції, запису та адміністративні ендпоїнти. 00:07:56.040 --> 00:07:58.820 Розробники підписуються не на окремі ARR, а на продукт. 00:07:58.960 --> 00:08:01.560 Коли вони підписуються, вони отримують ключ підписки. 00:08:01.740 --> 00:08:04.720 Насправді два ключі, щоб ви могли змінювати один без зупинки роботи. 00:08:04.860 --> 00:08:07.560 Цей ключ – їхній пропуск до будь-якого ARR у складі продукту. 00:08:07.560 --> 00:08:09.560 Ви керуєте тим, як працюють підписки. 00:08:09.680 --> 00:08:11.440 Продукти можуть потребувати схвалення. 00:08:11.600 --> 00:08:15.040 Ви можете вручну підтверджувати кожного підписника або дозволити самостійне оформлення. 00:08:15.220 --> 00:08:17.440 Будь-хто може зареєструватися і отримати миттєвий доступ. 00:08:17.640 --> 00:08:20.880 Ви також можете додати юридичні умови, які користувачі мають прийняти перед підпискою. 00:08:21.020 --> 00:08:23.500 Це важливо, якщо ваші ARR працюють із конфіденційними даними. 00:08:23.660 --> 00:08:25.120 Ось як можна монетизувати ARR. 00:08:25.380 --> 00:08:28.200 Безкоштовний продукт із низькими лімітами – 5 запитів на хвилину. 00:08:28.200 --> 00:08:33.100 Платний продукт із вищими лімітами чи більшою кількістю ендпоінтів – 100 запитів на хвилину плюс доступ до преміум-функцій. 00:08:33.220 --> 00:08:34.560 Вашому беккенду це байдуже. 00:08:34.700 --> 00:08:37.900 Шлюз застосовує обмеження залежно від того, на який продукт підписався користувач. 00:08:38.020 --> 00:08:39.000 Ось реальний приклад. 00:08:39.160 --> 00:08:41.300 Уявіть, що ви створюєте додаток для конференції. 00:08:41.480 --> 00:08:45.720 Ви створюєте продукт для відвідувачів з ARR для розкладу сесій, біографії спікерів та карти місця проведення. 00:08:45.880 --> 00:08:48.960 Потім спонсорський продукт, який також включає ARR для залучення лідів. 00:08:48.960 --> 00:08:52.140 Спонсори можуть сканувати байді відвідувачів та отримувати контактну інформацію. 00:08:52.260 --> 00:08:55.040 Один і той самий беккенд, різні продукти, різні рівні доступу. 00:08:55.160 --> 00:08:57.480 Ці два ключі-підписки призначені для ротації. 00:08:57.720 --> 00:09:00.260 Якщо ключ скомпрометовано, ви генеруєте новий. 00:09:00.440 --> 00:09:03.340 Другий ключ дозволяє переключитися без переривання сервісу. 00:09:03.500 --> 00:09:06.520 Згенеруйте новий ключ, оновіть свій додаток, скасуйте старий. 00:09:06.700 --> 00:09:07.680 Безшовний процес. 00:09:07.820 --> 00:09:10.500 Портал розробника – самообслуговування для споживачів ARR. 00:09:10.660 --> 00:09:12.580 Отже, ви налаштували свої ARR продукти. 00:09:12.580 --> 00:09:14.260 Тепер розробники мають знайти їх. 00:09:14.420 --> 00:09:15.920 Це завдання порталу розробника. 00:09:16.060 --> 00:09:19.140 Портал розробника – це веб-сайт, вбудований у кожен екземпляр APIM. 00:09:19.320 --> 00:09:21.420 Розробники використовують його для перегляду ваших ARR, 00:09:21.520 --> 00:09:24.740 читання документації та тестування ендпинтів інтерактивно прямо в браузері. 00:09:24.880 --> 00:09:27.360 Жодних налаштувань і довгих переписок електронною поштою. 00:09:27.500 --> 00:09:29.840 Але є нюанс – за замовчуванням він не опублікуваний. 00:09:29.980 --> 00:09:33.500 Коли ви вперше створюєте екземпляр APIM, портал існує, але його ніхто не бачить. 00:09:33.500 --> 00:09:35.660 Спершу його потрібно налаштувати та опублікувати. 00:09:35.800 --> 00:09:36.920 Це зроблено навмисно. 00:09:37.080 --> 00:09:39.420 Ви ж не хочете показувати світові недопрацьований портал. 00:09:39.560 --> 00:09:41.240 Ви можете налаштувати кольори бренду, логотипи 00:09:41.240 --> 00:09:44.380 та навіть вбудувати контент WordPress для блогу поруч із вашою документацією ARR. 00:09:44.480 --> 00:09:47.000 Він повністю адаптується під стиль вашої компанії. 00:09:47.200 --> 00:09:49.240 Справжня цінність – це самообслуговування. 00:09:49.440 --> 00:09:52.500 Розробники реєструються, автоматично отримують ключі підписки 00:09:52.500 --> 00:09:54.220 та одразу починають викликати ARR. 00:09:54.380 --> 00:09:56.980 Жодних ручних листів, очікувань на схвалення чи тікетів 00:09:56.980 --> 00:09:58.880 у підтримку з питанням, як отримати ключ. 00:09:59.060 --> 00:10:02.120 Вони роблять це самі, що значно знижує навантаження на підтримку. 00:10:02.280 --> 00:10:05.040 Ви також можете публікувати журнали змін та примітки до релізів. 00:10:05.160 --> 00:10:08.840 Коли ви оновлюєте ARR, розробники бачать це на порталі без жодних сюрпризів. 00:10:09.000 --> 00:10:11.200 Доступ може бути публічним для всіх, хто має URL, 00:10:11.380 --> 00:10:14.480 або ви можете обмежити його лише користувачами вашого орендаря EntraID, 00:10:14.680 --> 00:10:17.200 щоб лише люди з вашої організації могли переглядати портал. 00:10:17.320 --> 00:10:19.380 Обидва варіанти існують для різних потреб. 00:10:19.380 --> 00:10:23.080 Портал розробника – це те, що робить ваше ARR управління повноцінною платформою. 00:10:23.240 --> 00:10:24.980 Вважайте це вітреною для ваших ARR. 00:10:25.160 --> 00:10:28.640 Без нього розробникам довелося б шукати документацію та постійно запитувати в інших. 00:10:28.800 --> 00:10:31.680 З ним вони знаходять усе необхідне і починають розробку. 00:10:31.960 --> 00:10:35.240 Безпека, автентифікація, авторизація та секрети. 00:10:35.400 --> 00:10:38.460 Уся ця потужність марна, якщо безпека не на належному рівні. 00:10:38.620 --> 00:10:42.280 Тож давайте поговоримо про те, як APIM працює з ідентифікацією, доступом та секретами. 00:10:42.420 --> 00:10:44.820 APIM підтримує декілька методів автентифікації. 00:10:44.820 --> 00:10:47.800 Найпростіший – це ключі підписки, про які ми згадували раніше. 00:10:47.960 --> 00:10:54.180 Але для продуктивних систем вам потрібно щось надійніше, як от OOT 2.0, JWT-токени, сертифікати клієнтів або IP-фільтрація. 00:10:54.300 --> 00:10:57.080 Ви комбінуєте їх залежно від того, наскільки конфіденційним є ваш ARR. 00:10:57.260 --> 00:11:00.820 Для продуктивного середовища найкращою практикою є використання OOT 2.0 з EntraID. 00:11:01.000 --> 00:11:02.020 Ось як це працює. 00:11:02.140 --> 00:11:06.100 Клієнтський додаток отримує токен від EntraID і надсилає його разом із запитом до ARR. 00:11:06.100 --> 00:11:10.440 APIM перевіряє токен, звіряючи підпис, видавця, аудиторію та термін дії. 00:11:10.620 --> 00:11:14.480 Якщо він дійсний, APIM пересилає запит до вашого бекінда разом із токеном. 00:11:14.640 --> 00:11:19.240 Ваш бекінд довіряє йому, оскільки APIM уже виконав перевірку, тому бекінду не потрібно повторно валідувати. 00:11:19.380 --> 00:11:22.260 Це ще одна річ, якою не потрібно займатися кожному окремому сервісу. 00:11:22.380 --> 00:11:23.800 Тепер поговоримо про секрети. 00:11:23.920 --> 00:11:28.540 ARR-ключі, рядки підключення, сертифікати – ви не повинні жорстко прописувати їх у файлах, політик чи системі контролю версій. 00:11:28.540 --> 00:11:31.360 APIM має функцію під назвою іменовані значення – named values. 00:11:31.500 --> 00:11:35.300 Ви зберігаєте секрети централізовано в APIM і посилаєтеся на них за назвою у своїх політиках. 00:11:35.420 --> 00:11:38.060 Фактичне значення ніколи не з'являється у коді ваших політик. 00:11:38.180 --> 00:11:41.020 Ба більше, ви можете підключити іменовані значення до Azure Key Vault. 00:11:41.200 --> 00:11:44.520 Секрети залишаються зашифрованими в Key Vault, а APIM отримує їх під час виконання. 00:11:44.680 --> 00:11:47.800 Ніхто, навіть ваша DevOps-команда, не бачить реального значення секрету. 00:11:47.920 --> 00:11:52.500 Коли потрібно оновити ключ, ви змінюєте його в Key Vault, і APIM автоматично підхоплює зміни. 00:11:52.500 --> 00:11:55.760 APIM також підтримує керовані ідентифікатори Managed Identities. 00:11:55.900 --> 00:12:01.820 Це дозволяє APIM автентифікуватися в інших сервісах Azure, таких як Key Vault або Arie Backend, не зберігаючи жодних облікових даних. 00:12:01.940 --> 00:12:05.000 Azure керує ідентифікацією, тому вам потрібно лише надати відповідні дозволи. 00:12:05.120 --> 00:12:08.880 А для мережової ізоляції ви можете розгорнути APIM всередині віртуальної мережі. 00:12:09.020 --> 00:12:10.140 Це рівень преміум. 00:12:10.320 --> 00:12:17.240 Або розмістити Azure Front до суть у тому, що ваші бекенд-сервіси ніколи не повинні бути напряму відкриті в інтернеті. 00:12:17.240 --> 00:12:23.000 APIM – це єдине, що бачить зовнішній світ. Такий багаторівневий підхід забезпечує глибокий захист. 00:12:23.440 --> 00:12:27.640 Автентифікація на шлюзі, секрети у сховищі, мережова ізоляція навколо бекендів. 00:12:27.760 --> 00:12:31.860 Кожен рівень посилює наступний. Тарифні плани, який з них підходить вам. 00:12:32.040 --> 00:12:34.700 Отже, яка вартість? Давайте розглянемо ці рівні. 00:12:34.840 --> 00:12:36.140 Рівень споживання – consumption. 00:12:36.400 --> 00:12:38.720 Оплата за виклик Arie без фіксованої щомісячної вартості. 00:12:38.720 --> 00:12:42.220 Ідеально для невеликих обсягів або епізодичних навантажень, наприклад, під час створення прототипів. 00:12:42.320 --> 00:12:44.600 Якщо ви ще не впевнені, що саме вам потрібно, почніть з цього. 00:12:44.760 --> 00:12:48.160 Рівень для розробників Davelop пропонує фіксовану низку щомісячну плату близько 50 доларів. 00:12:48.260 --> 00:12:49.720 Повний набір функцій, але без SLA. 00:12:49.900 --> 00:12:51.560 Ідеально для середовищ розробки та тестування. 00:12:51.720 --> 00:12:54.540 Ви отримуєте все те саме, що й у преміум, але не можете використовувати це для продуктивних цілей. 00:12:54.680 --> 00:12:56.820 Базовий рівень Basic – це початковий рівень для продуктивного використання. 00:12:56.820 --> 00:13:00.340 Менша пропускна здатність, відсутність підтримки віртуальних мереж, але ви отримуєте справжній SLA. 00:13:00.520 --> 00:13:04.300 Підходить для внутрішніх інструментів або малих проєктів, де приватна мережа не є критичною. 00:13:04.460 --> 00:13:06.560 Більшість компаній обирають стандартний рівень. 00:13:06.720 --> 00:13:11.640 Він включає підтримку віртуальних мереж SLA 99,95% та високу пропускну здатність. 00:13:11.800 --> 00:13:15.340 Якщо ви використовуєте критично важливі ARRI, швидше за все, ви зупинитеся на цьому. 00:13:15.500 --> 00:13:19.900 Рівень преміум призначений для глобальних корпорацій, яким потрібна максимальна надійність і приватні мережі. 00:13:19.900 --> 00:13:25.680 Розгортання в багатьох регіонах, власний шлюз SLA 99,99% та повна інтеграція з віртуальними мережами. 00:13:25.800 --> 00:13:28.700 Ціна стартує приблизно від 2700 на місяць за одиницю. 00:13:28.840 --> 00:13:32.920 Майкрософт також представила рівні V2, Basic V2, Standard V2 та Premium V2. 00:13:33.140 --> 00:13:36.940 Вони спрощують ціноутворення завдяки включеним квотам запитів та оплаті за кожен мільйон понад ліміт. 00:13:37.040 --> 00:13:41.960 Замість відстеження багатьох метрик, ви отримуєте чіткий обсяг запитів і платите за додаткове використання простими частинами. 00:13:42.100 --> 00:13:43.160 Ось як зробити вибір. 00:13:43.160 --> 00:13:44.920 Починайте з Davelope для тестування. 00:13:45.060 --> 00:13:47.020 Переходьте на Standard для виробничого середовища. 00:13:47.140 --> 00:13:50.040 Обирайте Premium, якщо вам потрібен глобальний масштаб або приватна мережа. 00:13:50.120 --> 00:13:52.500 І пам'ятайте, ви завжди можете змінити рівень пізніше. 00:13:52.640 --> 00:13:54.860 Починайте з малого і зростаєте в міру зміни потреб. 00:13:55.040 --> 00:13:56.160 Ось що ми розглянули. 00:13:56.300 --> 00:14:02.480 Керування ARRI впорядковує хаос багатьох ARRI, об'єднуючи їх у єдиний центр керування шлюзами, політиками, безпекою та розробкою. 00:14:02.640 --> 00:14:04.560 Головний висновок – це не просто проксі. 00:14:04.560 --> 00:14:07.700 Сприймайте це як мозок і нервову систему вашої ARRI-екосистеми. 00:14:07.820 --> 00:14:11.140 Без нього кожна команда створює власну автентифікацію, логування та обмеження швидкості. 00:14:11.280 --> 00:14:15.540 Ви отримуєте неузгодженість, прогалини в безпеці та відсутність цілісного бачення того, що відбувається. 00:14:15.740 --> 00:14:21.540 З ним ви отримуєте послідовність, безпеку та масштабованість, не ви находячи велосипед для кожної служби. 00:14:21.720 --> 00:14:22.880 Ось проста вправа. 00:14:23.020 --> 00:14:25.740 Згадайте один ARRI, який ви зараз надаєте напряму. 00:14:25.900 --> 00:14:28.520 Можливо, це кінцева точка функції або сервіс програми. 00:14:28.520 --> 00:14:33.080 Як розміщення ARRI-менеджмент перед ним змінить ваш стан безпеки та можливість відстежувати використання. 00:14:33.240 --> 00:14:35.980 Навіть просте обдумування цієї вправи покаже вам цінність. 00:14:36.140 --> 00:14:37.840 Наступний крок – підпишіться на канал. 00:14:38.000 --> 00:14:43.420 У наступних епізодах ми покажемо, як імпортувати ARRI, застосувати першу політику та моніторити використання в реальному часі. 00:14:43.580 --> 00:14:45.260 Ви перейдете від теорії до практики. 00:14:45.400 --> 00:14:48.220 І якщо це було для вас корисним, поділіться цим з кимось, хто розробляє додаток. 00:14:48.300 --> 00:14:50.080 Це вбереже їх від місяців головного болю. 00:14:50.220 --> 00:14:51.180 Дякую за увагу.