Azure od zera - przewodnik dla początkujących

Pierwszy raz otworzyłem portal Azure kilka lat temu i zamknąłem go po dwóch minutach. Lewe menu miało kilkadziesiąt pozycji, każda z ikoną, której nazwa nic mi nie mówiła. Wróciłem tam dopiero pół roku później, bo musiałem gdzieś wystawić API w .NET Core i nie miałem ochoty administrować własnym serwerem.

Ten artykuł to wszystko, co chciałbym wiedzieć wtedy: jak zbudowana jest struktura konta, jak wystawić pierwszą aplikację, ile to naprawdę kosztuje i w których miejscach najłatwiej przepalić pieniądze.

Czytanie: ~20 min

Czym jest Azure, jeśli odjąć marketing

Azure to chmura Microsoftu. W praktyce oznacza to, że Microsoft ma na całym świecie centra danych pełne serwerów, a Ty wynajmujesz od niego kawałek mocy obliczeniowej, dysku albo gotowej usługi. Płacisz za to, co realnie zużyjesz, rozliczane najczęściej co godzinę albo za operację.

Cała reszta to warianty tego samego pomysłu. Możesz wynająć goły serwer z Windowsem i sam go administrować (maszyna wirtualna). Możesz wynająć środowisko, w którym wrzucasz tylko swój kod, a Microsoft dba o system, łatki i skalowanie (App Service). Możesz wynająć samą funkcję, która budzi się na żądanie i zasypia, gdy nikt jej nie woła (Functions).

Im wyżej wchodzisz w tej drabinie, tym mniej administrujesz i tym mniej rzeczy możesz zepsuć. Płacisz za to elastycznością, bo gotowa usługa narzuca reguły gry.

W katalogu Azure jest ponad 200 usług. Wygląda to przytłaczająco, ale prawda jest taka, że przez pierwszy rok będziesz używał pięciu, może sześciu. U mnie przez długi czas był to zestaw: App Service, Azure SQL, Key Vault, Storage Account i Application Insights. Cała reszta menu istniała gdzieś obok i nie przeszkadzała.

Dlaczego portal wygląda tak, jak wygląda

Portal Azure jest projektowany dla wszystkich naraz. Dla studenta, który stawia pierwszą stronę, i dla korporacji z dwoma tysiącami zasobów w dwudziestu regionach. Stąd ta ściana opcji.

Najlepsze, co możesz zrobić na starcie, to zignorować lewe menu i korzystać z wyszukiwarki na górze. Wpisujesz nazwę usługi, wchodzisz, robisz swoje. Po kilku tygodniach zaczniesz kojarzyć, gdzie co leży, i menu przestanie być problemem.

Subskrypcja, grupa zasobów, zasób - hierarchia, bez której nic nie zrozumiesz

To jest fragment, który najczęściej się pomija, a potem ludzie mają bałagan na koncie i nie wiedzą, skąd się wziął rachunek.

Hierarchia w Azure wygląda tak:

Tenant (katalog Entra ID) - Twoja tożsamość organizacyjna. Tu żyją konta użytkowników i uprawnienia.
Subskrypcja - jednostka rozliczeniowa. Do subskrypcji jest podpięta karta albo umowa i to na jej poziomie widzisz rachunek.
Grupa zasobów (Resource Group) - folder na zasoby. Nic nie kosztuje, służy do porządku i do wspólnego usuwania.
Zasób - konkretna rzecz, która kosztuje: baza, aplikacja, dysk, klucz.

Grupa zasobów to najbardziej niedoceniana rzecz w Azure. Nie ma ceny, a ratuje życie. Jeśli tworzysz wszystko dla jednego projektu w jednej grupie, to po zakończeniu testów kasujesz grupę i masz pewność, że nie zostało nic, co dalej nalicza koszty.

Moja pierwsza zasada dla każdego, kto zaczyna: jeden projekt lub jedno środowisko to jedna grupa zasobów. Nie mieszaj produkcji z testami w jednym worku, bo prędzej czy później skasujesz coś nie tego.

