Menu

azure

azure_free_tier_cloud_vs_money

Azure Free Tier: Mire jók valójában az ingyenes eszközök?

, , , , ,

| Olvasási idő: 6 perc |

Rendszeresen találkozom a kérdéssel: „érdemes-e Azure-t tanulni?”. A válaszom mindig ugyanaz, és ezt mér korábban itt a blogon is kifejtettem, 2026-ban nem hogy érdemes, de az AI fejlődéséi iránya miatt talán még fontosabb, mint valaha. Azután, ahogy beszélgetünk hamar ugyanoda lyukadunk ki: mennyi pénzbe kerül-e az első lépés?

A legtöbben attól félnek, hogy a cloud azonnal százezres számlát generál. És igen, láttam már olyat, hogy valaki elfelejtett leállítani néhány VM-et, vagy egy prototípusoknak szánt Kubernetes cluster-t felskálázva hagy (Én), és meglepődött a hó végén.

Az is tény, hogy ha valaki komolyan szeretne elmélyedni ebben a világban, annak be kell fektetnie a tudásba és a jövőbe. Semmi sincs ingyen.

Ez a cikk azonban nem arról szól, hogy elvegyem mindenki kedvét a tanulástól, fejlődéstől és az új lehetőségek megismerésétől. Sőt, pontosan az a célom, hogy aki hezitál, vajon bele merjen-e vágni a felhő tanulásba, annak azt mondjam: Igen! Az Azure Free Tier a tökéletes belépési pont mert: lehet ezt tudatosan, biztonságosan és költségkontroll alatt csinálni.

Ez is segíthet, hogy el tudd dönteni, hogy miért lehet jó választás az Azure 2026-ban.

Most megmutatom, mire elég valójában az Azure ingyenes csomag – és azt is, mire nem.

Mit jelent az Azure Free Tier?

Az Azure három fő ingyenes kategóriát kínál:

  1. 12 hónapig ingyenes szolgáltatások
  2. Mindig ingyenes szolgáltatások (Always Free)
  3. 200 USD induló kredit új regisztrációkor

Ez nem csupán marketingtrükk, ezek valódi, használható lehetőségek.

Fontos: az ingyenesség erőforrás- és mennyiségi korlátokhoz kötött.

Virtuális gépek – Tanulásra elég?

Az Azure biztosít bizonyos méretű Linux vagy Windows VM-et 12 hónapig ingyenesen (korlátozott havi óraszámmal).

Mire elég ez a gyakorlatban?

  • Linux alapok tanulása
  • NGINX vagy Apache webserver kipróbálása
  • Docker telepítés
  • Egyszerű API deploy
  • CI/CD pipeline tesztelése

Mire nem?

  • Production workload
  • Magas rendelkezésre állás
  • Komoly terhelés

A Free VM tipikusan B-sorozatú, burstable instance. Ez azt jelenti, hogy rövid ideig jól teljesít, de nem folyamatos terhelésre tervezték.

Amit sokan elrontanak: Nem állítják le éjszakára. A Free tier óraszámhoz kötött.

Ez azt is jelenti, hogy a havi 750 óra nem egyetlen gépre vonatkozik, hanem az adott gépméretből az adott hónapra. Tehát indíthatok 3 db gépet is az ingyenes mérettel, de ez esetben egy gépre havi 250 óra jut majd. Ebből is látszik, hogy van ebben rugalmasság, ami emeli a használhatóságot.

Azure App Service – Egyszerű webapp hosting

Az Azure App Service rendelkezik Ingyenes (F1) csomaggal. Ez általában napi 60 perc használatot tesz lehetővé. Nem az indítástól számítják ezt az időt, hanem összegzik azon másodperceket, amikor a szolgáltatást a felhasználóink igénybe vették. Ez így máris jobban hangzik.

Mire alkalmas?

  • Portfólió weboldal
  • Prototípus alkalmazások
  • Node.js vagy .NET demo alkalmazás
  • REST API tesztkörnyezet
  • Karrierváltóknak GitHub → DevOps gyakorlás
  • Ritkán használt alkalmazások

Mire nem?

  • Enterprise szintű skálázás
  • SLA (rendelkezésreállási) garancia
  • Éles rendszer szintű stabilitás
  • Izolált környezetek létrehozása

Ez inkább egy játszótér, ahol kipróbálhatunk és megtanulhatunk dolgokat. Erre a célra viszont tökéletes.

Azure Functions – Serverless tanulás

Az Azure Functions consumption plan (Rugalmas fogyasztási csomag) modellben havi szinten bizonyos számú futtatás ingyenes.

Ez már komolyabb dolog.

Mire elég?

  • Webhook feldolgozás
  • Egyszerű háttérfolyamat
  • Időzített feladat (cron jellegű)
  • API backend MVP

Serverless architektúrát lehet vele tanulni valós módon.

Itt már látszik az enterprise gondolkodás alapja: Event-driven design, skálázás igény szerint.

Azure Cosmos DB Free Tier

Az Azure Cosmos DB rendelkezik Free Tier opcióval, amely bizonyos throughput (RU/s) és tárhely limit mellett ingyenes.

Mire jó?

  • Dokumentum alapú adatmodell tanulása
  • JSON alapú NoSQL gondolkodás
  • API backend adatbázisa
  • Proof of Concept (PoC)

Mire nem?

  • Nagy forgalmú rendszer
  • Komplex multi-region architektúra

Tanulásra, fejlesztésre teljesen reális.

Azure Storage – A csendes hős

Blob storage, Queue, File – ezekből mindig van egy kisebb ingyenes keret.

Mire elég?

Sokan nem is sejtik, hogy egy teljesen működő statikus weboldalt ki tud szolgálni Storage + CDN kombináció.

Azure SQL Database – Korlátozott, de hasznos

Az ingyenes keretben elérhető bizonyos DTU-alapú adatbázis.

Ez nem production, de:

  • SQL tanulás
  • ORM kipróbálás
  • Backend fejlesztés

Teljesen elegendő.

Azure Active Directory (Microsoft Entra ID)

Az identitás- és hozzáférés-kezelés (IAM) az egyik legfontosabb enterprise téma. Eben az Entra ID adja az alapot, ami nagyon sokáig elegendő ingyenesen is. Tehát az alap funkcionalitás mindig elérhető.

Mire jó?

  • App registration / Service principal (programozott hozzáféréshez)
  • RBAC teljeskörű használata
  • OAuth2 / OpenID kapcsolódás
  • SSO
  • Multi-tenant alkalmazás támogatás
  • B2B external user meghívás (külső felhasználók meghívása az erőforrások kezelésére)

Ami nincs benne

Karrierváltóknak, vagy akik a hagyományos Active Directory-ban jártasak, ez aranyat ér.

Ízelítő – Azure Free Tier lista (12 hónapig ingyenes és mindig ingyenes)

KategóriaSzolgáltatásIngyenesség típusaFő limit / kvóta
ComputeLinux Virtual Machine (B1s/B2)12 hónap750 óra/hó
ComputeWindows Virtual Machine12 hónap750 óra/hó
StorageBlob Storage (LRS)12 hónap5 GB
StorageAzure Files12 hónap100 GB
StorageArchive Storage12 hónap10 GB
StorageManaged Disks12 hónap2 × 64 GB
ContainerAzure Container Registry12 hónap100 GB tár
DatabaseCosmos DB12 hónap400 RU/s + 25 GB
DatabaseAzure Database for MySQL12 hónap750 óra + 32 GB
DatabaseAzure Database for PostgreSQL12 hónap750 óra + 32 GB
DatabaseSQL Managed Instance12 hónap720 vCore-óra
IntegrationService Bus (Standard)12 hónap750 óra + műveleti limit
NetworkLoad Balancer12 hónap750 óra
NetworkVPN Gateway12 hónap750 óra
NetworkOutbound Data Transfer12 hónap15 GB
SecurityKey Vault12 hónap10 000 művelet
ServerlessAzure FunctionsMindig1 millió futtatás
App HostingApp Service (F1)Mindig10 app
WebStatic Web AppsMindig100 GB bandwidth
ContainersAzure Kubernetes Service (control plane)MindigControl plane ingyen
ContainersContainer AppsMindigHavi kvótás compute
DevOpsAzure DevOpsMindig5 user
IdentityMicrosoft Entra IDMindig50 000 objektum
IdentityAzure AD B2CMindig50 000 MAU
AIAzure AI SearchMindig50 MB index
AIAzure TranslatorMindig2 millió karakter
AILanguage ServiceAlways Free5 000 rekord
AISpeech ServiceAlways FreeLimitált perc
IntegrationAPI ManagementAlways Free1 millió hívás
IntegrationEvent GridAlways Free100 000 művelet
IntegrationLogic AppsAlways Free4 000 beépített művelet
IoTIoT Hub FreeAlways Free8 000 üzenet/nap
MonitoringAzure MonitorAlways FreeLimitált adat
AdminCost ManagementAlways FreeIngyenes
AdminCloud ShellAlways Free5 GB tár
AutomationAzure AutomationAlways Free500 perc

Teljes, naprakész lista itt található.

Mit lehet ebből valójában felépíteni?

Egy reális MVP architektúra Free tierből:

  • Frontend: Azure Storage statikus weboldal
  • Backend: Azure Functions
  • Adatbázis: Cosmos DB Free tier
  • Authentikáció: Entra ID
  • Hosting: App Service Free

Ez már egy valódi, működő webalkalmazás.

Nem egy végtelenségig skálázható, robosztus rendszer, de szakmailag releváns.

Mire figyelj költség szempontból?

  1. Mindig állíts be költség keretet (nem véd meg a magas számláktól, de riaszt, amikor elérted a beállított szintet)
  2. Teszt és “éles” környezetet külön kezeld
  3. Ne futtass fölöslegesen VM-et
  4. Monitorozd a használatot

Fontos: A Free tier nem azt jelenti, hogy nem lehet számla, vagy minden ingyenes. Csak azt, hogy egy szint alatt nem kell fizetned.

Karrier szempontból mit jelent ez?

Sokan azt gondolják, hogy cloud tanuláshoz egy cég kell, ahol ki tudod próbálni az egyes megoldásokat valós élethelyzetben.

Ez nem teljesen igaz. Gyakorolhatsz való életből származó példákon (webalkalmazás, alkalmazás réteggel és adatbázissal) keresztül is.

Így egy tudatosan felépített Free tier architektúrával:

Ha jól átgondoltan teszed mindet, akkor ez már interjúképes tudás is lehet.

Őszinte korlátok

Nem lesz:

  • Magas rendelkezésre állás (High availability)
  • SLA
  • Több régióra kiterjedő redundancia (Multi-region redundancy)
  • Vállalati szintű biztonsági megfelelőség (Enterprise security compliance)

Kezdésnek azonban nem is ez a cél, hanem az alapok stabil megértése és megértése.

Úgy gondolom, hogy aki tudatosan használja az Azure Free Tier lehetőségeit, az nemcsak tanul, hanem megérti a költséghatékony működésalapjait is. És ez az, ami igazán számít.

Ez segít megkönnyíteni, melyik felhőszolgáltatót válaszd:

Ha érdekelnek a hasonló Cloud és AI tartalmak:

Iratkozz fel az InfoPack hírlevélre
Kövess LinkedIn-en
Iratkozz fel a YouTube csatornámra
Keress meg TikTok-on is

Rendszeresen jelentkezem új, szakmai tartalmakkal, hogy ismerd a Cloud izgalmas világát.

azure_openai_enterprise

Azure és OpenAI: fordulat az enterprise AI piacán?

, , , , , , , ,

| Olvasási idő: 5 perc |

Az előző cikkben megnéztük, hogy a Microsoft hogyan mozdul el a saját AI–modellek irányába, és miért csökkenti hosszú távon a függőségét az OpenAI-tól.

Most viszont beszélek a legfontosabb kérdésről: Mit jelent ez nekünk, akik Azure-t és OpenAI-modellt használunk?

Néhány fontos és mindenkiben felmerülő kérdést igyekszem megválaszolni.

Stabil marad az Azure OpenAI?

A rövid válasz: igen.

Az Microsoft és az OpenAI között több évre szóló megállapodás van érvényben. Az Azure OpenAI Service jelenleg működik, frissül, támogatott.

Ha ma:

  • chatbot-ot futtatsz Azure-on
  • RAG rendszert építesz
  • belső tudásbázist generatív AI-val egészítesz ki

akkor nincs ok azonnali aggodalomra.

Ez nem egy hirtelen váltás, sőt az is lehet, hogy hosszú távon sem fog ez Téged érinteni.

Mit csináljunk máshogy az AI-al?

Amit én sok cégnél látok: az LLM-et fix, központi komponensként kezelik. Konkrét modell névre és típusra építik a szolgáltatásokat.

Nagyon ritka, hogy valaki megfelelően, konfigurációs állományban definiálva használja a modelleket. És néhány esetben láttam már olyat is, hogy egy modellre specifikusan van írva a kód. Nincs fallback, nincs B terv.

Ez rövid távon működik, vagy prototípusok esetén kiválóan működik, de hosszú távon nagyon kockázatos.

Ha a Microsoft saját foundation modelleket (alapmodell) vezet be Azure-on belül, akkor valószínűleg még a jelenleginél is több modell közül választhatunk majd. Ez jó hír, hiszen még több lehetőségünk van megtalálni a megoldásunkhoz tökéletesen passzoló modellt.

Ez azonban csak akkor működőképes, ha az architektúránk erre fel van készítve. Ha tanácstalan vagy, hogyan tudod ezt megtenni, az alábbiak segíthetnek:

  • Service layer: Az LLM-hívás legyen egy központi backend szolgáltatásból megvalósítva, és ne a UI réteg (frontend) vagy minden mikroszolgáltatás saját, egyedi integrációja. Így ha később modellt kell cserélni, azt nem az egész kódbázisban kell átírni, hanem csak a backend-hez kell hozzányúlni.
  • Konfigurálható modellválasztás: A használt AI-modell ne legyen fixen beégetve a kódba, hanem konfigurációból lehessen meghatározni, hogy éppen melyik modellt és annak melyik verzióját használja a rendszer. Ez lehetővé teszi, hogy teszteléskor egy olcsóbb (akár helyi) modellt használjunk, éles környezetben pedig egy erősebbet, vagy hogy gyorsan váltsunk, ha változik az ár vagy a teljesítmény.
  • Monitoring token- és költségszinten: Az AI-hívások költsége token alapú, ezért nagy forgalomnál gyorsan elszállhat, ha nincs rálátásunk a használatra. A felhőszolgáltató ad alap költségfigyelést, de enterprise környezetben alkalmazás szinten is érdemes mérni, mely funkció mennyi AI-erőforrást fogyaszt. A token az AI világában ugyanaz, mint korábban a CPU-idő volt: ha nem mérjük, nem tudjuk kontrollálni.
  • Fallback modell logika: Érdemes úgy megtervezni a rendszert, hogy ha az elsődlegesen használt modell nem elérhető, túl lassú vagy túl drága, akkor a rendszer automatikusan át tudjon váltani egy alternatív modellre. Ez növeli az üzletmenet-folytonosságot és csökkenti a szolgáltatáskimaradás kockázatát.

Ezek nem felesleges lépések, hanem a hosszútávú stabilitást biztosító praktikák.

Ugyanúgy, ahogy nem kötjük egyetlen availability zone-hoz a rendszert, ne kössük egyetlen modellhez sem.

AI vendor lock-in kérdés

Az Azure használata önmagában nem feltétlenül probléma. Az viszont igen, ha az AI logika teljesen egy adott modell viselkedésére optimalizált, az már kockázat.

A piac abba az irányba megy, hogy a nagy cloud szolgáltatók (kivéve Azure) kínál saját modelleket. A Google (Gemini, Imagen, stb) és az AWS (Amazon Titan) is kínálnak saját modelleket.

Ha te Azure-on maradsz, az teljesen jogos döntés, de az AI-réteg legyen cserélhető.

Egy jól átgondolt architektúrában az alábbiakat követjük:

  • Platformfüggetlen: A rendszer ne egy konkrét cloud szolgáltató vagy modell sajátosságaira épüljön, hanem általános LLM-képességre.
  • API-absztrakció: Az LLM-hívásokat egy központi backend API kezelje, ne a frontend vagy több különálló komponens közvetlenül a modellt.
  • Tudatos modellválasztás: A modell kiválasztása use case, teljesítmény és költség alapján történjen, ne alapértelmezett döntésként.

Copilot jövője

A Microsoft 365 Copilot és a GitHub Copilot jelenleg jelentős részben OpenAI modellekre épülnek, de tudunk már egyéb modelleket is használni, például a Sonnet-et vagy a Opus-t.

Ha a Microsoft saját modelleket integrál, az nem feltétlenül jelent minőségromlást. Én úgy gondolom, inkább előrelépést hozhat, mert nem egy általános modellt kapunk majd, hanem specializált megoldásokat.

A Microsoft célja inkább a:

  • költségcsökkentés
  • adatkontroll
  • stratégiai függetlenség

Felhasználói oldalról nagyobb változás csak akkor várható, ha a modellváltás érezhetően befolyásolja a minőséget.

AI költségtudatosság

Ez az a pont, amit nem lehet megkerülni. Az AI nem olcsó és bármit is hoz a jövő a költség az egyik legfontosabb tényező marad.

Az AI-szolgáltatások token alapú számlázással működnek, vagyis minden elküldött és generált szöveg után fizetünk, és mivel a modellek komoly számítási kapacitást igényelnek, nagy forgalomnál a költség nagyon gyorsan meg tud nőni.

Ha a Microsoft saját modellekkel optimalizálni tudja a költségstruktúrát Azure-on belül, az enterprise ügyfeleknek előny lehet.

Ma még nem tudjuk, hogy az új modellstratégia pontosan milyen árszinten jelenik meg, ezért különösen fontos a használat folyamatos monitorozása és a költséglimitek beállítása. Érdemes a teszt- és éles környezetet szigorúan elkülöníteni, valamint kontroll alatt tartani a fejlesztői környezeteket is, hogy ne maradjanak feleslegesen futó, költséget termelő AI-folyamatok.

Igen, ez AI-nál is ugyanaz a jelenség, mint VM-eknél: ha nem figyelsz, elszáll a költség.

Karrier szempontból mit tanulj?

Ha Azure + OpenAI irányba haladsz, ne csak prompt engineeringet tanulj.

Tanuld meg az alapokat és az általános AI világ rejtelmeit:

  • hogyan működik egy RAG architektúra
  • miként mérünk modell teljesítményt
  • milyen módon optimalizálunk költséget
  • miért tervezzünk multi-model környezetet
  • stb.

A piac nem egy modell köré szerveződik. Hanem AI megoldások és technikák köré.

A lényeg

Nem kell kétségbe esni, a két cég nem szakít és nem vállnak azonnal ketté útjaik. Inkább járjunk nyitott szemmel és készüljünk fel a változásra.

  • Az Azure OpenAI ma stabil
  • A stratégia változik
  • A piac érik és fejlődik
  • Az architektúrának rugalmasnak kell lennie

Ha AI-rendszert építesz Azure-on, most van itt az ideje annak, hogy enterprise szinten gondolkodj: költség, biztonság, rugalmasság.

Érdekelnek a hasonló Cloud és AI tartalmak?

microsoft_openai_broken_heart_1024x1024

Microsoft Azure és OpenAI 2026: új korszak az AI-ban?

, , , , , , , ,

| Olvasási idő: 4 perc |

Amikor AI-ról beszélek, időről időre együtt említettem a Microsoft és az OpenAI nevét. A két cég együtt formálta azt, amit ma enterprise AI-nak hívunk. Azure + GPT modellek. Copilot. ChatGPT integrációk. Egy ökoszisztéma, ami nagyon gyorsan alapértelmezetté vált. Kettejük kapcsolatáról és az első lépésekről olvashattál már korábban. Abban a cikkben, nem feltétlenül ezt a jövő képet vázoltam neked, ami sok szempontból teljesül is.

Azt azonban akkor még nem lehetett megjósolni, ami most kezdődött el. Mert egy fontos stratégiai elmozdulás látszik. Egyértelműen, nem ez volt a tervük, de talán maga a piac, ami mindent megváltoztatott.

A Microsoft megerősítette, hogy hosszabb távon csökkenteni szeretné a függőségét az OpenAI modelljeitől, és saját foundation modellek fejlesztésébe fektet komoly erőforrásokat. Ez nem bulváros szakítás, hanem stratégiai érettség és reakció a többi szolgáltató (AWS, Google Cloud) által mutatott trendekre.

És habár elsőre ez sokkolóan hathat, én úgy gondolom, hogy inkább egy logikus lépés volt.

Mi történik valójában?

A Microsoft nem “kapcsolja le” az OpenAI-t. A két fél között továbbra is élnek szerződések, több évre szóló együttműködéssel. Az Azure OpenAI Service továbbra is működik.

Ami változik, az a hangsúly. A Microsoft saját AI-modell fejlesztési kapacitást épít, hiszen eddig erre nem sok energiát fordított. Inkább kényelmes pozícióból figyelte az eseményeket, miközben az OpenAI modelljeit kínálta. Most saját compute, saját kutatócsapatok, saját architektúra lesz. Ennek célja:

  • nagyobb kontroll
  • költségoptimalizálás
  • kisebb külső függőség
  • stratégiai önállóság

Enterprise világban ez teljesen logikus lépés, bár a Google-től már ebben eléggé lemaradt.

Egy nagyvállalat nem szeret egyetlen beszállítóra támaszkodni egy ennyire kritikus és gyorsan változó területen.

Miért most?

Az AI ma már nem kísérlet. Nem innovációs laborkérdés. Az AI ma „core” platform komponens.

Ahogy korábban a virtualizáció, majd a cloud, most az AI vált infrastruktúra-szintű döntéssé. És infrastruktúrában senki nem szeret 100%-ban egy partnerre építeni. Ez egy stratégiai diverzifikáció.

Mit jelent ez az AI-piacnak?

