Категорія: Uncategorized

Microsoft представила одне з найбільш захоплюючих нововведень у .NET — нову команду dotnet run. Ця функція доступна в .NET і повністю змінює підхід до написання та запуску коду на C#.

Тепер більше не потрібно створювати повноцінний проєкт, щоб просто протестувати ідею або вивести «Hello World». Усе стало набагато простіше, легше і дружелюбніше для новачків.

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

Початок роботи
Почнемо з повністю порожньої папки у Visual Studio Code — без файлів проєкту, без рішення, просто чистий робочий простір.

Зверніть увагу: у вас мають бути встановлені .NET 10 та C# Dev Kit для VS Code.

Створіть новий файл під назвою hello.cs і вставте в нього наступний код:

Console.WriteLine("Hello from .NET 10! This is a cool feature.");

Без просторів імен, без класу, без методу Main() — один файл, один рядок, і все працює.

Запуск файлу
А ось і магія. Замість створення проєкту просто відкрийте термінал і введіть:

dotnet run hello.cs

І програма запуститься! Результат на екрані:

Hello from .NET 10! This is a cool feature.

.NET компілює та запускає файл безпосередньо — без додаткового налаштування та без проєкту. Під капотом код збирається в пам’яті та виконується як скрипт.

Це ідеально для швидких експериментів або одноразових ідей, які потрібно перевірити на льоту.

Додаємо функціональність: робота з датами
Тепер зробимо крок далі. Припустимо, ми хочемо вивести дату публікації, наприклад — 3 дні тому.

Додамо такий код:

var postedDate = DateTime.UtcNow.AddDays(-3); Console.WriteLine($"Posted date: {postedDate}");

Після запуску програма виведе повну дату та час, як і очікувалося. Але це не найзручніший варіант для користувача — рядок занадто громіздкий і нечитабельний.

Виправимо це.

Використання NuGet-пакетів без проєкту
Тепер можна використовувати NuGet-пакети навіть без створення проєкту.

Візьмемо пакет Humanizer, який форматує дати у зручному вигляді — наприклад, замість відмітки часу покаже «3 дні тому».

На початку файлу додамо:

#r "nuget: Humanizer, 2.14.1"

Далі підключимо простір імен:

using Humanizer;

Тепер змінимо виведення в консоль:

var postedDate = DateTime.UtcNow.AddDays(-3); Console.WriteLine($"Posted {postedDate.Humanize()}");

Запустіть знову:

dotnet run hello.cs

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

Posted 3 days ago

Просто, красиво та читабельно — саме те, що потрібно.

Створення мінімального API в одному файлі
Тепер підемо ще далі. Що, якщо потрібно створити невеликий API, але без повноцінного проєкту? Це тепер теж можливо.

Створіть новий файл api.cs і додайте в нього:

var builder = WebApplication.CreateBuilder(args); var app = builder.Build();app.MapGet("/testapi", () => "Hello from .NET 10!"); app.Run();

Спробуйте запустити:

dotnet run api.cs

Ви отримаєте помилку: WebApplication не існує в поточному контексті. Це логічно — ми використовуємо функції мінімального API, але не вказали, що працюємо з Web SDK.

Підключаємо Web SDK
Щоб усе запрацювало, додамо на початок файлу рядок:

#sdk "Microsoft.NET.Sdk.Web"

Тепер знову запустимо:

dotnet run api.cs

І все працює! API запущено і прослуховує за адресою http://localhost:5000.

Відкрийте Postman або браузер і перейдіть за маршрутом /testapi. Відповідь:

Hello from .NET 10!

Мінімальний API повністю працює — і все це в одному файлі.

Перетворення файлу на повноцінний проєкт
Якщо файл стає занадто великим — ви додаєте більше ендпоінтів або middleware — можна легко перетворити його на повноцінний проєкт. Достатньо виконати команду:

dotnet project convert api.cs

.NET автоматично:

• створює нову папку проєкту,
• переносить туди api.cs,
• генерує файл .csproj,
• додає всі необхідні SDK та посилання на пакети.

Приклад створеного .csproj:

<Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>net10.0</TargetFramework> </PropertyGroup> </Project>

Тепер можна збирати, відновлювати та запускати проєкт як зазвичай.

Конвертація Hello World у проєкт
Те ж саме можна зробити з файлом hello.cs:

dotnet project convert hello.cs

.NET створить консольний проєкт і автоматично додасть залежності, які використовувалися, включно з Humanizer.

Приклад .csproj:

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net10.0</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="Humanizer" Version="2.14.1" /> </ItemGroup> </Project>

Усе готово до запуску — і жодного ручного налаштування.

Висновок
Ми пройшли шлях від одного C#-файлу з кількома рядками коду до:

• запуску його безпосередньо через dotnet run,
• використання NuGet-пакетів,
• створення мінімального API в одному файлі,
• і конвертації всього в повноцінний проєкт.

І все це — без ручного налаштування. .NET 10 справді змінює те, як ми починаємо працювати з C#. Чи ви новачок, який створює прототип, чи досвідчений розробник, який пише скрипт, новий процес став чистішим, швидшим і зручнішим. Якщо стаття виявилася корисною — ставте вподобайку та слідкуйте за новими матеріалами про .NET 10, мінімальні API, AI-інтеграцію та інші оновлення екосистеми .NET.

У сучасному середовищі розробки ігнорування безпеки залежностей — це не просто недбалість, а свідомий шлях до інцидентів. Кожен новий пакет NuGet, який ви додаєте в проєкт, потенційно може містити вразливості.
Тому автоматизація перевірки залежностей — це не просто «гарна практика», а необхідний мінімум безпеки, без якого неможливо впевнено випускати надійний продукт.

