Azure fejlesztői konferencia, december 13.

Az év utolsó fejlesztői konferenciáját – legalábbis ez lesz az utolsó, ami a Windows Azure platformmal foglalkozik – december 13-án, Luca napján tartjuk. Három dolog miatt is megéri majd eljönni:

  • Vadonatúj felhőszolgáltatásokat ismertetünk majd, annyira újakat, hogy maga a "nagy" Microsoft is csak az előző hétvégén rántja le a leplet róluk – ezért aztán a napirendben egyelőre nem is oszthatunk meg minden részletet.
  • Gyakorlati megoldásokat mutatunk be, gyakorló fejlesztők közreműködésével – olyan problémákra keressük a választ, amelyek a legtöbb felhőprojektben előbb-utóbb felbukkannak majd.
  • Értékes szakkönyvet adunk minden résztvevőnek.

Ami a könyveket illeti, választási lehetőség is van (mármint az időben érkezőknek; aki késik, azt kapja, amiből még maradt):

A konferencia fizetős, a részvétel díja 5000 Ft (ez kevesebb, mint a fenti könyvek bármelyikének ára). Regisztrálni ezen a weblapon lehet, a jelentkezőkkel e-mailben vesszük fel a kapcsolatot. Adatok az átutaláshoz: Szilke Kft., OTP Bank: 11703006-20249472 (kapcsolattartó: Mikecz Dalma, szilke(kukac)t-email.hu).
A tervezett napirend:

09:00-10:20  A Windows Azure platform decemberi újdonságai
Nem mondhatunk el mindent, különben hova lenne a meglepetés – de annyi már kiszivárgott, hogy a Microsoft jelentős mértékben leegyszerűsíti a regisztráció, az előfizetés-kezelés és a számlázás folyamatát. Az előfizetők költségplafont állíthatnak be (hogy az ingyenes előfizetés tényleg ingyenes legyen), valós időben követhetik az erőforrások használatát és számlájuk alakítását, és sokkal áttekinthetőbb, jobban kezelhető portált kapnak. Vannak persze technikai újdonságok is – ezekről majd inkább élőben számolunk be!

10:20-10:40  Szünet

10:40-11:20  Felhőalkalmazások automatikus skálázása
Ha felhőalkalmazásunk terhelése kiszámítható minta szerint alakul, előre meghatározhatjuk, melyik időpontban hány virtuálisgép-példányra lesz szükségünk. Ha viszont váratlan csúccsal kell szembenéznünk, jó lenne, ha maga az alkalmazás reagálna a megnövekedett igényekre – természetesen az általunk előírt logika szerint. Ezekre a követelményekre kínál megoldást a Microsoft patterns & practices csapata által december elején kiadott Autoscaling Application Block, amely egyszerűen beilleszthető felhőprojektünkbe – az előadásban bemutatjuk használatát.

11:20-12:00  Robusztus felhőalkalmazások készítése
A felhőplatformban, akárcsak az internetes fejlesztéseknél, előfordulhatnak tranziens jelenségek – a hálózat túlterhelt, ezért egy webszolgáltatás később válaszol, mint azt alkalmazásunk várná, és máris hibajelzést kapunk. Az orvosság az ilyen esetek rugalmas kezelése, például egy jól időzített ismétlés. A Microsoft patterns & practices csapatának egy másik friss terméke, a Transient Fault Handling Application Block kulcsrakész eszközt ad a fejlesztő kezébe – demonstráljuk használatát.

12:00-12:40  Ebédszünet

12:40-13:20  Federált hitelesítés a felhőben
Az üzletmenet szempontjából kritikus adatok és alkalmazások, amelyeket a vállalatok a saját adatközpontjukban tartanak, ritkán érhetők el külső felhasználók számára. A Windows Azure felhőplatform megoldást kínál egy ilyen kapcsolat biztonságos megvalósítására. Az eszközök: federált hitelesítés, hozzáférés-vezérlés és szolgáltatásbusz. Az előadásból kiderül, milyen gyakorlati lépések szükségesek egy nyitott, mégis jól védett környezet kialakításához.