Ahogy én jelenleg látom, ez a lépés három dolgot jelez felénk.

  1. az AI verseny élesedik: Nem egy domináns modell világa jön, hanem több erős szereplőé.
  2. csökkenő különbség: A foundation modellek (pl.: GPT, Claude, Gemini, Llama) közötti különbségek egyre kevésbé jelentenek majd valódi versenyelőnyt. Ha több nagy szereplő saját modellt fejleszt, az árversenyt és innovációt hoz.
  3. AI platformokká alakulás: A cloud szolgáltatók AI-first platformmá válnak. Az AI nem kiegészítő lesz, hanem a platform része.

Ez nem csak Microsoft történet. Ugyanez látszik a Google és az Amazon oldalán is, saját modellekkel, saját AI stackkel.

És mi lesz az OpenAI-jal?

Ez egy igazán fogós kérdés. Amit látunk: az OpenAI továbbra is jelentős befektetéseket von be, masszív compute igénnyel működik, és komoly piaci jelenléte van.

Az AI modellek fejlesztése extrém költséges. GPU, adat, kutatás, energia. Ez nem egy olcsó sport, és több korábbi előrejelzés és beszámoló szerint is, az OpenAI anyagi gondokkal küszködik.

A piac most abba az irányba halad, ahol a nagy szereplők saját infrastruktúrára és saját modellekre támaszkodnak. Ez nem feltétlenül gyengíti az OpenAI-t, de átrendezi az erőviszonyokat.

Miért fontos ez neked?

Ha cloud irányba tanulsz, ha AI-ban gondolkodsz, ha karrierváltóként nézed ezt a világot, akkor ez egy nagyon fontos jel. Az AI nem egy céghez kötött technológia. Az AI egy platformréteg.

És platformrétegben mindig az nyer, aki érti az architektúrát, nem csak a konkrét API-t.

Ha ma GPT-t tanulsz, jó úton jársz.
De még jobb úton jársz, ha azt tanulod meg:

  • hogyan épül fel egy LLM-alapú rendszer
  • milyen módon működik egy RAG architektúra
  • miképp kezeljük a token költséget
  • hogyan tervezzünk modell-agnosztikus rendszert

(Modell-agnosztikus: olyan megoldás vagy rendszer, ami nem függ egy konkrét AI modelltől, és több különböző modellel is működhet – pl. GPT, Claude, Gemini, Llama)

Mert ahogy Te magad is tapasztalod a modellek jönnek-mennek és csak az architektúra állandó.

Jön a folytatás

Ebben a cikkben a stratégiai képet néztük meg: mi történik a Microsoft és az OpenAI kapcsolatában, és mit jelent ez a piac számára.

A következő részben viszont konkrétan arról fogok írni:

Mit jelent ez nekünk, Azure és OpenAI felhasználóknak?

  • Stabil marad az Azure OpenAI?
  • Kell-e újratervezni az architektúrát?
  • Változik a Copilot jövője?
  • Hogyan gondolkodjunk a vendor lock-in jelenségről 2026-ban?

Abban az esetben, ha Azure-ban vagy AI-ban építkezel, azt a részt ne hagyd ki.

Ha kíváncsi vagy, hogyan folytatódik a történet akkor ne maradj me a folytatásról, ahol már kicsit gyakorlati szemmel is nézzük a kérdést.

Érdekelnek a hasonló Cloud és AI tartalmak?

azure-logic-apps-hero

Az Azure Logic Apps csendben felnőtt – és AI-kompatibilis is

, , , , , , , , , ,

| Olvasási idő: 5 perc |

Amikor az elmúlt években Azure Logic Apps-ről beszélgettünk, gyakran ugyanoda jutottunk: jó eszköz, rengeteg integrációs lehetőséggel, mégis maradt bennem egy állandó hiányérzet. Én magam is sokszor éreztem azt, hogy működik, de nem igazán élvezetes vele dolgozni. Mondhatni, kicsit merev és nem túl vonzó a grafikus felülete.

Ez az érzés 2025 nyarán is nagyon erősen visszajött, amikor készítettem a „NoCode és LowCode megoldások Azure-ban és AWS-ben” videós képzési anyagot. Akkor is pontosan ezt láttam: az Azure Logic Apps elképesztően sok lehetőséget rejt, mégsem olyan kényelmes használni, mint amennyit valójában tud. Nem a funkcionalitás hiányzott, hanem a használhatóság nem nőtt fel a képességekhez.

2025-ben viszont ez a helyzet látványosan megváltozott. Nem egy hangos marketingkampánnyal, hanem több, egymásra épülő, tudatos fejlesztéssel. Ráadásul ezek a változások már nem csak az integrációról szólnak, hanem arról is, hogyan illeszkedik a Logic Apps az AI-ügynökökkel dolgozó architektúrákba.

Azure Logic Apps Designer újratervezése

2025 novemberében a Microsoft bejelentette az Azure Logic Apps Designer teljes újratervezését, amely jelenleg Public Preview státuszban érhető el a Standard workflow-khoz.

Ez nem egyszerű UI-frissítés. Inkább egy felismerés eredménye. A Logic Apps-et ma már nem csak kisebb automatizmusokra használják, hanem üzletileg kritikus folyamatokra is.

A korábbi designer elsősorban kisebb workflow-kra volt optimalizálva. Nagyobb folyamatoknál gyorsan átláthatatlanná vált, és hosszabb távon mentálisan is fárasztó volt vele dolgozni.

Az új szerkesztő ezzel szemben sokkal jobban kezeli a nagy és összetett workflow-kat. Logikusabb lépésszervezést ad, és végre nem büntetés egy több tucat lépésből álló folyamat karbantartása.

Tehát az új funkció jelenleg csupán a Standard verzióknál elérhető.

Azure Logic Apps new designer availability

Erre figyelni kell, ha szeretnék kipróbálni az új felületet. Itt sem alapértelmezetten kapjunk, hanem be kell azt kapcsolnunk. Ezt könnyű megtenni a portálon.

Azure Logic Apps new designer on

Ha pedig nem tetszik, bármikor vissza is válthatunk a korábbi megoldásra.

Azure Logic Apps new designer off

Az XML kezelése végre élhetőbb

Kevésbé látványos, de szakmailag nagyon fontos változás az XML-kezelés javítása.

Aki dolgozott már SOAP-alapú integrációkkal, legacy rendszerekkel vagy vállalati adatcsere-folyamatokkal, pontosan tudja, mennyire nehézkes volt korábban az XML feldolgozása Logic Apps-ben.

2025-ben ezen érezhetően javítottak. Az XML struktúrák kezelése átláthatóbb lett, a kifejezések logikusabban épülnek fel, és az egész élmény már közelít a JSON feldolgozás egyszerűségéhez. Nem lett tökéletes, de végre nem érzem azt, hogy tudatosan kerülni kellene.

Azure Logic Apps mint MCP szerver

A Microsoft Build 2025 egyik stratégiailag legfontosabb bejelentése az volt, hogy az Azure Logic Apps Standard képes MCP, vagyis Model Context Protocol szerverként működni.

Ez elsőre technikai részletnek tűnhet, valójában azonban szemléletváltást jelent. Az MCP célja az, hogy az AI-ügynökök strukturált módon érjenek el műveleteket. Nem ad-hoc API-hívásokkal, hanem egy egységes, szabványosított protokollon keresztül.

Ebben a modellben a Logic Apps egy vizuálisan definiált, enterprise szintű végrehajtási réteggé válik. Több száz connector, kiforrott security és governance modell, valamint most már MCP-kompatibilis működés áll rendelkezésre. Ez ideális alapot ad AI-agentek számára is.

Egy Azure Logic Apps példa

Képzelj el egy AI-ügynököt, amely beérkező e-maileket elemez, majd eldönti, hogy incidensről, számlázási kérdésről vagy support megkeresésről van szó. A döntés után elindítja a megfelelő üzleti folyamatot.

Ebben a felállásban az AI-ügynök hozza meg a döntést, a Logic Apps pedig megbízhatóan végrehajtja azt, ahogy eddig is tette azt. Jegy létrehozás, adatlekérdezés, értesítés, auditálás mind jól definiált workflow-kban történik, MCP-n keresztül.

Itt válik igazán érdekessé a Logic Apps szerepe. Nem okosabb lesz, hanem stabilabb és kiszámíthatóbb végrehajtó réteggé válik.

Mit jelent ez ha most kezded?

Ha most ismerkedsz a felhővel vagy a NoCode és LowCode világgal, akkor a Logic Apps továbbra is könnyen tanulható maradt. Nem kell azonnal AI-agentekben vagy AI-ügynökökben gondolkodnod. Az alap automatizmusok ugyanúgy működnek, mint eddig.

A különbség az, hogy amit most tanulsz, az nem zsákutca. Később természetes módon bővíthető AI-alapú megoldások irányába is.

Haladóknak és karrierváltóknak

A 2025-ös változások egyértelmű irányt mutatnak. Az integráció, az automatizálás és az AI egyre inkább összenő.

Az Azure Logic Apps ma már nem csak összeköt, hanem orchestration rétegként és végrehajtási motorként működik. AI-ügynökök stabil háttérrendszere lehet, nagyvállalati környezetben is.

Ez hosszú távon értelmezhető, jövőálló tudás. Ráadásul most már mindezt egyben elérheted az Azure-on belül.

Öszefoglalva

2025-ben az Azure Logic Apps csendben, de határozottan szintet lépett. Az új designer használhatóbbá tette, az XML-kezelés élhetőbb lett, az MCP-szerver képesség pedig teljesen új szerepbe helyezte a szolgáltatást.

Számomra ez azt jelenti, hogy a Logic Apps újra komolyan vehető eszköz lett. Nem csak integrációra, hanem AI-ügynökökkel együttműködő architektúrákban is.

Ami fontos: Az új designer sem váltja ki az átgondolt tervezést.

Ígérem, nem állunk meg az elméletnél. Hamarosan hozok egy részletes, végigkövethető példát is, amelyet már az új Logic Apps designerrel valósítok meg, valós problémára, valós döntési pontokkal. Megmutatom, hol erős az új megközelítés, és azt is, hol vannak még kompromisszumok.

Ha követsz, elsőként látod majd ezt a gyakorlati anyagot, és nem csak azt fogod érteni, mi változott, hanem azt is, mikor és miért érdemes használni.

Ha szeretnél ebben az irányban tisztábban látni, érdemes követned a további cikkeimet és feliratkozni az InfoPack hírlevélre.

MiertAzure2026-cikk

Felhőválasztás 2026 – Azure az egyik legkényelmesebb felhő?

, , , ,

| Olvasási idő: < 1 perc |

Éveleje a fogadalmak időszaka. És ez kiváló alkalom arra, hogy elhatározzuk, megtanulunk valami új dolgot vagy elérkezettnek látjuk az időt a karrierváltásra, és megnézhetjük mit tartogat nekünk a felhő.

A felhő egy kikerülhetetlen szereplő és az AI térhódításával még hangsúlyosabb, hogy alapos ismeretünk legyen ezen a területen. És ekkor merül fel a kérdés: Vajon melyik felhőszolgáltató a legjobb? Melyiket válasszam?

