Azure GyIK a technológiával ismerkedőknek

A technetklub.hu számára csokorba gyűjtöttem a leggyakoribb kérdéseket, melyeket a valamilyen technológiában már jártas, de Azure-t még nem ismerő fejlesztők szoktak feltenni.

Mi ez az Azure? Már megint újra kell tanulni a fél Microsoft-platformot?

Az Azure gyakorlatilag nem más, mint a Microsoft alkalmazásszervereinek központilag hosztolt, azaz “felhőből kínált” változata. A platform három alkotóeleme a Windows Azure, a SQL Azure és az Azure AppFabric.

A Windows Azure szolgáltatásait igénybevéve gyakorlatilag a megszokott Windows Server alapú környezetbe tehetünk fel alkalmazásokat, azaz továbbra is Windows-zal, IIS-sel, .NET-tel van dolgunk.

A SQL Azure a helyi SQL Server felhőbe vitt verziója. A két termék olyannyira kompatibilis egymással, hogy az adatbázis sikeres felhőbe migrálása után elég a connection string-et módosítani, és alkalmazásunk észre sem veszi, hogy változás történt.

Az AppFabric pedig kiegészítő eszközöket ad a fejlesztők kezébe, hogy a felhőben és a földön lévő alkalmazásokat még könnyebb legyen egymással összekötni.

Összefoglalva: az Azure nem jelent drámai technológiai váltást. Természetesen van tanulnivaló, de a megszokott technológiákra és megszokott eszközökkel fejleszthetünk, valamint már meglévő alkalmazásaink átmozgatása sem jelent túlzott kihívást.

Miért jobb ez, mintha a jól bevált módon saját magamnál, esetleg egy külső hosztercégnél tartanám az alkalmazásokat és adatokat?

Nézzük a legfontosabb érveket technológiai és üzleti szempontból is.

Technológiai szempontok:

• Skálázható és rugalmas: A felhőben nincs olyan, hogy elfogyott a hely, vagy kevés a memória. A legtöbb erőforrás magától skálázódik, ami meg nem, azt a webes felületen lehet néhány kattintással utánállítani. Ráadásul ez nem csak felfelé működik: ha lement a roham, ugyanilyen könnyen vissza is lehet venni, így nem kell fölösleges kapacitásért fizetni.
• Gyors “onboarding”: Ha megvan az alkalmazás-ötlet, 5 perc múlva megvan hozzá a szerver is. Nem kell írni a beszerzési osztálynak és keresgetni a hosztert. Ugyanígy nincs gond a licencekkel sem (mert áruk benne van a felhő árában).
• Jól menedzselt adatközpont: Jártál már olyan cégnél, ahol az asztal bal oldalán a munkaállomás, jobb oldalán meg a szerver áll? El lehet képzelni, hogy mi történik egy ilyen szolgáltatással, ha áramszünet, vagy ne adj’ Isten betörés van, esetleg a router teszi le a lantot. A felhőben az ehhez hasonló rendelkezésreállási és biztonsági problémákat a jól menedzselt vállalati adatközpontokkal megegyező magas szinten kezelik, és ezt írásba is adják.

Üzleti szempontok:

• Nincs induló költség: Nem kell beruházni szerverbe, licencbe, stb. Az Azure pontosan méri a fogyasztást, és csak a ténylegesen elhasznált erőforrások után kell fizetni minden hónap végén. Azaz: tőkeköltség nincs, csak operatív költség. Továbbá nincs fix havidíj, üresjárati díj, rendelkezésreállási díj, stb – ha felhő-előfizetésünkön nincs semmi, akkor költsége 0 Ft.
• Számolható kiadások: Az Azure költségei dokumentáltak, és használatunk ismeretében a díj pontosan tervezhető. Nincs olyan, hogy megdrágul az áram, vagy fizetésemelést kér a rendszergazda.
• Megtakarítás: Egyetlen Azure-adatközpontban több százezer szerver kap helyet, így a tömegtermelés miatt a költségek alacsonyan tarthatók. Testreszabott számítások kérhetők pl. itt.
• Nemzetközi jelenlét: Jelen cikk írásakor 3 kontinensen 6 nagy Azure-adatközpont található, melyek bármelyikébe, illetve egyszerre akár többe is feltehető alkalmazásunk. Magyar, kínai és amerikai ügyfelek egyaránt nagy sávszélességgel férhetnek hozzá. Ha pedig kimondottan nagy sávszélességet kell biztosítanunk ügyfeleinknek, pl. mert nagy fájlokat szolgálunk ki, akkor némi felárért és minimális plusz adminisztrációval kihasználható az Azure Content Delivery Network a maga több, mint 20 világszerte szétszórt kisebb adatközpontjával.