У цій статті показано, як додати обов’язковий етап перевірки безпеки (security-scan) у файл .gitlab-ci.yml будь-якого .NET-проєкту, використовуючи стандартні інструменти з пакету .NET SDK.

Додаємо етап Security Scan до .gitlab-ci.yml

Нижче наведено YAML-фрагмент, який можна безпосередньо включити у ваш CI/CD-конвеєр:

security-scan:
stage: security-scan
image: mcr.microsoft.com/dotnet/sdk:8.0
before_script:
- dotnet tool install --global dotnet-outdated-tool
script:
# Step 1: Check for known vulnerabilities in packages. This is mandatory.
- echo "Searching for KNOWN vulnerabilities in packages..."
- dotnet list package --vulnerable --include-transitive

# Step 2: Check for outdated packages. Important for maintenance and security.
- echo "Checking for outdated (non-secure) packages..."
- dotnet-outdated
allow_failure: true
only:
- main
- develop
- merge_requests

stage: security-scan

Перевірка безпеки винесена в окремий етап, щоб підкреслити її важливість.
Це гарантує, що сканування виконується регулярно — зазвичай після етапів збірки та тестування.

image: mcr.microsoft.com/dotnet/sdk:8.0

Використання офіційного Docker-образу .NET SDK від Microsoft забезпечує доступ до найновіших CLI-інструментів, необхідних для надійного аналізу та звітності.

before_script

Цей блок готує середовище для сканування.

Команда

dotnet tool install --global dotnet-outdated-tool

встановлює утиліту dotnet-outdated-tool.
Хоча основна перевірка вразливостей виконується вбудованими засобами, цей інструмент допомагає відстежувати застарілі пакети — важлива частина підтримання «гігієни» залежностей.
Ігнорування оновлень з часом перетворюється на технічний борг і підвищує ризики безпеки.

script

Тут виконуються основні команди, що безпосередньо захищають ваш код.

• Крок 1: Пошук відомих вразливостей
  Команда dotnet list package --vulnerable перевіряє всі залежності (включно з транзитивними) і показує список небезпечних пакетів.

• Крок 2: Перевірка застарілих пакетів
  Команда dotnet-outdated визначає залежності, які втратили актуальність або можуть містити невиправлені проблеми.

allow_failure: true

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

only

Цей блок визначає, для яких гілок виконується перевірка — main, develop і merge requests.
Завдяки цьому можна виявити ризики ще до того, як потенційно небезпечний код потрапить до основної гілки.

Висновок

Наведена конфігурація — це не «опція» і не «додаткова функція», а базовий стандарт безпеки для будь-якого .NET-проєкту.
Вона автоматично виконує дві критично важливі задачі:

1. Виявляє активні загрози — пакети з відомими вразливостями.

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

Пропускаючи цей етап, ви фактично залишаєте двері відчиненими для атак.
Додайте ці перевірки сьогодні — і завтра ваш проєкт буде набагато безпечнішим.

Сьогодні ми зануримося у щось абсолютно нове та дуже захоплююче для всіх .NET-розробників — це Microsoft Agent Framework. Цей попередній реліз піднімає інтеграцію штучного інтелекту та .NET на абсолютно новий рівень.

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

Що таке агенти

Агент — це, по суті, ІІ-робітник, який може думати, приймати рішення та діяти, щоб досягти мети. Уявіть його як цифрового колегу — у нього є конкретне завдання, власна «особистість», і він може використовувати інструменти або API за потреби.

Згідно з Microsoft, агент — це не просто система запит–відповідь. Він може:

• розмірковувати та планувати,

• викликати API,

• користуватися пам’яттю,

• співпрацювати з іншими агентами.

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

Розуміння робочих процесів

Робочий процес (workflow) визначає, як агенти взаємодіють один з одним та працюють спільно для виконання завдання. Його можна уявити як блок-схему — спочатку переклад, потім перевірка, а потім підсумок.

Робочі процеси можуть виконуватися послідовно або паралельно, залежно від сценарію. Вони забезпечують структуру та контроль, перетворюючи випадкові відповіді ІІ у надійні, відтворювані процеси.

Коротко:

• Агенти приносять інтелект — вони розуміють контекст, розмірковують і генерують результат.

• Робочі процеси приносять структуру — вони визначають порядок, залежності та розгалуження.

Коли ви об’єднуєте їх, отримуєте команду взаємодіючих ІІ-агентів, здатних досягати значно більшого, ніж окремі виклики моделі. Наприклад, один агент може перекладати текст, інший — перевіряти його, а третій — підводити підсумки. Все це координується визначеним вами робочим процесом.

Це схоже на те, як великі мовні моделі перетворюються на добре організовану програмну систему, а не просто на чат-бота.

Знайомство з Microsoft Agent Framework

Тепер поговоримо про зірку сьогоднішнього відео — Microsoft Agent Framework.

Це новий SDK з відкритим кодом від Microsoft, поки що в попередній версії, який об’єднує агентів, робочі процеси, інструменти та пам’ять в єдину платформу для розробників .NET та Python.

Він базується на ідеях Semantic Kernel та Autogen, але був перероблений, щоб зробити створення мультиагентних систем простим та масштабованим.

За допомогою цього фреймворку ви можете:

• легко створювати агентів,

• з’єднувати їх через типобезпечні робочі процеси,

• інтегрувати Azure OpenAI або локальні моделі,

• виконувати кроки паралельно або з участю людини (human checkpoints).

Підготовка проекту

Тепер ми створимо послідовний робочий процес перекладу за допомогою чотирьох агентів:

1. French Translator Agent — переклад англійського на французьку;

2. Spanish Translator Agent — переклад англійського на іспанську;

