Lze predikovat platby za Windows Azure platformu?

Je neuvěřitelné, jak často dostávám otázku, která je v názvu postu. Obavy z toho, že nejsem ihned schopen vyčíslit měsíční náklady na provoz aplikace, mnohé přivádí k myšlence návratu nákupu vlastních licencí provozovaných na vlastních serverech, ať ve firmě nebo u hostera.

Vše není „v oblacích“

Podívejme se na začátek na měřené parametry spotřeby na platformě Windows Azure:

Když nyní víme co se měří, podívejme se, které z výše uvedených parametrů máme pod kontrolou a které již méně.

Windows Azure Compute

Standardní chování Windows Azure je takové, že počet, velikost i dobu použití jednotlivých instancí definuje provozovatel aplikace sám. Ať je o programátora nebo IT správce. Cloud sám o sobě žádný z uvedených parametrů nemění, byť by to mohlo mít např. při vysokém náporu uživatelů za následek degradaci výkonu. Pokud nezapojíme nějaký automatický systém zvyšování výkonu, jak jsem např. popsal dříve, tuto část nákladů za cloud máme prvně v rukou.

SQL Azure

Druhou službou, kterou máme plně pod kontrolou je cloudová SQL databáze. Její cena se odvíjí pouze od maximální kapacity (v tuto chvíli to je 1-50GB), počtu těchto databází a doby, po kterou je máme nasazeny. Opět žádný z uvedených parametrů se sám nemění v reakci na zatížení. U SQL Azure se tedy nijak neměří objem skutečně uložených dat, počet provedených dotazů a transakcí.

Azure Storage

Toto je první služba, jejíž cena je ovlivněna reálným používáním nějakou aplikací. Její dva měřené parametry – objem dat a počet transakcí závisí na:

1. Optimalizaci aplikace samotné
2. Počtu přistupujících uživatelů a jejich činností, které na pozadí služby Azure Storage využívají

Zde existuje celá řada postupů, které mohou náklady na tuto službu minimalizovat. Část jsem z nich pospal zde.

Azure AppFabric

AppFabric se ve skutečnosti skládá ze dvou služeb. Servisní sběrnice a Access Control. U servisní sběrnice nepředpokládám, že by se na ni připojovalo nekontrolovatelné množství aplikací. Proto tento parametr lze ve většině případů chápat jako determinovatelný. Navíc cena za jedno připojení je relativně vysoká, takže žádný vlastník služby by tuto věc nepustil z dohledu.

Jiný případ je u Access Control. Čím více uživatelů se připojí, čím intenzivněji pracují, dojde k nárůstu transakcí ověření přístupu.

Datové přenosy

Tady asi není třeba vést nijak rozsáhlou diskusi. Prostě se měří objem dat, které do datového centra přitečou a z něj odtečou. Na tomto místě je nutné pouze zdůraznit, že přenosy se opravdu měří pouze na hranici datového centra s internetem. Pokud přenáším data mezi cloud aplikací, Azure Storage nebo SQL Azure, a všechny tyto komponenty běží v rámci jednoho datového centra, nic se neměří a tedy neplatí.

Praktický příklad

Abych ilustroval výše uvedené poznatky, udělal jsem si model fiktivního řešení, které používá zcela všechny služby platformy Windows Azure.

Z této celkové částky vím, že 100 USD (compute, SQL) zaplatím zcela jistě. Zbývajících 50 USD je můj odhad na základě předchozích průměrný měsíčních spotřeb. Ve skutečnosti se však může lišit na základě intenzity použití řešení.

Jaká je tedy odpověď?

V současné době jsem do značné míry schopen predikovat platby za použití služeb Windows Azure. Do budoucna chystáme další nástroje, které budou schopny aktuální spotřebu lépe monitorovat. Otázkou však zůstává, co se bude následně dít? Pokud bych překročil mnou stanovený cenový limit, aplikace by měla být zastavena nebo degradován výkon? To je již na rozhodnutí každého majitele aplikace.