Ebben szeretnék neked segíteni legújabb videó sorozatommal, mely röviden bemutatja mindhárom felhőszolgáltatót.

Egy korábbi cikkemben egy sajátos összehasonlítást végeztem a felhőszolgáltatók között.

Ennek első része röviden ismerteti az Azure azon előnyeit amelyeket én elsőre fontosnak tartok és szerintem kezdők számára ez lehet a legkényelmesebb választás.

Ezeket érintem:

  • Miért Azure?
  • Biztonsági előnyök
  • AI és Power Platform
  • Gyakorlati előnyök

Ha szeretnél ebben az irányban tisztábban látni, érdemes követned a további cikkeimet és feliratkozni az InfoPack hírlevélre vagy a YouTube csatornámra.

azure-aws-gcp-1024

Azure, AWS vagy GCP? – melyiket érdemes választani

, , , , , , , , ,

| Olvasási idő: 7 perc |

Itt az év elején kiváló alkalom kínálkozik arra, hogy megválaszoljam az egyik leggyakrabban felmerülő kérdést a cloud világában, amit rendszeresen feltesznek nekem a diákjaim és a mentoráltjaim is:

Azure, AWS vagy GCP?

Ez a kérdés szinte mindenkinél előjön. Kezdőknél, karrierváltóknál, de még olyanoknál is, akik már dolgoztak valamelyik platformmal. Megnézel pár videót, elolvasol néhány cikket, és könnyen azt érzed, hogy most azonnal döntened kell. Mintha ez egy végleges választás lenne.

Én viszont mást tapasztaltam. Az elmúlt években többször változott, hogy melyik platform áll közelebb hozzám, és ez teljesen rendben van. A cikk végén el is árulom, 2026 elején én személy szerint melyiket kedvelem jobban – és miért.

Ez az írás nem egy részletes összehasonlítás, hanem egy iránymutatás és gondolatindító, amely segít csökkenteni a döntés körüli bizonytalanságot.

Egy fontos igazság, amit kevesen mondanak ki

Technikai értelemben nincs rossz választás.

A Microsoft Azure, a Amazon Web Services és a Google Cloud Platform mind ugyanarra képesek alapvetően:

A különbség nem abban van, hogy mit tudnak, hanem abban, hogyan közelítik meg ezeket a problémákat, és mennyire könnyű ezt megérteni új belépőként.

API és CLI – mindhárom erős

Ezt érdemes külön hangsúlyozni:
API– és CLI-támogatásban mindhárom platform kiváló.

Azure, AWS és GCP esetén is:

  • szinte minden szolgáltatás elérhető API-n keresztül
  • stabil, jól dokumentált CLI eszközök állnak rendelkezésre
  • az automatizálás és CI/CD első osztályú

Ez azt jelenti, hogy hosszú távon egyik platform sem korlátoz technikailag. A különbség inkább ott jön elő, mennyire könnyű elindulni és átlátni, hogy mi történik a háttérben.

Azure – érthető nyelv, strukturált gondolkodás

A Microsoft Azure egyik legnagyobb előnye az őszinte, egyértelmű elnevezés.

Virtuális gép az virtuális gép.
Hálózat az hálózat.
Tároló az tároló.

Ez tanulás közben óriási segítség. Nem kell egy külön „cloud nyelvet” megtanulnod ahhoz, hogy megértsd az alapokat, hanem mindent úgy használhatsz, ahogy eddig hallottad, olvastad vagy tudtad.

A portál megjelenése sokszor konzervatív, de cserébe nagyon jól támogatja az átláthatóságot. Az erőforráscsoportok, címkék és szűrők segítenek rendet tartani, ami később költség és üzemeltetés szempontjából is kritikus.

Fontos különbség kezdőknek: az Azure felülete és dokumentációja magyar nyelven is elérhető.
Ez nem kötelező, de az elején komoly mentális terhet vesz le a válladról. Azt azonban fontos szem előtt tartani, hogy a magyar nyelv gépi fordítású, tehát bizonyos esetekben nem a legkellemesebb olvasni azt. Ezen felül a portálon is észrevehető több esetben hogy egy-egy szolgáltatás több néven szerepel, attól függően, hová kattintunk. Ez zavaró lehet.

2026. elején az Azure iránti érdeklődés különösen erős az AI-integrációk miatt, főleg az OpenAI-hoz kapcsolódó szolgáltatások és az enterprise fókusz miatt.

AWS – cloud-native szemlélet, maximális rugalmasság

Az Amazon Web Services filozófiája más. Itt szolgáltatásokban gondolkodsz, nem projektekben.

A konzol letisztult, gyors, viszont nem mutat meg mindent egy helyen. Kezdőként ez zavaró lehet, később viszont sokkal hasznosabb lehet, mert nagy rendszereknél jobban átlátható, ahol egy-egy szolgáltatást szeretnénk csupán egyszerre kezelni.

Az integrációk erősek, az automatizálás természetesen konfigurálható, a cloud-native irány itt nagyon hangsúlyos. Ha valaki szeret mélyebben rendszerekben gondolkodni, az AWS kiváló terep.

A klasszikus nehézség a jogosultságkezelés. Az IAM nagyon erős, de kezdőként könnyű túlbonyolítani. Ha egyszer összeáll a kép, utána már nem probléma – de az elején hosszabb a tanulási folyamat. Ezt tovább nehezíti, hogy kifinomult jogosultságokat több módon is be lehet állítani, amelyeket nagyrészt JSON objektumokon keresztül érhetünk el. Semmi esetre sem hátrány ez, csupán egy lassabban elsajátítható tulajdonság.

Fontos különbség: AWS esetén nincs magyar nyelvű felület vagy dokumentáció, minden angolul érhető el.

GCP – mérnöki logika, adat és AI fókusz

A Google Cloud Platform sokszor kevesebb figyelmet kap, pedig technikailag nagyon erős.

A GCP egyik legnagyobb előnye a letisztult, mérnöki megközelítés. Sok szolgáltatás mögött ugyanaz a technológia van, amit a Google saját rendszereinél is használ. Ez különösen az adatfeldolgozás és AI területén érződik.

A felület általában egyszerűbb, kevésbé zsúfolt, mint a másik kettőnél. Elsőre is könnyű átlátni, mi történik, viszont kisebb az „enterprise cucc”, mint Azure vagy AWS esetén. Ez nem azt jelenti, hogy nem alkalmas nagyvállalati megoldások megvalósítására.

A GCP erős:

  • adatplatformokban
  • gépi tanulásban
  • Kubernetes-közeli megoldásokban

Ugyanakkor fontos látni: GCP-nél sincs magyar nyelvű felület vagy dokumentáció, minden angolul érhető el, és bizonyos enterprise minták kevésbé nyilvánvalóak, mint Azure-ban.

Mesterséges Intelligencia 2026-ban – mindhárom jó választás

Azure, AWS és GCP is komolyan veszi az AI-t. Más hangsúlyokkal, más eszközökkel, de mindhárom platform alkalmas valós üzleti megoldásokra.

Amit viszont mindig hangsúlyozok: az AI sem varázslat. Cloud alapokra épül, hálózatra, biztonságra, költségkeretekre. Ha ezek nincsenek rendben, az AI sem fog csodát tenni.

A felhő is csak akkor költséghatékony, ha okosan használjuk.

Hogyan válassz, ha most kezdesz bele?

Én ezt a gondolkodást javaslom:

  • ne technológiát válassz, hanem tanulási élményt: melyik esik kézre, melyik megértése egyszerűbb számodra
  • melyik motivál hosszabb távon: amelyik tetszik, azt válaszd
  • ne akarj mindent egyszerre megtanulni: a fokozatosság a kulcs
  • fogadd el, hogy a döntés nem végleges: a szolgáltatók is változnak és Te is. Ma még ezt kedveled, holnap a másikat. Ez rendben van.

Ha számodra a Microsoft-os háttér és az OpenAI a fontos, akkor merülj el az Azure világában. Cloud-native megoldások érdekelnek és a mély technikai megvalósítások, ez esetben az AWS lesz a Te utad. Ha pedig az adat, vagy a gépi tanulás, esetleg a Kubernetes-közeli világ foglalkoztat, akkor nézd meg a GCP-t.

Amit vállalati oldalon látok

A nagyvállalati valóság az, hogy a cégek többsége egyetlen hyperscaler-re fókuszál. Nem azért, mert ne ismernék a vendor lock-in kockázatát, hanem mert a gyorsaság, az egyszerűbb működés és a költségkezelés fontosabb számukra.

Sok esetben a vendor lock-in tudatos kompromisszum. Mire valódi problémává válna, a rendszer már annyira mélyen beágyazódott az adott felhő ökoszisztémájába, hogy a kiszállás csak jelentős költségek és komoly átalakítás árán lenne lehetséges. Ilyenkor inkább együtt élnek vele.

Reális alternatívaként gyakran hibrid megoldások jelennek meg, főleg hagyományos rendszerek, adatvédelmi vagy compliance okok miatt. Ez sokszor kezelhetőbb, mint több hyperscaler párhuzamos használata.

Én az ideális állapotot máshogy látom. Egy olyan több-felhős megközelítésben, ahol minden szolgáltatótól azt használom, amiben valóban erős, miközben tudatosan figyelek arra, hogy ne zárjam be magam visszafordíthatatlanul egyetlen platformba.

Számomra ez olyan, mintha egy különleges menüt állítanék össze a legjobb éttermek kínálatából. A végeredmény kiváló lehet, de több tervezést, nagyobb szakmai érettséget és folyamatos odafigyelést igényel. Nem a legegyszerűbb út, de hosszú távon a legkiegyensúlyozottabb.

A siker nem azon múlik, melyik platformot választod, hanem azon, hogy:

  • érted-e az alapelveket
  • költségtudatosan tervezel-e
  • biztonságban gondolkodsz-e már az elején
  • egyszerű és a megfelelő megoldásokkal indulsz-e

Számomra melyik?

2026 elején összességében az AWS áll közelebb hozzám. Nem azért, mert az Azure rossz lenne – sőt, AI területen jelenleg egyértelműen erős, különösen enterprise környezetben. Ezt kár lenne vitatni.

Amiért nálam most mégis az AWS a „nyerő”, az inkább rendszerszintű gondolkodás kérdése. Az AWS szolgáltatásai, integrációi és a cloud-native szemlélet sok esetben jobban illeszkednek ahhoz, ahogyan ma infrastruktúrát és platformokat tervezek. Nagyobb szabadságot ad, kevesebb röghöz kötött megoldással, ami számomra most előny.

Hangsúlyozom: Ez nem végleges álláspont. Volt már olyan időszak, amikor az Azure volt előrébb, és könnyen lehet, hogy lesz még ilyen. A cloud világában a technológia és az igények is gyorsan változnak – ezzel együtt a preferenciák is.

A lényeg nem az, hogy melyik platform jobb, hanem az, hogy tudd, miért választasz egyet egy adott helyzetben.

Zárásképpen

Az Azure, az AWS és a GCP valós piaci versenytársak. Más üzleti fókusz, más ökoszisztéma, más erősségek mentén fejlődnek. A gyakorlatban viszont a legtöbb mérnök és cég nem „platformhűség”, hanem konkrét problémák és költségek alapján dönt.

