다음을 통해 공유


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:

Služba

Měřený parametr

Windows Azure Compute

  •  Počet hodin, po které je aplikace nasazena na zvolený typ instance VM.
  •  Počet použitých VM.
  • Velikost zvoleného VM.  

Windows Azure Storage

  • Průměrný uložený objem dat za měsíc.
  • Počet provedených transakcí za měsíc.

SQL Azure

 

  • Maximální velikost SQL databáze
  • Počet alokovaných databází

Azure AppFabric

  • Počet připojených aplikací na servisní sběrnici
  • Počet transakcí provedených na službě Access Control  

Konektivita datového centra

  • Objem přenesených dat ven z datového centra do internetu
  • Objem přenesených dat dovnitř datového centra z internetu

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ě.

clip_image002

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.

Služba

 

 

 

Spotřeba

 

 

 

Cena / měsíc

 

 

 

Compute

  (1x S role)

750 hodin

(=1 měsíc bez přerušení)

90 USD

Storage

100 GB

(průměrná uložená kapacita)

15 USD

 

Storage Tx

10M transakcí

10 USD

Databáze

1 GB

(max. kapacita, 1 měsíc bez přerušení)

10 USD

 

Service Bus

5 připojení

10 USD

Datové přenosy (EU)   

2 GB in /  

100 GB out

15 USD

Cena

 

150 USD ≈ 3000 Kč

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.