Na most érkezett el a délután, mert nagy ravaszul, azt ugye nem írtam, hogy melyik déluán...

A cloudról sokan, sokmindent írnak, az egész már tisztára olyan mint a foci. Ráadásul, ahogy az a magyar focival van, több az ellendrukker, mint a drukker. Az április igazi cloud szenzációja nem valami nagy bejelentés volt, hanem az AWS leállása (erről egy külön posztban majd megemlékezünk, most hogy már kijött az amazon saját post-mortemje, ha lesz mit tanulságként levonni).

Persze a net most tele van beszámolókkal az eseményről, kommentárokkal stb. Egy ilyen felhasználói élménybeszámolót olvastam, ahol egy prémium supportot vásárolt ügyfélnek nem válaszolt az AWS, ő meg az amazon forumon próbált segítséget kérni. Korábban meg Greg Hoglundtól olvastam, hogy mennyire nem sikerült neki a Google technikai emberekkel beszélnie.

És itt van a rejtélyes kapcsolat Beth, Char, Gerben és jelent cikk között. Mert már régóta foglalkoztat egy lehetséges valódi különbség a cloud és a belső IT között. Vagy nem is itt a határvonal, hanem talán a utility computing és belső IT vagy outsource IT között.

A leggyakoribb érv a cloud-dal szemben és a belső/outsource-olt IT mellett, hogy nincs kontroll az előbbi esetén. Az utóbbinál a kontroll alatt általában nem a szerződéses kikötések állnak (hiszen már rég rossz ha a két fél a bíróság előtt vitatkozik), hanem a napi gyakorlatban hatásos és működő informális kontrollok: odamegyek a belső IT-shoz és leüvöltöm a fejét, írok egy anyázós levelet a közös főnöknek, felhívom a szolgáltató szolgáltatásmenedzserét, ügyvezetőjét, odamegyek a mérnökéhez és leüvöltöm a fejét stb. Egyik-másik módszer nem elegáns, de már hallottam szolgáltatótól, hogy egy hiba után a másik földrészen lévő ügyfél vezérnél kellett személyesen a szőnyeg szélén állva vezekelni. Tehát hatásos lehet.

A  utility computing középpontjában nem az olcsóság van. A cloud computing arról szól, hogy sztenderidizált módon nyújtanak nagy tömegben IT szolgáltatást, ami így olcsóbb tud lenni továbbegyenlő nekünk is olcsóbb lesz. Ez egy nagyon jó modell mert már most is egészen új perspektívákat nyújt, és még csak kezdjük tanulni az egészet.

De ennek az előre gyártott dobozoknak van (vagy lehet) egy bújtatott ára is. Ha igazán szükségem van a szolgáltatóra, akkor a személyes támogatás, amit kapok az utility alapú vagy sem. Vagyis számomra a utility computing utility customert jelent?

A utility customer az egyenlet másik oldala. Addig értjük és mindenki számára világos talán, hogy az IT erőforrás számunkra utility (ami a filléres, eldobható, egy a sok közül szinonímája), de a utility customer esetében mi felhasználók is egy filléres (a teljes bevételhez képest), eldobható (nem megy a cloud szolgáltató tönkre ha elmegyünk máshoz), egy a sok közül (az össz felhasználóhoz képest) ügyfelek vagyunk. Ha pedig ez így van, akkor a szolgáltató más szintű kiszolgálást tervez és működtet természetesen (üzleti) kockázatokkal arányosan. A fenti esetek alapján bennem felmerült a gyanú, hogy a szolgáltatók meghozták a döntésüket: a utility computing egyenlő utility customer.

Ez a gyakorlatban előre dobozolt SLA-kat, első, másod, harmadszintű támogatókat és ahogy láttuk az előző cikkben programozott ágenseket jelent. Ez az esetek legtöbbjében azért elég nekünk, ahogy a lakásbiztosítás sem életbe vágó egészen addig, amig be nem törnek valakihez. Mert akkor viszont nem egy IVR rendszerrel szeretnénk társalogni. Ha megvan a baj, ahogy láttuk, elég hamar szembe találhatja magát a felhasználó a utility computing árnyoldalával a utility customerrel.

Ez azért baj nekünk IT biztonságiaknak, mert az IT biztonságban külön eljárás szokott vonatkozik a normál működés esetén követendő eljárásokra és azokra, amiket baj esetén követünk. Ez utóbbit úgy hívjuk magyarul incidenskezelési szabályok.

Az tisztán látszik, hogy ez egylőre a szolgáltatóknak nem erős oldaluk: utility customerek vagyunk minden helyzetben.

-- Tiborcz József