13:20-14:00  Adatszinkronizálás ég és föld között
Ha elosztott adatbázisokra épülő megoldást szeretnénk létrehozni, a hagyományos út egy közzétevőkből és előfizetőkből álló replikációs rendszer kialakítása. Hogyan képezhetjük ezt le a felhőben, milyen eszközeink vannak az egyszerűen menedzselhető adatszinkronizációs megoldás megvalósítására? Az előadás bemutatja ennek folyamatát, és arra is kitér, hogyan hozzunk létre olyan alkalmazást, amely franchise jellegű üzleti modellt támogat.

14:00-14:20  Szünet

14:20-15:00  Mobilalkalmazások felhős háttérrel
Egyre több mobilalkalmazás épít valamilyen háttérszolgáltatásra – közösségi hálózatok és más hitelesítésszolgáltatók segítségével azonosítják a felhasználóikat, adatokat tárolnak, alkalmazásokat futtatnak a felhőben. A Windows Azure platform valamennyi három okostelefon-operációs rendszerhez, az Androidhoz, az iOS-hez és a Windows Phone 7-hez is elérhetővé tett egy-egy fejlesztői csomagot – mi most ez utóbbival foglalkozunk, konkrét példákat mutatunk az okostelefon és a felhő együttműködésére.

15:00-15:40  Piactér-támogató megoldások a felhőben
A Windows Azure Marketplace Magyarországról is elérhető, de más piactér-megoldásokat is érdemes megismerni, ha kereskedelmi célú alkalmazást készítünk. Ezen az előadáson (amelynek megtartása egyelőre még nem száz százalékban biztos) egy hazai partner mutatja be más fejlesztők számára is érdekes, készülőben lévő termékét.

15:40-16:00  Kérdések és válaszok

Mindenkit várunk a rendezvényen – továbbra is irány a felhő!

Reklámok

Windows Azure hírek: Egyszerűsített regisztráció, előfizetés-kezelés és számlázás

Sziasztok!

A hétvégén egy levelet kaptam a Windows Azure Platform Team-től, melyet a fontossága miatt osztanék meg veletek (változatlan formában). Azok akik nem kaptak ilyet, vagy lemaradtak róla, így szintén értesülhetnek a klub alkalmával többször is felmerült igényekre adott válaszról.

Tehát a levél:

“A  visszajelzések alapján számos fejlesztést hajtunk végre a Windows Azure élmény  fokozása érdekében.   Szeretnénk  kihasználni a lehetőséget, hogy tájékoztassuk a várható változásokról.

Főbb  pontok:

  • Egyszerűsített  regisztrációs folyamat:
    • Hozzon  létre új előfizetéseket 3 egyszerű lépésben
    • Használja  ki az új költségkorlátozás  lehetőségét, amely az új, 90 napos ingyenes  próbaverzióban és az új, MSDN előfizetésekben érhető el többletfelhasználási  díjak nélkül.
  • Rugalmas  előfizetés-kezelés:
    • Vegye fel  vagy frissítse előfizetéseit gyorsan
    • Váltson a  konstrukciók között egyszerűbben
    • Mondja le a  szükségtelen előfizetéseket közvetlenül a Windows Azure Management portálból
  • Fejlett  számlázási lehetőségek:
    • Valós idejű  hozzáférés a használattal és számlázással kapcsolatos adatokhoz közvetlenül a  Windows Azure Management portálból
    • A számlázás  minden hónapban ugyanakkor történik, az előfizetések számától függetlenül
    • Egyszerűbb,  összesített számla

A Windows  Azure használatát segítő ezen új lehetőségek (pl. költségplafon, valós idejű  hozzáférés a használati és terhelési adatokhoz) bevezetésével egy időben megszüntetjük  a havi értesítéseket a konstrukcióban foglalt számítási órák 75, 100 és 125  százalékának (vagy a 3 hónapos összesített átlag azon ajánlatok esetében,  amelyekben nincsenek számítási órák) elérésével kapcsolatban.