Továbbra sem az a legfontosabb kérdés, hogy melyiket választod elsőre, hanem az, hogy:

  • értsd a cloud alapelveket,
  • tudd, mikor melyik platform miért jó választás,
  • és képes legyél később váltani vagy több platformban gondolkodni.

A platformválasztás csak egy döntés. A valódi érték abból jön, ha tudatosan és magabiztosan használod.

Ha ebben szeretnél előrébb lépni, több módon is tudlak támogatni:

  • Mentoring – személyre szabott segítség cloud tanuláshoz, karrierváltáshoz vagy enterprise szemlélet kialakításához
  • InfoPack hírlevél – rendszeres, gyakorlatias cloud és AI tartalom.
  • Képzések a Mentor Klubnál – soft- és hardskill képzések egy helyen; nézz körül, és csatlakozz a következő képzéseim valamelyikéhez
ai-cloud-2026-featured-1024

AI + Cloud 2026: amikor a platform életre kel és gondolkodik

, , , , , , , , , ,

| Olvasási idő: 6 perc |

Az előző cikk végén ott hagytuk abba, hogy 2026-ban a cloud már nem cél, hanem eszköz. Egy gondolkodásmód, amire a legtöbb digitális rendszer épül. A következő lépés viszont már nem pusztán erről szól. Az igazi változás ott kezdődik, amikor az AI nem csak használja ezt az alapot, hanem formálni is kezdi a felhőt.

Ez a cikk erről a személetváltásról szól. Nem arról, hogy melyik modell jobb, és nem is technikai útmutató. Sokkal inkább arról, milyen szerepe lett és lesz az AI-nak a cloud működésében, és milyen következményei vannak ennek technológiai, gazdasági és döntési szinten.

Az AI szerepe a Cloud-ban megváltozott

Az AI ma már nem külön projektként jelenik meg a felhőben. Nem egy újabb doboz a sok közül, hanem platformszintű képesség. A cloud szolgáltatók nem egyszerűen futtatási környezetet adnak hozzá, hanem olyan rétegeket építenek köré, amelyek az AI-t beemelik a mindennapi működésbe. Mindehol ott a Co-Pilot jellegű működés, amely arra hivatott, hogy segítse a mindennapjainkat. Bár néha kifejezetten idegesítő.

Ez jól látszik abban, ahogyan a hyperscalerek pozicionálják az AI-t. Nem egyetlen „AI termékről” beszélnek, hanem olyan szolgáltatásokról, amelyek architektúra-tervezést, skálázást, költségoptimalizálást vagy incidensek értelmezését is támogatják. Fontos: Az AI nem helyettesít, hanem döntési teret alakít át.

Azure, AWS és GCP – „minden út Budára vezet”

A Microsoft Azure esetében az AI erősen az LLM-vonal köré szerveződik. Az Azure OpenAI Service és az erre épülő enterprise megoldások azt mutatják, hogy az AI szorosan integrálódik az üzleti folyamatokba. Nem önmagában érdekes, hanem azért, mert ott jelenik meg, ahol a felhasználók dolgoznak. Persze ez csak egy nagyon apró része annak az AI funkcionalitásnak és trendnek, amit ma ismerünk.

Az AWS más irányból érkezett. Régóta erős a machine learning területén, és ezt a tapasztalatot vitte tovább platformlogikába. A Bedrock a generatív AI-t teszi elérhetővé felügyelt módon, míg a SageMaker AI a klasszikus ML-életciklust fedi le. Az üzenet itt nem a modell, hanem az eszköztár és az irányíthatóság.

A Google Cloud Platform pedig azért érdekes, mert az AI nem új irány nála. A Google belső rendszerei évek óta AI-ra épülnek, és ez a szemlélet jelent meg a Vertex AI köré szervezett cloud kínálatban. Itt az adat és az AI szoros összekapcsolása kerül fókuszba.

A közös pont mindhárom esetben az, hogy az AI nem kiegészítő, hanem a platform működésének része lett.

Miért lett a cloud az AI természetes közege?

Sokan még mindig hardveroldalról közelítik meg az AI-t: milyen GPU kell hozzá, mennyi memória, elég-e egy erős otthoni gép. Ez a gondolkodás érthető, de egyre kevésbé írja le a valóságot.

A cloud egyik legnagyobb előnye az AI esetében nem pusztán a teljesítmény, hanem a skálázhatóság és az időbeliség. Olyan erőforrások érhetők el rövid időre is – több terabájt memória, több nagy teljesítményű GPU egy környezetben –, amelyek otthoni vagy kisebb on-prem környezetben nem reálisak.

A valódi szemléletváltás azonban ott történik, hogy az AI jellemzően felügyelt (managed) szolgáltatásként jelenik meg. Nem kell CPU-, RAM- vagy GPU-konfigurációval foglalkozni, nem kell drivereket, frameworköket karbantartani. Ezeket a problémákat a platform kezeli.

Személyes megjegyzésként idekívánkozik, hogy 2026-ban én is szert tettem egy aránylag erős helyi gépre, kifejezetten AI-val való kísérletezésre és fejlesztésre. Egy Ryzen 7 7800X3D, 64 GB RAM és egy RTX 3090 24GB körüli konfiguráció már alkalmas arra, hogy kis- és közepes modellekkel dolgozzak, tanuljak, prototípusokat építsek.

De ez a tapasztalat inkább megerősítette bennem: amit helyben lehet, az tanulás és kísérletezés. Amint skálázni, párhuzamosítani vagy üzemszerűen használni szeretnék, a cloud egyszerűen más ligában játszik.

És itt előtérbe kerül az árazás és az árazási modellek megértése a felhőben. Otthon az a kérdés, hogy elég-e a gép. A felhőben az, hogy mennyibe kerül, ha így használom. Ez az egyik oka annak, hogy az AI a cloud-ban nem hobbi-megoldásként, hanem üzemszerűen terjedt el.

Az AI hatása a hardverpiacra

Az AI és a cloud együtt nem csak szoftveres változást hozott. A hardverpiacon is érezhető a hatása. Az adatközponti AI igény nem csak GPU-kat szív fel, hanem memóriát is – különösen nagy sávszélességű és szerveroldali megoldásokat.

A piaci elemzések és üzleti hírek egyre gyakrabban kötik össze a memóriaárak alakulását az AI-adatközpontok növekvő igényével. A hangsúly eltolódott: a gyártók és beszállítók számára a hyperscalerek váltak a legfontosabb ügyfelekké.

A változás egyik leglátványosabb következménye az árakon látszik. Egyes GPU- és memóriaszegmensekben 2024–2025 során 1,5–3× közötti áremelkedés volt tapasztalható, különösen ott, ahol az adatközponti AI-igény közvetlenül megjelent. Ez nem egységes a teljes piacon, de jól mutatja az irányt: amikor a hyperscalerek és nagyvállalatok tömegesen vásárolnak, a fogyasztói és kisebb üzleti piac háttérbe szorul.

Ezt a folyamatot jól szemlélteti az NVIDIA bevételeit bemutató ábra. A sávok azt mutatják, hogyan vált a Data Center (DC) üzletág – vagyis a Cloud-os, AI-fókuszú infrastruktúra – a domináns bevételi forrássá, miközben a Gaming és az egyéb szegmensek aránya háttérbe szorult. A grafikon nem csak növekedést, hanem súlypont-eltolódást jelez: az AI ma már elsősorban adatközpontokban él.

Adatbiztonság és a félreértések

Az AI + Cloud kapcsán az egyik legtöbb bizonytalanságot az adatkezelés okozza. Sok félelem nem konkrét tapasztalatból, hanem feltételezésekből fakad. Gyakori gondolat, hogy a Cloud-os AI „biztos betanítja az adatokat”.

A valóság ennél árnyaltabb. A nagy cloud szolgáltatók dokumentációja különbséget tesz az alapértelmezett működés és az explicit engedélyezett tréning között. Enterprise környezetben az ügyféladatok jellemzően elkülönítve maradnak, és nem kerülnek más ügyfelekhez vagy alapmodell-tréningbe engedély nélkül.

Ugyanakkor fontos kimondani: a cloud nem varázslat. Az adatbiztonság nem automatikus. A shared responsibility modell itt is érvényes. A platform adja az alapokat, de a jogosultságkezelés, a hozzáférések és az adathasználat kontrollja továbbra is az ügyfél döntése.

A félelmek egy része abból fakad, hogy sokan a mai napig nem értik pontosan, hogyan működik egy AI. A modell, a tréning, az inference és az adatkezelés gyakran egyetlen „fekete dobozzá” mosódik össze a fejekben. Ha nem világos, mi történik egy kérdés elküldésekor, hol fut a feldolgozás, és mi marad meg belőle, akkor természetes reakció a bizalmatlanság. Ez a bizonytalanság nem rosszindulatból fakad, hanem információhiányból.

Ezért a zavar valószínűleg 2026-ban sem fog teljesen eltűnni. Nem azért, mert a szolgáltatók ne lennének egyre transzparensebbek, hanem mert az AI használata gyorsabban terjed, mint ahogy a szervezetek megtanulják helyesen értelmezni a működését.

Mit várhatunk 2026-ban az AI + Cloud területén?

Az AI és a Cloud együtt nem új trend, hanem új működési környezet. Kevesebb manuális döntés látszik, de több döntés történik a háttérben. Kevesebb technikai akadály, de nagyobb felelősség.

Azok járnak jól ebben a világban, akik nem csodát várnak az AI-tól, hanem értik, mire használják, és hajlandók felelősséget vállalni a döntéseikért.

2026-ban az AI nem egy kísérleti technológia lesz, hanem egy stratégiai alapvetés, amely a cloud működésének mindennapi részévé válik. A nagy technológiai szolgáltatók és elemzők szerint több irányban is érdemes felkészülni:

• Az AI szerepe tovább mélyül: A korábbi „AI mint eszköz” fázist teljesen felváltja az „AI mint partner” logika – az AI nem csak kérdésekre válaszol, hanem támogatja a döntéseket, együttműködik munkafolyamatokban és gyorsítja a kutatást. Ez nem csak technikai előny, hanem szervezeti és működési átalakulás is.

• Agentic AI és intelligens automatizálás erősödik: A vállalati környezetben 2026-ra szélesebb körben terjednek az olyan AI-agentek, amelyek nem csak input-output feladatokat végeznek, hanem autonómabban lépnek kölcsönhatásba rendszerekkel és döntési folyamatokkal.

• Adat és AI governance fókuszba kerül: A fogyasztók és szervezetek egyre nagyobb figyelmet fordítanak arra, hogyan használja az AI az adatokat, hogyan magyarázható és kontrollálható a működése. Ez nem csupán technikai kérdés, hanem a bizalom és jogi megfelelés alapja.

• Biztonság és infrastruktúra kiemelt téma: A növekvő AI-használat új támadási felületeket és identitás-vezérelt kihívásokat hoz, ezért a kiberbiztonság nem csak háttérfeladat, hanem stratégiai prioritás lesz az AI + Cloud környezetben.

Ezek az irányok nem csupán az én gondolataim, hanem a legfrissebb szakmai előrejelzésekkel egybevágó vélemény is.

Az AI nem külön dolog többé, hanem a Cloud működésének szerves, strukturális része lesz.

2026-ban már nem az a kérdés, használod-e az AI-t a Cloudban, hanem az, hogy jól használod-e. Ha ebben szeretnél biztosabb lenni, iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeimet.

cloud-2026-services-ai

Cloud 2026: hol járunk most, és merre tart a felhő

, , , , , , , , ,

| Olvasási idő: 5 perc |

Amikor több mint egy évtizeddel ezelőtt először dolgoztam felhővel, még egészen más kérdések foglalkoztatták a cégeket. Mekkora szervert vegyünk? Elég lesz-e két év múlva is? Mikor kell új vasat rendelni, és mennyi idő alatt ér ide? A döntések hónapokra, vagy évekre előre szóltak, és minden hibának ára volt.

Ma, 2026 elején, egészen másról beszélünk. A kérdés már nem az, hogy „használjunk-e felhőt”, hanem az, hogy hogyan használjuk jól.

Ez a cikk nem arról szól, hogyan kell kattintgatni a konzolon, inkább egy helyzetkép: hol tart most a cloud, mit tanultunk az elmúlt években, és mire érdemes készülni rövid távon.

Mi a cloud computing ma, röviden és érthetően

A cloud computing nem egy konkrét technológia, hanem egy működési modell. A lényege egyszerű: erőforrásokat használsz akkor, amikor kell, és csak addig fizetsz értük, amíg valóban szükséged van rájuk. Nem te vásárolsz szervert, nem te cseréled a meghibásodott alkatrészt, és nem neked kell minden részletet kézben tartani.

Fontos kimondani azt is, ami sokszor kimarad: a cloud nem ingyenes, és nem varázslat. Nem lesz tőle automatikusan gyorsabb vagy jobb egy alkalmazás. Viszont ad egy rugalmasságot, amit korábban csak nagyvállalatok tudtak megfizetni.

Egy egyszerű példa: egy webalkalmazás elindítása saját szerverrel ma is működik. Viszont ha hirtelen tízszer annyi felhasználó kezdi el használni, a cloud adja azt a mozgásteret, amivel ezt különösebb kapkodás és túlterhelés miatti leállás nélkül le lehet kezelni.

Mi változott az elmúlt években, és miért fontos ez 2026-ban

Néhány évvel ezelőtt sok helyen uralkodó gondolat volt, hogy „mindent vigyünk fel a felhőbe”. Ez azonban hibás gondolat, úgy ahogy a Scrum sem való minden projekthez. Emiatt ez a hozzáállás ma már egyértelműen kiforrottabb lett. A cégek megtanulták, hogy a cloud nem automatikusan olcsóbb, és a rosszul megtervezett rendszerek itt is gyorsan drágává és átláthatatlanná válhatnak.

2026-ra a cloud érett technológiává vált. Nem a kísérletezésről szól, hanem a tudatos döntésekről. Egyre több szervezet ismeri fel, hogy kevesebb szolgáltatás, egyszerűbb architektúra és átgondolt működés sokszor többet ér, mint a legújabb megoldások halmozása. Annak ellenére, hogy a felhőszolgáltatók sokszor mást sugallnak.

A cloud nem lett rosszabb. Mi lettünk tapasztaltabbak. És elkezdtük hatékonyabban használni.

Mire használják a cégek a felhőt 2026-ban valójában

A legtöbb vállalat ma nem csupán „innovációs lehetőségként” tekint a felhőre. Sokkal inkább stabil alapként. Tipikus felhasználási területek:

  • üzleti webalkalmazások futtatása
  • belső rendszerek és API-k
  • adatfeldolgozás és jelentéskészítés
  • fejlesztői és tesztkörnyezetek gyors létrehozása

Ezekben a felhasználási esetekben a cloud legnagyobb értéke a gyors indulás és a skálázhatóság. Nem kell mindent előre megtervezni évekre. Lehet kipróbálni, tapasztalni, majd dönteni.

Itt jelenik meg egyre természetesebben az AI is. Nem külön projektként, hanem funkcióként. Keresésben, ügyfélszolgálati automatizmusokban, vagy éppen adatok értelmezésében. A cloud biztosítja azt az alapot, amely nélkül ezek a megoldások nem lennének gazdaságosan működtethetők.

Hogyan indul ma egy kis cég?

Vegyünk egy mai, valós helyzetet. Egy kisebb cég szeretne egy webes alkalmazást indítani, aminek eleinte csak néhány száz felhasználója van, de nem tudják, fél év múlva mi lesz belőle.

2026-ban ilyenkor már ritkán merül fel az, hogy saját szervert vegyenek. Ehelyett:

Ha az alkalmazás sikeres lesz, a rendszer skálázható. Ha nem válik be, egyszerűen leállítható, nagy veszteség nélkül.

Ez a cloud egyik legnagyobb ereje: nem kell előre mindent tudni, mégis van mozgástér. Ez üzleti oldalról legalább akkora előny, mint technikai szempontból.

Hol találkozol a felhővel a gyakorlatban?

Sokan úgy gondolnak a felhőre, mint valami elvont, „nagyvállalati” dologra, pedig a legtöbben már most is naponta használják – csak nem így hívják. Ha azt mondom: Instagram, TikTok, Gmail, OneDrive és Netflix, akkor azoknak a szolgáltatásoknak a nevét sorolom, ahol naponta találkozol Te is a felhővel.

Amikor egy webalkalmazás gyorsan betölt, amikor egy online rendszer gond nélkül kiszolgál sok felhasználót egyszerre, vagy amikor egy szolgáltatás mögött nincs látható leállás, ott nagyon gyakran „cloud fut a háttérben”.

A felhő a nagy szolgáltatóknál nagyon hasonló alapokra épül.


Például:

  • Microsoft Azure esetén tipikusan virtuális gépek, menedzselt adatbázisok és tárolószolgáltatások adják az alapot.
  • Amazon Web Services ugyanezt az elvet követi, csak más elnevezésekkel, megközelítéssel és hangsúlyokkal.
  • Google Cloud Platform pedig különösen erős adatfeldolgozási és analitikai irányban.

A lényeg nem az, hogy melyik platformon vagy, hanem az, hogy nem nulláról építkezel, hanem kész, kipróbált építőelemekből dolgozol.

Mit jelent a cloud a felhasználók számára

A legtöbb végfelhasználó nem gondolkodik cloudban. Nem is kell. Ők gyors, megbízható szolgáltatásokat várnak el, lehetőség szerint zéró leállással és elfogadható válaszidőkkel. Ha egy alkalmazás lassú vagy elérhetetlen, nem az érdekli őket, hogy hol fut, hanem az, hogy miért nem működik.

2026-ra a cloud ebből a szempontból láthatatlanná vált. Ott van minden mögött, de csak akkor kerül szóba, ha valami nem úgy működik, ahogy kellene. Ez önmagában jelzi az érettségét. Pontosan olyan alapszolgáltatásként tekintünk rá, mint a vezetékes vízre vagy az áramra.

Mit jelent a cloud a karrierváltóknak és pályakezdőknek

Sokan kérdezik tőlem, hogy érdemes-e ma még cloud irányba indulni. A válaszom röviden: igen, de másképp, mint pár éve. Nem az számít, hogy hány szolgáltatás nevét ismered, hanem az, hogy érted-e az alapokat.

2026-ban a cloud jó belépési pont az IT világába azoknak is, akik nem szeretnének mélyen programozni. A rendszerszemlélet, az alap biztonsági gondolkodás és az üzleti igények megértése sokkal fontosabb lett, mint a konkrét implementációs részletek.

Az AI ebben a tanulási folyamatban segíthet, magyarázhat és irányt mutathat, de nem veszi le a döntés terhét a válladról.

A cloud szakember nem attól lesz jó, hogy mindent automatizál vagy mindent tud, hanem attól, hogy felelősséget vállal a döntéseiért és tanul a hibáiból.

Az AI szerepe röviden

Talán észrevetted az AI itt nem főszereplő még, de nem lehet megkerülni. 2026-ban egyértelműen látszik, hogy az AI felerősíti a cloud jelentőségét. Skálázás, költségoptimalizálás, automatizált elemzés mind olyan területek, ahol a kettő együtt ad valódi értéket.

Ugyanakkor fontos határt húzni. A cloud itt még az alap, az infrastruktúra és a platform. Az igazi változás ott kezdődik, amikor az AI már nem csak használja a felhőt, hanem formálja is. Erről szól majd a következő cikkem.

Korlátok, amik 2026-ban is megmaradnak

A cloud nem old meg rossz döntéseket. Nem helyettesíti a gondolkodást, és nem javítja ki a szervezeti problémákat. Rosszul használva továbbra is drága, és könnyen átláthatatlanná válik.

Ez AI-val együtt sincs másképp. Ha nincs világos cél, nincs felelősség és nincs kontroll, akkor a legmodernebb technológia is csak gyorsabban visz rossz irányba.

Útravaló

2026-ban a cloud nem trend, hanem alap. Nem cél, hanem eszköz. Azok a csapatok és szakemberek járnak jól, akik nem csodát várnak tőle, hanem tudatosan használják. A következő lépés viszont már nem csak erről szól. Az AI és a cloud együtt új kérdéseket vet fel, és új válaszokat kényszerít ki.

Erről fog szólni a folytatás…

Ha érdekel, merre halad ez az irány, és hogyan érdemes rá felkészülni, akkor iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeim.

vm-monitoring-log-analytics-dcr

VM naplózás lelke: Log Analytics és Data Collection Rules

, , , , ,

| Olvasási idő: 10 perc |

A felhős monitoring az egyik legösszetettebb terület az Azure-ben. Rengeteg szolgáltatás, beállítás, rövidítés és „best practice” kering körülötte, miközben a legtöbb ember csak azt szeretné tudni: látom-e, mi történik a virtuális gépemen; és ha több virtuális gépem van, tudom-e azok naplóbejegyzéseit egy helyen kezelni.

Nemrég az egyik mentoráltammal belekóstoltunk ebbe a világba. Ő kifejezetten rákapott a monitoring ízére, ami jó jel, viszont közben számomra is világossá vált, hogy nem a tankönyv szerinti megoldás a legjobb megközelítés ahhoz, hogy valóban megértsük ennek a világnak a működését.

Miért mondom ezt? Mert sokan úgy gondolják – és én is így mutattam be korábban –, hogy akkor kell beállítani a naplófájlok gyűjtését, amikor a virtuális gépet létrehozzuk. Hiszen amikor összetett rendszerekkel dolgozunk, általában egy előre beállított, finomhangolt monitoring rendszerbe illesztjük be az új gépeket.

Ezzel azonban pont azt a logikus, jól követhető utat kerülöm el, amelyen keresztül az érdeklődők a legkönnyebben elérik a céljukat: hogy gyorsan átlássák ezt a komplex világot.

Mit javaslok tehát? Kövessük a józan észt, és gondoljuk végig, mi egy alkalmazás vagy rendszer természetes evolúciója. Hogyan történik ez a valóságban, amikor kicsiben kezdünk?

Először létrehozok egy vagy több virtuális gépet, alapbeállításokkal, majd telepítem rájuk az alkalmazásaimat. Jön még egy gép, aztán még egy. Egy idő után azt veszem észre, hogy egy nagy, összetett rendszerem van, viszont vak vagyok: nem látom, mi történik a virtuális gépeimen, és nem látom a gépek által létrehozott naplóbejegyzéseket sem.

Ekkor jön a következő lépés: beállítom az Azure Monitor megoldását, hogy legyen szemem és fülem. És innentől már értelmezhető adatokat kapok arról, mi történik a rendszeremben.

Ugye milyen egyszerű így?

Ebben a cikkben erről – pontosabban ennek egy pici, de nagyon fontos szeletéről – fogok egy alap konfigurációt bemutatni. A fókusz a naplóbejegyzések központi kezelése lesz az Azure Monitoron belül.

Ennek két legfontosabb komponense:

  • a Log Analytics Workspace
  • és a Data Collection Rules (DCR)

Ezek adják az egész VM-alapú naplózás és megfigyelés gerincét.

Később górcső alá vesszük az Azure Monitor további elemeit is, hogy jobban belelássatok ebbe a nagyon komplex, mégis rendkívül izgalmas világba.

Nem elméleti áttekintést szeretnék adni, és nem is egy „mindent bele” vállalati monitoring architektúrát bemutatni. A célom sokkal egyszerűbb és gyakorlatiasabb:

  • megérteni, mi a szerepe a Log Analytics Workspace-nek,
  • tisztázni, mire valók a Data Collection Rules,
  • és végigmenni egy egyszerű beállításon Linux és Windows Server virtuális gépek esetén is.

Alapfogalmak és szerepek

Log Analytics Workspace (LAW) a központi adattároló, ahová minden log és metrika beérkezik. Gyakorlatilag egy speciális adatbázis, amely KQL (Kusto Query Language) lekérdezéseket támogat. Egy workspace több száz VM-et is kiszolgálhat, de szervezeti vagy biztonsági okokból létrehozhatsz többet is.

Data Collection Rule (DCR) határozza meg, hogy mit gyűjtsünk, honnan és hová küldjük. Ez a „szabálykönyv”, ami összeköti a forrásokat (VM-ek) a célponttal (LAW). A DCR-ek rugalmasak: különböző szabályokat alkalmazhatsz különböző VM-csoportokra.

Azure Monitor Agent (AMA) a VM-eken futó agent, ami a DCR alapján gyűjti és továbbítja az adatokat. Ez váltotta le a régi Log Analytics Agent-et (MMA) és a Diagnostics Extension-t.

mermaid diagram

A terv

Az alábbi lépéseket fogjuk követni tehát:

  1. Virtuális gépek (Linux, Windows) létrehozása (nagyon felületesen, mert tényleg alapbeállításokkal hozzuk létre)
  2. Log Analytics Workspace létrehozás
  3. Data Collection Rule létrehozás és beállítás
  4. Azure Monitor Agent ellenőrzése a Virtuális gépeken
  5. Naplóbejegyzések lekérdezése központilag

Öt egyszerű lépés, ami segít megérteni hogyan működik ez a szörnyeteg.

1. lépés: Virtuális gépek létrehozása

Amikor elindul a vállalkozásunk, először egy vagy tövv gépet hozunk létre. Tegyük ezt most is.

Minden lépést a Portálon fogunk elvégezni, az egyszerűség kedvéért.

Linux vm

  1. Hozzunk létre egy erőforráscsoportot, ebbe fogunk most dolgozni
  2. A Marketplace-n keresd meg: „Ubuntu 24.04 LTS – all plans including Ubuntu Pro”
  3. Ebből hozz létre egy „Ubuntu Server 24.04 LTS”
  4. Gép neve legyen „linux-monitor”
  5. Méret legyen egy kicsi, pl.: Standard_B1s
  6. Hitelesítés típusa legyen Nyilvános SSH-kulcs
  7. Lemez esetén elegendő egy Standard SSD
  8. Hálózatnál létrehozhatunk egy monitor-vnet nevű hálózatot
  9. A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
  10. És hozzuk létre az első virtuális gépünket

Windows vm

  1. A Marketplace-n keresd meg: „Windows Server”
  2. Ebből hozz létre egy „Windows Server 2022 Datacenter”
  3. Gép neve legyen „windows-monitor”
  4. Méret legyen egy kicsi, pl.: Standard_B2s
  5. Rendszergazdai fióknál állítsunk be egy felhasználónevet és a hozzátartozó jelszót
  6. Lemez esetén elegendő egy Standard SSD
  7. Hálózatnál válasszuk a linux-nál létrehozott monitor-vnet nevű hálózatot
  8. A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
  9. És hozzuk létre a második virtuális gépünket

2. lépés: Log Analytics Workspace létrehozása

Eljutottunk tehát oda, hogy megvannak a gépeink, de nem tudjuk mi is van velük, vagy mi történik az alkalmazásokkal. Kell nekünk egy központi tároló, ahová a gépeken keletkező naplóbejegyzések és/vagy metrikák beérkeznek. Most ezt hozzuk létre.

  1. Felül a keresőben keresd meg: „Log Analytics-munkaterületek„, majd kattintsunk rá.
  2. Kattints: „+ Létrehozás” gombra
  3. Töltsd ki:
    • Előfizetés: válaszd ki
    • Erőforráscsoport: válaszd a korábban létrehozttat
    • Név: egyedi név (pl.: law-mentor)
    • Régió: válaszd azt amit az erőforráscsoportnál és a VM-eknél is használtál
    • Kattints: „Áttekintés és létrehozás”, majd hozd létre. 1-2 perc és létrejön.

Most már van egy adatbázisunk, ahová gyűjthetjük az adatokat.

3. lépés: Data Collection Rule létrehozás és beállítás

Egyre közelebb vagyunk a célunkhoz. Most hozzuk létre azt a szabályt, hogy a létező VM-ekről milyen adatokat szeretnénk látni a központi adatbázisban (Log Analytics Workspace)

Alap adatok

  1. Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
  2. A bal oldali panelon keressük meg a Beállítások > Adatgyűjtési szabályok elemet és kattintsunk rá
  3. Kattints: „+ Létrehozás” gombra
  4. Add meg a szabály alap adatait:
    • Szabály neve: pl: dcr-vm-logs-all
    • Előfizetés és erőforráscsoport: ugyanaz, mint a LAW
    • Platform típusa: válaszd „All” (Ha Windows és Linux is kell. Mi most ezt szeretnénk)
    • Adatgyűjtési végpont: Nekünk ez most nem szükséges, mert Azure-on belüli gépekhez hozzuk létre
  5. Kattints: „Következő: Erőforrások >” gombra
  6. Erőforrások fül: Itt adod hozzá a VM-eket, amikről gyűjteni szeretnél. Kattints „+ Erőforrások hozzáadása” gombra és válaszd ki a VM-eket amelyeket korábban létrehoztál. (Az AMA agent automatikusan települ, ha még nincs fent.)
  7. Kattints: „Következő: Gyűjtés és küldés >” gombra
  8. Gyűjtés és küldés fül: Itt definiálod az adatforrásokat (mit olvasson be a VM-ekről)

Windows adatforrás

  1. Kattints „+ Adatforrás felvétele”
  2. Adatforrás típusánál válaszd a „Windowsos eseménynaplók” elemet. Ezzel lehetőséged van beolvasni azokat az eseménynapló-bejegyzéseket, amelyekre szükséged van. Ezeket nagyon részletesen testre lehet szabni.
  3. Mi most itt csak az Alapszintű elemeket fogjuk gyűjteni. Jelöld ki mindet.
  4. Ebben az ablakban kattints „Következő: Cél >” gombra.
  5. Ellenőrizd, hogy a megfelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
  6. Ezzel a Windows naplóbejegyzések betöltése készen áll

Linux adatforrás

  1. Kattints „+ Adatforrás felvétele”
  2. Adatforrás típusánál válaszd a „Linux Syslog” elemet. Ezzel lehetőséged van beolvasni azokat az eseménynapló-bejegyzéseket, amelyekre szükséged van. Ezeket nagyon részletesen testre lehet szabni.
  3. Ezután be kel állítanunk, hogy mi a minimális naplózási szint, amit szeretnénk beállítani. Alapvetően senkinek nem javaslom, hogy beállítsa az LOG_INFO szintet, de a példánk miatt, most ezt tesszük.
  4. Majd, szintén a példa kedvéért, kiválasztjuk az összes szolgáltatást.
  5. Ebben az ablakban kattints „Következő: Cél >” gombra.
  6. Ellenőrizd, hogy a megelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
  7. Ezzel a Linux naplóbejegyzések betöltése is készen áll.

Szabály véglegesítése

  1. Megvan a két adatforrásunk. A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
  2. És hozzuk létre a szabályt.

Most várnunk kell 5-10 percet, amíg elindul az adatok betöltése. Amíg ez megtörténik, ellenőrizzük le mindegyik VM-ünk esetén, hogy a monitor ügynők települt-e.

Megjegyzés: A teljesítmény metrikák beállítása is hasonlóan történik, ott az adatforrás típusa lesz más.

4. lépés: Azure Monitor Agent ellenőrzése a Virtuális gépeken

Ezt mindkét típusú (Linux, Windows) virtuális gépnél ugyanott tudjuk megtenni.

  1. Keressük meg az erőforráscsoportban a virtuális gép erőforrást (linux-monitor vagy windows-monitor) és kattintsunk rá
  2. A bal oldali panelon keressük meg a Beállítások > Alkalmazások és bővítmények elemet és kattintsunk rá
  3. Itt kell látnunk az AMA elemet
    • Windows esetén: AzureMonitorWindowsAgent
    • Linux esetén: AzureMonitorLinuxAgent

Ha ez hiányzik, akkor nem fogjuk tudni gyűjteni a naplóbejegyzéseket és metrikákat.

5. lépés: Naplóbejegyzések lekérdezése központilag

Most pedig elérkezett a pillanat amire vártunk: központilag le tudjuk kérdezni a begyűjtött adatokat. Azokat tudjuk elemezni, vagy további feldolgozást végezhetünk rajuk. Nincs határ.

Elemzések áttekintése

Amint az adatok begyűjtése elindul, a LAW munkába lendül és rengeteg hasznos információt biztosít számunkra. Ebből jelenleg csak az alap elemzési diagrammot szeretném megmutatni.

  1. Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
  2. A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
  3. Felül válaszd ki a megfelelő Workspace-t
  4. Majd kattints a nevére
  5. Megnyílik az elemzési áttekintő ablak

Naplóbejegyzése a portálon

Most pedig megmutatom az ajtót a naplóbejegyzések keresésének végtelen univerzumába.

  1. Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
  2. A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
  3. Felül válaszd ki a megfelelő Workspace-t
  4. Majd kattints a nevére
  5. Megnyílik az elemzési áttekintő ablak
  6. A bal oldali panelon keressük meg a Figyelés > Munküzetek elemet és kattintsunk rá.
  7. Itt találsz előre elkészített elemet.
  8. Mi most újat hozunk létre, mert az a legegyszerűbb. Kattints: „+ Új”
  9. A megjelenő lapon a Log Analytics-munkaterület Naplók (Analytics) Lekérdezés rész a KQL query editor. Ide írhatod meg az egyedi lekérdezésedet, amit utána el is menthetsz.
  10. Illeszd me az alábbit, majd kattints a Lekérdezés futtatása gombra
// Windows Információs bejegyzések az elmúlt 1 órából
Event
| where TimeGenerated > ago(1h)
| where EventLevelName in ("Information")
| project TimeGenerated, Computer, EventLog, EventLevelName, RenderedDescription
| order by TimeGenerated desc

Ezt is próbáld ki:

// Linux auth események (bejelentkezések)
Syslog
| where TimeGenerated > ago(3h)
| where Facility == "auth" or Facility == "authpriv"
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc

És egyéb példák:

// Összes Windows Event az elmúlt 24 órából
Event
| where TimeGenerated > ago(24h)
| summarize count() by EventLog, EventLevelName
| order by count_ desc

// Windows hibák és figyelmeztetések
Event
| where TimeGenerated > ago(1h)
| where EventLevelName in ("Error", "Warning")
| project TimeGenerated, Computer, EventLog, EventLevelName, RenderedDescription
| order by TimeGenerated desc

// Linux syslog események
Syslog
| where TimeGenerated > ago(24h)
| summarize count() by Facility, SeverityLevel
| order by count_ desc

// Linux auth események (bejelentkezések)
Syslog
| where TimeGenerated > ago(24h)
| where Facility == "auth" or Facility == "authpriv"
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc


// Adott VM összes logja
Event
| where Computer == "linux-monitor"
| where TimeGenerated > ago(1h)
| order by TimeGenerated desc

Tippek

Ezzel végeztünk is. Ugye, hogy milyen sima volt?

Fontos: A KQL lekérdezéseket érdemes tanulmányozni, hogy elérd a kívánt eredményt.

Problémák elkerülése:

Amikor eldöntjük, mit gyűjtünk, rengeteg lehetőség van. Én azt javaslom, hogy tudatosan tervezzük meg mire is van igazán szükségünk, mert könnyű elkövetni az alábbi hibákat:

  • túl sok adat gyűjtése feleslegesen,
  • nem egyértelmű, hogy egy VM miért nem küld naplót,
  • Linux és Windows eltérő logikájának keverése (ezért sem optimális a jelenlegi beállításunk),
  • vagy egyszerűen az, hogy nem világos, mi történik a háttérben.

Költségoptimalizálás tippek:

  • Ne gyűjts mindent „Information” szinten, csak Warning és felette
  • Állíts be data retention limitet (30 nap alap, növelhető)
  • Használj data collection rule transformations-t a felesleges adatok szűrésére

Összefoglalás

Együtt beállítottunk egy teljes körű log gyűjtési megoldást Azure Monitor segítségével. Létrehoztunk egy Log Analytics Workspace-t, ami központi tárolóként szolgál minden begyűjtött adatnak.

Konfiguráltunk egy Data Collection Rule-t, amely Windows Event Logs és Linux Syslog forrásokból gyűjti az eseményeket, és hozzárendeltük a monitorozni kívánt VM-ekhez.

Az Azure Monitor Agent automatikusan települt a gépekre, így azok azonnal elkezdték küldeni az adatokat. A begyűjtött logokat a Log Analytics Workspace Naplók menüpontjában KQL lekérdezésekkel tudjuk elemezni és keresni.

Ha most ismerkedsz az Azure Monitoring-al, vagy eddig csak „kattontgattad”, mert muszáj volt, akkor ez a cikk neked szólt.

Rövid gyakorlás után biztos vagyok benne, hogy hamar összeáll a kép.

featured_image

A Microsoft AI platform evolúciója: OpenAI és Foundry

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |

Nem rég fejeztem be egy videós képzési anyagot a Mentor Klub részére, ahol a résztvevők megismerhették az Azure-on belül elérhető OpenAI megoldásokat. Ennek részeként bemutattam az Azure OpenAI Studio felületét is, ami valójában az Azure AI Foundry egyik funkcionális eleme. Mindkettőt elég gyakran használom, különböző projektekben és különböző célokra. Hogy éppen melyik a jobb egy adott feladathoz, azt többnyire az aktuális projekt igényei döntik el.

A Microsoft azonban az elmúlt hónapokban egy olyan változtatást indított el, amely alapjaiban alakítja át azt, ahogyan eddig AI-megoldásokat építettünk Azure-ban. A Foundry platform fokozatosan átveszi az Azure OpenAI Studio szerepét, kiszélesítve annak lehetőségeit és egységesítve az AI-fejlesztés teljes ökoszisztémáját.

Mi volt az Azure OpenAI Studio szerepe

A Microsoft az Azure OpenAI Studio felületet arra hozta létre, hogy egyszerű legyen kipróbálni és tesztelni az Azure által kínált OpenAI modelleket. A felület segítségével lehetett:

  • modelleket kipróbálni egy játszótérben
  • finomhangolt modelleket kezelni
  • API-végpontokat és kulcsokat elérni
  • kötegelt feldolgozást és tárolt befejezéseket használni
  • értékeléseket futtatni
  • és még sok hasznos AI programozást segítő funkciót.

Az Azure OpenAI Studio azonban alapvetően egy modelltípusra, az Azure által értékesített OpenAI modellekre épült. Ez a projektjeim során is érezhető volt: ha más modellgyártó megoldását szerettem volna használni, akkor azt külön kellett integrálni vagy külső szolgáltatásból kellett elérni.

Ez az a pont, ahol a Foundry teljesen más szemléletet hoz.

Mit kínál a Microsoft Foundry?

A Microsoft Foundry egy egységes AI-platform, amely több modellszolgáltatót, több szolgáltatást és teljes életciklus-kezelést egy felületre hoz. A Microsoft Learn dokumentum így fogalmaz: a Foundry egy nagyvállalati szintű platform, amely ügynököket, modelleket és fejlesztői eszközöket egy helyen kezel, kiegészítve beépített felügyeleti, monitorozási és értékelési képességekkel .

A legfontosabb különbségek a következők.

Széles modellkínálat

Az Azure OpenAI-val szemben a Foundry nem korlátozódik egyetlen gyártóra. Elérhetők többek között:

  • Azure OpenAI modellek
  • DeepSeek
  • Meta
  • Mistral
  • xAI
  • Black Forest Labs
  • Stability, Cohere és más közösségi modellek

És ez még csak a jéghegy csúcsa.

Ügynökszolgáltatás és többügynökös alkalmazások (AgenticAI)

A Foundry API kifejezetten ügynökalapú fejlesztéshez készült, ahol több modell és komponens együttműködésére van szükség.

Egységes API különböző modellekhez

A Foundry egységes API-t biztosít, így a fejlesztőnek nem kell minden gyártó logikáját külön megtanulnia.

Vállalati funkciók beépítve

A Foundry felületén eleve jelen vannak:

  • nyomkövetés
  • monitorozás
  • értékelések
  • integrált RBAC és szabályzatok
  • hálózati és biztonsági beállítások

Gyakorlatilag, minden ami a nagyvállalati és biztonságos működéshez elengedhetetlen.

Projektalapú működés

A Foundry projektek olyan elkülönített munkaterületek, amelyekhez külön hozzáférés, külön adatkészletek és külön tároló tartozik. Így egy projektben lehet modelleket, ügynököket, fájlokat és indexeket is kezelni anélkül, hogy más projektekhez keverednének.

Hogyan kapcsolódik össze a két világ

A Microsoft nem megszünteti az Azure OpenAI-t, hanem lehetővé teszi, hogy az adott erőforrás Foundry-erőforrássá alakuljon. A frissítési folyamat lényege:

  • a meglévő végpontok és kulcsok megmaradnak
  • a finomhangolt modellek és állapotok megmaradnak
  • a Foundry funkciói azonnal elérhetővé válnak
  • a fejlesztő továbbra is használhatja az Azure OpenAI API-t

Mindezt lépésről lépésre írja le a frissítési útmutató.

Egy példán keresztül…

Amikor még csak Azure OpenAI-val dolgoztam, előfordult, hogy egy ügyfél Meta vagy Mistral modellt szeretett volna kipróbálni összehasonlításként. Ezt külön rendszerben kellett megoldani.
A Foundry megjelenésével ugyanabban a projektben elérhetővé vált:

  • GPT-típusú modell
  • Mistral
  • Meta
  • DeepSeek
  • és még sok más

Egy projekten belül egyszerre lehet kísérletezni, mérni és értékelni különböző modellek viselkedését.

Mit jelent ez a felhőben dolgozó szakembereknek

A Foundry nem egyszerűen egy új kezelőfelület. A gyakorlati előnyei:

  • Egységes platform, kevesebb különálló eszköz
  • Könnyebb modellválasztás és modellváltás
  • Átláthatóbb üzemeltetés, biztonság és hálózatkezelés
  • Bővíthető modellkínálat
  • Konszolidált fejlesztői élmény és API

A dokumentáció többször hangsúlyozza, hogy a Foundry nemcsak kísérletezésre, hanem üzleti szintű, gyártásra kész alkalmazásokra is alkalmas. Ez a mindennapi munkában is érezhető.

Miért előnyös ez a vállalatoknak

A vállalatok számára a Foundry több szempontból stratégiai előrelépés:

  • Egységes biztonsági és megfelelőségi keretrendszer
  • Több modellgyártó támogatása egy platformon
  • Könnyebb üzemeltetési kontroll
  • Gyorsabb AI-bevezetési ciklus
  • Rugalmasabb fejlesztési irányok

A Foundry megjelenésével a cégek már nem csak egyetlen modellre vagy ökoszisztémára építenek, hanem több szolgáltató képességét is bevonhatják anélkül, hogy töredezett lenne a rendszer.

TulajdonságAzure OpenAIFoundry
Közvetlenül az Azure által értékesített modellekCsak Azure OpenAIAzure OpenAI, Black Forest Labs, DeepSeek, Meta, xAI, Mistral, Microsoft
Partner és Közösség modellek a Marketplace-en keresztül – Stability, Cohere stb.✅
Azure OpenAI API (köteg, tárolt befejezések, finomhangolás, értékelés stb.)✅✅
Ügynökszolgáltatás✅
Azure Foundry API✅
AI-szolgáltatások (beszéd, látás, nyelv, tartalomértés)✅

Összegzés

Az Azure OpenAI Studio jó kiindulási pont volt az Azure AI-képességeinek megismerésére és modellek kipróbálására.

A Microsoft Foundry azonban túlnő ezen a szerepen:
egységes platformot biztosít a teljes AI-fejlesztési életciklushoz, több modellgyártóval és kiterjesztett vállalati funkciókkal.

A Microsoft nem leváltja az Azure OpenAI-t, hanem beépíti egy nagyobb, átfogóbb rendszerbe. Ez a lépés hosszú távon kiszámíthatóbb, hatékonyabb és sokkal rugalmasabb AI-fejlesztést tesz lehetővé.

Load More

Verified by MonsterInsights