Jak jsou Azure Functions organizovány uvnitř projektu

Co jsou Azure Functions a jejich účel

Azure Functions představují jednu z nejzajímavějších součástí cloudové platformy Microsoft Azure. Jedná se o bezserverovou výpočetní službu, která vývojářům umožňuje spouštět malé kusy kódu, takzvané funkce, aniž by se museli starat o infrastrukturu, na které tento kód běží. Celý koncept vychází z myšlenky, že v moderním světě vývoje aplikací není vždy nutné mít k dispozici celý server nebo virtuální stroj jen proto, aby bylo možné provést jednoduchou operaci. Stačí napsat kód, definovat spouštěč a Azure se postará o vše ostatní.

Základní myšlenka za Azure Functions je jednoduchá, ale v praxi přináší obrovské možnosti. Vývojáři mohou psát funkce v celé řadě programovacích jazyků, včetně C#, JavaScriptu, TypeScriptu, Pythonu, Javy nebo PowerShellu. Každá funkce reaguje na určitý spouštěč, například na příchozí HTTP požadavek, na zprávu ve frontě, na změnu v databázi nebo na časový plán. Tímto způsobem lze velmi elegantně řešit celou řadu scénářů, od zpracování dat přes automatizaci procesů až po budování API rozhraní.

Pokud jde o adresářovou strukturu projektu Azure Functions, ta hraje klíčovou roli při organizaci kódu a správném fungování celé aplikace. Každý projekt Azure Functions má svou specifickou strukturu složek a souborů, která musí být dodržena, aby platforma správně rozpoznala a spustila jednotlivé funkce. V kořenovém adresáři projektu se nachází soubor host.json, který obsahuje globální konfiguraci pro celý projekt. Vedle něj stojí soubor local.settings.json, jenž slouží pro lokální vývoj a uchovává nastavení připojovacích řetězců a dalších proměnných prostředí.

Každá jednotlivá funkce pak má svůj vlastní podadresář, pojmenovaný zpravidla podle názvu dané funkce. V tomto podadresáři se nachází soubor function.json, který definuje vazby a spouštěče pro konkrétní funkci, a samotný soubor s kódem funkce. Tato struktura platí zejména pro starší model vývoje, zatímco novější izolovaný model pracovního procesu přináší mírně odlišný přístup, kde jsou vazby definovány přímo v kódu pomocí atributů nebo dekorátorů.

Účel Azure Functions je tedy velmi různorodý. Mohou sloužit jako backend pro mobilní a webové aplikace, jako zpracovatelé událostí v rámci architektury řízené událostmi, nebo jako integrační vrstva mezi různými systémy. Díky modelu platby za skutečné využití, kdy se platí pouze za dobu, po kterou funkce skutečně běží, jsou Azure Functions ekonomicky výhodnou volbou pro aplikace s proměnlivou nebo nepředvídatelnou zátěží. Celý ekosystém Azure Functions je navíc úzce propojen s dalšími službami Azure, což z nich dělá přirozené stavební kameny moderních cloudových architektur.

Serverless architektura a její hlavní výhody

Serverless architektura představuje jeden z nejvýznamnějších posunů v moderním vývoji aplikací za poslední dekádu. Základní myšlenka spočívá v tom, že vývojář se přestává starat o správu serverů, jejich konfiguraci, škálování nebo dostupnost infrastruktury a místo toho se plně soustředí na samotný kód a logiku aplikace. Azure Functions jsou přímým ztělesněním tohoto přístupu a Microsoft je v posledních letech neustále rozvíjí jako klíčový prvek svého cloudového ekosystému.

Když se podíváme na to, jak serverless architektura funguje v praxi, je důležité pochopit, že slovo „serverless neznamená, že servery fyzicky neexistují. Servery samozřejmě existují, ale jejich správa je plně v rukou poskytovatele cloudové platformy. V případě Azure Functions se tedy Microsoft stará o veškerou infrastrukturu, zatímco vývojář definuje pouze funkce, které se mají spouštět v reakci na určité události. Tento model se nazývá event-driven computing a je základem celé serverless filozofie.

Jednou z největších výhod tohoto přístupu je ekonomická efektivita. Tradiční modely hostování aplikací vyžadují platbu za nepřetržitě běžící servery, i když jsou nečinné. U serverless architektury, konkrétně u Azure Functions, platíte pouze za skutečně spotřebované výpočetní prostředky. Fakturace probíhá na základě počtu spuštění a doby běhu funkce, což může v praxi znamenat dramatické snížení provozních nákladů, zejména pro aplikace s nepravidelným nebo těžko předvídatelným provozem.

Adresářová struktura projektu Azure Functions hraje klíčovou roli v organizaci a přehlednosti celého řešení. Každá funkce má svůj vlastní adresář, ve kterém se nachází soubor s definicí triggeru a bindings, tedy soubor `function.json`, a samotný kód funkce. Na kořenové úrovni projektu se pak nachází soubor `host.json`, který obsahuje globální konfiguraci pro celý Function App, a soubor `local.settings.json`, jenž slouží pro lokální vývoj a uchovává citlivé konfigurační hodnoty jako connection stringy nebo API klíče. Tato jasně definovaná struktura usnadňuje orientaci v projektu a zároveň podporuje dobré vývojářské praktiky.

Škálovatelnost je další oblastí, kde serverless architektura a Azure Functions excelují. Platforma dokáže automaticky škálovat počet instancí funkce v závislosti na aktuální zátěži, a to bez jakéhokoliv zásahu vývojáře. Pokud přijde náhlý nárůst požadavků, Azure automaticky spustí nové instance a po odeznění špičky je opět ukončí. Tento mechanismus je zvláště cenný pro aplikace, které zažívají výrazné výkyvy v provozu, například e-shopy během sezónních výprodejů nebo systémy zpracovávající dávkové úlohy.

Z pohledu vývojového procesu přináší serverless architektura také výhodu v podobě rychlejšího uvedení produktu na trh. Protože se vývojáři nemusí zabývat infrastrukturou, mohou se plně věnovat implementaci business logiky. Azure Functions podporují celou řadu programovacích jazyků, včetně C#, JavaScriptu, TypeScriptu, Pythonu, Javy nebo PowerShellu, což umožňuje týmům pracovat v technologiích, které jim jsou nejbližší.

