Dzisiaj odbyło się 82 spotkanie Microsoft Azure User Group Poland w Warszawie, w trakcie którego mieliśmy okazję posłuchać trzech prelekcji. Poniżej znajdziecie notatki z pierwszych dwóch wykładów, na których byłem obecny.

“FinOps - ale bardziej realnie” - Szymon Warda Link to heading

Prelekcja o tym, jak FinOps wygląda w praktyce — nie jako teoria, ale jako realne wdrożenie w organizacji. Główna teza: FinOps to nie jednorazowy projekt optymalizacji kosztów, lecz ciągły proces, który musi być wbudowany w codzienną pracę zespołów.

Typowe problemy, z którymi borykają się organizacje to:

  • niekontrolowane licencje,
  • maszyny działające 24/7 bez potrzeby,
  • brak budżetów i alertów kosztowych,
  • duplikacje zasobów oraz
  • Application Insights bez samplowania generujący ogromne rachunki.

Wspólny mianownik: koszty są niewidoczne podczas codziennej pracy i analizowane dopiero raz na kwartał — za późno, żeby reagować.

FinOps angażuje dwie strony:

  • dostawców (narzędzia i platformy dostarczające dane o kosztach, rekomendacje, automatyzacje) oraz
  • klientów (zespoły developerskie odpowiedzialne za licencje, tagi, budżety i procedury).

Bez zaangażowania obu stron FinOps nie działa.

Trzy filary praktycznego FinOps:

  • Governance — widoczność budżetów, eliminacja przestarzałych zasobów, automatyzacje przez Azure Policies i skrypty CI/CD
  • Nudge — automatyczne Start/Stop VM, autoskalowanie, automatyzacja backupów — zmiana zachowań przez automatykę, nie przez ręczne interwencje
  • Monitoring — cykliczne przeglądy, raporty, regularne spotkania zespołu wokół kosztów

Wdrożenie przebiega w trzech fazach:

  • najpierw inwentaryzacja i widoczność (stakeholderzy, licencje, tagi, alerty)
  • potem optymalizacja i review architektury
  • na końcu — faza kulturowa, która nigdy się nie kończy: zapobieganie regresjom, migracje, ciągłe doskonalenie procesów FinOps w organizacji.

“The Blind Spots We Didn’t Know We Had — Splitting Observability Between Datadog & Azure Log Analytics” - Vamsi Penmetsa Link to heading

Prelekcja o tym, jak efektywnie rozdzielić observability między Datadog a Azure Log Analytics — i dlaczego to nie jest wybór jedno-albo-drugie, lecz kwestia dobrania narzędzia do pytania, na które chcemy odpowiedzieć.

Datadog to platforma łącząca logs, traces i metrics w jednym miejscu — świetna do korelacji zdarzeń w czasie rzeczywistym, multicloud i środowisk hybrydowych.

Log Analytics to natywny Azure store do przechowywania i odpytywania logów zasobów za pomocą KQL — mocny w audycie, długoterminowej retencji (do 2 lat, archiwum do 10 lat) i analizie ad-hoc. Pierwsze 30 dni bezpłatnie, powyżej płatnie.

Typowa architektura:

  • App Service → Event Hub → Datadog (logi strumieniowane w czasie rzeczywistym)
  • App Service → Azure Monitor → Datadog (metryki)
  • App Service → Diagnostic Settings → Log Analytics (logi do analizy i audytu)

Główna rada z prelekcji (“10 Things I Wish Someone Told Me”): koszty mogą zaskakiwać. Basic Logs w Log Analytics są znacznie tańsze dla rzadko odpytywanych danych. Koszty ingestion w Datadog rosną gwałtownie wraz z wolumenem logów. Diagnostic Settings nie są domyślnie włączone — trzeba je skonfigurować per zasób. Sentinela nie należy umieszczać na tym samym workspace co logi operacyjne. Warto zapisywać często używane zapytania KQL jako Favourites i budować instant runbooks.

Wniosek: Datadog sprawdza się jako centrum operacyjne i korelacji zdarzeń, Log Analytics jako archiwum i narzędzie śledcze dla środowisk Azure-native. Używanie obu razem to nie nadmiarowość — to uzupełniające się kompetencje.