Nazewnictwo też ustal od razu, choćby najprostsze. U mnie działa schemat rg-nazwaprojektu-srodowisko, czyli rg-budda-dev, rg-budda-prod. Zasoby analogicznie: app-budda-prod, sql-budda-prod. Wygląda to nudno i o to chodzi. Po roku, gdy masz czterdzieści zasobów, nudne nazwy są jedynym, co pozwala się połapać.

Region ma znaczenie większe, niż myślisz

Przy tworzeniu każdego zasobu wybierasz region, czyli fizyczną lokalizację centrum danych. Trzy powody, dla których to nie jest kosmetyczny wybór:

Po pierwsze, opóźnienia. Jeśli Twoi użytkownicy są w Polsce, a baza stoi w Wirginii, każde zapytanie robi wycieczkę przez ocean. Przy aplikacji, która strzela do bazy kilkanaście razy na widok, robi się z tego zauważalna różnica.

Po drugie, ceny. Ta sama usługa potrafi kosztować inaczej w North Europe niż w Poland Central. Różnice bywają kilkunastoprocentowe.

Po trzecie, transfer między regionami jest płatny. Aplikacja w jednym regionie i baza w drugim to dodatkowa pozycja na rachunku, o której nikt nie pamięta.

Dla polskich projektów najczęściej wybieram Poland Central albo West Europe (Holandia). West Europe ma dostępne praktycznie wszystkie usługi, Poland Central jest młodszy i część rzeczy pojawia się tam z opóźnieniem. Jeśli któraś usługa nie chce się utworzyć w wybranym regionie, to zwykle właśnie dlatego.

Zakładanie konta i co naprawdę oznacza „darmowe"

Rejestracja wymaga karty płatniczej. Microsoft blokuje na niej symboliczną kwotę (rzędu kilku złotych) tylko po to, żeby zweryfikować, że karta jest prawdziwa. Blokada znika po kilku dniach.

Nowe konto dostaje kredyt na start, historycznie 200 dolarów do wykorzystania w ciągu 30 dni. Do tego dochodzi zestaw usług darmowych przez pierwszy rok oraz zestaw usług, które są darmowe zawsze w ramach określonych limitów. Ta trzecia kategoria jest najciekawsza, bo pozwala trzymać drobne projekty praktycznie za zero.

Co warto wiedzieć, zanim klikniesz „Rozpocznij bezpłatnie":

Kredyt startowy jest ważny 30 dni, nie 12 miesięcy. Jeśli założysz konto i zajrzysz tam za dwa miesiące, kredytu już nie ma. Zakładaj konto wtedy, gdy faktycznie masz czas usiąść do nauki.

Po wykorzystaniu kredytu konto domyślnie nie zacznie naliczać opłat. Azure wstrzymuje zasoby i czeka na Twoją decyzję o przejściu na plan płatny. To zabezpieczenie działa tylko na koncie w trybie bezpłatnym, więc po przejściu na Pay-As-You-Go już nie masz tej siatki bezpieczeństwa.

Limity darmowe liczą się per subskrypcja, nie per zasób. Jeśli usługa daje milion darmowych wywołań miesięcznie, to milion na całą subskrypcję.

Konto studenckie i inne skróty

Jeśli masz mail uczelniany, sprawdź Azure for Students. Dostajesz 100 dolarów kredytu bez podawania karty, odnawialne co roku przy weryfikacji statusu. Dla nauki to lepsza opcja niż zwykłe konto, bo nie ma ryzyka, że coś przez przypadek obciąży kartę.

Druga ścieżka to Visual Studio Subscription. Jeśli firma daje Ci licencję na Visual Studio Professional albo Enterprise, w pakiecie idzie miesięczny kredyt Azure (odpowiednio 50 i 150 dolarów). Sporo osób ma to w firmie i nie korzysta, bo nikt im nie powiedział.

Pierwszy zasób w praktyce: aplikacja webowa na App Service

Teoria wystarczy. Postawmy coś, co realnie działa.

