Egy újszülöttnek minden vicc új, így én a régi viccekre szakosodtam, azokat mondom el újra és újra.

Floorshrink diaries

Floorshrink diaries

Horseshoe bend Nr.1 – a Miért

2022. június 12. - Floorshrink

horseshoe_bend.jpg

A világ tele van természeti csodákkal, amelyekről percenként készül egy-egy fénykép. A Colorado folyó Page melletti kanyarulata ezek közé tartozik. Amatőr fotósként én is elkészítettem a magam változatát. (ne januárban menjetek…) A nyilvános felhővel kapcsolatban szintén percenként ír valaki egy új cikket, így nekiállni az N+1-iknek kb. annyi újdonságot ígér, mint a fenti fotó. A vészjósló #1 arra utal, hogy a mondókám nem fér el egyetlen cikkben, így várhatóan részletekben érkezik majd, mint egy kávéházi regény. Ennek ellenére abban bízom, hogy aki szán az alábbiak elolvasására pár percet, profitálni fog belőle.

Miért is érdekes ez az egész felhősdi?

  • A legerősebb érv a fejlesztők (és a mögöttük lévő üzlet) által megkövetelt „cikk-cakkban futás” joga (aka. agilis működés) és az IT infrastruktúra válaszadási képessége közötti szakadék áthidalása. Az üzlet kísérletezni akar, minél gyorsabban és persze minél kisebb költség mellett, miközben az IT éves költségvetési ciklusokban gondolkodik, ahol egy-egy hardver kigördítése az igény befogadásától számítva 3-4 hónap. (ha ehhez még hozzávesszük a chip hiányt, akkor bőven fél év felett)
  • Az IT infrastruktúrával szemben két panasz szokott felmerülni a stabilitáson túl: túl lassan tud nőni, és nem tud lefelé skálázódni, azaz rugalmatlan. Az alábbi ábrát eredetileg poénnak szántam egy felsővezetővel folytatott beszélgetés kapcsán: az informatikai infrastruktúra fejlődése a nyers erő exponenciális növekedésén túl a tetszőleges görbével leírható terhelési igényekre adott egyre pontosabb válasz képességével írható le. (az integrál számításban delta T tart a nullához) A nyilvános felhő egyik előnye az, hogy mind a dinamikusan skálázódni képes technológiát (pl. konténerekben futó mikroszolgáltatások), mind pedig ezen technológia létrehozását hatalmas mértékben felgyorsította. (aka. Infrastructure as a Code)

delta_t_tart_nullahoz.jpg

  • Egy munkatársam egy alkalommal azzal érvelt a nyilvános felhővel szemben, hogy mostanában minden változik (COVID, háború, gazdasági válság, infláció), nem lehet akár csak három évre sem előre tervezni, azaz még ráérünk. Az érvelés igaz, de az állítás téves: éppen ez a kiszámíthatatlanság igényli a gyors irányváltás képességét, és a nyilvános felhő segít gyorsan reagálni a váratlanra. Előfordul, hogy a “szövetségbe forrt szabad köztársaságok” egyike éppen rommá lövi a szomszédját, mert az túlságosan közel merészkedett a nagy testvér számára nem szimpi országcsoportokhoz. Az ukrán nemzeti bank kb. tíz évig piszmogott a kérdésen, aztán idén márciusban egy hét alatt engedélyezte a nyilvános felhő használatát bankok számára. Van az úgy, hogy sietni kell.
  • Az utolsó érvem az alábbi: az informatikai innováció java az utóbbi években valamely felhő szolgáltató piacterén jelenik meg (cloud first) és nem vagyunk messze attól a pillanattól, amikor ez átcsap „cloud only” állapotba. A nagy gyártók kínálatában ugyanazon termék on prem és cloud verzióinak funkcionalitása között évről évre nyílik az olló, azaz előbb van a mézesmadzag, utána jön a „nincs más választásod” állapot.

A tagadók érvei – kicsit megcincálva