A bevezetés  közeledtével meg fogjuk adni a frissítések pontos időpontját, valamint közöljük  majd a további részleteket.  A tervezett  frissítés során a számlázási rendszer rövid ideig nem lesz elérhető egy hétvégi időpontban – ez kevesebb  mint 24 órát igényel majd a kezdéstől a befejezésig. A frissítési folyamat  során nem tud majd új előfizetéseket felvenni, ám a folyamat nem érinti a  futtatott Windows Azure alkalmazásokat.

Örömmel vezetjük be ezeket a  fejlesztéseket azon elkötelezettségünk részeként, amelynek keretében szeretnénk  Önnek rugalmas, könnyen használható felhő alapú platformot biztosítani. Lépjen velünk kapcsolatba, ha bármilyen kérdése van a  frissítésre vonatkozóan.

A Windows Azure csapata Microsoft Corporation”

Szerintem a pontok magukért beszélnek, a költségkorlátozás és az egyszerűsített előfizetés menedzsment pedig minden fejlesztő álma!

Konfigurációkezelés a felhőben?

Amint egy előző cikkben említettem, ahhoz, hogy az alkalmazásunk a felhőben működhessen, bizonyos dolgokat máshogy kell megvalósítani, mint a hagyományos .NET fejlesztés során. Ezek közül elsőnek a konfigurációról írok.

Hagyományos, “földi” alkalmazásnál a konfigurációt jellemzően *.config fájlokban tároljuk. Ezekben a rendszergazdák tudják állítgatni a rendszer paramétereit, így rugalmassá tehető az alkalmazás használata. Például a kapcsolódó rendszerek elérési adatait vagy az adatbázis connection stringet nem kell a programba beégetni, megváltoztathatók lesznek az alkalmazás újratelepítése nélkül. Vagy vehetjük példának a naplózási szintet, amit hibakereséshez felemelhetünk (gyakran konfig állományban megadva azt is, hogy hová kerüljön a részletes napló).

A könnyű szerkeszthetőség megszült néhány mintát is, mikor a program működését is konfigurációs beállításokkal írjuk le. Például az objektumok összedrótozását vezénylő dependency injectiont, vagy a működést megvalósító plugin osztályok elérési útvonalát emeltük ki. Vagy a beégetett konstansokat vezettük ki, hogy hibakeresésnél a program működésének “tweakelése” egyszerűsödjön. Ez a fajta paraméterezhetőség nem az adminisztrátoroknak fontos, inkább a fejlesztők életét könnyíti meg, a tesztelhetőséget, támogathatóságot segíti.

Az Azure platformon ez kicsit máshogy viselkedik. A konfigurációs fájlok ugyan megmaradtak az összes fenti lehetőséggel, de azok a telepítés során a használt dll-ekkel együtt a .cspkg fájlba kerülnek (ez az a csomag, amit verzióváltásnál feltöltünk a felhőbe, de ott a tartalma az adminisztrátorok számára hozzáférhetetlen, módosíthatatlan lesz). Azaz van konfigurációnk, csak azt nem lehet megváltoztatni.

Persze ez nem gonoszságból van így, sokkal inkább biztonsági megfontolás. A titkosított csatornán feltöltött, digitális aláírással védett csomag garantálja azt, hogy a felhőben futó alkalmazás ugyanaz lesz, mint amit mi telepíteni akarunk. Kizárja a menet közbeni belepiszkálás lehetőségét, és az új alkalmazáspéldányok indításakor is garantálja, hogy a feltöltött kód változatlanul kerüljön telepítésre.

Valamilyen szintű konfigurálhatóságot enged az Azure platform ugyan a role configuration-on keresztül (ez a .cscfg fájl, amit szintén fel kell töltenünk telepítéskor), de ez elsősorban a feltöltött alkalmazás példányainak beállítását szolgálja. Azaz főleg arra van kihegyezve, hogy mekkora és hány virtuális gépen fusson, telepítéskor milyen extra lépéseket kell beállítani, hogyan történjen a diagnosztikai naplók publikálása, stb., és csak ezek mellett, kiegészítő lehetőségként szerepel, hogy egy egyszerű név-érték listában saját beállításokat adhassunk át az alkalmazáspéldányoknak.