3. Quality Reviewer Agent — перевірка обох перекладів на точність та тон;

4. Summary Agent — об’єднує результати в підсумковий звіт.

Це простий приклад, але він чітко демонструє, як кілька агентів можуть співпрацювати.

Я вже створив консольний додаток .NET 9. Спочатку очищу файл Program.cs.

Встановлення необхідних пакетів

Далі встановимо пакети Microsoft Agent Framework.

Відкрийте NuGet Package Manager та знайдіть наступні бібліотеки:

1. Microsoft.Agents.AI — встановіть цей пакет.

2. Microsoft.Agents.AI.Workflows — допомагає будувати та зв’язувати агентів через робочі процеси.

3. Microsoft.Extensions.AI.OpenAI — дозволяє інтегрувати моделі OpenAI або розміщені на GitHub.

Після встановлення всі вони з’являться у розділі Dependencies вашого проекту. Тепер ми готові реалізовувати агентів і робочий процес.

Додавання клієнта чату

Клієнт чату дозволяє агентам взаємодіяти з моделлю ІІ.

У нашому випадку використовується модель GitHub — GPT-4.0 Mini, легка, але потужна, ідеально підходить для демонстрацій. Щоб отримати доступ, потрібен GitHub API key.

У попередньому відео я показував, як створити такі ключі — обов’язково перегляньте, якщо ще не зробили цього.

Цей клієнт чату з’єднує наше додаток .NET з моделлю OpenAI на GitHub, щоб ми могли створювати агентів поверх неї.

Створення French Translator Agent

Наш перший агент — French Translator.

Він використовує клієнт чату, створений раніше, і виконує просте завдання — приймає англійський текст та перекладає його на французьку.

Створюємо екземпляр агента через клас ChatClientAgent і називаємо його French Agent.

У параметрах вказуємо:

• Name = “French Agent”

• Instructions = “Перекладай будь-який наданий текст французькою мовою, зберігаючи природність і точність.”

Готово — перший агент налаштований.

Створення Spanish Translator Agent

Щоб не писати все заново, скопіюйте код French Agent і внесіть кілька змін:

• Перейменуйте змінну в SpanishAgent;

• Встановіть ім’я “Spanish Agent”;

• Змініть інструкції: “Ти — перекладач, який перекладає текст іспанською мовою.”

Тепер у нас є два агенти:

• один для французької,

• інший для іспанської.

Створення Quality Reviewer Agent

Далі копіюємо код Spanish Agent і адаптуємо його для Quality Reviewer Agent.

Перейменовуємо змінну в QualityReviewerAgent та встановлюємо ім’я “Quality Reviewer Agent”.

Щоб зробити код чистішим, створюємо окрему рядкову змінну з інструкціями:
string qualityReviewerAgentInstructions = "...";

Цей агент буде перевіряти переклади та надавати оцінку якості за простою рейтинговою системою.

Створення Summary Agent

Тепер створюємо Summary Agent аналогічно.

Копіюємо код Quality Reviewer Agent і вносимо зміни:

• Перейменовуємо змінну в SummaryAgent;

• Ім’я — “Summary Agent”.

Створюємо новий рядок summaryAgentInstructions та прописуємо призначення:

“Об’єднай усі рецензії перекладів в один підсумковий звіт.”

Ось і все — Summary Agent готовий.

Побудова робочого процесу

Тепер потрібно зв’язати всіх чотирьох агентів в один процес.

Створюємо новий AI-агент WorkflowAgent за допомогою класу AgentWorkflowBuilder і викликаємо метод BuildSequential.

Це означає, що агенти виконуватимуться по черзі:

1. French Translator

2. Spanish Translator

3. Quality Reviewer

4. Summary Agent

Наприкінці викликаємо .AsAgentAsync(), щоб об’єднати всю ланцюжок у одного агента, з яким можна взаємодіяти безпосередньо.

У фреймворку результат одного агента автоматично передається наступному — створюється єдиний конвеєр взаємодії.

Запуск робочого процесу

Тепер додамо введення тексту від користувача для тесту.

Просимо користувача ввести англійське речення і передаємо його агенту через workflowAgent.Run(userInput).

Текст пройде весь конвеєр:

1. French Translator

2. Spanish Translator

3. Reviewer

4. Summary Agent

Кожен етап обробляє результат і передає його далі.

Для наочного виводу:

• ім’я агента виводимо жовтим,

• результат роботи — зеленим.

Запускаємо додаток.

У консолі з’явиться запит на введення. Введіть, наприклад, “Hello world” та натисніть Enter.

Ви побачите:

• French Agent переклав фразу французькою;

• Spanish Agent — іспанською;

• Quality Reviewer Agent перевірив обидва переклади на тон, граматику та точність;

• Summary Agent створив підсумковий звіт про якість перекладу.

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

Спробуйте ввести ще кілька речень — ви побачите, як кожен агент виконує свою роль крок за кроком, а весь процес працює автоматично.

Висновок

Ми щойно створили повноцінний багатомовний конвеєр перекладу з використанням Microsoft Agent Framework.

Ось що ми зробили:

• Створили чотири агенти — French Translator, Spanish Translator, Quality Reviewer та Summary Agent;

• Об’єднали їх у послідовний робочий процес;

• Спостерігали, як вони спільно виконують завдання від перекладу до підсумкового звіту.

Кожен агент відповідав за свою частину роботи, а фреймворк координував всю роботу — від перекладу до перевірки та підсумку.

Цей приклад демонструє, як легко можна спроектувати структуровані, взаємодіючі ІІ-системи прямо в .NET.

Ви можете розширити цей робочий процес:

• додати нові мови,

• створити додаткові етапи перевірки,