Én Java-s vagyok. Ki tudom majd használni az Azure-t?

Igen, ez kimondottan támogatott eset. A Java-hoz folyamatosan frissített Azure SDK tölthető le, az Eclipse pedig közel olyan szinten tud együttműködni Azure-ral, mint a Visual Studio.

Én PHP-s vagyok. Ki tudom majd használni az Azure-t?

Igen, ezt is támogatja a Microsoft. A PHP-hoz is letölthető a folyamatosan frissített Azure SDK, az Azure Companion projekt segítségével pedig minimális adminisztrációval telepíthető a felhőben futó PHP szerver.

Hol tudok nekikezdeni az Azure-ral való ismerkedésnek?

Magyar és angol nyelven is számos oktatóanyag érhető már el.

Magyarul ajánljuk a következőket:

• A devPortal TV-n megnézhető Train4Business Azure események felvételei. Ezek egésznapos Azure oktatások voltak, melyek a teljes platformot lefedik.
• A CloudDEV DVD anyaga, melyek szintén a platform nagyrészét lefedő videófelvételek.
• A magyar Azure közösség blogja.

Angolul pedig remek kezdés a hivatalos Azure honlapon található oktatóanyagok, ezen belül is a Windows Azure Platform Training Kit, amely a teljes platformot lefedő, nagyon részletes tananyag.

Mennyibe kerül ez? Nem lesz sokkal drágább, mint egy havi 2000 forintos hoszter?

Az Azure árazása listában is megtekinthető, illetve egy interaktív eszköz segítségével is számítható.

Az igaz, hogy egy kisforgalmú weboldalt nem feltétlenül érdemes Azure-ra tenni, mert a legkisebb Azure szerver is drágább a pár dolláros havi költségű hosztereknél. De fontos látni, hogy Azure-ban dedikált szervert kapunk ezért a pénzért, a hoszter pedig tucatnyi más weblappal közös infrastruktúrára zsúfolva tartja a weblapunkat (shared hosting).

Ha viszont több kisforgalmú weblapunk van, azok már rárakhatók egy Azure szerverre. Továbbá az Azure egyes részei külön-külön is vehetők, így könnyen megtehetjük pl., hogy kódunk helyben fut, SQL szervert pedig a felhőből vásárlunk (egy 1 GB-os SQL Azure adatbázis épp 2000 forint körül mozog).

A cégemet érdekli az Azure, de nincs most erőforrásunk kiképezni a fejlesztőket és küzdeni a problémákkal. Van más megoldás?

Van, pont az ilyen cégek számára indult az Azure Expressz program. Ennek keretében a megvásárolt Azure előfizetésekhez a Microsoft Magyarország ingyenes tanfolyamot, konzultációt és egyéb kedvezményeket biztosít. A részletek a program honlapján olvashatók.

Architektúra – miben lehet más a felhő?

Novák István az utolsó Azure Klubon vetette fel az ötletet: mi lenne, ha készítenénk egy listát a felhő platform azon sajátosságairól, amik architekturális szinten is különbségeket eredményezhetnek a megszokott megoldásokhoz képest?

Az én listám:

• Az alkalmazás nem kap full trust jogosultságot, azaz bizonyos .NET kódok amik eddig működtek, nem fognak (először a nem standard SMTP porton történő levélküldésnél futottam bele).
• A program szinte biztosan több példányban fog futni, párhuzamos terheléselosztott környezetben, azaz fel kell készülnünk az állapotmentes, tranzakcionális viselkedésre.
• Fájlrendszer és SQL szerver mellett megjelenik az Azure Storage, mint perzisztencia tároló, az alkalmazás tervezésekor ezt az alternatívát is figyelembe kell venni.
• Az alkalmazás konfigurációja (*.config) telepítés után adminisztrátorok számára nem hozzáférhető, tehát az olyan beállításokat amiket változtatni kell, az Azure platform role configuration-jébe kell kiemelni.
• A felhőben az autentikáció és autorizáció megoldások is eltérnek a megszokottól.

…és még folytatható akármeddig. Javaslom, hogy megjegyzésbe írjátok meg ti is, mik azok a különbségek amik számotokra fontosak, aztán később esetleg szerkesztett cikket is készíthetünk, amiben alaposabban körbejárjuk az egyes témákat.

Command-Query Responsibility Segregation – Egy érv az Azure Table Storage mellett?

A június 15.-i azure klub keretében előkerült a SQL Azure vs Table Storage kérdés, a kettő között felállítható párhuzam (ha létezik egyáltalán ilyen), valamint egyáltalán a NoSQL megoldások létjogosultságának és használhatóságának kérdése. Akik ott voltak a találkozón emlékezhetnek, hogy valódi érveket nehezen sikerült felhoznunk a Table Storage mellett, inkább csak megérzéseket: ha a megoldásunk nem igényli a relációs adatbázisok által nyújtott szolgáltatásokat, ám szükség van valamilyen perzisztálásra. E gondolat mentén elindulva jutottam el a „Command-Query Responsibility Segregation (CQRS)”-ig, még inkább a témával foglalkozó blog oldalakig.

Ezen oldalakról összeszedett gondolatokat rendszereztem kicsit, melyek teljes megértéshez mindenképpen szükséges a CQRS legalább átfogó ismerete, amiről innen kiindulva itt olvashattok, ám ezen ismeretek nélkül is értelmezhető.

A CQRS mögötti legegyszerűbben megfogható szándék, hogy szeparáljuk az adatok megváltoztatását (command) az adatok lekérdezésétől (queries). Ezen egyszerű döntés a klasszikus alkalmazás architektúrákra nézve magával hoz pár változtatást és lehetőséget. Melyek eredményeképp a CQRS kultusz valójában fejlesztési elvek, minták és ajánlások együttese, mellyel extrémen skálázható és robosztus, magas üzleti értékkel rendelkező alkalmazásokat tervezhetünk.

Elévült adatok

Általános, hogy alkalmazásainkban több szereplő (konkrét felhasználó, vagy automatizált folyamat) párhuzamosan fér hozzá írásra/olvasásra adatok ugyanazon köréhez. Elévült adatról (Stale Data) beszélünk akkor, ha miután az egyik szereplőnek megmutattunk egy információt, a lekérdezést követő pillanatban egy másik szereplő ezt információt megváltoztatta. Így tehát nem feltétlenül bízhatunk az első szereplő döntéseiben (módosításaiban), hiszen azokat olyan információkra alapozta melyek közben elévültek.

Standard architektúráinkban e problémát legtöbbször explicit nem is kezeljük, helyette relációs adatbázisba pakoljuk adatainkat, és rá bízzuk a konkurenciakezelést. A CQRS ezzel szemben azt állítja, hogy az adatoknak mindig aktuálisnak (staleness) kell lennie (legalábbis közel aktuálisnak), így explicit módon szükséges kezelni a konkurencia kérdését. Akkor miért is van szükségünk tranzakciós adatbázisra?

Lekérdezések (Queries)

Adatainkat a relációs adatbázisokban n.-ik (n>=2) normálformában tároljuk, majd ezeket képezzük le az üzleti modellünkre. Az adatokon kívül másra nincs szükségünk, így felesleges a relációs adatbázisok minden megszorítása és tárolási szabálya. Majd ezen üzleti modellt tovább transzformáljuk DTO-kra (Data Transfer Objects), hogy hálózaton keresztül továbbíthatóak legyenek. Elég csak a WCF DataContract-jaira gondolnunk. Az MVC minta elterjedésével pedig modellünket végül leképezzük a „view model” objektumaira. Rengeteg (felesleges?) munka, mindez az újrahasználhatóság jegyében!

Készítsünk helyette egy extra adattárat, elvégre az adataink úgyis mindig aktuálisak! Miért ne lehetne eleve a view model reprezentálva ebben a tárban? Egy tábla minden view-hoz. Alkalmazásaink egy egyszerű „select * from myviewtable” lekérdezéssel megjeleníthetnék aktuális felületüket. Gondoljunk ebbe bele egy kicsit! Nincsenek relációk az egyes view model-ek között, a kapcsolatot maximum egy „where” feltételben megfogalmazott elsődleges kulcs jelenti, azaz nincs szükségünk a relációkra az adattárolás oldalán sem! Sőt, semmi akadálya, hogy akár több tárunk is legyen a lekérdezések számára, megteremtve az extrém skálázhatóság egy újabb eszközét!

Módosítások (Commands)

A CQRS egyik legfontosabb pontja a felhasználói felületek újragondolása. Módosításainkat parancsokba szervezve, a modellen történő közvetlen módosítás helyett, újra kell gondolnunk, hogy mely párhuzamos műveleteket engedjük meg és melyeket utasítjuk vissza. Példaként egy partner nevének, vagy címének módosítása minden további nélkül megtörténhet párhuzamosan, sőt ugyanazon partner státuszát is bátran módosíthatjuk. Minden parancs esetén explicit módon szabályozva döntünk arról, hogy mely további parancsok feldolgozását engedjük. Minél nagyobbak entitásaink, minél több attribútummal rendelkeznek, annál nagyobb az esélye, hogy a standard architektúrákban ütközésre kerül sor, ezáltal frissítésre és a művelet megismétlésére kényszerítve a felhasználót. A módosítások „command”-okba szervezésével akár azt is megtehetjük, hogy ugyanazon szereplő újabb módosítást kérjen mielőtt az előző sikerességét egyáltalán visszajeleztük. Egy módosítás sikertelensége esetén pedig egyszerűen értesítjük a felhasználót az adott parancs sikertelenségéről, és ő dönthet a szükséges lépésekről.

Mint láthattuk a parancsainkat nem szükséges azonnal feldolgozni, várakozási sorba (Queue) pakolhatóak. A feldolgozás sebessége innentől nem architektúrális, hanem „SLA” kérdése. Mi több, parancsainkat kategorizálva külön-külön várakozási sorok alakíthatóak ki. Nagyobb terheltség esetén csak a szükséges parancsfeldolgozók számának növelésére van szükség.

Mivel módosításainkat ilyen módon külön tároljuk a lekérdezésektől és a modelltől, több lehetőség is megnyílik előttünk. Tárunkhoz való hozzáférés optimalizálását explicit módon szabályoztuk, csökkentve a rendszer érzékenységét a tár hibáira, a felhasználónak nem is kell értesülnie a felmerülő problémákról. Nincs is szükségünk a relációs adatbázisoktól megszokott tranzakcionalitásra, deadlock kezelésre.

Az üzleti modell

A CQRS elvei nagy hatással vannak alkalmazásaink üzleti modelljére is. Semmi sem követeli meg tőlünk, hogy különböző parancsainkat ugyanazon üzleti modellen értelmezzük. A másik oldal pedig, hogy immár nem az üzleti modellünkön fogalmazzuk meg a lekérdezéseket, így nincs szükség az egyes entitások közötti relációk nagy számosságára. Modellünk szeparálhatóvá válik, az egyes részek akár eltérő implementációval is megadhatók. A modellünkön értelmezett ilyen
egyszerűsítések bevezetésével az „aggregate root” entitások relációi akár meg is szüntethetőek. Senki sem fogja a modellünkön lekérdezni egy partner rendeléseit (Partner 1 – * Orders), a kapcsolatok egyszerű ID kapcsolatokra vezethetők vissza, melyek szükség esetén feltölthetőek, hisz a felhasználói felület megjelenését nem lassítják. Ezt az ID-t pedig a parancsaink hordozzák.

Ilyen formában parancsaink egyetlen entitáson értelmezhetőek lesznek, a relációs adatbázisok tábla
szerkezete is fölöslegessé válhat, valós alternatívává téve számunkra a felhő platformok kulcs-érték típusú table storage megoldásait.

Felhő plattform

Alkalmazásaink újragondolásával és a CQRS alkalmazásával a választott technológiáktól sokkal függetlenebbül
koncentrálhatunk tisztán az üzleti igényekre, úgy hogy élvezzük az alábbi előnyöket:

• Közel végtelen skálázhatóság
• Komplex problémák is modellezhetőek a fejlesztési komplexitás növekedése nélkül
• Más rendszerekkel való integráció jóval szabadabb foka
• Robosztus, hibatűrő és tervezetten konkurens alkalmazás
• Kiaknázhatjuk a felhő platform nyújtotta szolgáltatások előnyeit

Egy lehetséges referencia cloud platformra szánt architektúra az alábbiakból építkezhet:

• CQRS
• DDD
• Üzenet alapú architektúra, Message Queuing
• Service Bus és Event Sourcing
• NoSQL tárolás, Azure Storage

Természetesen ez nem jelenti azt, hogy felhőre minden alkalmazást így éri meg elkészíteni, mindig az aktuális követelmények határozzák meg a szükséges architektúrát és implementációs technológiát, ám remélem a lehetőségek egy újabb halmazát sikerült ezzel a kis gondolatébresztővel számotokra megvilágítani.

Forrásanyagok:

• http://abdullin.com/cqrs/
• http://abdullin.com/journal/2010/11/3/cqrs-architecture-and-definitions.html
• http://www.udidahan.com/2009/12/09/clarified-cqrs/

Ha valakinek akár a CQRS-el kapcsolatban, akár a CQRS és a felhő platformok lehetséges előnyeivel és hátrányaival kapcsolatban kérdése van, esetleg érdekelné példa architektúra és implementáció az írjon bátran a megjegyzések közé, vagy keressen email-ben az ersek.attila@hotmail.com címen.