Windows Azure SDK 1.3: A Microsoft kiadta a felhőplatformhoz tartozó CmdLets frissítést

News(Marius Oiaga cikke alapján) A Microsoft a közelmultban frissítette a felhőplatformjához tartozó CmdLets gyűjteményt, hogy az problémák nélkül együtt tudjon működni a Windows Azure SDK 1.3 változatával.
A Windows Azure Service Management Cmdlets már elérhető letöltésre az MSDN Code Gallery oldalain azok számára, akik a Windows Azure SDK 1.3 változatát használják.

“2011 február 7 reggeléig ha a Windows Azure SDK 1.3 változatával próbálta valaki lefordítani a Windows Azure Cmdlets komponenseket, az fordítási hibával találta magát szembe,” fejtette ki Avkash Chauhan a Microsoft-tól.

“A fordítási hibával kapcsolatos további vizsgálatok az alábbi problémát fedték fel:

A Windows Azure Cmdlets komponens AzureManagementTools.Cmdlets projektje egy referenciát tartalmaz a Microsoft.WindowsAzure.StorageClient.dll-re, amely még mindig függésben van a Windows Azure SDK 1.2-ben található Microsoft.WindowsAzure.StorageClient.dll-től (1.0.0.0 változat), és mivel a Windows Azure SDK 1.3-ban ennek a .dll-nek a verziószáma 1.1.0.0-ra lett módosítva, ez fordítási problémát okozott”, folytatta Chauhan.

A legutólsó Windows Azure Service Management Cmdlets gyűjtemény kifejezetten abban az irányban fejlődött, hogy az IT Pro szakemberek kihasználhassák az erőforrások Windows Azure SDK 1.3-val való használatából adódó előnyöket.

2011 ferbuárjának elején a Microsoft ismét frissítette a Windows Azure SDK-t. Azok az ügyfelek, akik a legfrisebb változatra váltottak, az SDK 1.3.20121.1237 változatát kell, hogy futtassák. Az SDK kiadott frissítését azért tervezték, hogy a fejlesztők javíthassák a Windows Azure-on futó alkalmazásaikat és szolgáltatásaikat.

A Microsoft közleménye szerint egy biztonsági problémát fedeztek fel, amely az 2010-es Windows Azure SDK 1.3-as változatával létrehozott ASP.NET projekteket érintette, ezek közül is azokat, amelyek a “Full IIS” képességet használták és Web Role telepítésére volt szükségük. Az ügyfeleknek újból kell fordítaniuk szolgáltatásaikat (új deployment csomag ot kell létrehozniuk)  és azt frissíteni vagy újratelepíteni a Windows Azure-ban.

A Windows Azure Service Management Cmdlets komponens ún. “cmdlet”-ek gyűjteménye, amelyek a “Windows Azure Management and Diagnostics API” köré épülve egyszerűsítik a Windows Azure konfigurációs és szolgáltatás-kezelési műveleteinek végrehajtását.

“Ezek a cmdlet-ek segítenek az Azure alkalmazások kifejlesztésében és tesztelésében mert egyszerűvé teszik a telepítés és frissités folyamatának szkriptelését, és gyorsan skálázhatóvá tenni az alkalmazást. Továbbá, ezek a cmdlet-ek a diagnosztika kezelését és konfigurálását is egyszerűsítik”, nyilatkozta a Microsoft.

A Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio (November 2010) frissítés innen tölthető le.

Reklámok

Útmutató a Windows Azure platform árazásához – 2. rész

Ez a bejegyzés egy cikksorozat második része. A sorozat többi része:

Az SQL Azure árazása

BlueCloudAz SQL Azure segítségével adatbázisainkat tárolhatjuk a felhőben – az ott található SQL Serveren. Egy előfizetés kapcsán több adatbázist is tárolhatunk, értelemszerűen mindegyikért fizetni kell. Az SQL Azure árazása sávos, minden egyes sáv egy maximális adatbázisméretet határoz meg az alábbiak szerint:

Adatbázis Max. méret Egységár
Web Edition 1 GB 9,99 USD/hó
  5 GB 49,99 USD/hó
Business Edition 10 GB 99,99 USD/hó
  20 GB 199,98 USD/hó
  30 GB 299,97 USD/hó
  40 GB 399,96 USD/hó
  50 GB 499,95 USD/hó

 