• інтегрувати зовнішні API для більш глибокого аналізу або покращеного перекладу.

У сучасному цифровому світі дедалі більше організацій переходять до мультихмарних стратегій, використовуючи можливості кількох хмарних провайдерів для досягнення гнучкості, відмовостійкості та глобального охоплення. Зазвичай сюди входить Microsoft Azure, але також активно використовуються Amazon Web Services (AWS), Google Cloud Platform (GCP), Oracle Cloud Infrastructure (OCI) та інші.

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

Мережеві основи в Azure

Базовим елементом мережевої інфраструктури Azure є Virtual Network (VNet). Кожна віртуальна мережа:

• існує в межах певної підписки і не може охоплювати кілька підписок;

• розташована в одному регіоні Azure, тобто не може бути розподілена між регіонами;

• визначається одним або кількома діапазонами IPv4 (і за потреби IPv6).

У межах VNet розгортаються ресурси — віртуальні машини (VM), контейнери та служби. Хоча не всі служби Azure спочатку є частиною VNet, багато з них можна інтегрувати для приватного підключення, минаючи публічні точки доступу й зменшуючи ризики взаємодії з інтернетом.

Підмережі та інтеграція сервісів

Кожна VNet поділяється на підмережі (subnets), у яких розміщуються ресурси. Існує два основних способи інтеграції сервісів Azure у мережу:

1. Delegated Subnets – деякі сервіси (наприклад, бази даних) можна розгортати в підмережах, делегованих конкретному сервісу. Це забезпечує доступ до них через приватні IP-адреси.

2. Private Endpoints – спеціальні мережеві інтерфейси, які підключають PaaS-сервіси Azure до вашої підмережі. Це забезпечує захищений доступ до них через внутрішню мережу.

В обох випадках зберігається приватне та безпечне з’єднання з сервісами, навіть якщо вони знаходяться за межами мережі.

DNS та безпека

DNS відіграє критичну роль у забезпеченні коректного підключення. Оскільки більшість з’єднань захищено за допомогою TLS, правильне розв’язання імен (DNS resolution) необхідне для відповідності сертифікатів TLS доменним іменам.
Azure пропонує Private DNS Zones і підтримує conditional forwarding для коректного розв’язання імен між пов’язаними мережами й локальними середовищами.

Гібридна хмарна взаємодія

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

• Публічне підключення

• Приватне підключення

Глобальна мережа Microsoft

Microsoft володіє однією з найбільших приватних мереж у світі:

• понад 165 000 миль оптоволоконних і підводних кабелів, що з’єднують 60+ регіонів Azure;

• понад 185 глобальних точок присутності (PoP), де здійснюється взаємодія з іншими мережами й інтернетом.

Ця мережа використовується як для публічних, так і для приватних з’єднань.

Приватне підключення: ExpressRoute

Для високопродуктивних і надійних з’єднань Azure пропонує ExpressRoute.
Як це працює:

1. Організація підключається від свого дата-центру до точки присутності (PoP), де доступна глобальна мережа Microsoft.

2. Провайдер зв’язку організовує крос-підключення до маршрутизаторів Microsoft.

3. У Azure розгортається ExpressRoute Gateway, який керує трафіком між хмарою та локальним середовищем.

Кожне з’єднання ExpressRoute має дві фізичні лінії для відмовостійкості.
Для критичних систем рекомендується використовувати кілька каналів у різних містах.

Публічне підключення: Site-to-Site VPN

Більш доступною альтернативою є Site-to-Site VPN — зашифрований тунель через інтернет між локальним VPN-пристроєм і Azure VPN Gateway.
Це дешевше, але має більшу затримку й варіативність продуктивності.
Часто використовується як резервне з’єднання для ExpressRoute.

З’єднання між віртуальними мережами

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

• VNet Peering – пряме з’єднання двох мереж за умови, що їхні IP-адреси не перетинаються.

• Hub-and-Spoke – центральна мережа (hub) підключає кілька «спиць» (spokes). Хаб містить спільні сервіси: DNS, файрвол, шлюзи тощо.

• Azure Virtual WAN – керована служба, що спрощує масштабне підключення.

• Azure Virtual Network Manager – централізоване управління маршрутами та зв’язністю.

Зв’язок між хмарами (Multicloud Connectivity)

Далі розглянемо взаємодію між різними хмарами — наприклад, між Azure, AWS, GCP або OCI.
Кожен великий провайдер має подібну мережеву модель:

• AWS — VPC (Virtual Private Cloud)

• GCP — VPC (Virtual Private Cloud)

• OCI — VCN (Virtual Cloud Network)

Ці мережі можуть підключатися як до інтернету, так і до приватних каналів.

VPN-з’єднання між хмарами

Найпростіший спосіб з’єднати Azure з іншою хмарою — Site-to-Site VPN, який створює зашифрований тунель між двома шлюзами.
Метод безпечний, але обмежений швидкістю (до 1 Гбіт/с) і стабільністю.
Підходить для тестових або резервних сценаріїв.

Приватне міжхмарне підключення

У кожного провайдера є власні рішення, аналогічні ExpressRoute:

• AWS Direct Connect

• Google Cloud Interconnect

• Oracle FastConnect

Ці сервіси використовують ті ж самі PoP-центри, що й Microsoft, що дозволяє організувати пряму міжхмарну взаємодію.
Основне правило — обирати географічно близькі регіони (наприклад, Azure London і AWS London) для зниження затримки.

Варіанти підключення

1. Пряме підключення (Dedicated)

   • Використання власних маршрутизаторів.

   • Пропускна здатність до 100 Гбіт/с.

   • Підходить для великих підприємств.