Důležitou součástí ekosystému Azure Functions jsou také tzv. triggery a bindings. Triggery definují, co spuštění funkce vyvolá, ať už jde o HTTP požadavek, zprávu ve frontě, časovač nebo událost z Event Hubu. Bindings pak umožňují deklarativně propojit funkci s dalšími službami bez nutnosti psát boilerplate kód pro připojení k databázím nebo jiným zdrojům dat. Tato abstrakce výrazně zjednodušuje vývoj a snižuje množství kódu, který je potřeba napsat a udržovat.

Nelze opomenout ani aspekt spolehlivosti a dostupnosti. Microsoft garantuje vysokou dostupnost platformy Azure Functions a v rámci různých plánů hostování nabízí různé úrovně SLA. Consumption plan, Dedicated plan a Premium plan se liší nejen cenou, ale také možnostmi konfigurace, výkonem a zárukami dostupnosti. Pro produkční aplikace s kritickými požadavky na dostupnost je vhodné zvážit Premium plan, který eliminuje tzv. cold start problém a nabízí předem zahřáté instance připravené okamžitě reagovat na příchozí požadavky.

Podporované programovací jazyky a prostředí

Azure Functions podporuje celou řadu programovacích jazyků, což z této platformy dělá velmi flexibilní nástroj pro vývojáře s různým zázemím a preferencemi. Mezi nejrozšířenější a nejlépe podporované jazyky patří C#, JavaScript, TypeScript, Python, Java, PowerShell a F#. Každý z těchto jazyků má svá specifika, pokud jde o způsob, jakým jsou funkce definovány, jak probíhá jejich spouštění a jak vypadá adresářová struktura projektu.

Pokud jde o jazyk C#, vývojáři mají k dispozici dva hlavní modely. Prvním je takzvaný in-process model, kde funkce běží ve stejném procesu jako hostitel Functions runtime. Druhým je isolated worker model, který spouští kód funkce v samostatném procesu. Tento druhý přístup přináší větší flexibilitu při výběru verze .NET a lepší izolaci závislostí. V adresářové struktuře projektu napsaného v C# najdeme typicky soubor s příponou .csproj, který obsahuje definici projektu a jeho závislosti, dále pak složky s jednotlivými funkcemi, přičemž každá funkce je reprezentována třídou s příslušnými atributy.

JavaScript a TypeScript jsou velmi oblíbené volby zejména mezi vývojáři, kteří pracují s Node.js ekosystémem. V případě těchto jazyků je adresářová struktura poněkud odlišná. Každá funkce má svůj vlastní adresář, ve kterém se nachází soubor function.json definující triggery, vstupy a výstupy dané funkce, a dále samotný kód funkce v souboru index.js nebo index.ts. Na kořenové úrovni projektu pak nalezneme soubor package.json se závislostmi a soubor host.json, který konfiguruje globální nastavení celé aplikace. TypeScript projekty navíc obsahují soubor tsconfig.json pro konfiguraci kompilátoru.

Python je dalším hojně využívaným jazykem, a to zejména v oblasti datové vědy a strojového učení, kde Azure Functions slouží jako skvělý způsob, jak nasadit modely nebo zpracovávat data v reakci na různé události. Pythonové projekty mají svou vlastní charakteristickou strukturu. Kořenový adresář obsahuje soubory host.json a requirements.txt, přičemž každá funkce je umístěna ve vlastním podadresáři s soubory function.json a __init__.py. Novější verze Azure Functions pro Python přináší takzvaný v2 programovací model, který umožňuje definovat všechny funkce přímo v jednom souboru pomocí dekorátorů, což výrazně zjednodušuje strukturu projektu a přibližuje ji konvencím, které Python vývojáři dobře znají z jiných frameworků.

Java využívá Maven nebo Gradle jako nástroje pro správu projektu a sestavení. Struktura projektu odpovídá standardním konvencím těchto nástrojů, takže vývojáři se zkušenostmi z enterprise Java vývoje se v ní rychle zorientují. Funkce jsou definovány jako metody třídy s anotacemi, které určují typ triggeru a případné vazby na další služby.

PowerShell nachází uplatnění zejména v oblasti automatizace a správy infrastruktury. Skripty PowerShell jsou organizovány podobně jako JavaScript funkce, tedy každá funkce má svůj adresář s souborem function.json a skriptem run.ps1. Tato volba je oblíbená mezi správci systémů, kteří chtějí využít výhod serverless architektury pro automatizaci rutinních úkolů.

Bez ohledu na zvolený programovací jazyk je pro všechny projekty Azure Functions společný soubor host.json, který se nachází v kořenovém adresáři a umožňuje konfigurovat globální chování hostitelského prostředí. Stejně tak soubor local.settings.json slouží k ukládání konfiguračních hodnot a připojovacích řetězců pro lokální vývoj, přičemž tento soubor by nikdy neměl být součástí verzovacího systému, protože může obsahovat citlivé informace.

Adresářová struktura projektu Azure Functions

Když začínáte pracovat s Azure Functions, jednou z prvních věcí, které si všimnete, je specifická adresářová struktura, která celý projekt definuje a organizuje. Tato struktura není náhodná — vychází z principů, které Microsoft zavedl proto, aby vývojáři měli jasný přehled o tom, kde se nachází jednotlivé části jejich aplikace, a aby nasazení na cloudovou infrastrukturu probíhalo co nejplynuleji.

Základem každého projektu Azure Functions je soubor host.json, který se nachází v kořenovém adresáři projektu. Tento soubor slouží jako globální konfigurační soubor pro celou funkční aplikaci. Definuje chování hostitelského prostředí, nastavení logování, timeouty a další parametry, které ovlivňují všechny funkce v rámci daného projektu. Bez tohoto souboru by projekt nebyl schopen správně fungovat, protože runtime prostředí Azure Functions by nevědělo, jak má aplikaci inicializovat.

Vedle souboru host.json najdete v kořenovém adresáři také soubor local.settings.json, který je určen výhradně pro lokální vývoj. Obsahuje proměnné prostředí, connection stringy a další nastavení, která se při lokálním spuštění načítají místo hodnot z cloudového prostředí. Je důležité poznamenat, že tento soubor by nikdy neměl být součástí verzovacího systému, protože zpravidla obsahuje citlivé údaje jako přístupové klíče nebo připojovací řetězce k databázím. Proto ho vývojáři standardně přidávají do souboru .gitignore.

