3. évad – 17. epizód – AWS szuverén felhő és migráció

00:16 Üdvözlök mindenkit! Ez itt a DIG-IT Podcast. Személyi László vagyok, a Future-NOW vezető partnere és társam a krimiben, Szekér Zoltán, az OD&IT Solutions és a SailingHangar alapító ügyvezetője.

00:27 Sziasztok!

00:27 Jó napot kívánok! A DIG-IT Podcast célja, hogy akit nem elégítenek ki a felszínes cikkek és a hangzatos jelszavak, az közelebb kerülhessen a digitalizáció és az informatika mai meghatározó trendjeihez.

00:41 Mi itt a mélyére fogunk ásni a dolgoknak.

00:47 A legutóbbi adásban végig a kiberbiztonságról beszélgettünk, és a vége felé ennek az adásnak szóba került, hogy mennyire vannak Európának saját eszközei, amivel meg tudja magát védeni a kibertérben. Bikkfanyelven van-e szuverén kibervédelmünk Magyarországon, illetve az EU-ban, és ezt én a mai adásra kiterjeszteném a kulcsfontosságú alkalmazásainkban értelmezett szuverenitásra, és így meg is érkezünk egy ilyen beszélgetéshez, hogy felhő alkalmazásokat szeretnénk használni, de szuverének is szeretnénk lenni. Hát ehhez a spéci területhez ma új műsorvezetőt is avatunk. Dr. Dávid Péter MI szakjogász személyében. Üdvözöllek Peti! Köszönöm, hogy társultál velünk.

01:31 Sziasztok! Üdvözlöm a hallgatókat, én köszönöm a lehetőséget.

01:35 És egy visszatérő vendéget hívtunk. Köszöntöm a Digit Podcast stúdiójában a Total Felhő Kft-től, azaz a TC2-től Sepsi Károly üzletfejlesztési vezetőt.

01:45 Sziasztok! Én is üdvözlöm a hallgatókat! Köszönöm a meghívást!

01:49 A nyár elején jött ki a hír, és innen indítanám a mai óránkat, hogy a két éve beharangozott teljesen európai felhőszolgáltatás még idén ténylegesen elérhetővé válik az AWS-nél.

02:02 És akkor így próbáltam ezt összehívni, hogy teljesen európai, de az AWS-től jön.

02:07 Tehát először is hogy van ez, és miért fontos mérföldkő ez, meg mitől lesz biztonságosabb így a világ, vagy csak többen fogják emiatt az AWS-t választani.

02:17 Igen, ez jó kérdés, hogy ez pontosan mit old meg, ahogy látjuk a világpolitikában, ami játszódik, és nyilván az ügyfelek is látják, tehát sok ilyen kérdést kapunk, hogy egy amerikai cégnek az EU-s data központjaiban ez biztonságos-e, hogy ott tartsuk az adatunkat, és ez olyan módon fog megoldást hozni az eusofering cloud, hogy ez egy külön entitás, ami egy EU-s cég, és csak EU-s munkavállalók dolgozhatnak ott.

02:45 Tehát ez azt jelenti, hogy EU-s törvények is vonatkoznak mind, akik ott dolgoznak, és magára a cégre is.

02:51 Ha jól értem, itt az a nagy kérdés, hogy nyilván én, mint egy kkv, lehet, hogy nem is érdeklődöm annyira ez iránt, de ha mondjuk már egy nagyobb vállalat vagyok, egy pedálkommunikációs cég, vagy egy közüzemi szolgáltató, vagy ne adj isten, egy pénzügyi szolgáltató, vagy hova tovább? Egy állami szerv, akár egy egyetem, vagy akár egy hatóság, hogy akkor az én adataimhoz, meg az én használati statisztikáimhoz, meg az én ügyfeleimhez hozzáférhet-e Amerikából valaki. És akkor itt egy kicsit a Petit is kérdezném, mert hát mégiscsak, bár műsorvezető, de egyben szakjogászként is ül itt, tehát hogy ez akkor egy ilyen jogi huzavonának az elejét veszi el, tehát hogy ne keveredjen bele egy technológiai szolgáltató, meg egy ügyfél, vagy általam felsoroltak ügyfelek egyike egy ilyen jogi huzavonába, hogy most akkor mi történik az adataimmal, vagy ennél többről lehet szó?

03:46 Én úgy gondolom, hogy ennél jóval többről van szó. Kifejezetten üdvözlendő, hogy most már az AWS-nek is lesz egy saját szuverén felhője Európában, számos szolgáltató meglépte ezt már. Ez egyébként a GDPR egyik pozitív hozadéka. Sokan a GDPR-t csak akadályozó tényezőként látták az életükben. Az elején annak is tűnhetett viszont azáltal, hogy előírja a kötelező európai adattárolást, ezáltal a saját adataink is biztonságban lesznek, nemcsak Magyarországon, hanem az EU-n belül is.

04:15 Igen, és nyilván az EU Solar Incloud az egy teljesen EU cég, és csak EU-s állampolgárok dolgozhatnak ott. Ilyen szempontból a törvényi rendelkezések és minden szempontból az EU, az EU-ra vonatkozó hatályos törvények alapján lehet bármit csinálni.

04:35 Vagyis kompleinten megfelel az EU jogszabályi normáinak.

04:38 És ezáltal nyilván sokkal izgalmasabb lehet az Európai Unión belül működő jelentősebb méretű cégek számára is.

04:47 Igen, így van. És azt gondoljuk, hogy aki az EU-s Over Incloud szolgáltatást szeretné használni, az valószínűleg EU-s partnerekkel szeretne dolgozni, tehát hogy akkor valószínűleg minden az EU-n belül maradjon, tehát a munkavállalók, akik itt dolgoznak, az szintén ilyen partneri körből kerüljön ki, úgyhogy úgy gondoljuk, hogy mi a TC2-nél ebben nagy szerepet tudunk vállalni, és erre készülünk is tudatosan.