App Service to hosting aplikacji webowych, w którym nie dotykasz systemu operacyjnego. Wrzucasz kod (.NET, Node, Python, Java, PHP) albo kontener, a Microsoft dba o resztę. To najprostszy sposób na wystawienie aplikacji w Azure i miejsce, od którego radzę zacząć.

Wersja klikana, przez portal

W wyszukiwarce portalu wpisz „App Services" i kliknij Create.
Wybierz subskrypcję i grupę zasobów. Jeśli nie masz grupy, utwórz nową (rg-test-dev).
Podaj nazwę aplikacji. Musi być unikalna globalnie, bo staje się adresem nazwa.azurewebsites.net.
Wybierz sposób publikacji: Code dla zwykłej aplikacji, Container dla obrazu Dockera.
Wybierz stos technologiczny, np. .NET 8 (LTS), oraz system: Windows albo Linux. Linux jest zwykle tańszy przy tych samych parametrach.
Wybierz region.
Wybierz plan cenowy. Tu jest cała zabawa i za chwilę o tym więcej.
Kliknij Review + create, potem Create. Po minucie zasób jest gotowy.

Aplikacja od razu ma publiczny adres HTTPS z certyfikatem. Nie musisz nic konfigurować, żeby działało po SSL, i to jest jedna z tych rzeczy, które w świecie własnych serwerów zajmowały pół dnia.

Wersja przez CLI, którą polecam bardziej

Klikanie w portalu jest dobre na pierwszy raz, żeby zobaczyć, co się dzieje. Przy drugim projekcie przerzuć się na Azure CLI, bo cały setup zamyka się w kilku linijkach, które możesz zapisać i powtórzyć.

# logowanie do konta
az login

# utworzenie grupy zasobów w regionie Poland Central
az group create --name rg-test-dev --location polandcentral

# plan hostingu w darmowej warstwie F1
az appservice plan create \
  --name plan-test-dev \
  --resource-group rg-test-dev \
  --sku F1 \
  --is-linux

# aplikacja webowa na .NET 8
az webapp create \
  --name app-test-mojaapka \
  --resource-group rg-test-dev \
  --plan plan-test-dev \
  --runtime "DOTNETCORE:8.0"

# publikacja z lokalnego folderu (spakowany build)
az webapp deploy \
  --resource-group rg-test-dev \
  --name app-test-mojaapka \
  --src-path ./publish.zip \
  --type zip

Pięć poleceń i masz działającą aplikację pod publicznym adresem. Ten sam skrypt odpalisz za trzy miesiące przy kolejnym projekcie, zmieniając tylko nazwy.

Plany cenowe App Service, czyli gdzie leży pierwsza pułapka

Plan App Service to maszyna, na której stoją Twoje aplikacje. Płacisz za plan, nie za aplikację, więc na jednym planie możesz postawić kilka aplikacji i koszt się nie zmieni.

Warstwy wyglądają mniej więcej tak (ceny orientacyjne, region West Europe, stan na połowę 2026 - sprawdź aktualne w kalkulatorze Azure):

F1 (Free) - 0 zł - Nauka, dema. 60 minut CPU dziennie, brak własnej domeny, brak skalowania
B1 (Basic) - ok. 55 zł/mies. - Małe projekty, środowiska testowe, własna domena
S1 (Standard) - ok. 290 zł/mies. - Produkcja, sloty wdrożeniowe, autoskalowanie
P1v3 (Premium) - ok. 500 zł/mies. - Poważniejszy ruch, izolacja, lepszy sprzęt

Warstwa F1 wystarcza do nauki, ale ma limit 60 minut czasu procesora na dobę. Po jego przekroczeniu aplikacja przestaje odpowiadać do północy. Do dema wystarczy, do czegokolwiek realnego już nie.

Pierwszy realny wybór to B1. Za około 55 złotych miesięcznie masz aplikację, która chodzi non stop, może mieć własną domenę i nie ma limitów czasu CPU. Brakuje jej slotów wdrożeniowych, czyli mechanizmu, w którym publikujesz nową wersję na drugi adres, sprawdzasz, że wstała, i dopiero potem przełączasz ruch. Sloty pojawiają się dopiero w S1 i to jest główny powód, dla którego przy produkcji warto dopłacić.

Baza danych: Azure SQL i decyzja, która ciągnie się latami

Skoro masz aplikację, potrzebujesz gdzieś trzymać dane. Dla świata .NET naturalnym wyborem jest Azure SQL Database, czyli SQL Server jako usługa. Nie instalujesz nic, nie robisz backupów ręcznie, nie łatasz systemu.

Przy tworzeniu bazy Azure zapyta o model rozliczeniowy i to jest decyzja, która najbardziej wpływa na rachunek.

DTU to model starszy i prostszy. Kupujesz abstrakcyjną jednostkę, w której zapakowany jest procesor, pamięć i operacje dyskowe. Nie wiesz dokładnie, ile czego dostajesz, ale nie musisz o tym myśleć. Warstwa Basic z 5 DTU i 2 GB miejsca kosztuje około 20 złotych miesięcznie i do nauki albo małej aplikacji spokojnie wystarcza.

vCore to model nowszy, w którym osobno wybierasz liczbę rdzeni i osobno rozmiar dysku. Daje kontrolę i jest jedyną drogą, jeśli chcesz skorzystać z licencji SQL Server, którą już masz.

W ramach vCore jest wariant, który polubiłem najbardziej przy projektach pobocznych: Serverless. Baza automatycznie zasypia po ustalonym czasie bezczynności i budzi się przy pierwszym zapytaniu. Płacisz tylko za sekundy, w których faktycznie pracowała, plus stały koszt dysku.

Przy aplikacji, z której korzysta kilka osób w godzinach pracy, potrafi to zbić rachunek z kilkuset złotych do kilkudziesięciu. Minus jest jeden i trzeba go znać: pierwsze zapytanie po przebudzeniu czeka kilkanaście sekund. Jeśli to Twoja produkcja z klientami, ten wariant odpada. Jeśli to wewnętrzne narzędzie albo projekt w budowie, jest idealny.

Firewall, o którym zapomni każdy przy pierwszej bazie

Świeżo utworzona baza Azure SQL nie wpuszcza nikogo. Zanim połączysz się z SQL Server Management Studio, musisz dodać swój adres IP do reguł zapory bazy. Znajdziesz to w zakładce Networking zasobu.

Tam też jest przełącznik Allow Azure services and resources to access this server. Włącz go, jeśli Twoja aplikacja z App Service ma się łączyć do bazy. Bez tego dostaniesz błąd połączenia i spędzisz godzinę na sprawdzaniu connection stringa, który jest w porządku. Wiem, bo tak zrobiłem.

Key Vault, czyli koniec z hasłami w pliku konfiguracyjnym

Connection string do bazy zawiera login i hasło. Wrzucanie tego do appsettings.json i commitowanie do repozytorium to klasyk, który potem wraca jako incydent bezpieczeństwa.

Azure Key Vault to sejf na sekrety, klucze i certyfikaty. Wrzucasz tam wartość, nadajesz aplikacji uprawnienie do jej odczytu i aplikacja pobiera sekret przy starcie. W kodzie nie ma żadnego hasła.

Najładniejsza część tego układu nazywa się Managed Identity. Włączasz ją jednym przełącznikiem w ustawieniach App Service, a Azure nadaje Twojej aplikacji własną tożsamość. Potem dajesz tej tożsamości dostęp do Key Vault. Efekt: aplikacja uwierzytelnia się do sejfu bez żadnego hasła, bo Azure wie, że to ona.

# utworzenie sejfu
az keyvault create \
  --name kv-test-dev \
  --resource-group rg-test-dev \
  --location polandcentral

# zapisanie sekretu
az keyvault secret set \
  --vault-name kv-test-dev \
  --name "DbConnectionString" \
  --value "Server=tcp:..."

