3679

Cloud szolgáltatók vs. helyi infrastruktúra: se veled, se nélküled

A nyilvános felhő a vállalati automatizálás jövője, mivel az AI hatalmas számítási igényét csak a felhő tudja kielégíteni. Miért érdekli mégis a nyilvános felhőszolgáltatókat a helyi infrastruktúra még mindig, és miért kínálnak 2024-ben is olyan megoldásokat, amelyekkel helyben futtathatók a folyamatok?

A felhőszolgáltatók on-premise platformjainak rövid története

Hibrid IT-világban élünk: míg a vállalatok automatizálási rendszereinek egy része a nyilvános felhőben fut, a többi még mindig helyben érhető csak el. A felhőszolgáltatók sokáig figyelmen kívül hagyták az on-premises támogatás szükségességét, mivel a trendek miatt elavult informatikának számított. Azonban a Microsoft az ügyfelei nyomására 2015-ben változást hozott az Azure Stackkel. A többi szolgáltató sokáig elhanyagolta az a on-premises rendszerek informatikai támogatását, sőt, a piacvezető AWS még azt is megkérdőjelezte, hogy egyáltalán szükség van-e ilyen lehetőségre.

Mindez megváltozott, amikor Thomas Kurian vette át a Google Cloud vezetését, és bejelentette a Google Anthos-t. Az Anthos megmutatta, hogy még mindig van igény a helyszíni számítástechnikára, hiszen a Google – az örökké kreatív harmadik helyezett a nyilvános felhő szolgáltatók között – nemcsak helybeni támogatást kínált, de az Azure és az AWS platformokon is elérhetővé tette az Anthos-t (eredetileg az Anthos 2018-ban indult, GKE on-premises néven). Az AWS sem bírta sokáig, és a 2018-as re:Inventen bejelentette az AWS Outpostsot.

A Microsofthoz hasonlóan – az ügyfelek kérésére – az Oracle is elkezdte kínálni a Cloud@Customer-t 2016-ban, de akkor még nem volt életképes nyilvános felhő opciója, ami persze mára az Oracle Cloud Infrastructure-rel (OCI) megváltozott. Az IBM 2020-ban jelentette be on-premise kínálatát az IBM Cloud Satellite-tal (ennek előfutára 2016-tól az IBM Cloud Private). Mindezeket új generációs számítástechnikai platformoknak nevezzük, mivel lehetővé teszik a vállalatok számára, hogy ugyanazokat a munkaterheket párhuzamosan futtassák helyben és a nyilvános felhőben, ami korábban nem volt lehetséges vagy elérhető.

Miért érdemes tehát helyben futtatni a felhőinfrastruktúrát?

A vállalat szempontjából három fő tényezőre vezethető vissza, hogy a vállalatok miért igénylik a munkafolyamatok helyben történő futtatását. A teljesítményigényes folyamatok esetében, amelyek helyszíni rendszerekhez kapcsolódnak (gondoljunk a gyártásra, IoT-re stb.), a felhő teljesítménye nem biztos, hogy megfelel a valós felhasználási esetnek, és a más országokban található felhőalapú adatközpontok hálózati sebessége is lassú lehet.

Az adatok elhelyezkedése szintén döntő fontosságú; a jogi követelmények arra kényszerítik a vállalkozásokat, hogy az adatokat az ország szuverenitási határain belül tartsák. Ha nem áll rendelkezésre felhőalapú adatközpont, akkor a folyamatok házon belüli üzemeltetése az egyetlen lehetőség a vállalat számára, hogy megfeleljen a jogszabályoknak. 

Végül pedig a nyilvános felhővel kapcsolatos szkepticizmus is megmaradt; számos olyan CxO (Chief Experience Officer – ügyfélélményért felelős vezető) maradt, aki nem bízik a felhőalapú működésben, és továbbra is fizikai hozzáférést és tulajdonjogot szeretne a számítástechnikai rendszeréhez.

A felhőszolgáltatók szempontjából ezek mind erős érvek, de a szolgáltatóknak maguknak is megvannak az okaik arra, hogy helybeni futtatással is kínálják felhőcsomagjaikat. Először is, ez lehetővé teszi a szolgáltatók számára, hogy korai betekintést nyerjenek a helyben végzett munkamenetekbe. A helyben végzett munkafolyamatok gyakorlatilag a felhőszolgáltatók „malacperselyei” lehetnek, mivel átalakíthatók, és potenciális jövőbeli felhőbevételeket kínálnak a méretükkel.

Másodszor, a felhőszolgáltatók újra felhasználhatják korábbi kutatásaikat és fejlesztéseiket. A technológiai infrastruktúra szempontjából létfontosságú, hogy az helyben is futtatható legyen. Azonban az ilyen ökoszisztémák összetettek, és nehéz őket létrehozni, üzemeltetni és karbantartani, és már több mint 20 éve nem készülnek olyan alkalmazások és ökoszisztémák, amelyek ezt biztosítják.

Végül, de nem utolsó sorban, ezáltal a szolgáltatók növelhetik az ügyfélelköteleződést. A felhőszolgáltatók nemcsak betekintést nyerhetnek a munkaterhelésekbe az üzlethelyiségekben, hanem korán az ökoszisztémájukba is zárhatják a vállalatokat. Ez ugyanúgy érvényes mind az architektúra, mind a kereskedelmi oldalra. Ebben az esetben az on-premise szerződés is működik, és ezért felhőkrediteket ad.

Tehát, mint láttuk, jelentős célkongruencia van a vállalatok és a felhőszolgáltatók között, ami ahhoz vezet, hogy majdnem minden felhőszolgáltató kínál on-premise elérhetőséget: ezek a következő generációs számítástechnikai ajánlatok.

A megegyezőség ural mindent

Ahhoz, hogy a következő generációs számítástechnikai platformgyártók értéket tudjanak nyújtani, lehetővé kell tenniük a munkafolyamatok mozgathatóságát a helyi és a nyilvános felhőben lévő infrastruktúrák között. Külön érték, ha a folyamatok más szolgáltatók nyilvános felhőibe is átvihetőek – vagy ha egy olyan gyártó, mint az IBM, már nem játszik a nyilvános felhőpiacon. A CxO-k szeretnék elkerülni az egy szolgáltató melletti elköteleződést, és szeretnék, ha a munkaterhelésük ott futna, ahol az üzletileg, architektúrailag és jogilag megvalósítható, valamint a legelőnyösebb a vállalkozásuk számára.

A megegyezőség elég nagy kihívást jelenthet a felhőszolgáltatók számára, mivel ugyanazokat az API-kat és technológiai stackeket kell helyben futtatniuk, mint a felhőben. Sajnos a felhőstackeket úgy tervezték, hogy a felhőben fussanak – nem pedig helyben -, ami kihívást jelent a helyben történő rendelkezésre bocsátás során.

A Microsoftnak – a kezdeményezőnek – több mint három évébe telt, mire az Azure Stack-kel általános elérhetőséget biztosított. Az Oracle megegyezősége viszont figyelemre méltó kivétel, mivel – a ”felhőtörténelem” egy különös fordulata miatt – az Oracle piacra kerülésekor még nem kínált versenyképes nyilvános felhőszolgáltatást, így az Oracle Exadata és a Cloud@Customer vált az OCI sarokkövévé. A gyakorlatban ez azt jelenti, hogy az Oracle egy on-premise rendszert ültetett át a nyilvános felhőbe – ellentétben az összes többi gyártóval, akik a nyilvános felhőtechnológiai stackjeik egyes részeit alakították át úgy, hogy azok helyben fussanak.

A megegyezőség mellett a CxO-k olyan teljes átláthatóságot szeretnének, amely lehetővé teszi számukra a munkaterhelésük felügyeletét, függetlenül attól, hogy azok hol futnak. A munkaterhelések hibrid és több felhőben történő felügyeletének, üzemeltetésének és kezelésének képessége ma kulcsfontosságú a vállalatok sikere szempontjából.

Az aktuális profilok megtekintése

Hol tartanak tehát ma ezek a nagy technológiai nevek a felhőszolgáltatások terén?

Az AWS Outposts egy helyben áll, az AWS pedig tovább nyomul. Ma az AWS Outpost kínálata az AWS Outposts rackek és az AWS Outposts szerverek között oszlik meg. Az előbbi egy teljes rack, amelyet az AWS telepít, amihez a vállalatok biztosítják az áramellátást és a hálózatot. Az utóbbi az AWS által szállított és az ügyfél vagy egy harmadik fél által telepített szerver.

Az AWS Outposts rackek több helyi szolgáltatást kínálnak, mint az AWS Outposts szerverek, ezért nagyobb megegyezőséget is kínálnak. Az elmúlt években az AWS erősen promótálta az AWS Local Zones-t is, és ezért több regionális adatközpontba fektetett be, a nagy régiók kisebb alapterületűek. Ez enyhülés hozott az AWS-ügyfelek egy nem túl jelentős részének, akiknek szükségük van az AWS Outposts lábnyomának kiterjesztésére. 

A Google bár halad, úgy tűnik, hogy most egy kis szünetet tart. A Google próbálkozásai, hogy feljebb jusson a ranglétrán, folyamatos szálkák az AWS és a Microsoft szemében. Így volt ez az Anthos bejelentésekor is – azzal, hogy képes volt a modern, konténeralapú alkalmazásokat mind helyben, mind a fő versenytárs felhőjébe portolni. Ez az AWS-t az Outposts fejlesztésére késztette, így dicséret illeti a Google Cloudot, amiért képes a piacvezetőre nyomást gyakorolni. Viszont – valószínűleg az egész iparág AI-ra való összpontosítása miatt – a Google 2022 ősze óta nem bővítette az Anthost. Eközben a CxO-k örömmel fogadták a lehetőséget, hogy az Anthost VMware-en futtassák, amely több mint egy évtizede megbízható vállalati platform. Közben az Anthos Service Mesh teszi lehetővé a Google Anthos ügyfelei számára a több felhőben való működést.

Az IBM Cloud Satellite, a vállalati technológia Svájca, egyre növekszik. Mivel az IBM elvetette saját nyilvános felhő ambícióit, és az összes nagy felhőszolgáltatóval partnerségben áll, könnyen lehet, hogy az IBM metaforikus Svájccá váljon – az összes felhővel való üzletkötés semleges terepe. A Red Hat OpenShiftet hasznosító IBM Satellite pedig kulcsfontosságú ahhoz, hogy ez létrejöhessen (és visszaszerezzen valamennyit a Red Hat csillagászati felvásárlási árából). Az IBM folyamatosan bővíti a Satellite lábnyomát: az IBM Cloud Pak, az IBM Cloud Databases és még sok más, jelenleg elérhető megoldással számos lehetőséget kínál; az IBM Cloud Catalogja pedig egyre népszerűbb hely a vállalatok számára a harmadik féltől származó alkalmazások értékelésére és beszerzésére.

A Microsoft Azure Arc továbbra is népszerű, de az utóbbi időben nem sokat fejlődött. A Microsoft a szünet előtt folyamatosan fejlesztette az Azure Arcot (korábban Azure Stack), és bővítette a szolgáltatásait. Különös erőfeszítéseket tett mind az alkalmazásfejlesztés, mind a (kiber)biztonság terén, ami jól hangzik a telepítői bázis körében. A Google-höz hasonlóan a Microsoft is a kínálatának teljes körű, mesterséges intelligenciával történő átalakításán dolgozik -valószínűleg ez áll a szünet hátterében az Azure Arcnál. A jelenlegi generatív AI-mozgalom elindítójaként a Microsoft lehet az első olyan gyártó, amely valamilyen Azure Arc-alapú generatív AI-futtatóidőt kínál. A jövő majd eldönti.

Az Oracle vezet a megegyezőségben, és lassan sokdimenziós játékossá válik. Az Oracle figyelemre méltó utat járt be az on-premise-től a nyilvános felhőn keresztül most már a többfelhős megoldásokig. A többfelhős támogatás legújabb bővítményét a 2022-es CloudWorld konferencián mutatták be az Oracle Database (és ezzel együtt az Oracle Exadata) Azure-on belüli natív provizionálásával. Mivel a mindig megegyező Exadata alapplatformra építkeznek, a kínált funkciók azonosak a platformok között, ami az iparágon belüli legnagyobb megegyezést eredményezi. Mivel az Oracle komolyan fektet a mesterséges intelligenciába, hasonlóan érdekes lesz, hogy miként fogja az Oracle hozzáadni a mesterséges intelligencia-modellek erejét a platformjaihoz.

Bonyolult, de jó hír

A vállalati informatika látképe napról napra összetettebbé válik. A felhőinfrastruktúrákban a terhelés megnövekedése már most is komoly fejfájást okozó probléma. A generatív AI nem fog javítani a helyzeten, mivel új képzési és végrehajtási, valamint új, AI-ra specializált hardverplatformok fognak megjelenni miatta.

Most az AI-modellek képzése és kivitelezése teszi szükségessé a következő generációs számítástechnikai platformokat: a vállalkozásoknak a nyilvános felhőt kell kihasználniuk nemcsak az AI-modellek oktatásához, hanem az automatizálási telepítéseikben – más felhőkben és helyben, sőt akár a peremen – történő megvalósításához is. 
Egy végső gondolatként – a felhő győzedelmeskedik, de lejön on-premise, helybe. Ez jó hír; a CxO-knak van választási lehetőségük.

Vezesse be kollégáit is a hatékonyabb működés világába – ossza meg innovatív megoldásainkat!

Ez is érdekelheti

Digitális átalakulás vagy ERP-átalakulás?

Digitális átalakulás vagy ERP-átalakulás?

Először bontsuk meg a kifejezést, és vizsgáljuk meg az egyik összetevőjét: az átalakulást. Az átalakulás szótári definíciója szerint "a forma vagy a megjelenés alapos vagy drámai megváltozása". Ha...

bővebben
Junior C#/.NET szoftverfejlesztő

Junior C#/.NET szoftverfejlesztő

Feladat Vállalatirányítási üzleti folyamatok megismerése Az általunk használt keretrendszerek, saját termékeink és a vállalatirányítási rendszerek integrációs lehetőségei megismerése Ügyféligények...

bővebben
ERP-implementáció a COVID19 után

ERP-implementáció a COVID19 után

Korábban az első szintű (Tier 1) implementációhoz a projekt időtartama alatt tíz vagy akár több száz tanácsadóra volt szükség a helyszínen, de a harmadik szint (Tier 3) is megkövetelt heti pár napra...

bővebben
A diszkrét gyártók alaptípusai

A diszkrét gyártók alaptípusai

A receptúra alapú gyártással (process manufacturing) szemben – amely az alapanyagok feldolgozásával, vegyítésével formulák szerint állít elő élelmiszereket, italokat, gyógyszereket, kozmetikumokat,...

bővebben