05:11 Ez drágábbá teszi az AWS szolgáltatásait? Tehát ha én azt szeretném, hogy nekem az európai verzió kéne.

05:19 Most így első hallásra arra gondoltam, hogy az AWS-nek egy csomó mindent duplikálnia kell, ami eddig megvolt külön, az most ugye külön cég, külön központ, külön szoftverkörnyezet, mit tudom én, bocsánat, hogy ilyen slendriánul mondom, de hogy mindenféléből lehet akkor kettő, akkor ez gondolom drágább.

05:38 Igen, sajnos még mindig némi misztikum övezi ezt a szolgáltatást. Egyébként két hete voltam pont Londonban, ahol több AWS executive emberrel is beszéltem, pont ebben a témában is, és azt mondják, hogy 15-20 százalékkal vélhetően drágább lesz, tehát lesz ennek egy price over headje. Én azt gondolom, hogy úgy lesz jó használni az ügyfeleknek a szuverén cloudot, hogy nem mindent odaraknak adott esetben, hanem ahogy ma hibrid felhőt építenek, hogy ugye a fele operaméz, fele felhő, fele mondjuk ABS, és bizonyos rendszereket ott tartanak on Premise-t. Lehet, hogy ezt pont az on Premise válthatja ki, és akkor csak bizonyos rendszerek esetén fogják a szuverén felhőbe rakni, ahol mondjuk erősebb adatszabályozás van érvényben, és a másik fele, amit esetleg jobban lehet innoválni, ott meg a sima AWS publikus fejekbe rakjuk, nyilván azokat is az EUSD-t a centerekbe, tehát ugyanúgy GDPR kompliant módon, mert ugye azt is mondták, hogy valószínűleg a szuverén felhőkben lassabban fognak odaérni a különböző AWS feature-ök, tehát itt is vannak különböző verziók, ahogy kirakják az új fejlesztéseket, és lehet rá számítani, hogy nem oda fog elsőnek kiesni, hanem új fejlesztések az AI, meg akármivel.

07:03 Hát igen, ezt az Apple-nél is látjuk, meg több helyen is, hogy azért Európát most így egy kicsit prioritás kettőbe tették, nem?

07:12 Talán a szabályozási biztonság miatt, hiszen nálunk az adatok nem feltétlenül csak azért vannak, hogy ebből valami üzleti előnyt szerezzenek, hanem itt kifejezetten a személyes adatok és az üzleti adatok védelme is fókuszban van.

07:26 Nekem az merül föl, hogy érthető, hogy drágább, hiszen azért ez egy jobban szabályozott, biztonságosabb környezet, de hogy a jogbiztonság mellett biztos fölmerül az ügyfelek fejében, hogy valami extrát is kapnak, hogy mi lehet emellett.

07:37 Kontroll vagy pénzügyi tervezhetőség, vagy milyen fajta extra várható azoknak, akik itt ebben a souverén cloudban fogják az adataikat tárolni?

07:47 Alapvetően szerintem a szabályozás oldalról fogják ezt megfogni az ügyfelek, tehát akinek erre van szüksége, és esetleg emiatt nem tudott még a felhőbe mozdulni, akkor ez lehet a válasz rá.

07:57 Hát ez egy nagyon jó pont.

07:59 Itt egy picit fúrjunk, vagy ássunk a mélyére, hogy a szlogenünket alkalmazzam. Tehát az egyik fele az, hogy drágább, mert több duplikáció van benne, egy kicsit európaiassá van téve, oké, de hogy ugye mik lehetnek az előnyei. Az egyik előnye, amit te mondasz, Karcsi, hogy az az ügyfél, aki eddig nem volt feltétlenül képes vagy jogosult AWS-t használni, most akkor elvileg az is jogosulttá válik. Ez az egyik fele a kérdésemnek, hogy vajon mennyire láttok ilyeneket, ez nektek nyilván egy üzletfejlesztési kérdés, megnyit-e új piacot számotokra így az AWS, a másik fele pedig, amit a Peti kérdez, hogy akkor vannak-e olyan funkciók, amit eddig köré kellett varrni, így nem túl szépen fogalmazva belső vagy külső, de plusz szolgáltatók segítségével kellett megvalósítani annak a magyarországi vagy európai cégnek, aki AWS-t akart használni azért, hogy megfeleljen minden jogszabályi és biztonsági előírásnak, de most, hogy megnyílik a szuverenitás, lehet, hogy lesznek benne olyan funkciók, ami beépítve tartalmaz ilyet, tehát a másik oldalon lehet, hogy csökkennek költségek.

09:12 Ez egy jó kérdés. Egyelőre én nem látok olyan plusz funkciót, ami ezt indokolná.

09:18 Egyébként pont olyan lesz az a szuverén felhő, mint egyébként az AWS felhő, tehát amit mondtam, lehet, hogy lassabban érkeznek oda a funkciók. Egyébként nem Prio II szerintem Európa ezt erre akarta még reagálni, mert ahogy jönnek az új funkciók, az mindig az Írország és a frankfurti régióban nagyon hamar lecsapódnak. Egyébként én ezt így nem érzem. Van egy stratégia, hogy kirakják az új fejlesztéseket az AWS-nél, kvázi verziózzák a szolgáltatásokat, még ha nem is látjuk, hogy verziózva van. A platform, ez a szörvi szolgáltatások. Úgyhogy reagálva az eredeti kérdésre, én azt gondolom, hogy ez nagyrészt reguláció alapú lesz, hogy ezek az új projektek és az üzletfejlesztés szempontjából, hogy jöhetnek be ide az ügyfelek.

10:07 Az is biztos, hogy ha ez elindul, akkor további ilyen szuverén felhőtétes szenterek fognak kinőni az ABS-nél. Tehát ez az első most Brandenburgban lesz, Németországban, de vélhetően más országban is meg fognak jelenni.

10:22 És számítotok új ügyfélkörre, aki megjelenik a TC2-nél azért, mert most ez egy olyan konstelláció, amit ő el tud fogadni, de az előző ÁVH-s konstellációkat nem tudta?

10:34 Ezt nehéz megmondani. Az itthoni ügyfélkörben személy szerint nem.

10:40 Először az EU-s rendelkezések meg kell, hogy mondják, vagy megszülessen egy olyan szabályozás, ami ezt nemcsak hogy lehetővé teszi, de akár elő is segíti, és minden bizonnyal aztán mi is lekövetjük, ha vannak ilyen rendelkezések.

10:58 Nézzük ezt egy kicsit partneri oldalról.

11:01 Azt én mindig elmúlva és csodálattal olvasom, vagy osztom meg az ismerősi körben, hogy a TC2 milyen magas szintű partnere az AWS-nek. Itt Lassóval se nagyon lehet fogni Közép-Európában ilyen szintű partnert. Ti, mint integrátor és magas szintű partner milyen feladatokat kaptok az AWS-től egy ilyen nagy horderejű változás bevezetése, piaci ismeretterjesztése vagy bármilyen technikai támogatása kapcsán.

11:30 Van nyilvánvalóan egy szakértői elvárás, hogy ezt jól ismerjük, amiket kihoznak az ABS-től.

11:38 Vizsgázni kell belőle.

11:40 Vizsgázni kell abszolút, tehát igen, ezen mérve vagyunk, mint partner, hogy mennyi szakértőnk van az adott témákban. Egyébként az AWS azt is nagyon nyomja a partnereknél, hogy legyenek úgynevezett összecsomagolt termékek kvázi, amiket aztán lehet biztonságos módon az ügyfeleket vinni. Nekünk az egyik ilyen fő termékünk, flagship termékünk, úgy is mondhatnám, a landing zónunk, ezt mi Lazy-nek hívjuk.

12:13 Erre emlékszem.

12:13 Igen, igen, erről beszélgettünk. És nekünk adja magát, hogy ezt a megoldást úgy terjesszük ki, hogy ez aztán szuverén felhőt is, meg sima datacenterekben lévő datacentereket is tudjon használni, és a korábban elmondott példa szerint jól működjön ebben a vegyes használatban, hogy nem mindent rakunk egy helyre, hanem oda-vissza lehet rakosgatni különböző rendszereket.

12:38 Ilyenkor szabad kezet kaptok a csomagok összerakásánál, vagy azért valamilyen irányt meghatároz az AWS?

12:45 Teljesen szabad kezünk van, de mindig konzultálunk, hogy mit tartanak jónak, illetve ők aztán ezt felülvizsgálják. Úgy van egy ilyen plecsni, hogy azt az AWS felülvizsgálta, és ők is best practice alapú kivitelezésnek mondják.

13:00 Értem.

13:00 Arra gondoltam itt, hogy akkor kifejezetten akár légióra vagy Magyarországra szabott megoldásokat tudtok nyújtani az AWS jóváhagyásával.

13:07 Igen. Egyébként nekünk van egy TC2 csapatunk az AWS-nél, és ott van hozzánk rendelt szólista architektúra, van külön partner development menedzserünk, és még marketingre is van emberünk.

13:20 Tehát van egy ilyen kb. hatfős csapat, aki minket segít ebben, hogy a piacra lépés és a megoldások megfelelőek legyenek.

13:28 Félidőhöz érkeztünk, és a Karcsi jól tudja, hogy mi jön ilyenkor. Ideje lazítani, ha már a Lazy előkerült, és hát elárulok egy műhelytitkot itt az adás előtt az egyikőtök kezében egy kávéscsésze volt, a másikótok kezében egy teáscsésze. Mintha készültetek volna, hiszen én azt a kérdést tettem föl a forgatókönyvben, hogy majd felolvassam, hogy kávé vagy tea, hidegen vagy forrón, sokszor vagy kevésszer, mennyire egzotikus, vagy mennyire kommersz, hogyan szoktatok lazítani, italok, szóval egy élénkítő italok szempontjából.

14:06 Én Kálvinékről olyan vagyok, mint a Claudiát kapcsolat nélkül, hogy csak villogok, de nem működök, úgyhogy nekem a kávé hidegen és hosszan.

14:16 Hidegen?

14:16 Igen, én szeretem, ha kiül a kávé és utána szokni.

14:19 Vagy egyből ezt a coldblue-t, ezt az új divatot.

14:21 Nyáron, nyáron jó, kifejezetten, igen, egy narancs karikával.

14:27 Én inkább teás vagyok, én általában zöld teát iszok elég sokat, vagy esetleg macs alattit, azt mostanában kezdtem rászokni.

14:35 Én a kávét nem nagyon, nem nagyon iszom.

14:37 Ez mindig így volt, vagy ez inkább egy ilyen új keret?

14:40 Nem, ez most az utóbbi pár évben változott meg. Én nagyon sokat kávéztam régen, és akkor, amikor már ilyen 6-7 kávé egy nap, az kicsit sok volt, és le kellett tenni.

14:49 Két olyan ismerősöm is van, aki tizenöt, akár húsz, de a Szőnyi kávét megiszik. Nyilván van, amikor kombináltam, meg nem tudom, szóval hogy a hat az ehhez képest semmiség. Én általában egy ilyen négyig jutok el egy nap maximum, de inkább kettő körül. Én nem nőttem még ki a kávéból, viszont én a napot szeretem teával indítani, amivel elég egyedi vagyok az ismerősi körben, mert általában mindenki kávét főz először odahaza, és inkább lehet, hogy nem is iszik egész nap utána. Na, én viszont egy jó tea nélkül nem indulok el otthonról, az kizárt, még ha nem is reggelizem, tehát legalább valami edényben elviszek. És nem csak zöldet, nagyon sokfélét szoktunk. Külön teakeverékeket is otthon összekotyvasztok.

15:32 Hogyha elmegyünk, mondjuk most voltunk, megadatott Spanyolországba jutottunk, Córdobába bementünk egy fűszerboltba és ott fél órán át szagolgattam, válogattam, hogy valamit hazahozo, és sikerült egy nagyon finom Andalúz Kapricsot, szóval valahogy ez mind a kettő. Ez mind a kettő nálam, de hát visszatérve a felhőszuverenitáshoz, mert itt most nem a tea szuverenitás a téma. Van-e másik szolgáltató a piacon ezen gondolkoztam, és hát nem kellett messzire menni, már nyilván van egy Microsoft, de van olyan is, akivel ti magatok is foglalkoztok valamennyire, ez az Oracle, merthogy az ő adatbázisait optimalizáljátok, adott esetben migráljátok, és hát köztudott, hogy az egyik legnagyobb adatbázis-szolgáltató a világon.

16:17 Erre vonatkozóan lehet-e azt mondani, hogy van egy trend ebben az Oracle migrációban, tehát hogy bizonyos okok miatt egyes ügyfélkörök egyszerűen átkerülnek átmigrálnak, átevickélnek talán ez a leggyakorlatiasabb kifejezés egy idő után az Oracle-ről az AWS-be, és egyébként ha ez nem csak egyedi eset, akkor viszont mi történik ilyenkor az alkalmazásokkal? Mert hát ugye ez egy teljesen különálló réteg, ami frontenddel és egyebekkel rendelkező mindenféle kapcsolattal hívjuk interface-nek. Hát ez alól kihúz egy migráció egy szőnyeget, és igyekszik ugyanolyan lendülettel egy másikat alárakni, de hogy ez érintetlenül hagy, biztos, hogy nem hagyja érintetlenül az alkalmazásokat, nem? Hogy van ez?

17:03 Igen, egy kicsit távolabbról indítva én azt látom, például az itthoni piacon, hogy elég sokan használnak már felhőt, tehát most már azért a nagy bankoknál is ott van, és a nagyvállalati szférában mindenhol hibrid felvi irányba mennek, tehát valamennyi on premise, meg egy vagy több szolgáltató. És a klános stratégiában én jellemzően azt látom az ügyfeleknél, hogy a régi alkalmazások maradnak on premis, az újak meg az új fejlesztések mennek felhőbe. És szerintem most már kialakult a bizalom, hogy a felhő jól működik, és most kezdünk odaérni, hogy meg lehet nézni, hogy a legacy alkalmazásokat is lehetne modernizálni és felhőbe rakni. Szerintem ez egy jó időpont most. Mi most elsőként az Oracle adatbázisok modernizációját és a hozzá tartozó alkalmazásokat.

17:51 Ott is egyébként gyanús, hogy nagyon sok Java alkalmazást fogunk találni, most ezt célozzuk. Azt látjuk, hogy nagyon sok helyen túlhasználják a licenceket, vagy túl sokat használnak, vagy indokolatlanul nagy térben, tehát hogy enterprise verziót használnak, holott lehet, hogy a sztenderd is elég lenne, vagy akár indokolatlanul Oracle-t használnak, tehát mondjuk egy Postgresql ugyanúgy megfelelne, hogyha azt a felhőt befuttatnák, funkcionálisan elég, teljesítmény szempontjából elég, csak adott esetben megszokták a fejlesztők, hogy Oracle-t használnak. Régen a projekt indulásánál ez nem is volt opció, hogy mást használjanak, vagy nem is gondoltak rá, most meg beragadtak egy jelentős licencköltséggel.

18:36 És mi a partneri kapcsolataink révén fókuszálunk erre a feladatra vagy kihívásra. Mi összebútoroztunk a Cindrával, akik már 25 éve origó partnerek, és nekik van egy olyan megoldásuk, hogy meg lehet vizsgálni ezeket az adatbázisokat, és különböző adatok alapján elsőként a licenctúlhasználatot nézik meg, ami relatíve egyébként egy egyszerű dolognak tűnik, de egyébként távolról sem az, az Oracle licencpolitikája miatt, azt nagyon kell érteni, akkor utána, hogy lentebb lehet-e downgrade-elni mondjuk Standard Editionre, vagy van az úgynevezett database freedom nevű ilyen megfontolás, hogy könnyen ki lehet-e hozni mondjuk Fostgard SQL-re. És akkor ez belenéz ott a különböző beállításokba, meg hogy mi fut az adatbázisokba, és ez alapján el tudja dönteni.

19:32 Egyébként hozzáteszem, nem is muszáj, hogy ez AWS be legyen migrálva, tehát egy ilyen felmérést meg tudunk csinálni az ügyfeleknek, és lehet, hogy az jön ki belőle, hogy akkor marad ott, ahol van az adatbázis, csak esetleg kevesebb licenccel, és akkor ezzel is pénzt tud megtakarítani az ügyfél. Emellett az AWS nagyon jó programokkal és visszatérítésekkel sarkalja az ügyfeleket arra, hogy ezek a migrációk megtörténjenek. Van a Mágia és Eneca elérési program, erről már korábban beszéltünk az egyik podcastban, ahol vannak különböző visszatérítések. Hogyha Oracle-t migrálunk, akkor hozzáteszem, háromszoros a visszatérítés, tehát az AWS az így célba vette az Oracle felhasználókat. És azon belül is van egy olyan opció, ami kvázi én egyfajta hibaként értelmeztem az AWS árazásban, hogy van egy olyan szolgáltatás, a menedzselt adatbázisa az AWS-nek, ez az RDS névre hallgat, és ott van olyan verzió, hogy Oracle Standard Edition, licence includes.

20:36 Tehát az árazásban benne van a licenc is, és erre is ezt a háromszoros visszatérítést adja. Egyébként nem is titok, ez 75 százaléka az új költéseknek, tehát annyit visszatér itt Creditben az ABS. Tehát ez szerintem olyan business case-t eredményez az ügyfeleknek, hogyha ezt sikerül kihasználni, ami biztos, hogy indokolja, hogy érdemes megfontolni ezt a migrációt.

20:59 Most elbújtattunk itt egy szót elegánsan, merthogy szakmabeliek vagyunk, és ez így elfér, ez a legaszi alkalmazás. Ezt egy picit járjuk már körbe életszerűen, hogy mi számít ma ilyen megörökölt, vagy régóta itt lévőnek? Valami ilyesmi. A legeszűbb az örökség, de hát ezt kicsit ilyen tágabban és összetettebben kell látni az IT világában. Szóval, hogy mi számít ma ilyennek? Hány év után? Ugye van ez az óbor, nem? Hogy mi számít óbornak. Most az jutott eszembe, hogy és akkor hány év után számít valaminek eszének, vagy inkább nem is ez, hogy akkor most félévesen még újnak számít, de ötévesen már legaszi, hanem van-e bármi más ismérve, ami alapján ezt így el lehet mondani. Mondjuk, hogy nincs már házon belül tudás, akkor onnantól számít annak.

21:46 Ti mit hívnátok annak, vagy mit szoktatok annak hívni?

21:50 Erre nekem sincs egzakt definícióm, de jellemzően, ami nehezen fejleszthető, mert kevés a szakértelem, vagy egyszerűen csak kifutott már a supportja az adott gyártónál, tehát nyilván van a Legacy, illetve annyira sokat változott a programozás is, tehát adott esetben architekturálisan nézve és szoftver architektúrára nézve is lehet valami legaszi. Tehát én azt nem biztos, hogy évszámhoz kötném. Egyébként nagyon sok esetben hallunk olyan alkalmazásokról, amihez egyszerűen nem mernek hozzányúlni, és akkor működik, amíg működik. Kiváltani se nagyon tudják, és egyre nehezebb tényleg szakértelmet találni hozzá, mert kiöregedett az a réteg, aki azzal foglalkozott, tehát most gondoltunk ilyen kobold meg vizsgáló ABC alkalmazásokra.

22:41 Egyébként ilyen szempontból a Java nem Legacy nyelv önmagában, de mondjuk 2010 előtt szinte minden vagy oregoni árára ment, vagy SQL Server Dotnetre, és azért azok a Java 7-es, Java 8-as alkalmazások szerintem azok is erősen legaszik már, tehát azt azért nehéz hozzányúlni. Úgyhogy ilyen szempontból, aminek az üzemeltetési költsége olyan értelemben, hogy változásokat, fixeket belerakni, az már nagy erőfeszítést igényel, én ezt mind ide sorolnám.

23:12 Menjünk eggyel tovább.

23:14 Ugye felmerül a kérdés, hogy hogy viszonyul ez a kettő egymáshoz, hogy AWS mondjuk natívan, meg AWS Oracle-ből migrálva, meg hát ugye mind a kettőnél, ahogy mondtad is, nem egyszerű feladvány a licenszek optimalizálása, merthogy magának az alkalmazásnak is többféle licenckonstrukciója van, standard, nem tudom, enterprise. Meg ezek a visszatérítések is befolyásolnak, tehát ez önmagában egy biznisz kész, és nagyon sokszor itt tévednek a cégek, hogy elég drága szokott lenni az a kiadás, amit a licencekre kiadnak, miközben mondjuk az éves licencköltség tizedéből meg lehetne spórolni a licencköltségek harmadát, felét akár, hogyha így kiadnák egy tanácsadó csapatnak, hogy nézzék, vizsgálják már felül.

24:10 Hogyan végzitek ti ezt? Azt értjük, hogy segíteni tud a TC2, de arról is kéne egy kicsit szerintem beszélgessünk, hogy ezt hogyan tudjátok megtenni, milyen eszközökkel dolgoztok? Ha jól tudom, hogy itt vannak külföldi eszközök is a tarsolyban.

24:25 Igen. Nyilván minden ügyfél úgy szeretne belevágni egy ilyen projektbe, hogy meg fog térülni.

24:34 Minden esetben egy megtérülési.

24:37 Elvárható.

24:38 Igen, ezt még általánosságban mondhatjuk, igen.

24:41 Tehát, hogy nem szeretnék úgy a szülinapi zsúromra menni, hogy nincs torta, ez szerintem így okés.

24:47 Igen, azt szeretném kihangsúlyozni, hogy igen, tehát ezt a legelején a projektnek meg tudjuk határozni, tehát ki tudjuk számolni, és ezek az esetek 99 százalékában, sőt nem 100 százalékában. Eddig sose lőttünk mellé, tehát hogy lehet kis eltérés, de mondjuk 5 százalék differencia, tehát hogy bőven látszik, hogy ez most megéri vagy nem éri meg. Az, hogy egy ilyen totál cost of warnership, tehát a teljes költségelemzést megtegyünk, ezt három részre lehet bontani. Egyrészt van az infrastrukturális költségek, amit egyébként általános migrációban is meg szoktunk tenni, tehát hogy mekkora infrastruktúrán fut a Premis, és mekkorán fog a felhőbe futni, és hogyha optimalizáljuk, akkor ez mekkora különbséget eredményez.

25:35 Egyébként már itt is egy ilyen 5-15 százalék megtakarítást lehet általában látni, hiszen a Data Centerek azok jellemzően van kihasználatlan erőforrás, tehát azt nem tudják pont úgy méretezni, hogy optimális legyen. A második része az a licencoptimalizáció, ezt az AWS OLA programnak hívják, optimalised licence assessment névre hallgat, és akkor itt nézzük meg, hogy a licenceken mekkora költséget lehet faragni, tehát amit mondtam az előbb, hogy túlhasználat van-e, vagy lehet-e downgrade-elni, vagy esetleg teljesen kiszabadítani az adatbázist. A harmadik része pedig, hogy az alkalmazás is migrálódik, márpedig jellemzően migrálódik az alkalmazás és az adatbázissal együtt, akkor ott milyen migrációs stratégiát választunk.

26:28 Van hétfajta migrációs stratégia, az AWS által meghatározva, tehát hogy van a liftensip, amikor csak átrakjuk. Ez jellemzően egy legaszja alkalmazásnál nem jó. Tehát ott is modernizálni kell, és mondjuk csak, hogy a túlsó végét mondjam, lehet teljesen reflektorálni, és adott esetben AWS natív szolgáltatásokat használni. Ugye szerver lesz infrastruktúrára, ott többször láttunk már 90 százalékos megtakarítást is, tehát az egy komoly megtakarítás lehet. Úgyhogy, hogy összességében ebből mi jön ki, az elég változó lehet, de az elején látszik, hogy ez vélhetően mekkorára fog rúgni. És akkor a kezdeti számolást aztán alá is támasztjuk ilyen kisebb ilyen proof of concept projektekkel, hogy validáig, hogy valóban jól gondoltuk, ott lehet egy következő kiigazítás, de alapvetően itt azért nem szoktunk olyan nagyokat tévedni, hogy az egész business cast az felrúgja az üzleti tervet erre a migrációra.

27:33 A 90 százalék az egy durva szám, tehát itt ez egy erősen kék óceán piac. Egyébként az AI eszközök segítenek ebben?

27:41 Abszolút, igen. Az AI az rettentően innovatív terület manapság, és ez az alkalmazásfejlesztés, meg modernizáció egy nagyon jó szegmense, hiszen végül is gépi kódot kell értelmezni, tehát ilyen szempontból egyébként nagyon jól megfogható az AI számára. Úgyhogy látunk az AWS-ben is ilyen eszközöket, hogy segít a modernizációban. Az AWS maga tízezernél is több gyáva alkalmazást modernizált például a saját szolgáltatásával, és csak azt árulta ki nekünk, hogy használjuk, és ez is folyamatosan fejlődik, illetve a partnereink révén akár kobalt vagy vizsgáló basic alkalmazásokat is tudunk modernizálni, és ez nemcsak a kódot nézi, hanem a dokumentációkat, vagy ha nincs dokumentáció, mondjuk a régi GRA jegyeket megnézi, és akkor ebből alkot egy dokumentációt, illetve javasol egy tervet, hogy hogy lehetne modernizálni ezt az adott alkalmazást.

28:46 Én úgy érzem, hogy ez nagyon úgy hangzik, hogy az éjjel kivételesen nem hype-ra van használva, hanem akár nagyon komoly költségoptimalizálást tudtok ezzel elérni. Ugyan említetted a 90 százalékot, de hogy mi volt talán a legmeglepőbb eset, amit ilyen használatával létre tudtatok hozni.

29:04 Általánosságban azt mondják, és mi is azt látjuk, hogy mondjuk a fejlesztési ciklusokat 30 százalékkal gyorsítja. És ez szerintem egy nagyon kézzelfogható nyereség, amiért mindenkinek érdemes AI toolok használatában gondolkozni. Egyébként igen, tehát ezek, amiket mi használunk, ezek alapvetően bevált területen bizonyított megoldások, tehát ilyen szempontból nem az egzotikusra lövünk, hanem amit már sokan végigcsináltak, és minél több céghez el kéne vinni, hogy ebből az előnyeiből részesüljenek.

29:41 Értem, ha jól értettem, kiragadnék egy szót a teljes kontextusból. Azt mondtad, hogy akár utólag tudnak dokumentálni is, ha jól értem, akkor persze nagyon ritkán maradnak el az IT fejlesztések dokumentációi, ezt mindannyian tudjuk, de hogy azért előfordulhat, és így ezeket gyakorlatilag újra tudja gyártani utólagos a megfelelés érdekében akár?

30:04 Ez egy erős ígéret lenne, szerintem ebben biztos tud segíteni, illetve az biztos, hogy valakire szükség van, aki érti minimum az üzleti igényeket. Azért azt látjuk, hogy fejlődnek a fejlesztésre használt AI toolok, tehát nagyon sok mindent tud generálni az AI, de az minden esetben megspórolhatatlan, hogy valaki tudja, hogy mit akarunk itt elérni, nem? Tehát egy specifikáció legyen rendesen megírva, és akkor most például van az AWS, kiadta ezt a Kiró nevű fejlesztői eszközt, és ott ha nagyon jól meg tudjuk írni a specifikációt, akkor ledokumentálja nekünk, megcsinálja a diagramokat, letervezi és meg is csinálja a kurdot. Nyilván ez azért messze a legjobb, legszerencsésebb felhasználási eset, tehát mindig van vele munka, de pont azt a részt lehet kiváltani, ami maga a kódolás.

31:02 Igen, azt szoktuk mondani, hogy az effortot nem tudod megspórolni, csak az idő a végén, hogyha AI-t használsz, viszont ez akár nagyon nagy segítség lehet mondjuk egy NISZ 2-es megfelelésnél, amikor egy régebbi Legacy rendszernek mondjuk nem találjuk a teljes dokumentációját, és hát mégis lehet utólag gyártani.

31:19 Igen, igen, ez nagyon fontos. Egyébként pont vizsgáltuk a Dóra és Nis 2 megfelelési igényeket, és arra jutottunk, hogy a mi Lazy Landingsonunk teljesen a platform szempontjából mindent teljesít. Nyilván az AWS-ben ott vannak a megfelelő szolgáltatások és funkciók, csak jól kell őket használni.

31:41 Abszolút.

31:41 Na most, ami egyfelől ilyen erős számítás, meg büdzsé kontroll, meg kódgenerálás és dokumentáció, az a másik oldalon valahol egy vezetői feladatkupacot jelent, és ha most ezt a nevezzük IT főnöknek ezt az IT vezetői irodát nézem, akkor ott fölmerül az átképzés, a motivációs rendszer, a munkaköröknek a frissítése, kiszervezés, visszaépítése, elvesztett vagy elhagyott, hogy úgy mondjam funkcióknak a szervezetben. Karcsi, mit láttok, hogy mi a helyzet az ügyfeleknél ezekben a vezetői kompetenciákban? Van-e bármi, amire felhívnátok a figyelmet, ami általánosan esetleg fejlesztendő, illetve ti magatok hogyan hidaljátok át, hogyha a határidők nem teszik ezt lehetővé, hogy a kompetenciák is odaérjenek.

32:34 Tehát az AI használatra.

32:36 Nem csak az AI, de általában a migráció és AWS nem migráció projektjeiben.

32:44 Igen, nekünk a migráció felmérésnél és üzleti tervnél egyébként mindig része az is, hogy az adott ügyfélnek, nem is feltétlenül AWS, a felhős érettségét felmérjük, ez a Cloud Adaption Framework névre hallgat, mindenre van egy framework, és ez is meglehetősen jól működik.

33:03 Tehát itt is több ezer migráció alapján rakták ezt össze, hogy mi az, ami fontos az adott szervezetben. Egyébként jellemzően mondhatjuk, hogy nem a technikai kihívás a nehéz, hanem a szervezeti, meg tényleg az embereket fejlesztjük. Ez egyébként az AI-nál meg végképp igaz, tehát hogy amilyen tempóban fejlődik, meg a szabályozás is, ahogy követik, tehát nagyon-nagyon nehéz ezzel tartani a tempót. Mi egyébként mindig is úgy gondolkoztunk, hogy nekünk van egy ilyen AWS first stratégiánk, tehát hogy amit csak lehet, jellemzően az AWS szolgáltatásaival oldunk meg, hiszen azok rendkívül megbízhatóak, és az üzemeltetési költség az adott ügyfeleknél jóval kisebb, mintha mindenféle Supportét, meg Open Souls-okat ragasztgatunk össze.

33:52 Most hozzuk be az AI First stratégiát szintén, tehát hogyha valamit AI-jal lehet támogatni, automatizálni. Nyilván nem azon az áron, hogy veszélybe sodorunk, tehát ha kiadunk bármiféle adatot, ezt mindig megvizsgáljuk, hogy az adott funkciós szolgáltató hogy felel meg a mi biztonsági előírásainknak. De ezt nagyon meg kell figyelni, hogy olyan sokat lehet nyerni egy adott AI szolgáltatás használatával, hogy akár sokszorosan leredukálhatja az időt, amíg egy munkát el kell készíteni. És ugye egy publikus felhő lévén bárki használhatja. Én azt gondolom, hogy a versenytársainkat sokszor nem is ismerjük még, mert a földből nőnek ki manapság. Nem tudom, mondjuk a Revolutra ha gondolunk, vagy akár a Perplexitől, hogy mennyire nyomul előre a keresőpiacon, tehát a Google ellen, tehát nagyon érdekes látni, hogy pillanatok alatt jönnek az új szereplők, és átveszik a régi és stabilnak gondolt pozíciókat.

34:57 Úgyhogy ezért vagyunk rákényszerítve, hogy ezt használjuk, és ebben innoválni kell, úgyhogy abban tudunk segíteni, hogy javaslunk olyan lépéseket, hogy milyen tudást kell behozni, és ezt honnan lehet behozni. Ebben az AWS is rendkívül támogató az ügyfeleknek.

35:14 És láttok olyan vezetői kompetenciát az ügyfeleknél, ami úgy általában alacsony vagy fejlesztendő, vagy úgy ellenkezőleg, pont a vezetői oldalon vannak nagyon jó ügyfeleitek, és inkább a megvalósító kompetenciákban látjátok az űrt?

35:31 Ez változó, azt mondhatom, hogy mindig kell, hogy legyen valaki, aki erre dedikált vezetői szinten, hogy ez jól működjön, tehát egy valaki, aki ezt felvállalja és szponzorálja a szervezeten belül.

35:47 És hát igen, fontos tudni, hogy egyáltalán a felhős modell pénzügyi szempontból hogy működik jól, tehát ez nemcsak üzleti, hanem pénzügyi szempontból is kell, hogy legyen szponzora, aki érti, hogy ennyire alapvető dolgokat, a CAPEX és OPEX, tehát hogy az előreberuházás versus a havi költségekre átállás, tehát ez már önmagában nagyon sok helyen gond szokott lenni. Egyébként technikai oldalon nagyrészt azért mindenki izgatott és várja, hogy ilyen technológiákkal dolgozhasson, úgyhogy ott kevésbé szokott ez lenni az akadály.

36:25 Mennyire van ellenállás az AI-jal kapcsolatban?

36:28 Van egyfajta megfontoltság, tehát hogy egyébként nem sok olyan terméket lehet látni, ami elmegy production-ig. Egyébként nagyon sok a proof of concept, a tesztelgetés, de azért már látszanak több helyen, hogy hogy használják. Mindenki az adatait félti is nagyon helyesen, tehát hogy ezt meg kell nézni, hogy kinek melyik szolgáltatását használjuk. De nyilván egyébként az összes gyártó megkészül azzal, hogy az európai szabályozásnak megfeleljen, úgyhogy ilyen szempontból elég nagy a választék, hogy kikkel lehet dolgozni.

37:06 Peti, te így utolsó kérdést a végére, hogy te így a jogász szemével hogyan látod az ügyfeleknek a felkészültségét.

37:16 Nekem projektvezetőként is, szakemberként is az a gyakori élettapasztalatom, hogy a jogi területeket viszonylag későn vonják be, és viszonylag alacsony tudásuk van arról, hogy miről beszélünk, és ezért a leggyakrabban azt látom, hogy a technológiai haladás gyorsabb, mint maga a jogszabályi megfelelés dokumentálása. Te ezt hogy látod?

37:40 Igen, ezt zászlóshajóként is tűztük ki idén, mert több felmérés is azt mutatja, hogy talán még jobban elmaradottak vagyunk az AI-eknek az alkalmazása területén, vagy egyáltalán a megismerése területén, mint anno a GDPR volt. A GDPR tudta mindenki, hogy lesz, majd 18. május 25-én hatályba lépett, és mindenki egy hűha élménnyel elkezdte gyorsan implementálni, rövidebb-hosszabb idő alatt. Az ilyeneknél még kevesebben vannak tisztában, főleg az, hogy igazából az ilyenek már hatályba lépett, 2026. augusztus 2-tól alkalmazandó is. Talán a legfontosabb az lenne, hogy mindenki tervezze be a jövő évi költségvetésében, hogy kell vele foglalkozni, mert mindenkire hatályos lesz, akire az AI vonatkozik. Ez az egyik legfontosabb dolog.

38:27 Egyébként nem ördögtől való, hisz ahogy mondtam már a GDPR-nak is rendkívül sok pozitív hozadéka volt, ugyanilyen akár az európai uniós szuverén felhőmegoldások a nagyobb szolgáltatótól. Ugyanígy az AI-t is egyfajta jó minőségű adatbázist, adatbiztonságot, személyes adatok védelmét, visszaellenőrizhetőséget fog hozni. Én úgy gondolom, hogy hosszú távon ez egyfajta bizalmat és versenyelőnyt fog okozni azoknak a cégeknek, akik időben rákapcsolnak erre, és fölkészülnek arra, hogy megfeleljenek az EU-AI-ért előírásainak. Ezt úgy hívjuk, hogy compliance by design, hogy már a tervezésnél az elején építsük be ezeket a megfelelési pontokat, egyébként nem bonyolult és nem sok, amikkel meg tudunk felelni az ilyen helyek előírásainak, GDPR-nál ott volt a Privacy By Design, ugyanúgy az első pontoktól oda kellett figyelni az adatállomásra, megfelelés, törlés, stb. Ugyanúgy az AX esetén is ezt könnyedén meg lehet oldani, csak egy kicsit dedikáljunk rá mind munkaerőt, mind időt.

39:28 És a Privacy By Design, meg a Compliance By dizájn, ez megjelenik egyébként a felhőszolgáltatásoknál, és most visszakanyarodva kábé legelső kérdésre, tehát hogyha mondjuk egy ilyen nagy amerikai szolgáltató csinál egy európai változatot, most hívjuk így trendlyenul, akkor abban lehet, hogy több compliance by design van, mint az amerikaiban volt? Vagy egyszerűen csak rá van téve a Kft. az eddigi nem tudom, LLC-re most leegyszerűsítem, vagy a GMBH, mert ugye Németországról beszélünk.

39:59 Azáltal, hogy már itt van az Európai Unióban, európai uniós alkalmazottakkal, európai uniós szabályoknak felel meg, gyakorlatilag meg a lehető legnagyobb lépést megtette a Privacy By Design érdekében, és ugyanígy majd az ilyen helyeknek is a komplex by design esetén is, tehát ez nagyon fontos, hogy kontinensen belül maradjanak az adatok, a kezelés, ez az egész.

40:21 Egyébként ez egyáltalán nem triviális, most ezen gondolkoztam, hogy AI-nál, főleg a generatív AI, tehát lásd Language modellek, hogy volt itt, amikor volt ez a nagy bumm, hogy az adott szolgáltató felhasználja-e az adatodat, hogy visszatanítsa a modellt. Egyébként az AWS-nél is a legelső kérdéseink voltak, és az AWS-nél nem. Tehát az, amit használunk adatot, az ott is marad az adott accountban és régióban, tehát hogy tudjuk a lokációt, de ez egyébként nem ennyire egyértelmű mindenhol, és nem is írják ki sok helyen, hogy ez így vagy úgy van. Úgyhogy ilyen szempontból tényleg meg kell fontolni, hogy kit akarunk használni, meg kit nem. Az AWS egyébként azért is jó, mert nagyon sok gyártót összegyűjtött, tehát surpartykat, és akkor nekik a larzengage modelljüket lehet használni.

41:14 Az AWS-nek mondjuk van, nem is tudom, hogy hány darab, de közel tízszer annyi, vagy talán még több van a külső gyártóktól, tehát egyfajta lokin ellen, ez jó. Hiába az AWS-ben használjuk, de ugyanúgy lehet, nem tudom, az Antropic Cloudit vagy bármi mást használni. Ezzel biztosítva, hogy lehet próbálgatni is, hogy melyiknek jobb a költség performancia aránya, tehát itt is ezeknél a projekteknél látjuk, hogy elsőre mindig az a fontos, hogy működjön, és amint működik, akkor legyen olcsóbb. Rögtön utána jön. Állati drága modellek vannak egyes esetekben. Úgyhogy szerintem az AWS ilyen szempontból egy jó választás ezt próbálgatni és kiépíteni ilyen megoldásokat.

41:56 Azt hiszem, hogy elég muníciót adtunk a hallgatóinknak, és van mit továbbgondolniuk a felhős stratégiájukat, van mivel foglalkozniuk.

42:05 Károly és természetesen Peti, köszönöm, hogy velünk voltatok. Köszönjük.

42:10 Köszönjük a lehetőséget.