A teljes képhez hozzá tartozik a „miért nem” kifejtése is.

  • „Ezt mi is meg tudjuk csinálni on-prem!” Való igaz, elvileg a felhő szolgáltatók minden technológiai megoldása és processze megvalósítható egy on prem környezetben is. Én is majdnem úgy nézek ki, mint Thor, már csak egy kicsit kell gyúrnom és kész.
    Egy átlagos hyperscale felhő szolgáltató jóval több szakképzett szoftver mérnököt tud ráállítani pl. a saját felhő infrastruktúrájának automatizálására, mint a legtöbb magyar nagyvállalat (együttesen). Ha elfogadjuk, hogy a Microsoft árbevétel arányosan allokálja az erőforrásait egy-egy területre és ehhez hozzá vesszük, hogy kb. 160 ezer ember dolgozik náluk, az Azure pedig 22 milliárd USD árbevételt hozott tavaly a 168 milliárd USD-s teljes átbevételből, akkor kb. 21 ezer MS munkatárs reszel nap mint nap az Azure-on. Ennek minimum a harmada fejlesztő mérnök és a műszaki vezetőik között olyan kaliberek vannak, mint Mark Russinovich. Ezt a meccset piszok nehéz lesz megnyerni, ne itt versenyezzünk.
  • „Eddig sem az infrastruktúrára kellett várni, az üzlet molyolt.”
    • Egy nagyvállalati informatikai infrastruktúra igény kielégítése annak megjelenésétől a tényleges működésig hónapokban mérhető, HA a vas már ott volt az adatközpontban az igény megjelenésekor. Ha nagyobb HW igényről van szó és a beszerzés az igény megjelenése UTÁN kezdi versenyeztetni a szállítókat, akkor min. fél évről beszélünk.
    • Ha a „molyolás” szót kísérletezésre cseréljük, akkor el kell ismernünk, hogy az üzlet időnként IT infra szempontból cikk-cakk-ban megy. Bár a kifejezés némileg lejáratódott, de igaz: az üzlet agilis, több helyre is tesz tétet, változtat és eseteként téved. A gyorsan és ebből adódóan kis költséggel „hibázás” legjobb támogatója a nyilvános felhő.
  • „A felhő drága!” – Ebben az állításban van egy jókora adag igazság, a felhő szolgáltatások, ha komolyan kezded használni őket, drágák tudnak lenni. A kijelentés ezek ellenére félrevezető az alábbi okokból:
    • Az on prem infrastruktúrák költsége „általánydíj” módon jelentkezik, azaz független attól, hogy milyen kihasználtsággal hajták őket. (for the record: egy nagyvállalati IT valahol egy gőzmozdony és egy Diesel hatékonysága között mozog, azaz kb. 20%-os utilizációval megy, de 100%-ot fizettet ki veled.) A felhő szolgáltatásokat viszont általában fogyasztással arányosan számlázzák, azaz, ha „égve hagyod a villanyt”, akkor valóban drágább lesz, mint az on prem. IT-sek több generációja szocializálódott azon, hogy a villanyt égve hagyni oké, mi több szerencsés, mert éjszakánként lefuthatnak a karbantartó script-ek, feltelepülhetnek a patch-ek. Évtizedes beidegződéseket kell majd felülírni.
    • A nagyvállalatok zöme jókora technikai adósság állományt cipel magával, aminek a járulékos költségét a kontrolling még csak meg sem próbálja megbecsülni. (a technikai adósságot párhuzamba állíthatjuk egy pénzügyi adóssággal, ahol a felvett hitel kamata a szervezet lassabb reakciókészsége a változásra.) Ha a nyilvános felhő segítségével csökkentheted a technikai adósságállományt, azzal gyorsítod a vállalatodat, ami pénzt ér. Ezt soha nem írod jóvá a felhő szolgáltatások árának vizsgálatakor.
    • A nagyvállalatok zöme nem képes megmondani, hogy az IT szolgáltatás portfolió egyes elemei valójában mennyibe is kerültek. (ezt az egyenletet nehéz felírni: ∑ i= 1 to N az IT szolgáltatás portfolió minden elemére(egységár x fogyasztott darabszám) = total IT költség) Ezek után előfordulhat, hogy a felhő szolgáltató árait ismerjük, az on prem IT infra árak pedig elmaszatolódnak a nagy közösben.
  • A felhő nem biztonságos – Írd be a (Google) keresődbe pl. a „Common vulnerabilities in Java” kulcsszót. Aztán, ha még nem vagy elég ideges, cseréld ki a Java részt dotNet-re, majd kedvenc (mobil) OS-edre stb. Mennyi idő alatt is javítottál ki minden log4j, Heartbleed stb sérülékenységet? Nem az a kérdés, hogy sebezhető vagy-e, hanem hogy mennyi idő után veszed észre a bajt és teszel ellene valamit. Nem akarom elbagatellizálni a kérdést, az utolsó valóban megbízható tűzfal a négy centis légrés volt. Arra akarok rámutatni, hogy a felhő pont annyira sérülékeny, mint az on prem infrád és ott több, esetenként jobban képzett ITSec-es munkatárs igyekszik csökkenteni ennek kockázatát. Az egy másik kérdés, ha maga a szolgáltató vagy az állam akar beleolvasni az adataidba.
  • A compliance követelmények miatt nem lehet – A PCI-DSS (Payment Card Industry Data Security Standard), SOC 2 (System and Organization Controls 2), HIPAA ( Health Insurance Portability and Accountability Act), ISO 27001 stb. követelményeinek megfelelni valóban nem kis feladat. Ezért is izgalmas e kifogást hallani olyan cégek munkatársaitól, akik informatikája a fentiek egyikét sem teljesíti, mi több, nincs is tervben ez a mutatvány. A nagy felhő szolgáltatók általában a fentiek mindegyikét megugrották évekkel ezelőtt, és évente testüreg motozza őket egy sor auditor, hogy még mindig rendben vannak-e.