Az adatbázisok létrehozása során megadhatjuk, hogy a táblázatban szereplők közül melyik legyen adatbázisaink maximális méretet. Akármelyik méretet is választjuk, az SQL Azure nem engedi, hogy a használat során a megadott méret fölé kerüljön az adatbázisunk. Természetesen, lehetőség van arra, hogy a későbbiekben ezt a méretet megváltoztassuk.

Az árazás az adatbázisok napi maximális mérete alapján történik. Minden nap a maximális méret alapján a táblázatban szereplő kategóriák közül a megfelelőbe kerül az adatbázis besorolásra. Ha pl. az 3 GB méretű, akkor a 49,99 USD/hó kategóriába kerül. Ha 0,5 GB, akkor a 9,99 USD/hó kategóriába. Ilyen módon, minden nap kiszámításra kerül az SQL Azure “napi fogyasztása”, és azok adódnak össze a hónap végéig. Ha pl. a hónap első 10 napjában az adatbázis méret 0,2 GB és 0,8 GB között változott, a második 10 napban 1,5 GB és 3,8 GB között, majd utána az adatbázist töröltük, akkor a havi számla az alábbi módon kerül kiállításra:

Időszak Méret Havidíj Díj
Első 10 nap 0,2 GB – 0,8 GB 9,99 USD 3,33 USD
Második 10 nap 1,5 GB – 3,8 GB 49,99 USD 16,66 USD
Utolsó 10 nap 0 USD
Összesen: 19,99 USD (kb. 3 998 Ft)

 

Nagyon fontos tisztában lenni azzal, hogy az adatbázisunk mérete minding sávosan kerül kiszámításra! Hiába csak egyetlen bájttal lépi túl az adatbázisunk az 1 GB-ot, a havi díj (illetve annak az adott napra kivetített összege) azonnal 9,99 USD-ről 49,99 USD-re nő meg! Értelemszerűen ez hasonlóan működik a tövvi sáv határának átlépése esetében is.

Egyéb költségek az SQL Server kapcsán

Az SQL Azure havi díjáért egy valódi üzemeltetett adatbázist kapunk adatbiztonsággal, index frissítésekkel, statisztikákkal, és – elvileg tetszőlegesen “szétskálázott” teljesítménnyel. A havi díjban tetszőleges számú és méretű tranzakció is benne van, nem kell külön fizetnünk az SQL logfájlokért sem. Azonban, mindenképpen lesz még néhány további költségünk, amelyekkel számolnunk kell:

Fizetnünk kell továbbra is az adatforgalomért, pontosan ugyanúgy, mint az Azure Compute és Azure Storage szolgáltatások kapcsán (lásd a sorozat előző részében). Emlékeztetőül, ez azt jelenti, hogy az SQL Serverre küldött kérések minden egyes GB-jáért 0,10 USD-t, a letöltött adatok egy GB-jáért pedig 0,15 USD-t kell fizetnünk.

Jelenleg az SQL Server nem végez biztonsági mentést. Ettől az adataink még biztonságban vannak abban az értelemben, hogy azok három helyen is tárolódnak, így nem kell attól tartanunk, hogy esetleges hardver meghibásodás miatt azok elvesznek, megsérülnek. Ugyanakkor, semmi sem véd meg bennünket attól, hogy az alkalmazásunkban lévő hiba vagy esetleg adminisztratív beavatkozás ne okozzhasson inkonzisztenciát az adatainkban. Egy rosszul megírt program például több rekordot is törölhet, mint amennyit kellene… Ennek elkerülése érdekében – jelenleg még saját magunknak – gondoskodnunk kell az adatbázis mentéséről. A mentések kapcsán az alábbiakkal kell számolnunk:

  • Ha az Azure Storage-ban tároljuk a biztonsági másolator, akkor a tárterületért kell fizetnünk (0,15 USD/GB/hó)
  • Ha nem a felhőben tároljuk az adatokat, akkor a letöltésért kell fizetnünk (0,15 USD/GB/hó)

A sorozat következő része az Azure AppFabric árazásával foglalkozik.

Útmutató a Windows Azure platform árazásához – 1. rész

Ez a bejegyzés egy cikksorozat első része. A sorozat többi részei:

BlueCloudA Windows Azure a Microsoft felhő-platformja. Minden olyan szolgáltatás, amelyek a felhasználók és fejlesztők igénybe vesznek, valahol az interneten – a felhasználótól távol – egy adatközpontban található “számítógép-erdőben” fut. A szolgáltatások felhasználóinak azokat az erőforrásokat kell megfizetniük, amelyeket igénybe vesznek. Ezek alapvetően az alábbi két típusba tartoznak:

  • Az adatközpont belsejében használt szolgáltatások – pédául a felhasznált CPU kapacitás, tárterület, stb.
  • Az adattovábbítás során felhasznált erőforrások – például adatok letöltése a központból a szolgáltatást fogyasztó számítógépekre, az adatok továbbítása a fogyasztók számítógépéről az adatközpontokig.

Amikor a Windows Azure platformon egy alkalmazás fut, a platform jónéhány jellemzőt mér, és azok segítségével számítja ki a havi fogyasztást, amely megjelenik az ügyfél számláján.

Az adattovábbítás szolgáltatási díjai

A web működési elvének megfelelően, egy alkalmazás használata során a kliens és a szolgáltatást biztosító adatközpont között internetes adatforgalom zajlik. Ezért az adatforgalomért a szolgáltatás bérlőjének fizetnie kell, mégpedik az alábbiak szerint:

  • Minden adatforgalom, amely során az adatközpontba információt töltünk fel, 0,10 USD-be kerül GB-onként.
  • Az adatközpontból letöltött adatokért is fizetni kell, minden egyes GB-nyi adat 0,15 USD-be kerül.
  • A szolgáltatás komponensei között az adatközponton belül áramló információ mennyiségi korlát nélkül ingyenes.

Példa:

Egy webalkalmazást egy hónapban 100 000 felhasználó látogat, mindegyik 0,5 MB adatot tölt fel és 4,5 MB adatot tölt le. A működése során az alkalmazás 12,5 GB belső adatforgalmat generál.

Irány Adat Egységár Díj
Feltöltés 48,82 GB 0,10 USD 4,88 USD
Letöltés 439,45 GB 0,15 USD 65,91 USD
Belső adatforgalom 12,5 GB 0,0 USD 0 USD
Összesen: 70,79 USD (kb. 14,158 Ft)

 

A Windows Azure komponens szolgáltatásainak árazása

A Windows Azure componens nem keverendő össze a Windows Azure platformmal. Amíg az utóbbi fogalom a platform egészére utal, addig a Windows Azure komponens (és ezt általában a “komponens” jelző nélkül használjuk) a platform alapvető feldolgozási és tárolási szolgáltatásait kínálja. A “Compute”, vagyis feldolgozás szolgáltatás számítási kapacitást, a “Storage” vagyis tárolás szolgáltatás pedig tárterületet kínál.

“Compute” szolgáltatás – számítási kapacitás biztosítása

A szolgáltatás használata során virtuális gépeket biztosít számunkra a platform. Több különböző kapacitású virtuális gép áll rendelkezésünkre:

Méret CPU Memória Háttértár I/O teljesítmény
Extra Small 1,0 GHz 768 MB 20 GB Alacsony
Small 1,6 GHz 1,75 GB 225 GB Közepes
Medium 2 x 1,6 GHz 3,5 GB 490 GB Magas
Large 4 x 1,6 GHz 7 GB 1,000 GB Magas
Extra Large 8 x 1,6 GHz 14 GB 2,040 GB Magas

 

A virtuális gépek árazása óradíjas alapon történik. Az Extra Small példány egy órai használata 0,05 USD-be, a többi gépé processzoronként 0,12 USD-be kerül. Ez azt jelenti, hogy a Small példány óradíja 0,12 USD, a Medium példányé 0,24 USD, a Large 0,48 UDS-be kerül, míg az Extra Large 0,98 USD-be.

Ha 200 Ft-os USD árfolyammal számolunk és 30 napos hónappal, akkor ez azt jelenti, hogy egy Extra Small példány kb. 7 200 Ft, egy Small példány kb. 17 280 Ft egy hónapra.

A virtuális gépekre bármikor feltölthetjük az alkalmazásunkat. Függetlenül attól, hogy a feltöltött alkalmazásunk fut-e (elindítottuk azt) vagy áll-e (leállítottuk azt), a számítási kapacitásért fizetnünk kell – hiszen az általunk “megvásárolt” virtuális gép kapacitását a rendszer nem tudja más felhasználó számára elérhetővé tenni. Ahhoz, hogy a számlázás leállításra kerüljön, alkalmazásunkat (szolgáltatásunkat) törölni kell.

