A számítási teljesítmény növekedése és az x86 virtualizációs technológia fejlődése egyfelől, valamint az IT kiszervezés elterjedése másfelől vezetett a utility computing (IT mint közszolgáltatás) koncepciójához. Miért ne lehetne az IT-t olyan módon fizetni, mint a vizet vagy az áramot – csak annyit és akkor, amikor szükség van rá, és nem többet?
Ekkor jelent meg a felhőalapú számítástechnika koncepciója – az IT szolgáltatások fogyasztása az „éből”, azaz egy külső erőforrás-készletből, anélkül, hogy aggódnánk amiatt, honnan és hogyan származnak ezek az erőforrások. Ahogyan nem aggódunk a vízművek szivattyúállomásainak infrastruktúrája miatt. Ekkorra a koncepció másik oldalával is foglalkoztak, nevezetesen az IT szolgáltatások fogalmával és azok kezelésével az ITIL / ITSM keretein belül.
Kifejlesztettek egy sor definíciót a felhőkről (felhőalapú számítástechnika), de ezeket nem szabad végső igazságként kezelni – csupán eszköz a utility computing nyújtásának formális keretezésére.
- "A felhőalapú számítástechnika egy olyan elosztott adatfeldolgozási technológia, amelyben a számítógépes erőforrások és kapacitások internetes szolgáltatásként kerülnek a felhasználóhoz" - Wikipédia
- "A felhőalapú számítástechnika egy modell, amely kényelmes hálózati hozzáférést biztosít a közös, konfigurálható számítási erőforrások (például hálózatok, szerverek, adatraktárak, alkalmazások és szolgáltatások) készletéhez, amelyek igény szerint gyorsan kioszthatók és biztosíthatók minimális kezelés mellett vagy minimális beavatkozással a szolgáltató részéről" - NIST
- "A felhőalapú számítástechnika egy paradigmaszemlélet a skálázható és rugalmas elosztott fizikai vagy virtuális erőforrások, amelyek önkiszolgáló módon és igény szerint kezelhetők, hálózati hozzáférésének biztosítására" - ISO/IEC 17788:2014. Információs technológia — Felhőalapú számítástechnika — Áttekintés és szókincs.
A NIST szerint három alapvető felhőtípus létezik:
- IaaS – Infrastructure as a Service — Infrastruktúra mint szolgáltatás
- PaaS – Platform as a Service — Platform mint szolgáltatás
- SaaS — Software as a Service — Szoftver mint szolgáltatás
A különbség nagyon egyszerűsített megértéséhez nézzük meg a Pizza-as-a-Service modellt:
A NIST a felhőalapú IT szolgáltatásként való elismeréshez szükséges IT szolgáltatásokat a következőképpen definiálja.
- Univerzális hálózati hozzáférés (broad network access) – a szolgáltatásnak univerzális hálózati interfésszel kell rendelkeznie, amely lehetővé teszi a szolgáltatás csatlakozását és használatát gyakorlatilag bárki számára minimalizált követelmények mellett. Például ahhoz, hogy használhassuk a 220V-os elektromos hálózatot, elegendő csatlakozni bármelyik szabványos univerzális interfésszel ellátott konnektorhoz (dugó), amely nem változik attól függően, hogy vízforralót, porszívót vagy laptopot csatlakoztatunk.
- A szolgáltatás mérhetősége (measured service) – a felhőszolgáltatás kulcsfontosságú jellemzője a szolgáltatás mérhetősége. Ha a villamos energiára hasonlítunk – pontosan annyit fogunk fizetni, amennyit fogyasztottunk a minimális részletességgel, egészen a költségekig, amelyek egy vízforraló egyszeri felforralásához kapcsolódnak, ha az egész hónapban egyszer voltunk otthon és egy csésze teát ittunk.
- Önkiszolgáló konfigurálás igény szerint (on demand self service) – a felhőszolgáltató lehetőséget biztosít az ügyfél számára ésszerű konfigurálásra, anélkül, hogy a szolgáltató alkalmazottaival kellene kapcsolatba lépni. Ahhoz, hogy felforralhassuk a vizet, nem szükséges előre kapcsolatba lépni az Energiaszolgáltatóval, majd figyelmeztetni és engedélyt kérni. Azt követően, hogy a ház csatlakoztatva van (szerződést kötöttünk), minden fogyasztó szabadon használhatja a rendelkezésre álló teljesítményt.
- Azonnali rugalmasság (rapid elasticity) – a felhőszolgáltató olyan erőforrásokat biztosít, amelyek lehetővé teszik a teljesítmény azonnali növelését / csökkentését (meghatározott ésszerű keretek között). Amint a vízforralót bekapcsoltuk – a szolgáltató azonnal 3 kW teljesítményt biztosít a hálózatban, és amint kikapcsoltuk – csökkenti a kibocsátást nullára.
- Erőforrások egyesítése egy poolban (resource pooling) – a szolgáltató belső mechanizmusai lehetővé teszik az egyes termelő kapacitások egy közös poolra (medencébe) történő egyesítését, amelynek keretében az erőforrásokat különböző fogyasztók számára szolgáltatják. Beleértve a vízforralót, a legkevésbé érdekel minket, hogy melyik konkrét erőműből érkezik az energia. És minden más fogyasztó együttesen használja ezt az energiát velünk.
Fontos megérteni, hogy a fent bemutatott felhőjellemzők nem a levegőből lettek leválasztva, hanem a utility computing koncepciójából logikusan következnek. A nyilvános szolgáltatásnak ezekkel a jellemzőkkel kell rendelkeznie a koncepció keretein belül. Ha bármelyik jellemző nem felel meg, az szolgáltatás nem lesz rosszabb, és nem válik „mérgezővé”, csupán nem lesz felhőalapú. Ki mondta, hogy minden szolgáltatásnak ilyen formában kell lennie?
Miért említem ezt külön? Az NIST definíciójának megjelenése óta eltelt 10 év során sok vita folyt a valódi felhőalapú megoldásokról a definíciók szerint. Az Egyesült Államokban a bírósági eljárások során néha használják, hogy "megfelel a törvény szövegének, de nem a szellemének" — és a felhőalapú számítástechnika esetében az alapelvek a lényeg, az erőforrások egy kattintással bérelhetők.
Meg kell jegyezni, hogy a fent említett 5 jellemző a nyilvános felhőre vonatkozik, azonban amikor a magánfelhőre térünk át, a többsége opcionálissá válik.
- Széleskörű hálózati hozzáférés (broad network access) – a magánfelhő keretein belül a szervezet teljes mértékben ellenőrzi mind a generáló kapacitásokat, mind a fogyasztókat. Így ezt a jellemzőt automatikusan teljesítettnek tekinthetjük.
- A szolgáltatás mértékletessége (measured service) – ez a utility computing koncepciójának kulcsfontosságú jellemzője, ahol a kifizetés a fogyasztás ténye alapján történik. De hogyan fizet egy szervezet saját magának? Ebben az esetben a generálás és a fogyasztás elkülönül a vállalaton belül, az IT-provideré válik, míg az üzleti részlegek a szolgáltatások fogyasztói. A részlegek közötti elszámolás történik. Két működési mód lehetséges: chargeback (valódi elszámolások és pénzmozgás esetén) és showback (a felhasználás jelentéseként rubelben, de pénzmozgás nélkül).
- Kérésre önálló szolgáltatáskonfigurálás (on demand self service) – a szervezet belső IT-szolgáltatással rendelkezhet, és ebben az esetben a jellemző értelme megszűnik. Azonban, ha saját IT-specialisták vagy alkalmazásadminisztrátorok vannak az üzleti részlegekben, akkor szükség van egy önkiszolgáló portál létrehozására. A következtetés – a jellemző opcionális, és a vállalat struktúrájától függ.
- A gyors rugalmasság (rapid elasticity) – a szervezet keretein belül értelmét veszti, mivel a privát felhő számára a berendezések fix készletét alkalmazzák. Korlátozottan alkalmazható belső elszámolások keretében. Következtetés – a privát felhőre nem alkalmazható.
- Az erőforrások egyesítése egy poolban (resource pooling) – manapság gyakorlatilag nem létezik olyan szervezet, amely ne alkalmazna szerver virtualizációt. Ennek megfelelően ezt a jellemzőt automatikusan teljesítettnek lehet tekinteni.
Kérdés: Mi is ez a privát felhő? Mit kell a cégeknek megvásárolniuk és bevezetniük a létrehozásához?
Válasz: a privát felhő egy új adminisztratív modellre való áttérést jelent az IT-Business együttműködésében, amely 80%-ban adminisztratív intézkedésekből és csupán 20%-ban technológiákból áll.
Csak a használt erőforrásokért való fizetés és a könnyű belépés, anélkül, hogy több százmillió dollárt kellene befektetni a tőkeköltségekbe, új technológiai tájat teremtett és milliárdos cégek megjelenéséhez vezetett. Például a modern óriások, mint a Dropbox és az Instagram, az AWS-en induló startupokként jelentek meg, nulla saját infrastruktúrával.
Fontos kiemelni, hogy a felhőszolgáltatások kezelésére szolgáló eszközök jelentősen közvetítettebbé válnak, és az IT igazgató kulcsfontosságú feladata a szolgáltatók kiválasztása és a minőség ellenőrzése. Tekintsük át e két új kötelezettség problémáit.
Az önálló adatközpontokkal és hardverekkel szembeni klasszikus alternatívaként megjelenő felhők megtévesztően könnyűek. Könnyen beléphetünk a felhőbe, de a kilépés kérdése általában elkerüli a figyelmet. Mint minden más iparágban, a felhőszolgáltatók törekednek a biztonság megvédésére és a verseny bonyolítására. Az egyetlen komoly versenyhelyzet csak a felhőszolgáltató elsődleges kiválasztásakor merül fel, ezt követően a szolgáltató mindent megtesz, hogy az ügyfél ne távozzon. Ráadásul nem minden erőfeszítés a szolgáltatások minőségére vagy választékára összpontosít. Elsősorban egyedi szolgáltatások nyújtásáról és nem szabványos rendszerszoftverek alkalmazásáról van szó, amelyek megnehezítik a váltást egy másik szolgáltatóhoz. Ennek megfelelően a szolgáltató kiválasztásakor párhuzamosan meg kell tervezni a váltás menetét (tulajdonképpen egy teljes DRP – katasztrófa-helyreállítási terv) és a tárolási architektúra illetve a biztonsági mentések kialakítását.
A második fontos szempontja az IT igazgató új kötelezettségeinek a szolgáltató által nyújtott szolgáltatások minőségének ellenőrzése. Gyakorlatilag az összes felhőszolgáltató betartja a SLA-t a saját belső metrikái alapján, ami esetleg csak közvetett kapcsolatban állhat az ügyfelek üzleti folyamataival. Ennek megfelelően a saját monitoring és ellenőrző rendszer kiépítése a kulcsfontosságú projektek egyike a jelentős IT rendszerek felhőszolgáltatóhoz való átvitele során. A SLA-k témáját folytatva fontos hangsúlyozni, hogy a felhőszolgáltatók abszolút többsége korlátozza a SLA megszegéséből adódó felelősséget a havi előfizetési díjra vagy a díj egy részére. Például az AWS és az Azure a 95%-os rendelkezésre állás túllépése esetén (36 óra havonta) 100%-os kedvezményt biztosít az előfizetési díjból, míg a Yandex.Cloud esetében ez 30%.
És természetesen ne feledkezzünk meg arról, hogy a felhők nemcsak Amazon és Yandex klasszisú óriások formájában léteznek. Vannak kisebb felhők is – macska méretűek, vagy akár egér nagyságúak. Ahogyan a CloudMouse példája is mutatta, néha a felhő egyszerűen csak véget ér. Nem fog kapni semmiféle kártérítést, sem kedvezményt – semmit, csak a teljes adatok elvesztését.
A fent említett problémák miatt az üzleti szempontból kritikus IT rendszerek megvalósításában a felhőinfrastruktúrákban az utóbbi években megjelent a "felhő repatriáció" jelensége.
2020-ra a felhőszolgáltatások terén elértük a túlfújt várakozások csúcsát, és a koncepció a csalódások árkába került (a Gartner hype ciklusának megfelelően). A kutatások szerint és a vállalati megrendelők akár 80%-a visszatér és tervezi is, hogy visszatér a felhőből a saját adatközpontjaiba az alábbi okok miatt:
- A rendelkezésre állás / teljesítmény növelése;
- A költségek csökkentése;
- Az információbiztonsági követelményeknek való megfelelés érdekében.
Mit tegyünk, és hogy van mindez "valójában"?
Nincs kétség afelől, hogy a felhők komolyan és hosszú távon itt maradtak. Évről évre szerepük nőni fog. Azonban nem a távoli jövőben élünk, hanem 2020-ban, egy teljesen meghatározott helyzetben. Mit tegyünk a felhőkkel, ha nem egy startup vagyunk, hanem egy klasszikus vállalati megrendelő?
- A felhők elsősorban olyan szolgáltatások helyszínei, amelyek előre nem látható vagy markánsan szezonális terheléssel bírnak.
- A legtöbb esetben az előre látható, stabil terheléssel rendelkező szolgáltatások olcsóbban fenntarthatók a saját adatközpontban.
- A felhőkkel való munkát tesztkörnyezetekkel és alacsony prioritású szolgáltatásokkal kell kezdeni.
- Az információs rendszerek felhőbe helyezésének megfontolása a felhőből egy másik felhőbe (vagy vissza a saját adatközpontba) történő átállás módszertanának kidolgozásával kezdődik.
- Az információs rendszer felhőbe helyezése a kontrollált infrastrukturába való biztonsági mentési terv kidolgozásával kezdődik.
Forrás: habr.com
