Dzisiaj miałem przyjemność uczestniczyć w [WAW] 83 spotkanie Microsoft Azure User Group Poland w Warszawie, które otworzyło jesienny sezon spotkań warszawskiej społeczności Azure. W agendzie były trzy prelekcje, ja byłem na dwóch pierwszych i to je podsumuję poniżej.
“Gdzie postawić agenta w Azure?” - Łukasz Kałużny Link to heading
Punktem wyjścia była prosta definicja:
Agent = model + tools + context
oraz pętla, w której agent działa (think → tools → observation → response). Pętlę uruchamia trigger, którym może być człowiek, cron, event albo wywołanie API.
Kluczowa myśl całej prezentacji: agent to zwykły mikroserwis. Albo klasyczna aplikacja, albo worker reagujący na zdarzenia. Stan agenta to po prostu baza danych, a narzędzia i LLM to nic innego jak kolejne API, które ta aplikacja wywołuje. Z tej perspektywy pytanie “gdzie postawić agenta” sprowadza się do tego samego pytania, które zadajemy sobie przy każdej innej usłudze.
Omówione opcje hostingu w Azure:
- Logic Apps - agent loop
- Microsoft Foundry - prompt agents
- Microsoft Foundry - hosted agents
- App Service
- Azure Functions - Durable Functions wraz z Durable Task Scheduler i Durable Task for AI agents
- Azure Container Apps, w tym dynamic sessions do bezpiecznego uruchamiania kodu generowanego przez LLM
- AKS
Przy skalowaniu i podejściu event-driven padły:
Ważna uwaga o frameworkach: to są klocki, a nie gotowy produkt. Nikt nie dostanie działającego rozwiązania po samym dodaniu zależności do projektu. Wspomniany został tu Microsoft Agent Framework.
Sporo czasu poświęcone zostało Logic Apps, które w kontekście agentów mogą pełnić kilka ról:
- jako serwer A2A
- jako narzędzie MCP
- jako knowledge base
- jako workflow wywołujące inne workflow
Osobny wątek to wyszukiwanie w internecie. Bing Search API jest praktycznie zabetonowane, a jedyną drogą pozostaje Grounding with Bing Search, które tak naprawdę jest wyłącznie obiektem billingowym. Warto pamiętać, że:
- dane wychodzą poza compliance boundary Azure,
- usługa korzysta z cache’u internetu, a nie z aktualnej treści stron,
- ciężko to debugować, bo nie widać dokładnie co wchodzi i co wychodzi z usługi.
Na koniec celna puenta - gwiazda śmierci wraca, tylko tym razem z LLM, czyli ryzyko, że wokół agentów znowu zbudujemy jednego wielkiego molocha, przez który przechodzi wszystko.
“Subscription Vending Machine: jak oddać Azure w ręce zespołów i nie stracić nad tym kontroli” - Krzysztof Polewiak Link to heading
Druga prelekcja dotyczyła automatyzacji zakładania subskrypcji w Azure, tak aby zespoły mogły je otrzymywać samoobsługowo, ale zgodnie z przyjętymi standardami organizacji. Całość została pokazana na bazie repozytorium:
Rozwiązanie opiera się na pipeline w Azure DevOps, który realizuje kolejne etapy: walidację parametrów wejściowych, przygotowanie subskrypcji, bootstrap za pomocą Bicep i Azure Verified Modules (resource group + user-assigned managed identity), nadanie uprawnień RBAC, opcjonalne utworzenie service connection z uwierzytelnianiem OIDC, a na końcu przeniesienie subskrypcji do docelowej management group wraz z weryfikacją.
Materiały do pogłębienia tematu:
- Subscription vending
- Azure landing zones
- Management groups
- User-assigned managed identity
- Workload identity federation dla service connection w Azure DevOps
“5 lat czy 27 dni? Disaster Recovery za rozsądne pieniądze…” - Kamil Mrzygłód Link to heading
Na tej prelekcji niestety już mnie nie było, więc odsyłam do agendy spotkania.