A számlázás során minden megkezdett óra egy teljes egésznek számít. Ez azt jelenti, hogy 3 perc használatért és 59 perc használatért is pontosan egy órát kell kifizetnünk, 61 perc használatáért már 2 órát.

Egy alkalmazás a működése során egy vagy több virtuális gépet is használhatunk, értelemszerűen mindegyikért fizetnünk kell.

A Windows Azure platform magas szolgáltatási szinttel rendelkezik (99,9%), de azt a szolgáltatási szintet – értelemszerűen – akkor tudja biztosítani, ha az érintett alkalmazások szűk keresztmetszetet jelentő komponenseihez (egy webalkalmazás esetén ilyen pl. a front-end felület) legalább két virtuális gépet is biztosítunk. Ha valamilyen hiba miatt (ez lehet akár hardver hiba, akár az alkalmazás súlyos hibája) az egyik virtuális gépet újra kell indítani, az újraindítás ideje alatt a másik gép még ki tudja szolgálni az értkező kéréseket. Ha csak egy gépünk van, természetesen annak újraindítása alatt a szolgáltatásunk nem lesz elérhető.

A platform lehetővé teszi, hogy alkalmazásainkat akár éles, akár tesz környezetben hozzuk létre a felhőben. Mindegyik környezetért pontosan ugyanúgy fizetnünk kell, a teszt környezet és az éles környezet árazása megegyezik.

Példa: Webalkalmazás egy Small front-end géppel, és egy Extra Small háttérkomponenssel, havi 12 napban használva (fejlesztés)

A havi 12 nap használat azt jelenti, hogy egy hónap minden hetében a fejlesztőcsapat kb. 3 napig tartja fent az alkalmazást a Windows Azure környezetben.

Szerep Darab Egységár Napok Díj
Front-end, Small 1 0,12 USD 12 34,56 USD
Háttér, Extra Small 1 0,05 USD 12 14,4 USD
Összesen:       48,96 USD (kb. 9 792 Ft)

 

Példa: Webalkalmazás két Medium front-end géppel és egy Small háttérkomponessel, párhuzamosan futó éles és teszt környezettel

Tegyük fel, hogy az éles környezet folyamatosan működik, amíg a teszt környezetet (amely egyébként megegyezik az élessel) csak havi 10 napban használjuk. Ekkor a számítási kapacitás kapcsán havi költségeink az alábbiak:

Szerep Darab Egységár Napok Díj
Éles front-end, Medium 2 0,24 USD 30 345,6 USD
Éles háttér, Small 1 0,12 USD 30 86,4 USD
Teszt front-end, Medium 2 0,24 USD 10 115,2 USD
Teszt háttér, Small 1 0,12 USD 10 28,8 USD
Összesen:       576 USD (kb. 115 200 Ft)

 

“Storage” szolgáltatás – tárhely biztosítása

Ez a szolgáltatás azt teszi lehetővé, hogy az alkalmazás adatokat tároljon a felhőben (pl. a felhasználók által feltöltött képeket, videókat vagy egyéb anyagokat, illetve a rendszer működéséhez szükséges fájlokat). 1 GB adatmennyiség egy havi tárolása 0,15 USD költséggel jár. Ez így egyszerűnek hangzik, de mivel a tárolt fájlok mennyisége folyamatosan változhat (nőhet és csökkenhet is egy hónapon belül), a számításhoz az alábbi módszert használja a rendszer:

A rendszer az átlagos napi tárterület mennyiségét számítja egy hónapra vonatkoztatva. Ha például a hónap során 29 napig egyetlen GB adatot sem tárolunk, egyetlen napra viszont ez 30 GB, akkor egy 30 napos hónapra kivetítve az napi 1 GB, tehát ezután 0,15 USD díjat kell az adott hónapra fizetni. Ha a hónap első 15 napjában folyamatosan 10 GB, a második felében folyamatosan 30 GByte adatmennyiséget tárolunk, akkor az havi szinten 20 GB-ot jelent napi átlagban, vagyis ezért 20×0,15 USD = 3 USD díjat kell fizetnünk.

“Storage” szolgáltatás – CDN biztosítása