2. Cloud Exchange-провайдери (наприклад, Equinix, Megaport)

   • Вони беруть на себе складну маршрутизацію.

   • Оптимальний варіант для компаній, що віддають перевагу керованим рішенням.

Також можна налаштувати VPN як резервне з’єднання для підвищення надійності.

Особливий випадок: Azure – Oracle Interconnect

Microsoft і Oracle пропонують спільне рішення Oracle Interconnect for Azure, яке поєднує ExpressRoute та FastConnect.
Це забезпечує мінімальну затримку між регіонами (наприклад, між Azure London і OCI London).

Продуктивність і оптимізація

Щоб досягти максимальної ефективності:

• Увімкніть ExpressRoute FastPath, щоб трафік оминав шлюз.

• Забезпечте єдине DNS-розв’язання.

• Використовуйте резервні канали в різних PoP для відмовостійкості.

Безпека, управління та моніторинг

Мультихмарна взаємодія має супроводжуватися:

• Централізованим моніторингом безпеки (логи, метрики, сповіщення);

• Єдиним управлінням і дотриманням політик (наприклад, через Azure Arc);

• Узгодженим управлінням ідентифікацією у всіх середовищах.

Висновок

Мультихмарна взаємодія не базується на «чарівних» технологіях — це практичне застосування класичних мережевих принципів.
Підключаючи Azure до локальної інфраструктури чи інших хмар (AWS, GCP, OCI), організації мають два основних варіанти:

• Зашифрований VPN-тунель через інтернет — простіше, але з обмеженнями швидкості.

• Приватне з’єднання через виділені канали — складніше, але з високою продуктивністю та надійністю.

Головне — планувати резервування, підтримувати єдине управління та видимість, а також забезпечувати безпеку та контроль у всіх хмарах.
Саме це і є суть мультихмарної мережевої архітектури — гнучкої, надійної та безпечної.

Сьогодні, коли штучний інтелект розвивається надзвичайно швидко, ще ніколи не було кращого часу бути .NET-розробником, який працює з AI. Завдяки сучасним бібліотекам і API, інтеграція великих мовних моделей (LLM) у застосунки .NET стала простою, ефективною та надійною.

Одним із ключових інструментів, що робить цей процес настільки зручним, є бібліотека Microsoft.Extensions.AI — вона надає чисті абстракції для роботи з різними AI-провайдерами.
У цій статті ми крок за кроком розглянемо, як використовувати GitHub Models у .NET 9: налаштуємо OpenAI-адаптер, створимо чат-клієнт і підключимо застосунок безпосередньо до моделі всього за кілька рядків коду.

1. Створення консольного застосунку .NET 9

Почнемо зі створення базового консольного застосунку .NET 9. Після цього додамо потрібні бібліотеки.

Встановлення бібліотек

1. Відкрийте NuGet Package Manager.

2. У полі пошуку введіть Microsoft.Extensions.AI.

3. Замість встановлення цієї бібліотеки напряму встановіть Microsoft.Extensions.AI.OpenAI — саме вона потрібна для підключення до GitHub Models.

4. Пакет OpenAI вже містить основну бібліотеку Microsoft.Extensions.AI як залежність, тому встановлювати її окремо не потрібно.

Після встановлення переконайтеся, що бібліотека з’явилася у вашому проєкті. Очистіть Program.cs, щоб перейти до наступного кроку.

2. Створення та налаштування чат-клієнта

Інтерфейс IChatClient — це головна абстракція, яку надає бібліотека Microsoft.Extensions.AI для взаємодії з великими мовними моделями у .NET.

Створення екземпляра чат-клієнта

Створіть змінну типу IChatClient і присвойте їй новий екземпляр клієнта.

• Назва моделі:
  Вказує, яку модель GitHub Models потрібно використовувати. Ми заповнимо це поле пізніше.

• API-ключ:
  Цей ключ автентифікує ваш застосунок у GitHub Models. Без нього запити не працюватимуть. Поки що залишимо порожнім — пізніше додамо справжній ключ.

• Endpoint:
  У OpenAIClientOptions є властивість Endpoint.
  Оскільки ми підключаємося до GitHub Models, вкажіть:

  https://api.github.com/models


  Це налаштування дає змогу клієнту надсилати всі запити безпосередньо до GitHub Models.

Після цього викличте .AsChatClient(), щоб перетворити клієнт конкретного провайдера на стандартний інтерфейс IChatClient.
Це важливо, адже такий підхід робить код чистим, гнучким і незалежним від постачальника. Якщо ви захочете змінити провайдера, логіку програми міняти не доведеться.

3. Створення GitHub API-ключа

Тепер створимо API-ключ GitHub, щоб отримати доступ до моделей.

1. Перейдіть у GitHub Models Marketplace.

2. У спадному списку виберіть потрібну модель.

3. Для прикладу ми використаємо GPT-4.1 Mini.

4. Натисніть «Use this model».

5. Якщо ви користуєтеся безкоштовним тарифом, натисніть «Create personal access token», щоб згенерувати ключ.

Створення токена

• Вкажіть термін дії (за замовчуванням — 30 днів).

• Задайте назву токена, наприклад YouTube GitHub Model Token.

• Натисніть «Generate token», щоб створити його.

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

Після вставлення токена додайте назву моделі ("gpt-4.1-mini") — і чат-клієнт повністю налаштовано.

4. Реалізація логіки чат-застосунку

Тепер, коли клієнт готовий, створимо логіку самого чату.

Привітальне повідомлення

Після запуску застосунку виведіть коротке привітання та інструкцію, як завершити чат.

Історія діалогу

Щоб модель могла підтримувати контекст, створіть список для зберігання всіх повідомлень між користувачем і моделлю.
У цьому списку зберігатимуться як повідомлення користувача, так і відповіді асистента.

Основний цикл чату

Чат має працювати безперервно, доки користувач не введе exit.

1. Використовуйте цикл while (true).

2. Виведіть запрошення до введення повідомлення.

3. Зчитайте введення користувача.

4. Якщо рядок порожній — повторіть запит.

5. Якщо введено exit — вийдіть із циклу.

Кожне повідомлення додавайте до історії, щоб модель мала повний контекст під час наступного запиту.

5. Потокові відповіді моделі в реальному часі

Перед тим як показати відповідь моделі, додайте позначку «Assistant:», щоб було зрозуміло, від кого повідомлення.

Метод GetStreamingResponseAsync() дозволяє отримувати відповідь поступово, токен за токеном, тобто ви бачитимете, як текст з’являється у режимі реального часу — ніби в живому чаті.

Використовуйте Console.Write() для виведення кожного токена одразу, створюючи ефект інтерактивного діалогу.
Паралельно зберігайте повну відповідь у змінній assistantResponse, додаючи кожну частину тексту.
Після завершення генерації додайте відповідь у список історії, щоб модель пам’ятала контекст.

6. Покращення інтерфейсу

Зараз повідомлення користувача та моделі виглядають однаково, тому їх важко розрізнити.
Виправимо це кольорами:

• Привітання: жовтий

• Повідомлення користувача: білий

• Відповідь асистента: зелений

Тепер чат став більш читабельним і приємним візуально.

Після змін запустіть програму знову — різниця очевидна.
Відповіді асистента плавно з’являються в режимі реального часу.

7. Тестування чат-застосунку

Перевіримо, як усе працює:

• Введіть: What’s .NET?
  → Асистент миттєво пояснює, що таке .NET.

• Спробуйте: Write a story about a superhero.
  → Модель починає стрімити історію в реальному часі прямо у консолі.

• Перевіримо контекст:

  1. Введіть Add 10 and 5.
     → Відповідь: 10 + 5 = 15.

  2. Потім введіть Minus 4.
     → Відповідь: 15 - 4 = 11.

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

8. Підсумок

Ви щойно побачили, наскільки легко .NET може працювати зі штучним інтелектом і великими мовними моделями за допомогою бібліотеки Microsoft.Extensions.AI.

Усього за кілька рядків коду ми:

• Підключили консольний застосунок .NET 9 до GitHub Models

• Реалізували стрімінг відповідей у реальному часі

• Додали збереження історії діалогу

• Створили інтерактивний чат

Це чудовий приклад того, наскільки потужною та гнучкою стала екосистема AI у .NET.
Просто, швидко й елегантно — ідеально для розробників, які створюють інтелектуальні застосунки.

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

Для B2C-розробників розуміння Onion Architecture — це важливий крок до оволодіння сучасними принципами проектування. Для B2B-керівників її впровадження допомагає прискорити розробку критично важливих систем і підвищити їхню стійкість до змін.
Ми спеціалізуємося на сучасних архітектурних підходах і допомагаємо компаніям знаходити експертів, здатних впроваджувати ефективні рішення, такі як Onion Architecture.

Що таке Onion Architecture

Onion Architecture пропонуємо як альтернативу традиційним багатошаровим архітектурам, де дизайн часто диктувався користувацьким інтерфейсом або інфраструктурою, що призводило до надмірної зв’язності та складності.
Onion Architecture, навпаки, ставить бізнес-логіку в центр системи, дотримуючись принципів Domain-Driven Design (DDD).

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

Шари Onion Architecture

1. Core Domain Layer (внутрішній шар)

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

2. Application Layer

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

3. Adapter Layers (зовнішні шари)

Зовнішні шари, або адаптери, забезпечують взаємодію із зовнішнім світом — базами даних, інтерфейсами, API та іншими сервісами. До них належать:

• Infrastructure Layer: відповідає за доступ до даних, роботу з файлами та інтеграцію з інфраструктурою. Дозволяє змінювати базу даних або інші технології без впливу на бізнес-логіку.

• Presentation Layer: реалізує взаємодію з користувачем — це може бути веб-інтерфейс, мобільний застосунок або API. Цей шар передає запити користувачів у застосунок і відображає результати.

• External Services Layer: інтегрує зовнішні сервіси — платіжні шлюзи, API або мікросервіси. Абстрагує взаємодію з іншими системами та забезпечує стабільну інтеграцію.

Основні принципи Onion Architecture

1. Принцип інверсії залежностей (Dependency Inversion Principle, DIP)

Високорівневі модулі (бізнес-логіка) не залежать від низькорівневих (інфраструктури). Обидва спираються на абстракції — інтерфейси або контракти. Це забезпечує слабку зв’язність і легку заміну компонентів без впливу на систему загалом.

2. Інверсія керування (Inversion of Control, IoC)

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

3. Розділення відповідальності (Separation of Concerns)

Кожен шар має чітко визначену роль. Бізнес-логіка відокремлена від інтерфейсу та інфраструктури, що робить систему модульною, зрозумілою та простою в обслуговуванні.

Переваги Onion Architecture

1. Підтримуваність

Завдяки ізоляції бізнес-логіки від інфраструктури можна змінювати або оновлювати окремі шари без ризику зламати всю систему. Це особливо важливо для великих проектів із кількома командами.

2. Тестованість

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

3. Гнучкість

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

4. Масштабованість

Кожен шар можна масштабувати окремо. Наприклад, інфраструктуру можна оптимізувати під великі навантаження без змін у бізнес-логіці.

5. Покращена командна співпраця

Чіткий поділ шарів дозволяє різним командам — розробникам, дизайнерам, DevOps-фахівцям — працювати паралельно, не заважаючи одна одній.

Де застосовується Onion Architecture

Ця архітектура ідеально підходить для великих і складних систем, зокрема:

• Корпоративні застосунки: ERP, CRM та інші рішення, що потребують довгострокової підтримки.

• Веб-застосунки: SaaS та e-commerce платформи, де важливе розділення логіки та інтерфейсу.

• Мікросервіси: кожен сервіс можна побудувати як окрему «цибулину» зі своєю бізнес-логікою та інфраструктурою.

• Фінансові системи: особливо ефективна там, де потрібна безпека та чітка ізоляція бізнес-правил від зовнішніх сервісів.

Як ми допомагає впроваджувати Onion Architecture

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

1. Архітектурний консалтинг

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

2. Підбір спеціалізованих фахівців

Ми підбираємо розробників, архітекторів і консультантів, які володіють знаннями Onion Architecture. Незалежно від того, чи потрібні вам тимчасові спеціалісти чи постійні співробітники — ми допоможемо сформувати оптимальну команду.

Висновок

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

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

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

1. Основні принципи та компоненти платформенної інженерії

У своїй суті внутрішня платформа розробника (IDP) — це єдине середовище, яке поєднує цифрові інструменти та спільну інфраструктуру для досягнення бізнес-результатів через повторювані та стандартизовані процеси. Основне завдання IDP — об’єднати розробників і спеціалістів з IT-операцій навколо безпечної, масштабованої та надійної основи.

1.1. Чотири «C» хмарно-нативної архітектури

Сучасна cloud-стратегія базується на чотирьох ключових шарах:

• Cloud (Хмара) — базова інфраструктура для робочих навантажень (AWS, Azure, Google Cloud або приватні хмари).

• Cluster (Кластер) — група фізичних чи віртуальних машин під керуванням контролера. Стандартом стали Kubernetes та Docker.

• Container (Контейнер) — легкі ізольовані середовища, які включають застосунок із залежностями для стабільної роботи будь-де.

• Code (Код) — логіка та інструкції, створені розробниками і виконувані всередині контейнерів.

1.2. Принципи проєктування

Дизайн платформи спирається на перевірені методології, такі як SOLID, що гарантують масштабованість і підтримку мікросервісних систем. Також враховуються мережеві моделі (наприклад, середні рівні OSI), які визначають взаємодію сервісів.

1.3. Ключові елементи платформи

Компоненти зазвичай діляться на дві групи:

• Інструменти для співпраці – IDE, системи контролю версій (GitHub, GitLab), трекери завдань (Jira, Aha!), канали комунікації (Slack, Mattermost), а також панелі управління з підтримкою SSO. Важливу роль відіграють інтегровані засоби безпеки: аналіз коду, перевірка залежностей тощо.

• Інфраструктура для деплою – формується через Infrastructure as Code (IaC): Terraform, Kubernetes-манифести, Docker-конфігурації. CI/CD пайплайни (Jenkins, GitHub Actions, GitLab CI/CD, ArgoCD, Flux) забезпечують швидкий і автоматизований реліз без «вузьких місць».

2. Масштабованість, безпека та стійкість

Ці три характеристики є фундаментом надійності платформи.

• Масштабованість – гнучкість системи під зміни навантаження. Kubernetes і Terraform відіграють ключову роль в автоматизації масштабування.

• Безпека – має закладатися від початку: шифрування даних «у спокої» та «в русі», багатофакторна аутентифікація (MFA), суворий контроль доступу через OAuth або LDAP.

• Стійкість – здатність системи відновлюватися після збоїв. Рекомендованим стандартом є модель резервного копіювання 3-2-1.

2.1. Архітектурні моделі

Існує три основні підходи:

1. Постійні – кластери, що працюють завжди (dev, test, prod). Стабільні та передбачувані.

2. Перехідні – динамічні середовища з автоскейлінгом і часовими обмеженнями. Вигідні за витратами.

3. Ефемерні – тимчасові кластери під конкретну задачу (наприклад, тести), після чого видаляються.

3. Екосистема інструментів платформи

Ефективна платформа базується на автоматизації:

• Infrastructure as Code (IaC) – Terraform, Chef, Puppet для опису інфраструктури кодом.

• Configuration Management (CM) – Ansible, Puppet, Chef для автоматизованого налаштування систем.

• VCS – Git як стандарт. Підхід GitOps дозволяє керувати інфраструктурою через репозиторій.

3.1. Оркестрація та спостережуваність

• Kubernetes – стандарт для контейнерів: балансування, самовідновлення, автодеплой.

• Service Mesh (Istio, Linkerd) – контроль трафіку та безпеки між сервісами.

• Моніторинг і логи – Prometheus та стек ELK для централізованої аналітики.

• OpenTelemetry – відкритий стандарт для збору метрик, логів і трасувань.

3.2. CI/CD пайплайни

CI/CD — це двигун, що переводить ідею у готовий застосунок.

• Популярні інструменти: Jenkins, GitLab, CircleCI.

• Пайплайни включають етапи: розробка → збірка → тест → деплой.

4. Безпека, відповідність і управління

Захист має бути частиною архітектури:

• Secure-by-Default – безпека закладається за замовчуванням.

• Шифрування даних – обов’язково у зберіганні та передачі.

• RBAC і SSO – контроль доступу за принципом найменших привілеїв.

• Vulnerability Management – регулярне сканування CVE, генерація SBOM для відстеження залежностей.

Інструменти безпеки інтегруються прямо у CI/CD пайплайн (SAST, dependency scanning).

5. Штучний інтелект у платформенній інженерії

ШІ докорінно змінює управління платформами:

• Автоматизація розробки – GitHub Copilot, Google Gemini допомагають писати код і пришвидшують рутинні задачі.

• Інтелектуальна інфраструктура – передиктивний скейлінг і оптимізація ресурсів.

• Підсилення безпеки – виявлення аномалій та аналіз загроз.

• Виклики – захист даних, регуляторні вимоги (GDPR), етичні питання прозорості й зайнятості.

6. Управління даними в платформенній інженерії

Дані – це паливо для ШІ та бізнесу.

• Значення даних – платформи забезпечують інфраструктуру для обробки великих обсягів інформації.

• Стратегії – вибір між data lakes і data warehouses, автоматизація пайплайнів.

• Архітектура даних – має враховувати 5 V Big Data: обсяг, швидкість, цінність, різноманітність і достовірність.

• DataOps – застосування принципів DevOps до життєвого циклу даних.

Висновок

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

Майбутнє розробки ПЗ — за платформами, де поєднуються автоматизація, ШІ та орієнтація на розробників. Ті компанії, які впроваджують ці практики вже сьогодні, отримають стратегічну перевагу у цифрову добу.

Керування Kubernetes-інфраструктурою часто нагадує жонглювання безліччю завдань. Це забирає в розробників дорогоцінний час і увагу, які краще спрямувати на створення застосунків. Щоб вирішити цю проблему, Microsoft представила AKS Automatic — новий режим розгортання для Azure Kubernetes Service, що наразі доступний у режимі попереднього перегляду. Його мета — зняти з команд значну частину операційного навантаження та передати її платформі Azure, дозволяючи зосередитися на коді, а не на кластерах.

У цій статті ми розглянемо, що таке AKS Automatic, які переваги він надає та як розгорнути свій перший автоматизований кластер.

Що таке AKS Automatic?

AKS Automatic — це спрощений варіант розгортання кластерів AKS. Замість того щоб вручну налаштовувати, масштабувати й оновлювати інфраструктуру, користувач отримує все «з коробки». Платформа бере на себе оновлення, безпеку та експлуатацію кластера, звільняючи команди для розробки застосунків.

Ключові можливості та переваги

1. Інтелектуальне керування вузлами та масштабування

Головна перевага — повністю автоматизоване керування вузлами за допомогою Node Autoprovisioning (NAP), побудованого на проєкті Karpenter з відкритим кодом. Система аналізує вимоги pod’ів, що очікують запуску, і автоматично підбирає оптимальний тип віртуальної машини для балансу продуктивності та вартості.

Крім того, AKS Automatic одразу вмикає кілька механізмів масштабування:

• Horizontal Pod Autoscaler (HPA): масштабує кількість pod’ів залежно від навантаження.

• KEDA (Kubernetes Event-driven Autoscaling): масштабує застосунки на основі зовнішніх подій (наприклад, повідомлень із черг чи тригерів бази даних).

• Vertical Pod Autoscaler (VPA): динамічно коригує запити ресурсів pod’ів (CPU, пам’ять).

Додатково:

• Автоматичний ремонт вузлів: при збої система намагається відновити вузол.

• Автоматичні оновлення кластера: забезпечують актуальні версії та патчі безпеки з можливістю планування технічних вікон.

Важливо: наразі AKS Automatic підтримує лише вузли на Azure Linux, Windows-вузли поки недоступні.

2. Вбудована безпека за замовчуванням

Безпека інтегрована від початку та відповідає найкращим практикам Microsoft:

• Azure RBAC: керування доступом через ролі й дозволи Azure.

• Microsoft Entra Workload ID: безпечне підключення застосунків до сервісів Azure без секретів і ключів.

• Політики розгортання: автоматична перевірка на відповідність стандартам Kubernetes за допомогою Azure Policy.

• Очищення образів: видалення уразливих і невикористовуваних контейнерних образів.

3. Повністю керована мережа

Мережеві налаштування у Kubernetes часто створюють труднощі, але AKS Automatic спрощує цей процес, надаючи готову оптимізовану інфраструктуру:

• Azure CNI Overlay з Cilium: високопродуктивний і безпечний зв’язок між pod’ами.

• Керований Nginx Ingress: інтеграція з Azure DNS для автоматичного налаштування доменів та Azure Key Vault для керування SSL/TLS-сертифікатами.

• Керований NAT Gateway: надійне й масштабоване вихідне з’єднання з інтернетом.

Практичний посібник: створення кластера AKS Automatic

Крок 1. Налаштування Azure CLI

Встановіть розширення та активуйте необхідні прапорці:

Дочекайтеся, поки статус функцій зміниться на Registered.

Крок 2. Створення кластера через Azure Portal

1. Відкрийте Kubernetes Services → Create.

2. У полі «Cluster preset configuration» виберіть Automatic.

3. Заповніть базові параметри (ресурсна група, назва, регіон).

4. (Опційно) Налаштуйте моніторинг з Azure Monitor, Prometheus і Grafana.

5. Натисніть Review + Create.

Крок 3. Підключення та перевірка

Отримайте облікові дані:

az aks get-credentials --resource-group <ResourceGroup> --name <ClusterName>

kubectl get nodes kubectl get pods -n kube-system

Крок 4. Розгортання тестового застосунку

Створіть простір імен:

kubectl create namespace demo-app

kubectl apply -f your-app.yaml -n demo-app

kubectl get ingress -n demo-app

Підсумок

AKS Automatic — це серйозний крок уперед у спрощенні роботи з Kubernetes. Автоматизація інфраструктури, масштабування, оновлень і безпеки знімає з команд рутинні завдання та дозволяє зосередитися на створенні бізнес-цінності. Попри те, що функція поки в режимі попереднього перегляду, вона вже демонструє величезний потенціал для користувачів Azure Kubernetes Service.