Azaz szükség lehet az Azure konfiguráció kiterjesztésére. Jó lenne, ha olyan megoldást találnánk, ami transzparens (azaz nem csak felhőben, hanem helyi telepítéseknél is működik, sőt, a megszokott ConfigurationManager osztállyal analóg), támogatja az adminisztrátorok általi szerkeszthetőséget, ugyanolyan kifejezőereje van mint a megszokott .config fájloknak, de emellett azért biztonságos, és egyszerűen használható.

Gyári komponenst, ami ezt tudja, egyelőre nem találtam, így saját fejlesztéssel estem neki a megoldásának. A következő postban ezt mutatom majd be.

Több felhasználó adatai egy adatbázisban, sémánként szétválasztva–de hogy írjunk ehhez programot?

Azure alkalmazások írásakor természetes igény, hogy egy alkalmazáspéldányból több felhasználót is kiszolgáljunk (azaz több-bérlős alkalmazást készítsünk). Ennek egy fontos vonatkozása, hogy a felhasználók adatait is egymástól szétválasztva kezeljük. Ennek talán legjobb megoldása a SQL séma-alapú szétválasztás, azonban a modern adathozzáférési módok (pl. Entity Framework) ezt nehézkesen kezelik. Ebben a bejegyzésben ezt a problémát hidaljuk át.

olvasásának folytatása

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:

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.

Fixdíjas Azure csomag és a számlázás

A fix havidíjas Azure előfizetői csomagok (pl. bővített fejlesztési gyorsító alapkészlet az esetemben) kiváló lehetőséget adnak, hogy belekezdjünk az Azure használatába, vagy Azure fejlesztésbe, mivel jelentős kedvezményt adnak a normál, használat alapú díjazáshoz képest. Érdemes azonban alaposan átnézni a konstrukciót, mert – szokás szerint – a részletekben rejlik a lényeg! Én – eddig – a következő meglepetésekre futottam rá:

  • Több előadáson is elhangzott, hogy a Compute számlázását a kis méretű gépre vezetik vissza, a többi gépméret ennek valahányszorosa. Nos, ez igaz is, kivéve a nagyon kicsi példány esetében, ami ettől független. Én erre nem számítottam, és a publikált alkalmazás konfigurációjában nagyon kis példány volt megadva. Ennek az a következménye, hogy hiába van az előfizetésben egy kis példány egész havi futtatásának az ára, minden egyes órát, amíg a nagyon kis példány futott, kiszámláztak, mert az nem számítható át a kis példányra.
  • Új SQL Azure adatbázis létrehozásakor az alapbeállítás az 1 GB méretű Web edition. Én úgy voltam vele, hogy az előfizetésben van 10 GB business adatbázis, de az 1 GB-os is elég az aktuális célnak, akkor meg minek módosítsam? A választ itt is a számlázás hozta meg. Azért kellett volna módosítanom, mert Web adatbázis nincs az előfizetésben, azzal meg nem foglalkoznak a számla összeállításkor, hogy ennél nagyobb viszont van. A végeredmény itt is az lett, hogy hiába van adatbázis is csomagban, mégis kiszámlázták a felhasználást, mert a csomagban foglaltnál kisebb szolgáltatást vettem igénybe.

Az első jelenségre találtam is konkrét magyarázatot a konstrukció leírásában, a másodikra ugyan nem, de a tapasztalat ezt mutatja.

Összefoglalva: attól, hogy látszólag kevesebbet használunk, mint amire a csomagunk szól, még lehet, hogy többet kell fizetnünk. Figyeljünk oda a konstrukció leírására, illetve nézzünk rá időnként a felhasználási adatainkra, hogy időben észrevegyük, ha valami olyat fogyasztunk, amire nem számítottunk!