Az Azure opcionálisan ún. CDN (Contend Delivery Network) szolgáltatást is nyújt az ott tárolt állományok (ún. “blob”-ok) eléréséhez. Ennek lényege, hogy a Microsoft azokat nem csak a saját adatközpontjaiban tárolja, hanem eljuttatja a CDN olyan csomópontjaira is, amelyek fizikailag közelebb vannak a felhasználókhoz. Az Azure ugyanazt a meglévő CDN-t használja, amit a legtöbben már jól ismerhetünk a Windows Update, Bing Maps, esetleg a Zune kapcsán.

Amikor egy adott felhasználó egy állományt letölt, akkor az nem csak az adatközpontból történhez, hanem egy hozzá közelebb lévő – és így értelemszerűen gyorsabb – CDN csomópontról is. A CDN szolgáltatásért az alábbi módon kell fizetni:

  • Ha egy CDN a csomópont Észak-Amerikában vagy Európában van, akkor az onnan történő letöltésért 0,15 USD-t kell fizetni 1 GB adatért.
  • Ha egy CDN a csomópont a világ más területén van, akkor az onnan történő letöltésért 0,2 USD-t kell fizetni 1 GB adatért.
  • Fizetni kell ezenkívül még minden egyes CDN tranzakcióért. 1 USD-ért 1 millió tranzakciót kapunk. Egy tranzakciónak számít egy blob-hoz való hozzáférés.

Ezek mellett az árak mellett még fizetnünk kell az adatközpontokból a CDN hálózat csomópontjaira való letöltésért, pontosan ugyanazt a letöltési díjat, mint amit az egyéb webes adatforgalomért.

Példa:

Tegyük fel, hogy egy képtárat bemutató alkalmazást készítünk, amelyet 100 000 látogató néz meg Európából, 50 000 látogató Észak-Amerikából és 250 000 látogató a világ többi részéből. Az egyszerűség kedvéért tételezzük fel, hogy a látogatók 25 képet néznek meg átlagosan, amelyek mindegyike 100 KB-os A megnézett 25 kép-ből 20 egy CDN végpontról jön, 5 pedig közvetlenül az adatközpontből. A CDN-ek végpontjain 25 000 kép tárolódik. Az első hónapban az alábbi díjat kell fizetnünk:

Költségelem Mennyiség Egységár Díj
Adatletöltés az adatközpontból a CDN-be 25 000 x 100 KB = 2,5 GB 0,15 USD 0,375 USD
Letöltés CDN-ből:      
Európa/Észak Amerika 150 000 x 20 x 100 KB = 300 GB 0,15 USD 45 USD
A világ többi része 250 000 x 20 x 100 KB = 500 GB 0,2 USD 100 USD
Letöltés adatközpontból:      
Európa/Észak Amerika 150 000 x 5 x 100 KB = 75 GB 0,15 USD 11,25 USD
A világ többi része 250 000 x 5 x 100 KB = 125 GB 0,2 USD 25 USD
Tranzakciók 400 000 x 25 = 10 000 000 tranz. 1 USD/1 millió 10 USD
Összesen:     191,63 USD

 

A cikksorozat második részében az SQL Azure árazását ismerhetjük meg.

Azure Express Workshop – Fel a felhőbe…

WhiteCloudElérkezett az Azure Express Workshop utolsó napja – és ez az előzőeknél is izgalmasabbnak ígérkezett. A nap első részét az Azure néhány üzleti vonatkozásának áttekintésével kezdtük, illetve megnéztük az árazással kapcsolatos tudnivalókat. Bár az árak első rátekintésre riasztóak lehetnek egy “szimpla” fejlesztő számára (kb. 17.000 Ft-ba kerül 1 db “Small” virtuális gép), de vannak olyan előfizetési lehetőségek, amelyek a fejlesztési időszakban gyakorlatilag ingyenes próbálkozást tesznek lehetővé.

A nap jelentős részében egy mintaalkalmazást valósítottunk meg. Mindenki egyedül dolgozott, és a feladat kiírása alapján igyekezett azt megoldani. Ha valaki elakadt, Farkas Bálint nyújtott segítséget a problémák kibogozásához. A megvalósítandó feladat az alábbi volt:

Hozzunk létre egyszerű képfeltöltő alkalmazást, amely egy weblapon  keresztül a gépünk háttértárján lévő képfájlt feltölti a Windows Azure-ba, majd ott azt a háttérben összetömöríti (kisebb képméretet használva). A feladat megvalósítása során az alábbi megvalósítási technikákat kellett használnunk:

  • Blob: a feltöltött képek tárolása
  • Table: a feltöltött kép metaadatainak (pl. méret, típus, stb.) tárolása
  • Queue: kommunikáció az alkalmazás front-end felülete és a tömörítést végző “worker role” között

A nap igazi érdekessége az volt, hogy nem csak egyszerűen elkészítettük az alkalmazást, hanem azt fel is töltöttük a felhőbe…

Talán furcsának tűnik, de nekem a legtöbb munkát a kép beolvasása, elmentése és átméretezése okozta (nem tudtam fejből az összes ilyen műveletet, utána kellett néznem). Mivel a workshop első napján minden Azure Storage objektumtípussal foglalkoztunk, ezért azok használata nem jelentett problémát, a mintapéldák azonnal elérhetők voltak.

A legtöbb gondot – egyszerűen gyakorlatlanságból – a felhőbe való feltöltés okozta. A legtöbbünk – így én is – elfeledkezett arról, hogy átállítsa alkalmazása ún. “storage account”-ját a felhőbe való feltöltés kapcsán. Ez az apró hiba azzal járt, hogy kb. 15 perc várakozás után sikerül észrevenni ezt a hiányosságot, amikor a szerveren a “worker role” folyamatosan újraindult. Ennek köszönhetően gyorsan megtanultam, mi is a teendő, és erre biztosan emlékezni is fogok…

Mindent összevetve, nagyon hasznos volt a közös a tréning:

  • Jó áttekintést kaptunk a felhőplatform égészéről és az Azurról is
  • Gyakorlati tapasztalatot szereztünk, meértettük, mit is jelent egy felhőalkalmazást készíteni
  • Sok apró részletet megértettünk az Azure kapcsán
  • Már tudjuk, hol, és miképpen fog fájni a pénztárcánknak

Azt hiszem, ha valaki szeretne Azure fejlesztésbe, illetve a platform megismerésébe belekezdeni, egy ilyen workshop lehet a megfelelő intenzív első lépés.

Azure Express Workshop – Az alapokon túl

WhiteCloudAz első naphoz hasonlóan pörgős második napunk volt a workshopon-on. Először a Windows Azure diagnosztikai lehetőségeit tekintettük át, megvizsgáltuk, milyen lehetőségek vannak az Azure-felhőben futó alkalmazások megfigyelésére, esetleges hibáik elhárítására. Azok, aki fejlesztői pályafutásuk óta az intelligens és fejlesztőeszközökkel integrált nyomkövetésen nőttek fel, valószínűleg sokkoló lehet visszalépni a nyomkövetésnek arra a szintjére, ahol a programba explicit módon beépített kód diagnosztikai üzenetei jelentik a segítséget a hibák feltárására, elhárítására. Azok, akik nagyvállalati alkalmazások környékén mozognak, ebben igazán meglepő dolgokat nem találnak, hiszen egy éles rendszer nyomkövetésére a vállalati “felhőben” – még akkor is, ha csak egyszerűen egy szerver parkról beszélünk – ugyanezek az eszközök használhatók. Szóval, az Azure alapvetően jól el van látva diagnosztikai lehetőségekkel, de természetesen, a fejlesztőknek hozzá kell szokniuk ezekhez – el kell sajátítaniuk a tesztelésre és üzemeltetésre fejlesztés szemléletmódját. Nagyszerű lehetőség a posztmortem nyomkövetésre az IntelliTrace technológia, amelyet az Azure támogat – ez azonban csak a Visual Studio 2010 Ultimate változatával lehetséges.

Mint adatbázisokkal, adatcentrikus alkalmazásokkal gyakran dolgozó szoftver építész és fejlesztő, kifejezetten örültem, hogy az SQL Azure segítségével egyszerűen hasznosíthatom meglévő SQL Server ismereteimet egy-egy felhőalkalmazás készítése során. Az SQL Azure jelenlegi képeségei nem állítanak egy fejlesztőt igazán nagy kihívások elő, azonban az üzemeltetési oldalon még vannak fajsúlyos – jelenleg nyitott, megoldatlan – kérdések, például a natív SQL backup hiánya. Ezt komoly nehézségnek tartom, főleg annak kapcsán, hogy 1 GB SQL tárhely kb. havi 10$-ba kerül, és ez szerintem sok. Annak ellenére, hogy rendelkezésre állást és skálázódást kapok érte, saját backup megoldást kell kidolgoznom, amely szintén jelentős összegbe kerülhet. Jó hír, hogy ezeknek a képességeknek a fejlesztése már folyamatban van, s remélhetőleg hamarosan élesben is használható lesz.