Každá jednotlivá funkce pak má vlastní podsložku pojmenovanou podle názvu dané funkce. Uvnitř této složky se nachází soubor function.json, který definuje trigger, vstupní a výstupní vazby (bindings) pro konkrétní funkci. Tento soubor je klíčový, protože říká runtime prostředí, jakým způsobem má být funkce spuštěna — zda jde o HTTP trigger, timer trigger, trigger fronty nebo jiný typ. Správná konfigurace souboru function.json je naprosto zásadní pro to, aby funkce reagovala na správné události a zpracovávala data z očekávaných zdrojů.

Samotný kód funkce se nachází ve stejné složce jako function.json. V závislosti na použitém programovacím jazyce může jít o soubor s příponou .js pro JavaScript, .ts pro TypeScript, .py pro Python, .cs pro C# nebo jiné podporované jazyky. Azure Functions podporuje širokou škálu programovacích jazyků, což dává vývojářům flexibilitu pracovat v prostředí, které jim nejlépe vyhovuje.

Pokud projekt využívá závislosti třetích stran, jejich správa závisí na použitém jazyce. U JavaScriptových projektů najdete v kořenovém adresáři soubor package.json a složku node_modules, která obsahuje všechny nainstalované balíčky. U Python projektů se pracuje se souborem requirements.txt, ze kterého pip nainstaluje potřebné knihovny. C# projekty pak využívají standardní strukturu .NET s projektovým souborem s příponou .csproj.

Moderní projekty Azure Functions vytvořené pomocí novějšího modelu, tzv. isolated worker modelu pro .NET, mají strukturu ještě přímočařejší. Funkce jsou definovány přímo v kódu pomocí atributů a není potřeba samostatný soubor function.json pro každou funkci zvlášť, protože potřebné metadata jsou generována automaticky během buildu. Tato změna přinesla vývojářům větší svobodu a lepší integraci se standardními nástroji ekosystému .NET.

Pro projekty, které sdílejí společný kód napříč více funkcemi, je běžnou praxí vytvořit sdílenou složku nebo knihovnu, do které se umísťují pomocné třídy, utility funkce nebo společné modely. Tato složka pak může být importována jednotlivými funkcemi podle potřeby, čímž se zabraňuje duplicitě kódu a usnadňuje údržba celého projektu.

Důležitou součástí adresářové struktury je také složka .azure nebo konfigurační soubory pro CI/CD pipeline, jako jsou yaml soubory pro Azure DevOps nebo GitHub Actions. Tyto soubory definují, jak probíhá automatické nasazení projektu do cloudového prostředí, a jsou nedílnou součástí moderního vývojového procesu. Správně nastavená pipeline zajistí, že každá změna v kódu projde testováním a automaticky se nasadí do příslušného prostředí bez nutnosti manuálního zásahu.

Celková adresářová struktura projektu Azure Functions tedy odráží filozofii jasného oddělení zodpovědností — každý soubor a každá složka mají svůj přesně definovaný účel a místo v hierarchii projektu.

Soubor host.json a jeho konfigurace

Soubor host.json představuje jeden z klíčových konfiguračních souborů v celé architektuře Azure Functions. Nachází se vždy v kořenovém adresáři projektu, tedy na stejné úrovni jako složky jednotlivých funkcí, a jeho přítomnost je pro správný chod celé aplikace naprosto nezbytná. Bez tohoto souboru by runtime prostředí Azure Functions nedokázalo správně inicializovat hostitelský proces a celá aplikace by se odmítla spustit.

Když se podíváme na typickou adresářovou strukturu projektu Azure Functions, uvidíme, že soubor host.json leží přímo v kořeni vedle souboru local.settings.json, který slouží pro lokální vývoj a uchovává proměnné prostředí a připojovací řetězce. Zatímco local.settings.json je určen výhradně pro vývojové prostředí a nikdy by neměl být commitován do verzovacího systému, host.json je součástí projektu natrvalo a jeho nastavení se promítají jak do lokálního spuštění, tak do produkčního nasazení v cloudu.

Samotný obsah souboru host.json je strukturován ve formátu JSON a obsahuje celou řadu konfiguračních direktiv, které ovlivňují chování celého hostitele. Verze schématu je určena klíčem `version`, přičemž aktuální projekty pracují s hodnotou `2.0`, která odpovídá druhé generaci runtime prostředí Azure Functions. Tato verze přinesla zásadní změny oproti první generaci a umožnila výrazně flexibilnější konfiguraci.

Jednou z nejdůležitějších sekcí uvnitř host.json je konfigurace logování. Prostřednictvím klíče `logging` lze nastavit úroveň logování pro různé kategorie zpráv, filtrovat výstupy podle jejich závažnosti a řídit, které informace se budou zapisovat do Application Insights. Správně nastavené logování je naprosto zásadní pro diagnostiku problémů v produkčním prostředí, kde nemáme přímý přístup k vývojovým nástrojům.

Další důležitou oblastí je konfigurace rozšíření triggerů a vazeb. Každý typ triggeru, ať už jde o HTTP trigger, timer trigger, nebo trigger napojený na frontu Azure Storage, může mít vlastní konfigurační sekci v rámci host.json. Například pro HTTP trigger lze nastavit maximální počet souběžných požadavků, timeout pro zpracování nebo chování při přetížení systému. Pro timer trigger zase můžeme definovat chování při zpožděném spuštění nebo nastavit, zda se má funkce spustit okamžitě po startu hostitele.

Velmi podstatnou roli hraje také nastavení škálování a souběžnosti. V sekci `extensions` lze definovat, kolik instancí konkrétní funkce může běžet paralelně, jaký je maximální počet zpráv zpracovávaných najednou z fronty, nebo jak agresivně má runtime přidávat nové instance při zvýšené zátěži. Tato nastavení mají přímý dopad na výkon aplikace i na náklady spojené s jejím provozem v cloudu.

Nesmíme zapomenout ani na konfiguraci timeoutů. Klíč `functionTimeout` určuje, jak dlouho může jedna funkce běžet, než ji runtime násilně ukončí. Pro plán Consumption je výchozí hodnota pět minut a maximální hodnota deset minut, zatímco pro plány Premium a Dedicated lze timeout nastavit na výrazně delší dobu, nebo jej dokonce zcela vypnout. Správné nastavení timeoutu je kritické zejména pro funkce zpracovávající velké objemy dat nebo komunikující s pomalými externími službami.

Celkově lze říci, že host.json je centrálním místem pro ladění chování celé aplikace Azure Functions a jeho důkladné pochopení je předpokladem pro profesionální vývoj a provoz cloudových řešení postavených na této platformě. Každá změna v tomto souboru se okamžitě promítá do chování všech funkcí v rámci dané aplikace, proto je důležité přistupovat k jeho úpravám obezřetně a vždy testovat dopady změn nejprve v testovacím prostředí.

Soubor function.json definuje triggery a vazby

Každá funkce v rámci Azure Functions je definována svým vlastním adresářem, který nese název odpovídající konkrétní funkci. Uvnitř tohoto adresáře se nachází několik souborů, přičemž ten nejdůležitější z pohledu konfigurace nese název function.json. Právě tento soubor říká celé platformě Azure Functions, jak se má daná funkce chovat, co ji spouští a s jakými externími službami nebo zdroji dat komunikuje.

Soubor function.json je textový soubor ve formátu JSON, a pokud jste s tímto formátem někdy pracovali, jeho struktura vám bude velmi povědomá. Obsahuje několik klíčových sekcí, přičemž ta nejzásadnější se nazývá bindings. Tato sekce je polem objektů, kde každý objekt představuje buď trigger, nebo vazbu — a právě tady se odehrává veškerá magie konfigurace.

Trigger je speciální typ vazby, který funkci spouští. Každá funkce musí mít právě jeden trigger — ne více, ne méně. Může to být HTTP požadavek přicházející zvenčí, zpráva doručená do fronty Azure Service Bus, událost z Azure Event Hub, změna v databázi Cosmos DB nebo třeba časový plán definovaný pomocí CRON výrazu. Trigger určuje, co funkci probudí ze spánku a předá jí vstupní data ke zpracování.

Vedle triggeru může funkce obsahovat také takzvané vstupní a výstupní vazby. Vstupní vazba umožňuje funkci číst data z externího zdroje, aniž by musela sama spravovat připojení nebo autentizaci. Výstupní vazba naopak slouží k tomu, aby funkce mohla zapisovat výsledky svého zpracování do jiné služby — například do Azure Blob Storage, do tabulky Azure Table Storage nebo zpět do fronty.

V praxi to vypadá tak, že vývojář v souboru function.json specifikuje typ vazby pomocí vlastnosti type, směr pomocí vlastnosti direction a název, pod kterým bude vazba dostupná v kódu funkce, pomocí vlastnosti name. Každý typ vazby pak může mít vlastní specifické vlastnosti — například u HTTP triggeru se nastavuje povolená metoda požadavku, u časového triggeru se zadává CRON výraz, u vazby na frontu se uvádí název fronty a připojovací řetězec.

Důležité je pochopit, že Azure Functions runtime čte soubor function.json při spuštění a na jeho základě automaticky zajišťuje veškeré připojování k externím službám. Vývojář se tak nemusí starat o nízkoúrovňové detaily jako je správa připojení nebo zpracování chyb při komunikaci s externími systémy — to vše řeší platforma sama.

Adresářová struktura projektu Azure Functions je navržena tak, aby byl každý soubor function.json umístěn přímo v adresáři příslušné funkce. Pokud má projekt například tři funkce s názvy ProcessOrder, SendNotification a CleanupData, pak každá z nich má svůj vlastní podadresář a v každém z těchto podadresářů leží samostatný soubor function.json s vlastní konfigurací. Tato struktura zajišťuje přehlednost a umožňuje spravovat každou funkci nezávisle na ostatních.

Soubor function.json lze editovat ručně v libovolném textovém editoru, ale v praxi ho vývojáři často generují automaticky pomocí nástrojů jako je Azure Functions Core Tools nebo přímo prostřednictvím vývojového prostředí Visual Studio Code s příslušným rozšířením. Automatické generování snižuje riziko překlepů a chyb, které by mohly způsobit, že funkce nebude správně reagovat na triggery nebo nebude schopna komunikovat s navázanými službami.

Pochopení souboru function.json je naprosto zásadní pro každého, kdo chce efektivně pracovat s Azure Functions. Bez správně nakonfigurovaných triggerů a vazeb by funkce jednoduše nefungovala tak, jak má — buď by se vůbec nespustila, nebo by nedokázala přistupovat k datům, která potřebuje ke svému běhu.

Když se ponoříte do adresářové struktury Azure Functions, zjistíte, že každá funkce žije ve svém vlastním světě – ve složce, která nese její jméno, obklopena souborem function.json, jenž definuje její vstupy a výstupy, zatímco nadřazený adresář host.json řídí celý ekosystém jako tichý dirigent neviditelného orchestru.

Radovan Šimánek

Složky jednotlivých funkcí a jejich obsah

Každá funkce v rámci projektu Azure Functions má svou vlastní složku, která nese stejný název jako daná funkce. Tato složka slouží jako základní organizační jednotka a obsahuje veškeré soubory potřebné k tomu, aby funkce mohla správně fungovat, být nasazena a spravována. Pochopení toho, co se uvnitř těchto složek nachází, je klíčové pro každého vývojáře, který chce pracovat s Azure Functions efektivně a bez zbytečných chyb.

Nejdůležitějším souborem uvnitř složky každé funkce je soubor function.json, který definuje chování dané funkce z pohledu Azure runtime. Tento konfigurační soubor obsahuje definice vazeb, tedy takzvaných bindings, které určují, jak funkce komunikuje s okolním světem. Vazby mohou být vstupní nebo výstupní a prostřednictvím nich funkce přijímá data nebo je odesílá do různých služeb, jako jsou fronty Azure Storage, Service Bus, Cosmos DB, HTTP triggery a mnoho dalšího. Každá vazba má svůj typ, směr a případně další specifické vlastnosti, které závisí na konkrétní službě.

Vedle souboru function.json se ve složce funkce nachází samotný kód funkce. V závislosti na zvoleném programovacím jazyce může mít tento soubor různé přípony — v případě JavaScriptu půjde o soubor s příponou .js, v případě TypeScriptu o .ts, pro Python se používá .py a pro C# pak .cs nebo .csx v případě skriptovacího modelu. Právě tento soubor obsahuje logiku, která se spustí při každém vyvolání funkce. Vývojáři zde píší veškerou business logiku, zpracování dat, volání externích API nebo jakékoliv jiné operace, které má funkce provádět.

Pokud projekt využívá izolovaný model pro .NET nebo jiný model s explicitní závislostní injekcí, může složka funkce obsahovat také pomocné soubory s definicemi tříd, modelů nebo rozhraní. Tyto soubory nejsou striktně vyžadovány samotným Azure Functions runtime, ale jsou součástí dobré praxe při organizaci kódu v rozsáhlejších projektech.

V některých případech se ve složce funkce mohou nacházet také lokální testovací soubory nebo soubory se vzorkovými daty, které vývojáři využívají při lokálním vývoji a ladění. Tyto soubory nejsou nasazovány do produkčního prostředí, ale výrazně usnadňují práci při vývoji, protože umožňují simulovat různé vstupy a ověřovat chování funkce bez nutnosti připojení k živým cloudovým službám.

Složka každé funkce je tedy samostatnou, soběstačnou jednotkou, která v sobě nese vše potřebné pro její fungování. Tato architektura přispívá k přehlednosti celého projektu, protože vývojář vždy přesně ví, kde hledat konfiguraci nebo logiku konkrétní funkce. Zároveň tato struktura usnadňuje práci v týmech, kde různí vývojáři pracují na různých funkcích paralelně, aniž by docházelo ke zbytečným konfliktům v kódu.

Při nasazování projektu do Azure se celá tato adresářová struktura přenáší na cloudovou infrastrukturu, kde ji Azure Functions runtime interpretuje a na základě obsahu souborů function.json správně konfiguruje triggery a vazby. Správně strukturovaná složka funkce je tedy základním předpokladem úspěšného nasazení a provozu jakékoliv funkce v cloudovém prostředí Microsoft Azure.

Triggery spouštějící funkce různými způsoby

Azure Functions nabízí celou řadu triggerů, které umožňují spouštět funkce v reakci na různé události nebo podmínky. Každý trigger představuje specifický způsob, jakým může být funkce aktivována, a volba správného triggeru je klíčovým rozhodnutím při návrhu serverless aplikací. Pochopení toho, jak triggery fungují a jak ovlivňují adresářovou strukturu projektu, je naprosto zásadní pro každého vývojáře, který chce s Azure Functions pracovat efektivně.

Nejpoužívanějším triggerem je bezpochyby HTTP trigger, který spouští funkci v okamžiku, kdy přijde HTTP požadavek. Tento trigger se chová podobně jako klasický webový endpoint a umožňuje vytvářet REST API nebo webhooky bez nutnosti spravovat server. V adresářové struktuře projektu se HTTP trigger projevuje souborem `function.json`, kde je definován typ triggeru jako `httpTrigger`, a také vstupní a výstupní binding. Funkce může reagovat na různé HTTP metody jako GET, POST, PUT nebo DELETE, přičemž každá metoda může být nakonfigurována zvlášť. Výhodou tohoto přístupu je naprostá flexibilita — funkce může přijímat data z těla požadavku, z URL parametrů nebo z hlaviček.

Dalším velmi rozšířeným triggerem je Timer trigger, který spouští funkci v pravidelných intervalech na základě CRON výrazu. Tento trigger je ideální pro plánované úlohy, jako je čištění databáze, odesílání pravidelných reportů nebo synchronizace dat. CRON výraz je definován přímo v souboru `function.json` nebo v kódu funkce pomocí atributu. Například výraz `0 */5 * * * *` spustí funkci každých pět minut. V adresářové struktuře projektu je Timer trigger organizován stejně jako ostatní triggery — každá funkce má svůj vlastní adresář s názvem funkce, ve kterém se nachází konfigurační soubor a samotný kód.

Queue trigger je dalším důležitým mechanismem, který reaguje na zprávy přidané do fronty Azure Storage Queue nebo Service Bus Queue. Tento trigger je mimořádně užitečný pro asynchronní zpracování úloh, kdy není nutné čekat na okamžitý výsledek. Jakmile se ve frontě objeví nová zpráva, Azure Functions ji automaticky vyzvedne a předá funkci ke zpracování. Pokud zpracování selže, zpráva se vrátí do fronty a pokus o zpracování se opakuje. Počet pokusů o opakování je konfigurovatelný, což dává vývojářům kontrolu nad chováním aplikace v případě chyb.

Blob trigger je specifický typ triggeru, který reaguje na změny v Azure Blob Storage. Funkce se spustí vždy, když je do určeného kontejneru nahrán nový soubor nebo když je existující soubor upraven. Tento trigger je oblíbený pro zpracování obrázků, dokumentů nebo jiných souborů ihned po jejich nahrání. V adresářové struktuře projektu je cesta ke kontejneru definována v konfiguraci bindingu, přičemž je možné použít zástupné znaky pro sledování více kontejnerů najednou.

Event Hub trigger a Event Grid trigger jsou triggery určené pro zpracování velkého množství událostí v reálném čase. Event Hub je optimalizován pro scénáře s vysokou propustností, jako je telemetrie IoT zařízení nebo streamování dat. Event Grid naopak nabízí reaktivní model, kde funkce reaguje na události z různých Azure služeb nebo vlastních zdrojů. Oba triggery jsou konfigurovány v souboru `function.json` a vyžadují příslušné connection stringy, které jsou typicky uloženy v souboru `local.settings.json` pro lokální vývoj nebo v nastavení aplikace pro produkční prostředí.

Cosmos DB trigger sleduje změny v Azure Cosmos DB prostřednictvím change feed mechanismu. Funkce se aktivuje vždy, když jsou v monitorované kolekci vytvořeny nebo aktualizovány dokumenty. Tento trigger je zvláště užitečný pro synchronizaci dat mezi různými systémy nebo pro invalidaci cache. Adresářová struktura projektu s Cosmos DB triggerem obsahuje mimo jiné konfiguraci databáze, kolekce a lease kolekce, která slouží ke sledování pozice ve change feedu.

Signální trigger a Durable Functions triggery pak rozšiřují možnosti Azure Functions o stavové workflow a real-time komunikaci. Durable Functions přidávají do adresářové struktury projektu další vrstvu komplexity, protože orchestrátory, aktivity a entity mají každý svůj vlastní adresář a konfiguraci. Orchestrátor řídí celý workflow, zatímco aktivity provádějí jednotlivé kroky a entity udržují stav po delší dobu.

Každý trigger má svá specifika, která se odrážejí nejen v kódu, ale také v organizaci souborů projektu. Správná volba triggeru a jeho konfigurace může zásadně ovlivnit výkon, spolehlivost a náklady na provoz aplikace postavené na Azure Functions.

Vstupní a výstupní vazby dat funkcí

Každá funkce v Azure Functions pracuje s daty, která přicházejí z různých zdrojů nebo odcházejí do různých cílů. Právě proto existuje koncept vstupních a výstupních vazeb, který výrazně zjednodušuje způsob, jakým funkce komunikuje s okolním světem. Místo toho, aby vývojář musel ručně psát kód pro připojení k databázi, frontě zpráv nebo úložišti, stačí nakonfigurovat příslušné vazby a Azure Functions se postará o zbytek automaticky.

Srovnání adresářové struktury Azure Functions s konkurenčními platformami

Vlastnost	Azure Functions	AWS Lambda	Google Cloud Functions
Hlavní konfigurační soubor	host.json	template.yaml (SAM)	index.js / main.py
Soubor definice funkce	function.json	handler.js / handler.py	function.yaml
Složka pro každou funkci	Ano (samostatná složka)	Ne (jeden soubor handleru)	Volitelně
Soubor závislostí	package.json / requirements.txt	package.json / requirements.txt	package.json / requirements.txt
Lokální nastavení prostředí	local.settings.json	.env soubor	.env.yaml
Podpora více funkcí v projektu	Ano (více složek)	Ano (více handlerů)	Ano (více souborů)
Hloubka adresářové struktury	2–3 úrovně	1–2 úrovně	1–2 úrovně
Podpora CLI pro generování struktury	Azure Functions Core Tools	AWS SAM CLI	gcloud CLI
Maximální velikost nasazeného balíčku	250 MB (rozbaleno)	250 MB (rozbaleno)	100 MB (rozbaleno)
Podpora Dockeru v projektu	Ano (Dockerfile volitelně)	Ano (container image)	Ano (Cloud Run)

Vstupní vazby slouží k tomu, aby funkce dostala data ještě předtím, než začne vykonávat svou hlavní logiku. Může jít například o čtení záznamu z Azure Cosmos DB, načtení souboru z Azure Blob Storage nebo přijetí zprávy z Azure Queue Storage. Výstupní vazby naopak umožňují funkci odesílat výsledky svého zpracování do definovaných cílů, aniž by bylo nutné explicitně volat příslušná API nebo SDK. Tento přístup výrazně snižuje množství boilerplate kódu a zároveň zvyšuje přehlednost celého projektu.

Pokud se podíváme na adresářovou strukturu projektu Azure Functions, zjistíme, že každá funkce má svůj vlastní adresář, ve kterém se nachází soubor `function.json`. Právě tento soubor je klíčovým místem, kde se definují veškeré vazby dané funkce. Struktura projektu obvykle vypadá tak, že v kořenovém adresáři najdeme soubor `host.json`, který obsahuje globální nastavení celého hostitele, a dále soubor `local.settings.json`, jenž slouží pro lokální vývoj a uchovává citlivé konfigurační hodnoty jako jsou connection stringy nebo API klíče. Každá funkce pak sídlí ve vlastní složce pojmenované podle názvu funkce samotné.

Uvnitř souboru `function.json` se nachází pole `bindings`, kde jsou definovány jednotlivé vazby. Každá vazba má povinný atribut `type`, který určuje, o jaký typ vazby se jedná, dále atribut `direction`, jenž nabývá hodnot `in` nebo `out`, a nakonec atribut `name`, který určuje název parametru, pod kterým bude daná vazba dostupná uvnitř kódu funkce. Například trigger z fronty zpráv bude mít `type` nastaven na `queueTrigger`, zatímco výstupní vazba na tabulkové úložiště bude mít `type` nastaven na `table`.

Je důležité si uvědomit, že trigger je vždy speciálním typem vstupní vazby, protože právě on rozhoduje o tom, kdy se funkce spustí. Bez triggeru by funkce nikdy nezačala běžet. Vedle triggeru může mít funkce libovolný počet dalších vstupních a výstupních vazeb, přičemž jejich kombinace závisí čistě na konkrétním use case. Funkce zpracovávající objednávky může například přijímat zprávu z Service Bus jako trigger, načítat doplňující data z Cosmos DB jako vstupní vazbu a výsledek ukládat jak do Blob Storage, tak odesílat notifikaci přes Event Grid jako dvě oddělené výstupní vazby.

V rámci adresářové struktury je také důležité zmínit, že při použití novějšího modelu izolovaného procesu pro .NET nebo při práci s Python v4 modelem se způsob definice vazeb mění. Namísto souboru `function.json` se vazby definují přímo v kódu pomocí atributů nebo dekorátorů, což přináší výhodu silného typování a lepší podpory ze strany vývojových nástrojů jako je IntelliSense. Adresářová struktura se v takovém případě zjednodušuje, protože odpadá potřeba udržovat samostatné JSON konfigurační soubory pro každou funkci.

Lokální vývoj a testování vazeb je možné díky emulátorům a lokálním verzím Azure služeb. Azure Storage Emulator nebo jeho modernější náhrada Azurite umožňují simulovat chování Blob Storage, Queue Storage a Table Storage přímo na vývojářském počítači. Tímto způsobem lze testovat celý tok dat včetně vstupních a výstupních vazeb bez nutnosti připojení k reálnému cloudovému prostředí, což výrazně urychluje vývojový cyklus a snižuje náklady na testování.

Celkově lze říci, že systém vazeb v Azure Functions představuje jeden z nejsilnějších nástrojů celé platformy, protože umožňuje vývojářům soustředit se výhradně na business logiku a přenechat veškerou infrastrukturní komunikaci na framework samotný. Správně navržená adresářová struktura spolu s promyšleně nakonfigurovanými vazbami tvoří základ každého robustního a udržitelného projektu postaveného na Azure Functions.

Lokální vývoj pomocí Azure Functions Core Tools

Lokální vývoj funkcí v Azure představuje jeden z nejpříjemnějších způsobů, jak pracovat s cloudovými službami bez nutnosti neustálého nasazování kódu do vzdáleného prostředí. Azure Functions Core Tools jsou sada nástrojů příkazové řádky, která vývojářům umožňuje spouštět, testovat a ladit funkce přímo na jejich vlastním počítači, jako by běžely v cloudu. Celý proces je přitom překvapivě přímočarý a jakmile si na něj člověk zvykne, jen těžko si představí jiný způsob práce.

Instalace nástrojů probíhá nejčastěji přes npm nebo přímo přes balíčkovací systémy jako Homebrew na macOS nebo Chocolatey na Windows. Po úspěšné instalaci stačí v terminálu zadat příkaz func init, který vytvoří základní strukturu nového projektu. Právě tato adresářová struktura je jednou z věcí, které stojí za bližší pozornost, protože pochopení toho, jak jsou soubory organizovány, výrazně usnadňuje orientaci v projektu i při jeho pozdějším rozrůstání.

Kořenový adresář projektu obsahuje vždy soubor host.json, který slouží jako globální konfigurační soubor pro celý projekt. Zde se nastavují věci jako verze runtime, výchozí chování logování nebo konfigurace rozšíření. Vedle něj se nachází soubor local.settings.json, který je naprosto klíčový pro lokální vývoj. Ukládají se do něj connection stringy, API klíče a další citlivé hodnoty, které by v žádném případě neměly skončit v repozitáři. Proto je důležité zajistit, aby byl tento soubor zahrnut v .gitignore.

Každá jednotlivá funkce má pak svůj vlastní podadresář. Uvnitř tohoto podadresáře se nachází soubor function.json, který definuje tzv. bindings — tedy vstupy a výstupy funkce. Binding může být například HTTP trigger, fronta ve Storage Queue, zpráva ze Service Bus nebo třeba záznam v Cosmos DB. Právě díky tomuto deklarativnímu přístupu není potřeba psát složitý kód pro připojení k těmto službám, protože runtime se o vše postará automaticky na základě konfigurace v tomto souboru.

Samotný kód funkce se nachází v souboru pojmenovaném podle zvoleného jazyka — typicky index.js pro JavaScript nebo TypeScript, případně __init__.py pro Python. Pokud vývojář pracuje s C#, situace je trochu odlišná, protože projekt má strukturu bližší standardnímu .NET projektu s .csproj souborem a funkce jsou definovány jako metody tříd s atributy.

Spuštění lokálního serveru je pak otázkou jediného příkazu — func start. Po jeho zadání se spustí lokální runtime, který načte všechny funkce z aktuálního adresáře a začne naslouchat na příslušných portech. HTTP triggery jsou dostupné na adrese localhost s výchozím portem 7071, takže je lze testovat přímo v prohlížeči nebo pomocí nástrojů jako Postman či curl. Ostatní typy triggerů, jako jsou například fronty nebo časovače, se chovají stejně jako v produkčním prostředí, což je obrovská výhoda při ladění.

Jednou z méně zřejmých, ale velmi užitečných funkcí Core Tools je možnost lokálního emulování Azure Storage pomocí nástroje Azurite. Tento emulátor umožňuje pracovat s Blob Storage, Queue Storage a Table Storage bez nutnosti připojení k reálnému Azure účtu. Stačí v local.settings.json nastavit connection string na hodnotu UseDevelopmentStorage=true a Azurite se postará o zbytek.

Při práci na větších projektech se adresářová struktura může stát poměrně rozsáhlou, zvláště pokud projekt obsahuje desítky funkcí. V takovém případě je vhodné přemýšlet o logickém seskupování funkcí do samostatných projektů nebo využít monorepo přístup s jasně definovanými hranicemi. Azure Functions podporují také model izolovaného workeru pro .NET, kde je struktura projektu ještě více sjednocena s běžnými .NET konvencemi a kde odpadá nutnost samostatných function.json souborů, protože veškerá konfigurace je řešena přímo v kódu pomocí atributů.

Celkově vzato, lokální vývoj pomocí Azure Functions Core Tools nabízí vývojářům pohodlné a efektivní prostředí, které věrně napodobuje chování produkčního cloudu. Kombinace přehledné adresářové struktury, flexibilní konfigurace a možnosti okamžitého testování bez nasazování dělá z těchto nástrojů nepostradatelnou součást každodenní práce každého, kdo se serverless vývojem v Azure zabývá vážněji.

Nasazení projektu do cloudového prostředí Azure

Jakmile je projekt Azure Functions připraven a lokálně otestován, přichází na řadu jeden z nejdůležitějších kroků celého vývojového cyklu – nasazení do cloudového prostředí Azure. Tento proces může na první pohled působit složitě, ale pokud vývojář dodržuje správnou adresářovou strukturu a postupuje systematicky, celý deployment proběhne bez větších komplikací.

Adresářová struktura projektu Azure Functions hraje při nasazení naprosto klíčovou roli. Každá funkce musí být umístěna ve vlastní složce, která nese stejný název jako samotná funkce. Uvnitř této složky se nachází soubor function.json, jenž definuje triggery, vstupní a výstupní vazby a další konfigurační parametry. Kořenový adresář projektu pak obsahuje soubor host.json, který řídí globální chování celého function app, a soubor local.settings.json, jenž uchovává lokální konfiguraci a proměnné prostředí. Tento soubor se při nasazení do cloudu standardně nepřenáší, protože citlivé hodnoty jako připojovací řetězce nebo API klíče se v prostředí Azure nastavují přímo prostřednictvím Application Settings v portálu nebo pomocí nástrojů jako Azure CLI.

Samotné nasazení projektu do cloudového prostředí Azure lze provést několika způsoby. Nejběžnějším přístupem v profesionálním prostředí je využití CI/CD pipeline, typicky prostřednictvím Azure DevOps nebo GitHub Actions. Tato metoda zajišťuje automatizované testování, sestavení a nasazení při každém commitu do hlavní větve repozitáře. Vývojáři, kteří preferují rychlejší a přímočařejší přístup, mohou využít nástroj Azure Functions Core Tools, který umožňuje nasazení přímo z příkazové řádky pomocí příkazu `func azure functionapp publish`. Tento příkaz zabalí celý projekt, přenese ho do cloudu a zajistí správné spuštění v cílovém prostředí.

Dalším oblíbeným způsobem je nasazení přímo z vývojového prostředí Visual Studio nebo Visual Studio Code, kde rozšíření pro Azure Functions nabízí intuitivní grafické rozhraní. Stačí se přihlásit ke svému Azure účtu, vybrat cílový subscription a function app, a nasazení se spustí automaticky. Visual Studio Code navíc zobrazuje průběh nasazení v reálném čase a upozorní na případné chyby, které je třeba před opakovaným pokusem vyřešit.

Při nasazení je nezbytné věnovat pozornost nastavení runtime verze. Azure Functions v současnosti podporuje více verzí runtime, přičemž nejrozšířenější je verze 4.x, která přináší podporu pro nejnovější verze .NET, Node.js, Pythonu a Javy. Nesoulad mezi lokálně používanou verzí runtime a verzí nakonfigurovanou v cloudovém prostředí patří mezi nejčastější příčiny problémů při nasazení a následném spouštění funkcí.

Důležitou součástí přípravy na nasazení je také správné nastavení Application Settings v Azure portálu. Tyto nastavení nahrazují lokální soubor local.settings.json a obsahují veškeré proměnné prostředí, které funkce potřebují ke svému běhu. Patří sem připojovací řetězce k databázím, klíče k externím službám nebo konfigurace specifická pro produkční prostředí. Správa těchto hodnot by měla být vždy prováděna s ohledem na bezpečnost – ideálně prostřednictvím Azure Key Vault, který umožňuje bezpečné ukládání a přístup k citlivým informacím bez jejich přímého vystavení v konfiguraci aplikace.

Po úspěšném nasazení je vhodné ověřit funkčnost jednotlivých endpointů prostřednictvím Azure portálu nebo nástrojů jako Postman. Azure portál nabízí záložku Monitor, kde lze sledovat logy, metriky výkonu a případné chybové hlášky. Tato viditelnost do chování aplikace v produkčním prostředí je naprosto neocenitelná, zejména při ladění problémů, které se projevují pouze v cloudovém prostředí a lokálně je nelze snadno reprodukovat. Celý proces nasazení, ačkoliv se může zdát na začátku náročný, se s každým dalším projektem stává rutinní záležitostí, která vývojářům šetří čas a přináší jistotu spolehlivého provozu jejich aplikací v cloudu.

Monitorování a ladění funkcí v produkci

Každý vývojář, který pracuje s Azure Functions v produkčním prostředí, dříve nebo později narazí na situaci, kdy se funkce chová jinak než v lokálním vývojovém prostředí. Právě tehdy se ukáže, jak důležité je mít správně nastavenou adresářovou strukturu projektu a zároveň vědět, kde a jak hledat příčiny problémů. Monitorování a ladění funkcí v produkci je proces, který vyžaduje kombinaci správných nástrojů, znalosti platformy a systematického přístupu.

Adresářová struktura Azure Functions projektu hraje při diagnostice zásadní roli. Každá funkce má svůj vlastní adresář, ve kterém se nachází soubor function.json, jenž definuje triggery, vstupní a výstupní vazby. Na úrovni celého projektu pak existuje soubor host.json, který ovlivňuje chování celého hostitele funkcí, včetně nastavení logování, timeoutů a dalších globálních parametrů. Pokud je tento soubor špatně nakonfigurovaný, může to způsobit problémy, které se v produkci projeví až po určité době nebo při konkrétní zátěži. Proto je důležité věnovat pozornost každému parametru v tomto souboru ještě před nasazením.

Azure Functions nativně integruje Application Insights, což je jeden z nejsilnějších nástrojů pro monitorování v produkčním prostředí. Po propojení funkce s Application Insights začnou automaticky proudit data o každém volání, době odezvy, výjimkách a závislostech. V portálu Azure pak lze pomocí nástroje Live Metrics sledovat provoz téměř v reálném čase, což je nesmírně cenné při diagnostice problémů, které se vyskytují sporadicky nebo pouze při vyšší zátěži. Dotazovací jazyk Kusto (KQL) umožňuje psát složité analytické dotazy nad logy a telemetrií, takže lze například snadno zjistit, které funkce mají nejdelší dobu zpracování nebo kde dochází k nejvíce výjimkám.

Důležitou součástí adresářové struktury je také soubor local.settings.json, který obsahuje nastavení prostředí pro lokální vývoj. Tento soubor by nikdy neměl být součástí verzovacího systému, protože může obsahovat citlivé přihlašovací údaje. V produkci jsou tyto hodnoty nahrazeny nastavením aplikace v Azure portálu nebo jsou načítány z Azure Key Vault. Pokud dojde k nesouladu mezi lokálním nastavením a produkčním prostředím, může to být zdrojem záhadných chyb, které se v lokálním prostředí vůbec neprojeví.

Pro ladění funkcí přímo v produkci nabízí Azure možnost Remote Debugging, kdy lze připojit Visual Studio k běžící instanci funkce a procházet kód krok po kroku. Tato metoda je sice velmi mocná, ale v produkčním prostředí by měla být používána s velkou opatrností, protože může ovlivnit výkon a dostupnost služby. Vhodnější alternativou je využití Deployment Slots, kde lze otestovat novou verzi funkce ve staging prostředí, které sdílí stejnou infrastrukturu jako produkce, ale nezasahuje do živého provozu.

Logování je dalším klíčovým aspektem monitorování. V souboru host.json lze nastavit různé úrovně logování pro různé kategorie, přičemž příliš podrobné logování může výrazně zvýšit náklady na Application Insights a zpomalit výkon funkcí. Správné nastavení úrovní logování je tedy kompromisem mezi viditelností a výkonem. Doporučuje se logovat na úrovni Warning nebo Error v produkci a podrobnější logy zapínat pouze dočasně při diagnostice konkrétního problému.

Dalším nástrojem, který stojí za zmínku, je Azure Monitor, který umožňuje nastavit upozornění na základě různých metrik, jako je počet selhání, doba odezvy nebo počet aktivních instancí. Tato upozornění mohou být doručena e-mailem, SMS nebo prostřednictvím webhook, takže tým může reagovat na problémy ještě dříve, než si jich všimnou uživatelé. Kombinace Application Insights a Azure Monitor vytváří robustní systém pro proaktivní monitorování, který je základem každého spolehlivého produkčního nasazení Azure Functions.

Pochopení adresářové struktury projektu a správné využití dostupných monitorovacích nástrojů jsou dva pilíře, na kterých stojí úspěšný provoz Azure Functions v produkci. Bez jednoho z nich je diagnostika problémů výrazně obtížnější a čas potřebný k jejich vyřešení se prodlužuje, což může mít přímý dopad na spokojenost uživatelů a celkovou spolehlivost systému.