# włączenie tożsamości zarządzanej dla aplikacji
az webapp identity assign \
  --name app-test-mojaapka \
  --resource-group rg-test-dev

Koszt? Key Vault liczy po operacjach i mówimy o groszach miesięcznie przy normalnym użyciu. To jedna z najtańszych usług w całym Azure, a wyciąga poziom bezpieczeństwa projektu o kilka klas.

W .NET podpięcie sejfu jako źródła konfiguracji to dosłownie kilka linii w Program.cs z pakietem Azure.Extensions.AspNetCore.Configuration.Secrets. Sekrety pojawiają się potem w standardowym IConfiguration, więc reszta kodu w ogóle nie wie, że coś się zmieniło.

Storage Account, czyli miejsce na pliki, którego i tak będziesz potrzebował

Prędzej czy później aplikacja zacznie przyjmować pliki: skany faktur, zdjęcia, wygenerowane raporty PDF. Trzymanie ich na dysku serwera aplikacyjnego to zły pomysł, bo App Service może w każdej chwili przenieść Twoją instancję na inną maszynę i pliki znikną.

Od tego jest Storage Account. Przy jego tworzeniu wybierasz kilka rzeczy, które warto rozumieć.

Typ danych. Storage Account obsługuje cztery rodzaje magazynów, ale w praktyce zaczniesz od Blob - to zwykłe pliki w kontenerach. Reszta (Files, Queues, Tables) przyda się później albo wcale.

Redundancja. LRS trzyma trzy kopie danych w jednym centrum danych i jest najtańsze. ZRS rozkłada kopie na trzy strefy w jednym regionie. GRS dodatkowo replikuje wszystko do drugiego regionu i kosztuje mniej więcej dwa razy tyle. Dla projektu w budowie LRS wystarcza. Dla dokumentów księgowych klienta bym się zastanowił.

Warstwa dostępu. Hot dla plików, po które sięgasz często. Cool dla archiwum sprzed kilku miesięcy, taniej za przechowywanie, drożej za odczyt. Archive dla rzeczy, które musisz trzymać, ale realnie nie otwierasz, przy czym odzyskanie pliku z Archive trwa godzinami. Możesz ustawić regułę cyklu życia, która automatycznie przenosi pliki starsze niż X dni do tańszej warstwy. Przy większym wolumenie to potrafi zbić koszt magazynu o połowę.

Ceny są niskie. Kilka gigabajtów w LRS Hot to kilka złotych miesięcznie. Uwaga pada gdzie indziej: płacisz też za operacje. Zapis, odczyt i wylistowanie zawartości kontenera to osobne pozycje w cenniku. Aplikacja, która w pętli sprawdza zawartość kontenera co sekundę, wygeneruje więcej kosztu operacji niż samego magazynu.

Dostęp do plików załatwiasz albo tą samą Managed Identity, o której pisałem wyżej, albo tokenem SAS. SAS to podpisany link z ograniczonym czasem ważności i zakresem uprawnień, idealny gdy chcesz dać użytkownikowi możliwość pobrania jednego pliku bez otwierania całego kontenera na świat. Domyślnie każdy kontener jest prywatny i to dobre ustawienie, którego nie warto zmieniać bez wyraźnego powodu.

Azure Functions, gdy nie potrzebujesz całej aplikacji

Czasem nie musisz stawiać serwisu, który chodzi 24 godziny na dobę. Potrzebujesz kawałka kodu, który odpali się raz dziennie o trzeciej w nocy, przemieli pliki i zniknie.

Do tego są Azure Functions. Piszesz funkcję, definiujesz wyzwalacz i płacisz za wykonania. W planie Consumption dostajesz milion wykonań miesięcznie za darmo, a powyżej tego stawka jest na tyle niska, że przy typowych zadaniach automatyzacyjnych rachunek zostaje symboliczny.

Wyzwalacze, z których korzystam najczęściej:

Timer - harmonogram w składni CRON. Raport co noc, czyszczenie danych co tydzień.
HTTP - funkcja jako endpoint. Idealne na webhooki od zewnętrznych systemów.
Blob - reakcja na pojawienie się pliku w Storage. Ktoś wrzuca PDF, funkcja go przetwarza.
Queue - przetwarzanie kolejki, gdy chcesz rozłożyć obciążenie w czasie.

Pułapka planu Consumption nazywa się cold start. Funkcja, do której nikt nie zaglądał od kilkunastu minut, przy następnym wywołaniu potrzebuje kilku sekund na rozgrzanie. Przy zadaniach nocnych nie ma to znaczenia. Przy endpoincie, który obsługuje użytkownika czekającego na odpowiedź, ma ogromne. Wtedy przechodzi się na plan Premium z ciepłymi instancjami, ale on kosztuje już kilkaset złotych miesięcznie i to zupełnie inna kategoria wydatku.

Ile to naprawdę kosztuje i gdzie znikają pieniądze

Najczęstsze pytanie, jakie dostaję o Azure, brzmi: „ile mnie to będzie kosztować". Uczciwa odpowiedź brzmi: zależy, ale da się to policzyć z góry.

Typowy zestaw dla małej aplikacji produkcyjnej w Polsce wygląda u mnie tak:

App Service - B1, Linux - ok. 55 zł
Azure SQL - Basic, 5 DTU, 2 GB - ok. 20 zł
Storage Account - LRS, kilka GB - kilka zł
Key Vault - kilkaset operacji - grosze
Application Insights - do 5 GB danych - 0 zł w limicie

Wychodzi około 80 złotych miesięcznie za działającą aplikację z bazą, monitoringiem i bezpiecznym przechowywaniem sekretów. Jak na to, że nie utrzymujesz żadnego serwera, nie robisz aktualizacji systemu i masz backupy w standardzie, to sensowna cena.

Problem zaczyna się tam, gdzie koszt nie wynika z tego, co świadomie wybrałeś.

Trzy miejsca, w których rachunek rośnie po cichu

Application Insights i logi. Monitoring ma darmowy limit 5 GB danych miesięcznie. Brzmi dużo, dopóki nie włączysz pełnego logowania zapytań przy debugowaniu i nie zapomnisz go wyłączyć. Aplikacja z umiarkowanym ruchem potrafi wtedy wygenerować kilkadziesiąt gigabajtów w tydzień. Każdy gigabajt powyżej limitu to kilkanaście złotych. To był mój pierwszy rachunek, na który spojrzałem dwa razy.

Zapomniane zasoby. Testujesz coś, tworzysz maszynę wirtualną, sprawdzasz i przechodzisz do innego zadania. Maszyna dalej chodzi. Zatrzymanie maszyny wirtualnej z poziomu systemu operacyjnego nie zatrzymuje naliczania opłat, bo zasób nadal istnieje i trzyma zarezerwowane zasoby. Musisz ją zatrzymać z poziomu portalu (stan Stopped (deallocated)) albo skasować. To samo dotyczy publicznych adresów IP i dysków, które zostają po skasowanej maszynie i dalej kosztują.

Transfer wychodzący. Dane wchodzące do Azure są darmowe. Wychodzące już nie. Pierwsze 100 GB miesięcznie nie kosztuje, powyżej płacisz za gigabajt. Przy zwykłej aplikacji biznesowej nie zobaczysz tego nigdy. Przy serwowaniu plików wideo albo dużych paczek zobaczysz bardzo szybko.

Dwie rzeczy, które ustaw w pierwszym tygodniu

Budżet z alertem. W sekcji Cost Management ustaw budżet miesięczny, na przykład 100 złotych, i powiadomienia mailowe przy 50, 80 i 100 procentach. Zajmuje to trzy minuty i jest jedynym mechanizmem, który uchroni Cię przed niespodzianką. Budżet nie blokuje zasobów, tylko wysyła maila, więc traktuj go jak czujnik dymu, nie jak gaśnicę.

Tagi na zasobach. Każdy zasób może mieć etykiety typu projekt=budda, srodowisko=dev. Potem w analizie kosztów filtrujesz po tagu i widzisz dokładnie, ile kosztuje dany projekt. Bez tagów masz jedną wielką kwotę i zgadujesz, skąd się wzięła.

Do tego dochodzi kalkulator cen Azure, który liczy koszt konfiguracji przed jej utworzeniem. Warto z niego korzystać, zanim klikniesz „Create", zwłaszcza przy usługach, których jeszcze nie znasz.

Jak to wygląda na realnym projekcie

Teoria z osobnymi usługami jest w porządku, ale dopiero złożenie ich w całość pokazuje, po co to wszystko. Opiszę układ, który powtarzam przy większości mniejszych wdrożeń.

Klient potrzebował narzędzia, do którego jego zespół wrzuca dokumenty, a system wyciąga z nich dane i zapisuje do bazy, żeby dało się po nich raportować. Klasyczne wewnętrzne narzędzie dla kilkunastu osób, działające w godzinach pracy.

Architektura wyszła taka:

App Service B1 z aplikacją .NET, która obsługuje interfejs i logowanie.
Storage Account na wgrywane pliki, kontener prywatny, dostęp przez Managed Identity.
Azure Function z wyzwalaczem Blob, która budzi się po pojawieniu się pliku i uruchamia przetwarzanie.
Azure SQL Serverless na dane wynikowe, z automatycznym usypianiem po godzinie bezczynności.
Key Vault na connection stringi i klucze do zewnętrznych API.
Application Insights na logi i podgląd błędów.

Rachunek zamknął się w okolicach 120 złotych miesięcznie. Największą oszczędnością okazała się baza w trybie Serverless, bo narzędzie realnie pracuje osiem godzin dziennie przez pięć dni w tygodniu, czyli mniej więcej jedną czwartą doby. Reszta czasu to zero kosztu obliczeniowego, płacimy tylko za dysk.

Rzecz, która okazała się ważniejsza, niż zakładałem na starcie: rozdzielenie przetwarzania do osobnej funkcji. Początkowo chciałem robić wszystko w aplikacji, bo prościej. Problem w tym, że przetwarzanie jednego dokumentu potrafiło zająć kilkadziesiąt sekund i blokowało wątek aplikacji, przez co interfejs zamulał przy kilku równoczesnych uploadach. Przeniesienie tego do funkcji rozwiązało sprawę bez dokładania mocy do App Service.

Druga lekcja dotyczyła usypiania bazy. Pierwsze wejście rano trwało kilkanaście sekund i użytkownicy zgłaszali to jako błąd. Rozwiązanie było banalne: funkcja z wyzwalaczem czasowym, która o 7:45 wykonuje jedno puste zapytanie i budzi bazę, zanim ktokolwiek usiądzie do pracy. Koszt tego triku wynosi zero, bo mieści się w darmowym limicie wywołań.

Taki zestaw da się postawić w jeden wieczór, jeśli wiesz, gdzie klikać. Dlatego namawiam, żeby przećwiczyć każdą usługę osobno na projekcie testowym, zanim złożysz je razem dla kogoś, kto płaci.

Pięć błędów, które popełniłem na starcie

Uczenie się na cudzych błędach jest tańsze, więc oto moje.

Stawiałem maszyny wirtualne, bo je rozumiałem. Maszyna wirtualna wydaje się bezpiecznym wyborem, bo to po prostu serwer, a serwer znasz. Problem w tym, że przenosisz do chmury cały bagaż administracyjny: aktualizacje, backupy, konfigurację IIS. Płacisz przy tym za czas, w którym maszyna stoi bezczynnie. Jeśli Twoja aplikacja może stanąć na App Service, postaw ją na App Service.

Trzymałem wszystko w jednej grupie zasobów. Po pół roku miałem tam trzydzieści zasobów z trzech różnych projektów i zero pewności, co można skasować. Sprzątanie zajęło mi cały wieczór i wcale nie było przyjemne.

Ignorowałem Infrastructure as Code. Klikanie w portalu jest szybkie za pierwszym razem i koszmarne za piątym. Jeśli powtarzasz ten sam setup, zapisz go: Bicep, Terraform albo choćby zwykły skrypt bash z poleceniami az. Bicep jest najprostszy do wejścia w świecie Azure, bo to natywny język Microsoftu i nie wymaga instalowania dodatkowych narzędzi.

Nie czytałem, co oznacza „warstwa Free". Postawiłem demo na F1, pokazałem klientowi, wszystko działało. Następnego dnia przy drugim pokazie aplikacja nie odpowiadała, bo wyczerpała dzienny limit CPU. Nie była to najlepsza rozmowa w moim życiu.

Zostawiałem włączone szczegółowe logowanie. Opisałem to wyżej, ale powtórzę, bo to najczęstsza przyczyna dziwnych rachunków u osób zaczynających. Debugowanie skończone równa się logowanie z powrotem na normalny poziom.

Co dalej, gdy podstawy już siedzą

Kiedy postawisz aplikację, bazę i sejf na sekrety, masz komplet, który wystarcza do większości małych projektów. Dalsza droga zależy od tego, dokąd chcesz iść.

Jeśli interesuje Cię automatyzacja wdrożeń, następnym krokiem jest GitHub Actions albo Azure DevOps. Konfiguracja pipeline'u, który po commicie na gałąź main buduje projekt i publikuje go do App Service, to kilkanaście linii YAML. Od momentu, w którym to skonfigurujesz, przestajesz myśleć o wdrożeniach.

Jeśli ciągnie Cię w stronę AI, tam jest teraz najwięcej ruchu. Azure AI Foundry pozwala uruchamiać modele językowe w ramach własnej subskrypcji, z danymi, które nie wychodzą poza Twoje środowisko. Dla firm, które nie mogą wysyłać dokumentów do publicznego API, to często jedyna droga do wdrożenia czegokolwiek z AI. Buduję na tym rozwiązania dla klientów z branży finansowej i argument o kontroli nad danymi pada tam w każdej rozmowie.

Jeśli chcesz mieć papier, jest AZ-900 (Azure Fundamentals). Egzamin kosztuje około 450 złotych, trwa 45 minut i sprawdza dokładnie ten poziom wiedzy, który opisałem w tym artykule plus podstawy modeli rozliczeniowych i zgodności. Materiały przygotowawcze Microsoft Learn są darmowe i naprawdę dobre. Sam certyfikat nie zrobi z Ciebie inżyniera chmury, ale porządkuje wiedzę i w niektórych rekrutacjach otwiera pierwsze drzwi.

A jeśli chcesz po prostu nauczyć się przez robienie, weź własny projekt, który leży u Ciebie na dysku, i postaw go w Azure. Nie ma szybszej metody. Godzina spędzona na wystawieniu własnej aplikacji da Ci więcej niż dziesięć godzin kursu, bo trafisz na wszystkie problemy, których kurs nie pokazuje.

Zanim klikniesz „Create" pierwszy raz

Azure nie jest trudny. Jest duży, a to zupełnie inny rodzaj problemu. Trudność polega na tym, że nie wiesz, których pięciu procent katalogu potrzebujesz, więc paraliżuje Cię pozostałe dziewięćdziesiąt pięć.

Zacznij od jednej grupy zasobów, jednej aplikacji na App Service i jednej bazy. Ustaw budżet z alertem. Potem dokładaj po jednej usłudze wtedy, gdy pojawi się realna potrzeba, a nie dlatego, że wygląda ciekawie w menu. Po trzech miesiącach takiego podejścia portal przestanie Cię przytłaczać, bo będziesz znał każdy zasób, który tam stoi, i wiedział, po co go tam postawiłeś.

Reszta katalogu poczeka. Zawsze czeka.

---

Budujesz coś w Azure i utknąłeś na architekturze, kosztach albo integracji z AI? Zajmuję się dokładnie takimi projektami - od prototypu po wdrożenie produkcyjne. Napisz przez mwozniczka.net/kontakt i pogadamy o tym, co masz do zrobienia.