Összefoglalás Mi vár ránk a kanyaron túl?

Az informatikai technológiai infrastruktúra mára tömegcikké válik. Ez a tömegtermék nélkülözhetetlen a versenyben maradáshoz (valójában a létezéshez), de nem jelent stratégiai versenyelőnyt a többiekhez képest, akik szintén rendelkeznek ezzel a technológiával.

A felhő, mint oly sok technológiai eredetű újítás, valami mást is tud, amit az eddigi megoldások nem és ez a valami megváltoztatja a játék szabályait. A kérdés, hogy tud-e egy vállalat versenyelőnyt kovácsolni az on prem IT infrastruktúra további kultiválásából ill. hogy tud-e a vállalati IT versenyezni a legnagyobb felhő szolgáltatók képességeivel.  Az első kérdésre a válasz egy valószínű igen, a másodikra egy biztosan nem. Ahogy Niels Bohr-tól tudjuk, a jóslás egy nagyon nehéz dolog, különösen, ha az a jövőre vonatkozik, de én mégis megpróbálom.

Az egyensúly a piaci célok (Alsó-Röcsöge vagy a világpiac meghódítása a cél), szabályozás által adott keretek, az adatok szenzitivitása és a költség optimum dimenziói mentén áll majd be, iparáganként és cégméretenként eltérő munkapontban. Minél kevesebb legacy-val bírsz (pl. egy startup) és minél messzebb vagy a specialitásoktól (pl. kormányzati informatika), annál valószínűbb, hogy pár éven belül az utolsó két on prem hardver eszközöd a kávéfőződ és a fénymásolód lesz. A több száz legacy (on prem) alkalmazással bíró, erősen szabályozott cégek esetén az egyensúly kb. a 65-75% on prem, 25-35% cloud környékén fog kialakulni.

A bejegyzés trackback címe:

https://floorshrink.blog.hu/api/trackback/id/tr1817855637

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása