- Üdvözlök mindenkit, ez itt a Digit Podcast. Személyi László vagyok, a Future-NOW vezető partnere és társam a krimiben Szekér Zoltán, az OD&IT és a Sailing Hangar alapító ügyvezetője. Sziasztok, jó napot kívánok! A Digit 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. Mi itt a mélyére fogunk ásni a dolgoknak. Születésnapost köszönthetünk a mai adásban, 10. születésnapját ünnepli. Visszatérő vendégünk a TC2, azaz a Total Felhő Kft. Gratulálunk ehhez a szép évfordulóhoz.
- Gratulálunk!
- A közelmúltban a TC2 többségi tulajdonrészt szerzett a szerb kombinat IT Services cégben, ez a másik apropója, hogy találkozzunk. Egyébként a Forbesban Révész Róbert alapító, vezérigazgató, aki szintén ült már a stúdiónkban és beszélgettünk vele, azt nyilatkozta, hogy nem csak egy akvizíció volt, hanem egy tudatos irányváltás és képességbővítés is, ez rögtön felkeltette a figyelmünket. Erről és általában a menedzselt szolgáltatások biztosításának csínjáról-bínjáról beszélgetünk ma a Digit Podcast vendégével. Hosszú idő után ismét Sepsy Károly, a TC2 üzletfejlesztési vezetője. Köszöntünk téged.
- Köszöntöm a hallgatókat, és köszönöm a meghívást.
- Károly, honnan kell indítani ennek a kombinált akvizíciónak a történetét, és nem is csak időpontban, hanem a TC2 életében ez hol jelent meg. Ki ez a cég, mióta ismeritek, mióta gondolkodtatok egyáltalán bármilyen akvizícióban?
- Ez egy régi időre nyúlik vissza ez az igény, már nem is tudom, 5-6 éve is megfogalmazódott bennünk. Nekünk van kortevékenységünk, amit elsősorban nagyvállalatoknak nyújtunk, tehát mi felhőtranszformációs partnerei vagyunk az ügyfeleinknek, migrációs modernizációban segítjük őket, illetve a Melit Services, tehát a felhőnek az üzemeltetése és optimalizációjában segítünk, és ehhez nagyon sok esetben, sőt szinte minden esetben van ennek alkalmazásfejlesztési aspektusa. Mi mindig úgy pozícionáltuk eddig magunkat, hogy mi az AWS platformszintig megyünk, és afelett meg majd az ügyfél megcsinálja, vagy egy másik partner, és voltak is ígéretes partneri együttműködéseink, de nem volt igazán hatékony, nem volt igazán olyan, ahogy mi csináltuk volna, sok esetben nem úgy futott ki, ahogy mi szerettük volna. Úgyhogy ez az igény nagyon régen megvan. Nem is tudom, hogy négy éve van meg talán a Manissa Richter-i rangunk, és ott is az Auditon mondták nekünk, hogy szép dolog ez, hogy platformszintig megyünk, de hogy annál fentebb is kellene. Ezt úgy hívják egyébként, hogy full stack, menet series provider az AWS terminológiában. Úgyhogy itt motoszkál azért egy jó ideje a fejünkben, hogy ha nem is echte teljesen alkalmazásfejlesztés cég leszünk, hanem a kettőt kombináljuk, és akkor a kettőből, a két világból, a platformból és az alkalmazásfejlesztésből a legjobbat kihozzuk. Úgyhogy emiatt tudatosan cégeket 2024-ben kezdtünk el vizsgálgatni. Volt egy profil, hogy miért szeretnénk, milyen fajta tudást, abból lett egy lista, abból lett egy shortlist, a shortlistnek a shortlistje.
- De mindenképpen az akvizícióra mozdultatok rá, tehát abban nem is gondolkodtatok, hogy organikusan fölépíteni belülről?
- Igazából felmerült az ötlet, de annyira másfajta tudást igényel, és olyan hosszúnak láttuk ezt az utat, hogy jobbnak láttuk, azzal is egybevetve, hogy egy másik országba is be tudunk lépni. Ilyen szempontból praktikusabbnak tűnt, de nyilván ez is, mint opció felmerült, hogy magunk építjük, de igen, az egy jóval hosszabb folyamat lett volna. Van egy kór szolgáltatási kör, amit érdemes vagy organikus módon, vagy akvizitív módon fejleszteni, és van egy olyan szolgáltatási kör, amit meg partneri úton tudunk erősíteni, és az én fejemben legalábbis ennek nagyon jól megfogható különböző scope-jai vannak, tehát ezt jól el tudom különíteni, hogy mit szeretnék.
- Milyen alapon? Na, ez egy jó kérdés. Mert egyébként ezt akartam is kérdezni. Tehát oké, most ilyenkor akvizíció, akkor van ennek egy szervezeti oldala, hogy hogyan integráljátok a két cég embereit, ez is egy jó téma, fogunk róla beszélgetni. De hogy hol döntöd el azt, hogy mi az, amit egy partnerre is jó rábízni, mert sokféle cég életében előkerül szerintem ez a kérdés, és hol van az, amit mindenképpen belső erőforrásként saját szervezeti kereteken belül szeretnél, és ha ehhez kell akvizíció, akkor azt integrálod azt a céget.
- Nekünk kvázi a TC2 brandje vagy identitása. Tehát, hogy nagyvállalatoknak ugye migráció, modernizáció, Meryl Services és cloud transzformáció, és ami ezen belül esik, tekintsük úgy, mint egy vertikális tudáshalmaz, hogy infrastruktúra, hálózat, biztonság, platform és akkor fellette jön az alkalmazás. Emiatt ezeket a fajta tevékenységeket jobb, hogyha belül van a csapat ilyen értelemben, tehát akvizíció által. De mondjuk mondok ellenpéldát is, tehát például nagyon szoros az együttműködés a Cindrával és a Remavd kettős cég, ugye ők egy tőről fakadnak, a Rimapda Syntrának a leányvállalata, és ők Oracle migrációs optimalizációval foglalkoznak, Oracle adatbázis. Tehát ez egy nagyon jól megfogható, ilyen kiegészítő tudást nekünk, és mi tudjuk azt, hogy hogy lehet ezt migráció és modernizáció szempontjából sikerre vinni az AWS platformon, ők meg hozzák ezt az extra tudást és az eszközt hozzá. Tehát ilyen szempontból még nagyon jól együtt tudunk működni, mert megvannak az egyértelmű határok. Viszont hogyha alkalmazásfejlesztésnél ezt tesszük, akkor olyan széles ez a határvonal, és egyébként volt több próbálkozásunk, tehát ezt nem csak gondoljuk, hanem ezt próbáltuk is. Ugye nekünk nagyon sok Research Andy Velopment tevékenységünk van, tehát ugye nem csak bedobunk valamit az ügyfeleknek, hogy akkor ezt csináljuk szerintünk, hanem azt előtte kipróbáljuk esetleg repetitív módon összegyúrjuk egy ilyen megoldássá. Ezzel is próbálkoztunk, hogy egyes partnereket kiválasztottunk, hogy például volt egy idő, amikor a gépi tanulás mesélő learningre a Sagemaker platform volt nagyon népszerű. Egyébként még ma is népszerű az AWS-ben, és akkor ezen kéne dolgozni. Több partnert is állítottunk ebbe, de valahogy elakadt mindig a lendület, vagy nem akartak invesztálni a partnerek ebbe, vagy valamilyen más dolog miatt nem alakult ki a közös együttműködésnek ez a hatékony kerete. Úgyhogy egy szó, mint száz, látszik egyébként, hogy miben érdemes és miben nem érdemes. Tehát ez oda megy vissza, hogy mi nekünk az alaptevékenységünk, amiben igazán erősíteni akarunk, és nagyon sokfele meg partneri hálózattal kinyúlunk emellett.
- Ennek az integrációnak van egy nagyon izgalmas nemzetközi vetülete. Ugye a kombinát egy szerb cég, ti pedig egy magyar cég vagytok.
- Így van egy EU-n belüli szereplő, és egy EU-n kívüli szereplő, egy harmadik személy. Mikor a nagyvállalati ügyfelek az alkalmazásaik során rátok bízzák az alkalmazásaik digitális életciklusát, akkor hogy tudtok nekik egy olyanfajta adatbiztonságot és ilyen határon átnyúló adatforgalommal kapcsolatos biztonsági megfelelést adni, hogy ez megfeleljen mind az EU-n belül, meg az EU-n kívüli adatforgalomnak, adatbiztonságnak, hogy lesz teljesen golyóálló ez a fajta megoldás?
- Ezt ügyfele válogatja, és ugye projektje válogatja, de hogy hova megy ki adat, az jellemzően a TC2 kontrollja alatt van, és mi, mint platform, Medicer is provider, meg hát nyilván az ügyfélnek a kontrollja elsősorban, tehát hogy mely AWS régiókat használja, és aztán ez az együttműködésnek a szkopjától függ, hogy a kombinált csapatot mibe vonjuk bele. Tehát például most is van olyan együttműködésünk, ahol alkalmazás optimalizációt végzünk velük együtt, és egyfajta jobb üzemeltethetőséget szállítunk az ügyfélnek. Ebben meg vannak küzdve a határok, és pontosan meg van határozva, hogy mit kapnak meg ők, és mi van nálunk, és hogy nyilván ez szerződésekkel van kontrollálva a kombinált is köztünk. Tehát ilyen szempontból egyébként jellemzően a személyes adatokat nem kapnak meg a kombinátos srácok, illetve semmilyen érzékenyet. Nyilván, hogyha alkalmazáskódon kell együttműködni, azt meg ugye külön szerződéssel le lehet fedni.
- Ha már így az országokról beszélgetünk, a szervezeti kultúrák között volt, vagy még esetleg van is különbség, meg hol tart most a két cégnek az összebútorozása?
- Van egy erős szakmai koordináció, hogy merre megyünk, és van mellette egy erős ilyen sales értékesítési koordináció is, tehát hogy nyilván, amit eladunk, azt aztán együtt le tudjuk szállítani. Egyébként kulturálisan nagyon közel állnak hozzánk, tehát ahogy szállítanak, tehát ez a csapat, elég sokáig keresgéltünk, és ez az egyike volt az első pontoknak, aminek stimmelnie kell, tehát másképp nem láttuk, hogy ennek realitása lehet, hogy megvegyünk egy olyan céget, hogyha nincs meg ez a culturalfit, ugye így szoktuk mondani. Emellett van egy lazán csatolt együttműködés, tehát az, hogy erőforrás menedzsment, projektmenedzsment, ugye financial management. Elég sok része van a lehetséges integrációnak. Mi alapvetően szerettük volna, hogy nehogy az együttműködés és a produktivitás kárára menjen az, hogy mi most itt elkezdünk integrálni. Ráadásul ugye fizikailag nem is egy helyen vagyunk, tehát az, hogy most ilyen nagyon rigid módon beolvasszuk a TC2-be a kombinátot, az fel sem merült. Mi szeretnénk az erősségeikre játszani, és közben azt a fajta szabályozott, folyamatvezérelt alapokat meg átadni és rájuk is kivetíteni a kombinátra, hogy aztán egy megbízható partnerek legyenek, vagy legyünk TC2-es kombinát együtt az ügyfelek számára.
- Na most egy akvizíció az pénzbe kerül. Nyilván egy csomó része ennek nem publikus, de az a része az publikus, hogy volt egy fordulópont még jóval az akvizíció előtt, amikor ti tőkét vontatok be, ha jól emlékszem 22-ben, tehát most már így lassan négy éve. És hogy volt egy ilyen mondása a Robinak, hogy ti nem maradtok 12 fős butik cég. És ez megütötte egy picit így a fülemet, meg aztán az is, hogy portugál tőkebefektetőt vontatok be, tehát aki kvázi nem ismeri a régiónkat, vagy nem járatos errefelé. Másfelől egy igen fejlett IT iparág van Spanyolországban és Portugáliában is. Tehát azt az iparágat viszont, amiben ti dolgoztok, azt valószínűleg ismerhették. És akkor ezen kezdtem el gondolkodni, hogy ez egy tudatos építkezés, vagy inkább arról beszélhetünk, hogy megnőtt az étvágy, hogy hát ha már van tőkebefektetőnk, és akkor most már tényleg tudunk növekedni, akkor most már vehetünk egy további céget is. És akkor ilyenkor mindig elgondolkodom egy picit, hogy na jó, de hát ennyi erővel a portugálok is megvehették volna közvetlenül a kombinátot, mégis rajtatok keresztül vették meg a kombinátot. Hogy is van ez?
- Ez jó kérdés egyébként, igen. De a portugálok alapvetően nem szakmai befektetők, hanem pénzügyi befektetők. Tehát ők ugye kvázi minket is átvilágítottak, ugye mi elpeacheltük, hogy mi ezt tudjuk, de hogy egyébként a portugálok is nagyon támogattak minket ebben a kombinált akvizícióban. Ezt a pitchinget is alaposan körbejártuk mi is, de hogy ők is megvették, tehát hogy nekünk kell ilyen tudás. De ilyen szempontból nálunk sokkal jobb helyen van, hogyha mi világítjuk át a céget szakmai szempontból és az együttműködési, a különböző együttműködési lehetőségeket definiáljuk, és aztán piacra visszük a közös tudásra megalapozott termékeket. Egyébként ezt a befektetést, azt mi arra használtuk, ez egyébként nagyon is tudatosnak mondanám. Ugye már tizedik éve egyébként mindig a TC2 tudásában és akkreditációkba fektettünk rengeteget, és hát ez azért nagyon sok esetben sok időt visz el, tehát a különböző AWS partneri rangok, vagy akár az ISO auditok, az ISO megfelelőségek, a termékfejlesztések, tehát mi mindig is úgy szállítottunk az ügyfeleknek, hogy előtte egy kipróbált megoldást vittünk az ügyfélhez.
- Az ügyfélen próbáltátok ki az ügyfeleket?
- Igen, igen.
- Tehát, hogy tesz környezetbe magatokon.
- Így van, így van. Tehát, hogy ilyen szempontból nyilván a nagyvállalati szektorban ez valamennyire elvárt is, vagy nyilván, hogyha mégsem próbáltunk ki valamit, akkor erről nagyon transzparensek vagyunk, hogy mik a kockázatok és meddig lehet elmenni. Ez is benne van a pakliban, de mi jellemzően előre kifejlesztjük, előre lepróbáljuk, előre leteszteljük, ahogy az ISO nagykönyvben is meg van írva, most kicsit ezek is a valós folyamatainkra vannak dokumentálva ezek az auditok. Úgyhogy ez is emiatt egyébként ez a befektetésnek nagyon jó helye volt, tehát hogy adott nekünk egy nagyobb teret, hogy több irányba is el lehetett indulni, nagyobb headcounttal, tehát ez is elég nyilván tőkeigényes a maga módján.
- Említetted az átvilágítást. Főleg egy ilyen nagy nemzetközi tőkebefektetés esetén elég szigorú pénzügyi, jogi és egyéb megfelelőségi átvilágításon estek át. Gondolom, nálatok is ez így történt.
- Igen.
- Ez számított valamifajta minőségi pecsétként vagy jogi megfelelőségként akár a hazai nagyvállalatoknál irányotokba? Hogyha gyakorlatilag volt egy sikeres tőkebefektetés, akkor ezek a srácok biztos megfelelően működnek, vagy nemzetközi szintű a szerződéses hátterük, a folyamataik. Ez támogatás volt számotokra?
- Én azt gondolom, hogy igen.
- Mondjuk ezt még nekem sosem mondta ki senki konkrétan.
- Egy ügyfél se borult a nyakadba, hogy végre egy portugál befektetést maga mögött tudó cég.
- De alapvetően pozitívan fogadta a piac. Nyilván az a része is, hogy valaki pénzt tesz arra, hogy mi sikeresek leszünk és jól működünk, és nem csak ilyen szerintem, hanem egy jelentős átvilágítás után is ezt gondolja.
- Inkább önbizalmat is adhat.
- Igen, igen, abszolút, igen. Tehát ilyen szempontból ez mindenképp pozitív.
- Igen, mert alapvetően ez úgy tűnhet, hogy jó volt egy U19-ünk, de azért ügyvédként én tudom, hogy ez milyen mértékű és mélységű feladat, a megfelelés, a végtelen dokumentáció, hogy bemutassátok a teljes transzparenciával működéseteket, úgyhogy én úgy gondolom, hogy azért erre legyetek büszkék.
- Köszönjük, igen.
- Azok vagyunk.
- Még egy picit az akvizíciónál maradva az AI képességeitek, ami ma igazából a kirakatban van minden IT érintettségű cégnél. Hogyan érintette ez az akvizíció kinél van, vagy mindkettő cégnél volt AI-jal kapcsolatos tudás. A kombinált felhő natív architektúrákban AI alapon dolgozik már egy ideje, tehát hogy elvileg náluk lehetett több, de hát ti is mondjátok, hogy az AI nem egy külön szolgáltatás, hanem a teljes értékláncban kéne integráltan gondolkodni. Van esetleg egy projekt példa a fejedben, amin ezt be tudod mutatni, hogy hogy néz ki a gyakorlatban most a közös, vagy inkább úgy mondom, a két cég többi, mint az egy, meg az együtt?
- Igen, igen. Ugyanakkor igen, ez elég sokrétű.
- Próbálkozom, próbálkozom.
- Belsőleg egyébként saját belső AI stratégiát is alakítottunk, tehát hogy nem is csak az ügyfelek fele, hanem a saját belső használatunkra is, hogy hatékonyabbak legyünk. Ez rettentő kiemelt fontosságú nekünk, hogy az adott számú kolléga az annyira hatékonyan működjön a mindennapi feladatokban, amennyire csak lehet. És erre egyébként nem is csak egy AI eszközt, hanem nyilván mindig megvan a Ride Tool for the Job, úgymond, tehát hogy többféle területen vizsgáljuk a különböző AI toolokat, hogy melyik mire jó, és akkor ennek megfelelően szabjuk egyes csapatokra ezeket a subscript söröket, meg use case-ekre. És alapvető filozófiánk egyébként, hogy ez use case alapon kell, hogy működjön, tehát hogy nem is csak a technológia, hanem hogy mire lehet használni. És hogy a use case-nek is része az, hogy üzletileg mi az értéke, tehát hogy megtérül-e, és nekünk ezt a filozófiát viszik az ügyfeleinkhez is. Tehát mi egy úgynevezett proof of verio keretrendszert definiálunk, ami nem proof of concept, tehát nagyon sok esetben kipróbálják, hogy technikailag működik-e, működik, szuper, és akkor mégis az AI pilotoknak a 80 százaléka nem megy tovább a kipróbálás után, mert ugye nem hopogható meg, hogy hogy lehet üzleti értéket teremteni hozzá. És mi egy ilyen fajta, ilyen rövidebb projekt életciklusú, proof of verio kis projektekbe visszük bele az ügyfeleinket, ahol nem elsősorban magán a coding megoldáson, hanem inkább azon van a hangsúly, hogy mit fog csinálni az AI Use Case, hogy fog ez megtérülni, milyen adaton, milyen szereplőkkel és milyen folyamatokon megy keresztül, mert ami működött mondjuk az A banknak, az nem biztos, hogy működni fog a B banknak is, bár vélhetően működni fog, hogyha ez egy ilyen iparágba bevált use case, de ettől függetlenül nem törvényszerű, vagy lehet, hogy nem pont úgy fog működni. És ugye ezeknek az ügyfél közös munkákból az fog kiesni egy 2-3-4 hét alatt, hogy kap egy tiszta választ arra, hogy ezzel érdemes tovább menni vagy nem. És akkor ez alapvetően egy alacsony költségszinten lehet validálni. És egyébként sokszor az is értékes válasz, hogyha az jön ki belőle, hogy nem érdemes vele foglalkozni, és akkor másra lehet fordítani az erőforrásokat.
- Ez a proof of verio, ez igazából a TC2-nek a módszertana, ti hoztátok a házasságba, és a fölvásárolt cég, ő mit hozott az AI terén?
- Ők nagyon ügyesek a szoftverfejlesztésben alkalmazott AI-jal, de ugye itt is többféle eszközt és technológiát meg lehet különböztetni. Tehát alapvetően azért mind a ketten, tehát mind a két oldal a TC2 meg a kombinát is azt vallja, hogyha nem lehet pontosan utókövetni, hogy mi van a kódban, akkor azt azért mi nem visszük productionbe. Tehát ugye itt várni kell pont, és igen, a hosszú bevezető után ide akartam kanyarodni, hogy van az úgynevezett Vibe coding, ugye, amikor megmondjuk, hogy mit csináljon a code, leírjuk emberi nyelven, és akkor azt gyönyörűen kigenerál nekünk egy alkalmazást, és akkor csili-vili működik, meg frontendet rak hozzá, és akkor elindul a gépünk, lokálisan a számítógépünkön futtatva, de hogy ez, mi úgy gondoljuk, hogy ez csak a validálásra jó a mai állapotok szerint, mert nem tudjuk, hogy mi fut benne. Tehát ez egy Blackbox. És akkor, ha meg úgymond production ready kódot fejlesztünk, akkor inkább, és ez inkább nyilván a kombinált asztala, alkalmazásfejlesztés terén, inkább assistic kódfejlesztés módszerekkel, tehát ahol tudjuk követni, hogy mi van a kódban, hogy hogy valósul meg, tehát hogy nincs kiadva ez a fajta kontroll a kezünk közül, de előtte már ez validálva volt, hogy az ügyfélnek ez hasznos lesz. Úgyhogy a kombinált az erős skillekkel jön az alkalmazásfejlesztés terén. A TC2 inkább operatív oldalról, tehát nekünk az MSP üzemeltetésünkben is rengeteg helyen van használva már AI. Sokkal hatékonyabb, sokkal gyorsabban meg lehet állapítani hibákat, lehet felülvizsgálni különböző környezeteket. És hát van ennek a kettőnek a metszete, hogyha valamilyen üzleti use case-t találunk ügyfeleknek, azért ilyen is van. Nyilván nem lettünk hirtelen domain expertek, nem tudom, ilyen-olyan területen, azonban az ügyfelekkel karöltve, illetve egy kis business consultinggal kiegészülve azért erre is vannak jó példáink, hogy különböző területeken akár banki ügyfélszolgálatnál ilyen AI asszisztenst, vagy ugye nagyon ráfeküdtünk most a Contact Center megoldására az AWS-nek, és akkor az több ügyfélnél is erő jön, az is körbe van véve különböző AI és öntökkel, hogy segítsék az ügyintézők munkáját. Tehát ilyenfajta use case-ekre lehet gondolni. Mindezt úgy tesszük meg, hogy mi nagyon erősen ismét csak AWS First gondolkozásmóddal. Az AWS-nek van a Bad Rock keretrendszere, ami véleményem szerint egy nagyon jó, talán egyedülállónak is mondanám, hogy olyan garanciákat ad, hogy az adatunk is ott marad az adott környezetben, és az AI öntök használatánál sincs visszatanítva a különböző külső providerek által adott modellek, hanem csakis az ügyfélnek a saját kérdésének a megválaszolására van használva az adat, és hát ugye többféle modellt is lehet használni, tehát ez nem csak AWS modellek. Tehát ez a fajta ilyen modell és gyártókiszolgáltatottság sincs meg, mert nyugodtan a Bad Rock keretein belül csak egy egyszerű átkonfigurálással át lehet menni más, lásd Language modellek használatára. Ugye vannak különböző guardierek, amiket csak konfigurálni kell, tehát hogy keretet szabjunk a működésének, az elemnek. Úgyhogy mi azt látjuk, hogy ez egy egyedülálló keretrendszer, és mi ennek a tetejére építettünk egy olyan kasztumizációt, ami kvázi úgy néz ki, mint mondjuk a Chatgpt, de használatarányosan árazódik, tehát nem ilyen periuzer ára van, hanem tényleg a hányadik vesztett megtokent elégetünk. És ugye nagyon jól lehet integrálni különböző enterprise rendszerekkel, ezekkel az úgynevezett MCP szerverekkel. Úgyhogy most ebbe kicsit így belemélyedtem, bocsánat, ez egy hosszú válaszra sikerült.
- Szerintem volt egy pont, ahol a Peti érdeklődését felkeltetted.
- Nemcsak hogy az érdeklődésemet felkeltetted, hanem a kérdésemre is megadtad a választ, úgyhogy gyakorlatilag mintha kiugrottunk volna, vagy túlugrottuk volna, mert pont ezt akartam kérdezni, hogy oké, hogy így az élet már az értékláncba építve adjátok meg, vagy gyakorlatilag így biztosítsátok, de hogy a vállalatvezetők meg a jogi vezetők is mindig aggódnak az AI-nak a megfelelősége, az általa kezelt adatok, gyakorlatilag a jogi kockázatok miatt, és nekem az lett volna a kérdésem, hogy ti hogy garantáljátok az AI által támogatott folyamatokat, erre teljeskörűen megadtad a választ, hisz helyben vannak az adatok, figyeltek a Norditension Policy-re, figyeltek arra, hogy szabadon lehessen változtatni a modell, nincs ez a Vendor Lockintól való félelem. Úgyhogy én úgy gondolom, hogy tökéletesen választ kaptam. Köszönöm.
- Igen, egyébként a szabályozás volt a mozgatórugója, hogy ezeket végigvettük, hogy milyen funkciók vannak, voltak, illetve aktívan követtük ezeket az új feature-öket, az AWS is őrült tempóban adja ki az újabb és újabb funkciókat, amiben az a szuper szerintem, hogy ezt nem csak egy modellre, hanem az összesre lehet használni, tehát egyébként nagyon ügyesen követik.
- Igen, platformként állnak hozzá abszolút, és pont az adás előtt beszélgettünk a Petivel, hogy ezekben az években most nagyon-nagyon könnyű elveszteni a fonalat az AI területen, mert nagyon sokrétű és nagyon sokféle fejlesztés igénybe vehető, és egy nagyvállalatnál aztán meg ez sokszorozottan jelentkezik az egyedi területi vagy igazgatósági vagy folyamati use case-ek miatt. Szakmai kíváncsiság említetted itt a különböző ISO megfeleléseket, hogy a 42 ezer egy ilyen menedzsment megfelelésen gondolkodtatok már?
- Gondolkodtunk már, még nincs meg egyelőre, de.
- Kábé senkinek nincs itthon szerintem, mert nagyon új, de hogy egyre többfelől hallom ezt, hogy jó lenne egy kicsit korlátok közé, meg nem is a korlát a lényeg, hanem követhetővé, felügyeltté tenni az AI használatát az egész szervezetben, meg olajozottá tenni a be és a kivezetési döntéseket is.
- Pont itt a Governance-szektorban beszélgettünk az EY Governance-szel kapcsolatban, és pont az merült föl, hogy már ez a 42 ezer nagyjából meg tudná oldani, de te is említetted, hogy saját belső use kézeitek vannak, illetve folyamataitok, úgyhogy az látszik, hogy rendkívül mód készültök az AI-ekre. Ugye tudjuk, ez várhatóan a legnagyobb mérföldkő augusztus 2-án lép életbe, ha el nem tolja most az Európai Bizottság ennek a bevezetését.
- Az AWS is ugye a különböző partneri programokkal abszolút ebbe az irányba tereli az összes partnert, tehát hogy olyan megfelelőségi pontok vannak, amik teljesen egy húron pendülnek az ISO, meg AI-k megfelelőséggel, tehát egyirányú utca úgymond, és az AWS meg a platformba is ezeket a dolgokat fejleszti bele, tehát hogy úgymond csak arra kényszerít, hogy amit odaad használatra, azt használjuk is és jól használjuk. Úgyhogy igen, ilyen szempontból ez egy jó pálya.
- Nem csak adja alá a lovat, hanem zablát is ad hozzá.
- Így is mondhatjuk.
- Ha emlékeztek a múltkori műsorban pont arról beszéltünk, hogy ugye ezek a nagy európai uniós általános szabályok, ezek mennyire korlátozzák itthon a fejlődést, akár az egész EU-n belül, és akkor mondtam, hogy például a GDPR-nak köszönhető a szuverén adatfelhő.
- Ugye a múltkor pont ez volt a témánk. És most gondoljatok bele, hogy mondták, hogy majd az AI-t nem fogjuk tudni fejleszteni, meg teljesen elmaradunk Amerikától meg a kínaiaktól, és ahhoz képest már az AWS úgy fejleszti direkt le, hogy már megfeleljen az AI-knek a megoldásainak, és már komplex módon adja át számotokra is, illetve az Európai Unión belüli cégek számára is.
- Úgyhogy azért ennek van pozitív hozadéka, én úgy gondolom.
- Igen, igen. Az AI sok esetben a megfelelőséget is segíti, hogy ezt könnyebb legyen felmérni, megugrani, abszolút, igen.
- Félidő van, nem tudom, mennyire emlékszel, mi szokott ilyenkor történni a Vidi Podcastban. Emlékszem. Jön a személyes szál. Legutóbb Károlynak a kávé vagy tea kérdését szegeztük, de most így a 10. születésnap kapcsán süti torta édességek témáját vetném fel, hogy mennyire vagytok édesszájúak, van-e kedvencetek, süttök-e magatoknak, vagy megveszitek a boltban.
- Ilyesmi.
- Na, akkor kezdem én. Én szoktam enni azért édességet, igen, de minden alkalommal a boltban veszem meg. Inkább ilyen gyümölcsös vonalon mozgok egyébként, vagy inkább savanyú és édes, úgyhogy krémesek, meg ezek a paleo sütemények is bejönnek, egyébként azok is finomak, úgyhogy ami nagyon cukros, azt nem szeretem, mert attól elálmosodok, és akkor puff, elalszom tőle, úgyhogy ez a veszély van csak benne.
- Peti?
- Én inkább sósszájú vagyok és a pogácsák nagy hívője, úgyhogy főleg egy kis gouda sajtos pogácsa, vagy valami hasonló, azért az nehéz ellenállni neki.
- De mostanában ellene tudsz.
- Mostanában igen, rendkívül modellen állok mindennek, de ez egy külön történet.
- Én egyébként relatív édesszájú lettem, nem voltam feltétlenül mindig az. Egyébként gyerekkoromat így szívesen emlékszem vissza, hogy amikor én egészen kicsi gyerek voltam, akkor még háztól hoztuk a tejet a tehenészetből, és annak az volt a tulajdonsága, hogy hajnalban elhoztuk, és akkor estig a tej tetején volt egy ilyen 10 százalék tejszín, tehát 5 liter tejből, mondjuk egy nagy fél liter tejszín ott összegyűlt, és akkor azt így leszedtük, hogy ezt-azt készítünk belőle, de az volt a kedvenc édességem, hogy abba egy kis cukrot keverni, egy ilyen kis csészébe, és akkor azt kanalazgattam. Ma már én is inkább a péksütik, meg kókuszgolyók világában, de valamennyire korlátozom én is, mert ha nagyon sokat eszem, akkor utána igen, az kiüt teljesen.
- Érdekes dolog fölhozta egy régi emléket. A nagymamám sokat sütött, még emlékszem, a vájlingba gyúrja a tésztát, és hogy a nyers tészta alapján meg tudtuk neki mondani, milyen süti lesz, tehát mi is ettünk azért egy nyers tésztát rendesen. Emlékszem az ízére, ez nagyon szép emlékeket hoz föl.
- Nekünk a szembe szomszéd nénink még konkrétan tésztaüzemet is, vagy hát manufaktúrát az asztalon működtetett, voltak ilyen kis fémgépei, és akkor.
- Azon is lehetettek elindulni.
- Abszolút, úgyhogy hát igen, ez egy letűnt világ, és az informatikában is néha az az érzésem, hogy már ilyen letűnt világok vannak és az újak nagyon mások. Most Károly, te tulajdonos is vagy gyakorlatilag a kezdetektől. Amikor elkezdted a TC2-t, akkor ez mondjuk 100 millió forintos forgalmú cég volt, most több mint tízszer annyira milliárd fölött van a forgalom. Nekem ez nem tűnik egy ilyen triviálisnak, hogy maga a felhőtechnológiának a piaca, igénye növekedett ilyen mértékben, vagy ti ezt a piacot is felülmúlva tudtatok növekedni, és mi ennek a titka, hogy jókor voltatok jó helyen, vagy van valami olyan know-how, most nem biztos, hogy ezt el lehet mondani, de mégis, amivel fölül tudjátok múlni a piacot.
- Ez érdekes kérdés. Egyébként nem tudom, hogy felette vagyunk, vagy nem, ugye a növekedési trendnek, de hát amikor mi piacra léptünk, akkor Magyarországon azért nem volt annyira felhőpiac, tehát akkor ez egy egzotikus valami volt. Nem volt sok versenytársunk sem, és nagyon sok idő abban ment, hogy népszerűsítettük a felhőt kvázi. Ha meg a mai állapotokra nézek, akkor ugye az a fura, ha valaki nem használ felhőt, tehát hogy annyira adja magát nagyon sok esetben, hogy az ellentétjére fordult a helyzet. Nyilván valaki nem használ, meg nem mondom, hogy mindenre jó, de azért kevés az elképzelhető mai modern bármilyen cég, aki ne tudna valamilyen jó ponton használni felhőt. Úgyhogy ezzel együtt nekünk szerintem mindig is az volt a stratégia, hogy a szakértelembe és az átláthatóságba, tehát a megbízhatóságba fektetünk, és kitartóan építettük ezt a Renomét, ami úgy gondolom, hogy ma is megvan, és erről ismernek minket. Ma már elsősorban nagyvállalati szektorban, úgyhogy talán jókor is voltunk jó helyen, tehát mindig kell egy kis szerencse is, én azt gondolom, de kell a többi is, kell a tudatos építkezés, hogy ezekbe a különböző skillekbe és tudáshalmazokba invesztáljunk, és akkor ezeket organikusan vagy akvizitív módon kialakítsuk.
- Van még a Robinak egy erős mondása, most erről a fenntarthatóságról jutott eszembe, hogy nem technológiát akartok eladni, hanem nyugodt döntéseket. És azon gondolkoztam, hogy itt a felhő világában is, meg különösen az AWS, meg a ti módszertanaitok világában ugye mindent mértek, mindent követtek, nyomon követtek, monitoroztak és kiszámoltak, és még előre is, közben is és a végén is kiszámoljátok. Hogyan mérhető a nyugodt döntés. Vagy ez az a része, amit már ti sem számoltok.
- Hát az ügyfeleink biztos, hogy számolják, mert a nap végén döntéseket hoznak. Szerintem az üzleti siker ennek a mérőszáma. Több olyan példát is láttam az ügyfeleknél, amikor nem voltunk bevonva, vagy csak utólag voltunk bevonva, és akkor ennek vannak ilyen tipikus példái, hogy túl drága felhő.
- Igen, az ügyvédi világban is előfordul utólag túl drága.
- Igen. És egyébként akkor volt, hogy megnéztük, igen, ezt így kéne, azt úgy kéne, hát újra kéne építeni az egészet, mert nem jó lett megtervezve, és hát de hát ez akkor még jobban nagyon vágja az egészet. Tehát sok olyat láttunk, ahol lemigrált az ügyfél a felhőből, mert nem adta meg a kellő időt és szakértelmet, vagy esetleg partneri segítséget nem mond be az elején, és aztán egy ilyen zsákutcába sakkozták magukat. Egyébként ez nem csak költségre, hanem olyan is van, hogy túl lassú a rendszer, tehát akár performanciára, vagy túl lassú a szervezet. Egyes kérések ott álltak 3-6 hónapot, és ennyi erővel akkor hagyományos Data Centerben is lehetnénk és dugdoshatnánk a kábeleket a gépekbe. Tehát, hogy ugyanoda sakkozták el magukat, olyan folyamatokat alakítottak ki. Azért én büszkén állíthatom, hogy az összes ügyfél, aki felhőbe jött velünk, az vagy ott van, vagy nyilván volt, aki lemigrált, mert mondjuk a live cycle végéhez ért, tehát az életciklusának a végére ért az adott alkalmazás, tehát akkor azért lett ilyen dicomation állapotban, vagy van, aki már nem velünk van, mert úgy döntött, hogy felvesz egy csapatot, egy belső csapatot, és akkor átadtuk a tudást, de mindenki vígan elvan az AWS-ben, és jó költségszinten és jó hatékonysággal és jól tudják az üzleti igényeket lekövetni. Úgyhogy igen, elég sok példát látni jóra is, meg kevésbé jóra is.
- Oké.
- A nagyvállalati döntés azok számára a nyugodt döntés gyakran jogi és szerződéses garanciákban testesül meg.
- Igen.
- Amikor full stack MSP-ként teljes körű menedzseri ment szolgáltatást nyújtotok, hogyan fordítódik le ez a nyugalom a szerződések, az SLA-k és a felelősségvállalás nyelvére. Vagyis mitől aludhat nyugodtan egy jogi igazgató, ha TC2-vel dolgozik.
- Az AWS és a partner és az ügyfél között van az úgynevezett shared response bility modell, a megosztott felelősség, amiben nagyon egyértelműen látszik, az AWS miért vállal felelősséget, és egyébként jellemzően a platformszolgáltatásokra, azokért vállal SLA-kat, és annak a mikéntje, tehát hogy hogy van beállítva és hogy van használva, hogy milyen adat van benne, az pedig az ügyfélre per, a partnerre van bízva. És mi egyébként ezt a légüres teret, valamikor légüres teret töltjük ki, mint partner. Tehát hogyha nincs meg ez a fajta AWS tudás, hogy hogy legyen kezdetileg kialakítva, aztán hogy legyen felügyelve, hogy legyen optimalizálva, hogy legyen nem várt hibák esetén a hiba elhárítva, tehát erre mind mi SLA-t vállalunk. Mi egyébként mára nekünk van több ilyen AWS partneri rangunk, van a Solution Provider partner, ami azt jelenti, hogy tudjuk továbbértékesíteni az AWS kapacitást diszkont áron az ügyfeleknek. Ugye vagyunk a Meryl Service providerek, hogy tudunk üzemeltetni és optimalizálni az ügyfeleknek, és mi vagyunk partner lett support partner is, ami azt jelenti, hogy mi szintén nem is csak hogy diszkont áron, de egy sokkal jobb konstrukcióban tudjuk az AB és Enterprise supportot úgy adni az ügyfeleknek, hogy az Enterprise support az a level 2, egy ilyen üzemeltetési felállásban, és mi vagyunk a level 1. Tehát kvázi az AWS ad nekünk supportot és a TC2 ad az ügyfélnek. És ugye ezzel együtt ez is megegyezik az AWS által adott SLA-val, amit mi vállalunk, csak ugye jó a konstrukció, meg hát igazából gyorsabb az elhárítás, mert mi ismerjük az ügyfélrendszereket. Egy enterprise supportnál azért valahova becsattan valószínűleg Indiába a levelekben. Tehát végül is mi ezzel gyorsítjuk a folyamatot. Tehát hogyha valamit infrastruktúra, mint kóddal, az az automatizálva van elsőként lerakva AWS-ben, akkor azt úgy is kell üzemeltetni. És akkor van ugye egy change management posses, amiben nem kézzel állítgatunk dolgokat, hanem infrastruktúra, mint kóddal változtatunk a meglévő infrastruktúrában. Mert ugye hogyha elkezdünk kézzel belenyúlkálni, akkor szétesik ez a rendszer. Ugye ilyen driftet okozunk, ugye ezt így mondják. Szerintem erről már korábban is beszéltem. Ugye bármilyen auditot kap az ügyfél, hogyha regulált környezetben működik, akkor végképp szeretik az auditorok. Hogyha mondjuk, hogy ez egy infrastruktúra, mint kóddal lett lerakva, és emiatt ugye önmagát dokumentálja kvázi a kód, amivel le van rakva. Minden változáson látszik, hogy ki futtatta a változást. Miért futtatta, kikérte? Lehet rollbackelni, lehet visszaállítani, hogyha valami nem jól sikerült. Tehát ez ugye az ultimate megoldás, amikor vannak ilyen auditok, aztán nem is mindenre, de nagyon-nagyon sok ilyen dobozt kipipál ezzel az ember. Úgyhogy ez mind összeáll. Tehát ezek sok ilyen kis apró aspektusa annak, hogy mi menetszüret provalderek vagyunk, és hát ennek a kombinált is a részesei, tehát ezekbe a folyamatokba őket is bevonjuk, tehát ilyen szempontból mi vagyunk a fővállalkozó, tehát mi vagyunk az MSP, ők mint működő partner, ezek a csapatok működnek a különböző alkalmazás optimalizációs, meg refaktoring tevékenységekben.
- Úgy is megfogalmazhatnám, hogy amit ti csináltok, az elejétől a végéig van. Tehát, hogy ti az ötlettől a működő skálázható alkalmazásig el tudtok juttatni egy céget, ha akarja és ha képes rá. Ugye azt hiszem, az AWS-nél ezek a szavak vannak, hogy a discovery, a build Migrate az Operate és még az Optimalis fázisra talán a legvége. De vajon mennyire képesek erre az ügyfelek, illetve inkább pontosabban kérdezve, hol vannak a gyenge pontokat tudásban, képességben vagy akár kapacitásban a hiányok ezeknél a nagyvállalatoknál, ami igazából akadályozza őket a továbbfejlődésben, vagy a kiteljesedésben, és mit tudtok ebben mondjuk ti hozzátenni, hogy hol vannak ezek a gyenge pontok, és hol vannak azok a módszerek vagy tréningek, vagy lehetőségek, amivel hogyha ők erre nyitottak, akkor ezt be tudjátok foltozni nekik.
- Ezt nagyon jól mondtad, ez most nagyon tetszik. Tehát az elejétől a végéig tényleg tokkal-vonóval mi ezt meg tudjuk valósítani. Tehát ha azt mondanád nekem, hogy fejlesszünk egy nem tudom, valamilyen alkalmazást, ami ezt és ezt tudja, és akkor rá szeretnék ereszteni egy millió usert, aktív usert mondjuk ekkor. Mi azt vígan és dalolva megcsinálnánk neked, mint szoftver, ez egy service akár. Ugye nyilván nem ez a valóság. Tehát jellemzően az ügyfelek már meglévő kötöttségekkel, technológiai kötöttségekkel, jönnek elképzeléssel, ami nem baj, ami köré tudunk mi dolgozni, illetve hát ahol ez a szép álomvilág meg szokott szakadni, az ugye a meglévő rendszerek integrációja. Nyilván egy új rendszert a meglévőkkel össze kell integrálni. Egyébként szerintem nagyon erősek vagyunk hagyományosan, hogy nagyvállalati környezetben nagyon sok hibrid felhős környezetet építettünk ki, ahol az AWS minden esetben csatlakozik más platformon lévő jellemzően on-premise rendszerekkel, jellemzően legaszi rendszerekkel, tehát a modern alkalmazásokat összekötögetni az jellemzően nem olyan nagy kunszt. Úgyhogy szerintem mi ebben is tudunk pluszt nyújtani, hogy most már nem csak a modern alkalmazást is tudjuk kifejleszteni és aztán üzemeltetni, hanem a régi világgal is össze tudjuk hatékonyan kötni.
- Nagyon udvarias a Károly, mert még mindig nem mondta el az ügyfelei gyenge pontjait, de megkérdezem még egyszer. Mi az, ami jellemzően, ha van ilyen, hogy jellemzően nem megy jól még ezeknek az itthoni ügyfeleknek, amiben fejlődniük kéne, meg amiben tudjátok őket támogatni, és akkor, ha azt megtanulják, megoldják, vagy bevezetik, vagy bővítik, stb., akkor tudnak a következő szintre lépni. Ezt azért kérdezem, merthogy azt még mindig kevesen tudják, de hogy ez nem osztogatja az Amazon, vagy bocsánat, az AWS így olyan könnyen ezeket az MSP meg egyéb címeket, tehát hogy a világban nincs nagyon-nagyon sok cég, aki ezt tudja, nemhogy Magyarországon. Ezáltal nektek a TC2-ben van egy nagyon magas szintű tudásotok. És ti ahhoz képest tudjátok szerintem kicsit elemezni az ügyfeleknek az érettségét, meg a hiányosságait.
- Ilyen általánosságokat tudok csak mondani, hogy ugye elsőnek meg kell tervezni valamit, és aztán megépíteni. Van, ahol már ez is a földbe áll. De nagyon sok esetben nem áll a földben, és meg van építve valami, ugye ügyfél által, és akkor jön a következő, ki üzemelteti? Jellemzően nem az üzemelteti, aki megépítette.
- Ezt fel nem foghatom.
- Hát az új generációs, vagy újfajta kisebb cégeknél egyébként nagyon sok esetben így van.
- De már 10-12 éve van devops módszertan. Tehát, hogy ott kéne ülni a fejlesztők mellett abban a projektcsapatban, majdnem azt mondtam, hogy fejlesztőcsapatban. A projekt csapatban az üzemeltetőnek is. De akkor ezek szerint ez egy következő gyenge pont, ami fejlődik.
- Igen, én azt látom, hogy elvileg van ilyen, de még mindig sírósodva vannak, főleg a nagyvállalatok, meg a szervezetek. Tisztelet a kivételnek. Egyébként látok jó példát is, meg látom, ahol van külön dedikált felhőcsapat. Nyilván a dedikált felhőcsapatnak össze kell hozni akkor az Onpremmel, tehát hogyha ez össze van kötve ez a két világ, és akkor mondjuk lehet tudni monitorozni, meg hibát elhárítani, de egyébként még így is, ezzel együtt is sok esetben úgy kezelhetik a felhőt, mint a régi világban, hogy akkor ez öt évre van, és akkor lelöki a sarokba. De hogy ugye a valóság az nem így működik.
- A felhőben különösen nem.
- Igen, igen. Úgyhogy érdemes beleinvesztálni, mert csak annál jobb lesz, és akkor ugye vagy költségcsökkentéssel, vagy magabiztosabb működéssel, vagy hibamentes működésre hálálja meg ezt a plusz törődést, amit egyébként sok esetben régebben ezt nehéz volt eladni, tehát hogy miért kell vele folyamatosan tűrni. Tehát költünk az alkalmazásra, ami már egyszer fut, de hogy azért költünk rá, hogy aztán olcsóbb legyen, tehát ez visszahozza az árát több fronton is. És hát akkor most az AI funkciók az egy újabb LA-re, tehát hogy most mondhatnám még az automatizációt, meg infrastruktúra, mint kód, ami az előbb szóba került, akkor az AI funkciók, hogy azt hogy használjuk, tehát ugye itt is van valóban egy jogos félelem, tehát hogy mit engedünk és mit nem engedünk, meg hogy hol legyen az a bizonyos emberi kontrollpont a folyamatban, mert persze, hogy kell, de hogy hova, és meddig lehet elengedni, és meddig nem. És nyilván egyébként ez nekünk is egy folyamatos tanulás, tehát ahogy fejlődik az AI és újabb és újabb use case-eket találunk, ez egy nagyon izgalmas, ami a teljes cég mögé van állítva, tehát nemcsak a szakmai emberek, hanem a back office és a sales és mindenki. Úgyhogy nem tudom, hogy válaszoltam-e a kérdésre.
- Majd a hallgatók eldöntik.
- Én még az üzemeltetésnél maradnék egy kérdés erejéig. Ugye jogi és üzletmenet folytonossági szempontból sok nagyvállalat tart a technológiai bezártságtól, vagy hát említettem ezt a vendor lockin kockázatot az üzemeltetési fázisban. Amikor elvégzitek ezt a felhőérettségi vizsgálatot különböző dimenziókban, akkor hogyan építetek be egy olyan jogi és stratégiai rugalmasságot a rendszerekben, hogy az ügyfél ne érezze azt, hogy csapdába kerül hosszú távon, hanem addig dolgozom veletek, amíg valóban az előnyét élvezi.
- Hát ez a TC2 szempontból mi nem építünk be ilyen kötöttségeket, tehát addig van velünk az ügyfél, amíg ennek értelmét látja, tehát ugye a szerződéseink értelmében, illetve a megoldásaink tekintetében minden dokumentálva a rendelkezésére bocsátunk. AWS szempontbó, hogyha azt feszegetjük, hogy van-e lokin, meg hogy hogy lehet, hogy exit plan legyen minden ilyen ügyfél engagementhez. Igazából ez attól is függ, hogy milyen területen működik az ügyfél, tehát hogy mennyire regulált, de mondjuk tipikusan egy banknál megvan az a fajta technológiai stack, amit szeretnek használni, és amit én úgy látom, hogy mindenki használ, ami jellemzően open storce alapú, de mégis menedzselt szolgáltatásokra épül, tehát hogy ilyen, nem is tudom, hogy ez cloud natív, vagy ez inkább ilyen cloud cloud natív ez is egyébként. Tehát a Kubernetes, meg a monitoring toolok, meg a relációs adatbázisok és barátaik. Úgyhogy ez egyfajta biztonság egyébként, hogy ha szükséges, akkor át lehet vinni más fejbe, vagy le lehet vinni földre. Egyébként az újabb gondolkodásban, vagy hogy úgy mondjam, tehát én személyesen is azt gondolom, hogy ha exitről beszélünk, akkor ami igazán számít, az az adatunk, meg a szellemi termékünk. A többi az mind körítés egyébként. Az, hogy ez egy technológiai futtatói környezet is megy-e vele úgy, ahogy eddig, az már részletkérdés. Lehet, hogy nyilván többet veszítünk azon, hogyha az egészet refaktorálni kell, mert igazán cloud natívban voltunk, tehát ami AWS specifikus, ugye szerver lesz megoldások, viszont lehet, hogy sokkal többet nyerünk addig az ideig, amíg az exit be nem következik. Ami ugye sok esetben soha nem következik be az exit. Úgyhogy ilyen szempontból is főleg most itt ma, hogy itt az AI korát éljük, tehát egy alkalmazás refaktorunk sem addig tart, mint régen, hogy akkor na, akkor állítsunk rá 20 fejlesztőt és akkor elkezdenek ott zongorázni a billentyűn, hanem rettentő gyorsan egy meglévő funkcionális, jól felépített kódot simán át lehet rakni valamilyen más technológiára, úgyhogy elgondolkoztató, tehát tényleg, hogy a kitettség, a vándorlóként, meg az exit mentén miben merünk és miben nem merünk invesztálni, mert a végén csak arról fog szólni, hogy az ügyfeleinknek valamilyen árszínvonalon tudunk adni szolgáltatásokat, tehát ez meg piaci versenybe fog aztán beesni, tehát minél jobbra tudjuk faragni ezt a modellt, annál előrébb leszünk a valós versenyben.
- Itt a felhőátállások, meg a felhő alapú növekedés vagy IT infrastruktúra fejlesztés évei alatt folyamatos volt az ár körüli vita. Tehát, hogy mennyire könnyen elszállnak a felhőárak, ez mekkora anyagi kockázat egy cégnek, ez az AWS natív út, meg hogy olyan gyorsan változnak a technológiák, hogy mi lesz, ha egyszer nem tudja követni a platform, és akkor hogy tudunk majd onnan exitálni. De hogy azt lehet mondani, hogy az AI beköszöntével, vagy így az AI által támogatott kódolásnak a beköszöntével ezek a felhőszolgáltatási költségek is csökkennek? Merthogy azt mondjuk, hogy ha könnyebb migrálni, akkor muszáj olcsóbbnak is lenni. Ugye nyilván a rutin is azt diktálná, hogy mivel most már komorító termék a felhő, ezért legyen olcsóbb, mint amikor nagyon izé volt. Másfelől meg azt halljuk, hogy a mögötte lévő mind a számítási kapacitás, mind a tárhely sokkal drágább ma, mint amikor elindultunk a felhőbe, merthogy a chip árak, meg a nem tudom, meg az energiaárak. Szóval ez egy összetett kérdés. Én igazából oda szeretnék kilyukadni, hogy mi kerül ma elő egy IT igazgató vagy egy IT architekt beszélgetésben az AWS kapcsán. Nektek az AWS-ről szól a nagy része a munkának, tehát elég specializáltak vagytok ebben, nyilván van egy ilyen kockázat, hogy amerre az AWS mozog a piacon, ti is arra fogtok mozogni fölfelé is, meg lefelé is.
- Ez valóban egy komplex kérdés. Egyébként az AWS, ezt mindig mondom, de ez igaz, hogy ők folyamatosan vagy csökkentik az árat, tehát sosem növelik, és ez még mai napig igaz ez a trend, ami egy tök jó sztálink volt az AWS-re, és úgy tudom, hogy a többi felső szolgáltató nem ennyire drasztikusan tart ki emellett. Egyre több megújuló energiaforrásból fedezik a futási költségeket, és hát valahogy ezt kitalálják, hogy ez hogy működik. Egyébként, hogy milyen kérdések kerülnek elő ma, leginkább az a driver, hogy amilyen funkciókat elérhetünk, szolgáltatásokat a felhőben, az ma nincs on-premise-ben. A felhőben is a publikus felhőszolgáltatók a legnagyobb ilyen gravitációs mezőt képviselnek, odavonzzák a többi kis szolgáltatót is. Emiatt egyszerűen velük éri meg elkezdeni próbálgatni új technológiát, mert sokkal-sokkal. Mondjuk, hogyha 6 hónap mire kifejlesztünk egy ilyen megoldást, ott már rég elszaladt mellettünk a világ. Tehát, hogy erre nincs ennyi idő. Hát most, hogy ettől olcsóbb lesz-e vagy nem, most pont ezen gondolkoztam, amikor ezt kérdezted, hogy alapvetően az az olcsóbb, amilyen gyorsan tudunk piacra lépni egyes funkciókkal. Ez inkább a produktivitásban mérhető olcsóság. Egyébként hozzáteszem, hogy az AI-t is, hogyha elkezdi füstölni az ember, akkor nagyon jó kis számlákat tud kapni. Nem, hogy nem olcsóbb, de el tud szállni az ára. Azt is meg kell figyelni, hogy milyen modellekkel dolgoztatunk, milyen feladatokra. Ez ugye triviálisnak tűnik, de egyáltalán nem az, hogy mikor van az, hogy már valamelyik Goodynuf, és nem használom mindig a legfrissebbet olyan találatokra, amikre sokkal gyengébb modell is elég lenne. És akkor egyébként nyilván az ilyen újító projektek hátán meg jönnek a hagyományosabb migrációk is a hátukon. Tehát hogyha már ezt felvittük a Földre, akkor azt is érdemes, de akkor ugye a data gravity miatt, tehát hogy ne húzgáljuk át az interneten keresztül a rengeteg adatot. Nagyon sok esetben költöznek egyes kórrendszerei is az ügyfeleknek, és akkor ez képvisel egyfajta és hát nyilván az árak, tehát hogy az AWS is csábítgatja át akár a versenytársaitól is az ügyfeleket, tehát olyan programokat csinálnak, ahol egyszerűen kijön a matek. Tehát, hogy az első három évben mondjuk a migráció elején lehet, hogy drágább lenne az ügyfeleknek, akkor arra kínál egy jelentős árkedvezményt, utána meg úgyis modernizálni fog az ügyfél. Mi is ezen vagyunk, és hogy ezzel így költséget csökkentsen, de nagyon sokszor megkapjuk a kérdést, hogy mi nem-e azon vagyunk mérve, hogy minél többet költsön az ügyfél, és hogy ne pumpáljuk felfele a költést, de hogy ennek sosincs jó vége, mert akkor egy idő után ki fog szállni az ügyfél ebből a játékból és elmegy, úgyhogy még mindig azon vagyunk incentiválva, hogy csökkentsük ezeket a költéseket, és hogy ez a well architected review framework, ez egy nagyon régi keretrendszer, hogy hogy lehet olcsót és jót és megbízhatót építeni az ABS-en. Ez még mindig ma is releváns, úgyhogy még ma is ebben a programban benne vagyunk, és akkor mi ezen is vagyunk mérve, hogy hány ügyfelet tudtunk ezzel optimalizálni. Úgyhogy szerintem a piacra lépés egyébként az elsődleges, ami olcsóbb lesz az AI-jal, és azt viszont nagyon jól lehet használni. Nagyon sokféle esetben mindenkinek felgyorsítja a munkáját, és akkor végül is nem az infrastruktúra költséget, hanem a személyi állománynak a költségét tekerjük le ezáltal, tehát végül is így is van értelme, csak tényleg olyan hiúzkészeket kell keresni, aminek van értelme és hasznot termel az ügyfélnek.
- Azt hiszem, elég muníciót adtunk a közönségünknek, hogyan foglalkozzanak a menedzselt szolgáltatásaikkal.
- Károly, azaz Mr. CDO, köszönjük, hogy velünk voltál ismét a Big It Podcast stúdiójában.
- Köszönöm a beszélgetést.
- Köszönjük, hogy velünk voltál.