A nap utolsó részében az AppFabric componens Service Bus és Access Control moduljait ismertük meg. Az első azt teszi lehetővé, hogy két alkalmazás-végpontot egymással összekapcsolhassunk (a hálózati verem “alkalmazás” szintjén) – bárhol is helyezkedjenek el azok, akár az interneten vagy akár egy vállalati intraneten. A második az ún. “claim-based identity” vagyis “igény-alapú azonosítás” megvalósításának egy jól átgondolt és egyszerűen használható eszköze. Ennek segítségével például olyan alkalmazásokat tudunk készíteni, amelyek könnyedén azonosítanak egy felhasználót a vállalati címtár, a Windows Live, Facebook vagy Google azonosítási modulok segítségével, s ráadásul ezek kombinálhatók is.

A mai – utolsó napon – a Windows Azure üzleti modelljét fogjuk áttekinteni, és elkészítünk egy valódi, élő alkalmazást, amelyet már nem a fejlesztői gépen, hanem a felhőben fogunk kipróbálni.

Azure Express Workshop – Az első nap tapasztalatai

WhiteCloudSok magyar és külföldi konferencián találkoztam már a Windows Azure-ral és több alkalommal is lehetőségem volt arra, hogy egy-egy laborgyakorlat segítségével közelebb kerüljek a platform megértéséhez, részleteinek kipróbálásához. Ezen a héten egy nagy lökést kaptam, ahhoz, hogy ezek az elszórt, alkalmi próbálkozások rendszerré szerveződhessenek: lehetőségem nyílt résztvenni egy három napos Azure Express Workshop-on.

Tegnap volt a közös műhelymunka első napja, amelyet Farkas Bálint vezényelt le. Korábbi ismereteimhez képest a workshop nem adott lexikálisan újdonságokat, hiszen valahol, valamilyen részletekben már találkoztam azokkal a fogalmakkal, amelyek itt elhangzottak. Nem is ezt vártam tőle! Arra számítottam, hogy segít áttekinthetővé tenni, összefoglalni mindazokat az apró tudásmorzsákat, amelyeket cikkekből, előadásokből, prezentációkból sikerült már eddig felcsipegetnem. Nem is csalódtam ebben!

Bálint a bevezetőjében körüljárta a számítási felhő, illetve a felhő platform fogalmát – de jó lenne a megfelelő magyar kifejezést megtalálni ezekre! – majd tömören és áttekinthetően mutatta be a Windows Azure platform elemeit, azok szerepét. Tetszett a megközelítésmód, mert segített megértetni azt, hogy milyen “földi” feladatokra és problémákra ad “égi” megoldást a platform. Megtanultam, hogyan is kell helyesen használni a “Windows Azure Platform” és “Windows Azure” fogalmakat, mert ezek bizony két különböző dolgot jelenthetnek, attól függően, hogy milyen kontextusban használom őket.

Az első nap az “Azure Compute” és “Azure Storage” komponenseinek részletes megismerésével folytatódott – megint valami olyat írtam le, amelyre szívesen megtalálnám a szép és közérthető magyar kifejezést. Eljutottunk odáig, hogy ezeket az ismereteinket egy-egy a lokális gépen futó mintaprogram segítségével kipróbálhattuk.

Az ebédet egy közeli étteremben fogyasztottuk el, ahol a Microsoft a’la cart vendégei voltunk. A közel másfél órás ebédszünetben volt lehetőségünk egymással beszélgetni arról, hogy ki és miért is vesz részt ezen a workshop-on. A résztvevők általában azt mondták el, hogy alapvető ismeretekethez szeretnének hozzájutni, hogy kipróbálhassák a platform elemeit, kitalálhassák, hogyan tudnák azt napi munkájukban hasznosítani. Az ebéd közben és a műhelymunka során is felmerültek olyan típusú architekturával és árazással összefüggő kérdések, amelyekről úgy gondolom, hogy érdemes lesz a jövőben ennek a blognak a témái között is foglalkozni.

Már várom a mai nap újabb felismeréseit…