Mi inkább a cloud ... jelenleg.

Egyéb

[...] az Egyesült Királyságban megkérdezett szervezetek 25%-a már visszahelyezte felhőalapú workload-jának felét vagy még több részét a helyszíni (on-premise) infrastruktúrákra. Ez derül ki a Cloud Software Group friss tanulmányából.

felé megyünk
62% (365 szavazat)
irányából jövünk
27% (162 szavazat)
Egyéb, leírom.
11% (66 szavazat)
Összes szavazat: 593

( _Franko_ v | 2024. 02. 18., v – 11:03 )

Meglepő módon nem mindenkinek jó a felhő, ahogy az on-prem se jó mindenkinek. Fel kell mérni, ki kell számolni és utána el kell dönteni. Na, ebből a háromból az első kettő az, amit sok helyen nem végeznek el. A másik gyakori hiba, hogy az on-prem sokszor nulla pénz az egyenletben, mert "már megvettük a vasat és van rá emberünk is", így hiába lenne olcsóbb a felhő, az ilyen "nulla" pénzzel nem tud versenyezni.

https://iotguru.cloud

( asch v | 2024. 02. 18., v – 11:15 )

Nem megyünk, nem is jövünk, mert sosem indultunk el a felhő felé :-)

Én kezdettől fogva gyanakvó voltam. Publikus weboldalt persze nem is csináltunk/üzemeltettünk soha, úgyhogy az infrastruktúra költség sosem volt óriási, ezért a spórolás eleve nem volt csillogó lehetőség.

Kiváncsi vagyok mit gondoltok erről a témáról: "AWS Fooled Devs & Sabotaged The Industry | Prime Reacts" https://www.youtube.com/watch?v=zjBx9ZgjPt4 (az eredeti videó, amire ez reakció, de ezt én sem néztem meg: "Matteo Collina on how he believes AWS fooled devs & sabotaged the industry (to make more money)" https://www.youtube.com/watch?v=7l3H6iY8Obg )

Röviden valami olyasmi, hogy a "lambda" megoldással működő milliszekundumonként fizethetjük a szervert, viszont cserébe a megoldás technikája miatt ez sokkal több lesz, mint ha egy dedikált gépen futna az alkalmazásunk. Vagy valami ilyesmi, pontosan nem gondoltam bele, de azt állítják, hogy ugyanazt sokkal olcsóbban is ki lehet hozni. Illetve máshol is megjelentek olyan cikkek, hogy a felhőről lejőve egy csomót spóroltak. Olyan cégek, ahol az üzemeltetési költség jelentős tétel a költségvetésükben.

Nekem ami alapból zsigeri ellenállást váltott ki a felhővel szemben, az a "más gépe" effektus, tehát hogy az összes adat meg minden másnál van. Ráadásul többnyire olyan USÁ-s nagyvállalatoknál, amiknek a politikáját khm khm nem túlzottan kedvelem.

Másrészt pedig a szolgáltatók azért kicsit különböznek, hogy nehéz legyen váltani, és ezért meg tudnak szivatni hirtelen áremeléssel. Meg eleve nem annyira olcsó az, ha mindent összevetünk. És valóban ott van az az effektus is, hogy a felhő miatt a fejlesztők elfelejtenek optimalizálni és a végén emiatt is baromi drága (és lassú) lesz minden.

Röviden valami olyasmi, hogy a "lambda" megoldással működő milliszekundumonként fizethetjük a szervert, viszont cserébe a megoldás technikája miatt ez sokkal több lesz, mint ha egy dedikált gépen futna az alkalmazásunk.

Aki ezzel érvel a felhő ellen, annak vélhetően fogalma sincs arról, hogy milyen választási lehetőségeket kínálnak a cloud providerek, ill. a saját alkalmazásának mi a terhelési mintája.

Csak ha ezt az egyszerű példát nézzük, van egy végrehajtandó kód, ami mondjuk napi százszor fut le, és néhány másodpercig tart. Vajon mi éri meg jobban, lambdában futtatni, vagy erre külön dedikálni egy szervert? Nyilván lambdában a felhőben.

Vegyük a másik végletet, van egy olyan kódrészlet, ami nagy terhelés alatt van, pl. másodpercenként százas nagyságrendű webes kérés kiszolgálása. Megéri ezt lambdában? Nyilván nem, mert drága lesz. Itt vélhetően jobban jársz, ha néhány VM van dedikálva neki. És akkor felmerülhet a kérdés, hogy ezek a VM-ek on-premise legyenek? Ha teljesen konstans ez a terhelés egész évben, napon belül is, és tuti biztos, hogy több évig tart a projekt, akkor valószínűleg jobban jársz on-premise. Ha lelövik a projektet 1 hónap múlva? Vagy pont az ellenkezője, várható, hogy nagyon népszerű lesz egy hónap múlva? Erősen hullámzó a terhelés napon belül, vagy az év bizonyos időszakában? Ezekben az esetekben viszont szinte biztos, hogy érdemes megnézni, mit tudsz a felhőben csinálni, ahol a terhelés függvényében tudsz indítani VM-eket, annyi ideig, amíg ténylegesen kell.

A szűklátókörűség a nagy multik szerves része. Kihül a mérnök/architect gyomra a sok pofázástól, akkor sem a jövőálló (de kicsit drágább) megoldást választja az aláírós ember, mert a másik az 10 dollárcenttel olcsóbb évente. Cserébe az összedől ha 3-6-12 hónap múlva, mikor hirtelen változnak az igények. De addig legalább olcsóbb volt, és spóroltunk rengeteget. Most meg el lehet égetni még többet a v2-re.

A manager-t "spórolásra" fizetik. Ergo neki addig nagyon jó volt. Később meg a cég szív a hülyeség miatt, ő meg vagy lelép máshová ahol elmeséli mennyit spórolt, vagy marad, és kimarad egy project bónuszból, de másik 3 project-ből még mindig jól keres amik 1-2 év múlva dőlnek csak be, de addigra lesz másik 2 project-je, vagy lelépett.

Röviden valami olyasmi, hogy a "lambda" megoldással működő milliszekundumonként fizethetjük a szervert, viszont cserébe a megoldás technikája miatt ez sokkal több lesz, mint ha egy dedikált gépen futna az alkalmazásunk.

Ha 24/7 terheled a dedikalt geped, akkor igen.

Most akkor nezzuk meg azt, amikor (valos pelda) napi zaraskor kell egy riportot futtatni penzugyi modellezessel, ami nagyon szamitasigenyes, es a zarastol fogva 4 oran belul le kell adni az eredmenyt a felugyeleti szervnek. Plusz az az igeny hazon belul, hogy a riportnak 2 oran belul le kell futnia, hogy legyen lehetoseg egyszer ujraprobalni, ha hiba tortenik. Ahhoz, hogy ez negy (ketto) oran belul lefusson, nagyon sok szamitasi kapacitas kell.

Fenntartasz egy szerverparkot csak arra, hogy napi 2 oraban menjen, esetleg havariahelyzetben ketto helyett negyet?

Ráadásul többnyire olyan USÁ-s nagyvállalatoknál, amiknek a politikáját khm khm nem túlzottan kedvelem.

Miert, EU-s cloud szolgaltato nincsen? Magyar nincsen?

Az AWS, Azure, Google Cloud millió egy szolgáltatást nyújt a "lambda"-tól kezdve a komplett gépig. Kiemelni egyet és mondani, hogy szar az egész, azért meredek.

Van, ahol segít ez, van ahol nem. Nyilván nem ész nélkül kell menni a cloudba és nem ész nélkül kell on-prem rendszert fenntartani.

Viszont a cloud nem csak arról szól, hogy olcsóbb, van, amikor a kényelmet, rendelkezésreállást vagy a szolgáltatást vagy a rugalmasságot fizeted meg. Nekünk pl. 4-5 éve egy projekt elején rendszeresen volt igény arra, hogy akkor most kell 10...20x16 core számítási kapacitás mondjuk 8-10 órára egy héten, de egyébként nem.

( SkyNET | 2024. 02. 18., v – 12:18 )

"on-premises" a végére kell az "s" különben mást jelent.

Attól függ mi a cél, a webes frontendeket már szinte csak ott mert elég szélsőségesen hullámzik a terhelés, B2B interfész és middleware helyben de van rajta vita, adatvagyon és kezelő sw-ek esetén szó sem lehet a kiszervezésről.

Fejlesztés támogató eszközöknél véleményes, de inkább nem. 

( wlaszi | 2024. 02. 18., v – 13:59 )

a világ, a “nyugat” vagy mi kicsiny országunkban?

Szerintem van némi fáziskésés a trendekben, így amíg az egyik erre tart a másik még a másik fázisban van. Ez szerintem egy örök ingaeffektus a számítástechnikában. Központosítunk, elosztunk loop.

"The only valid measurement of code quality: WTFs/min"

( DirtY_iCE | 2024. 02. 18., v – 14:37 )

Lenyegileg amit lehetett az mar reg at lett rakva felhobe, kihozni onnan barmit meg szerintem meg otlet szintjen se merult fel, meg amugy is annyira azure-ra van megirva a technologia, hogyha a microsoft bejelentene hogy nincs tobb azure instant menne csodbe a ceg.

I hate myself, because I'm not open-source.

( rpsoft v | 2024. 02. 18., v – 15:43 )

Ugyan semmi közöm nálunk az IT-hez, de annyit azért tudok, hogy van, ami felhő (pl. a levelezés), van ami saját hardveren megy (számolókapacitás). Mi mire jó.

( bazso | 2024. 02. 18., v – 17:14 )

Jé, nincs ezüst golyó...

Kíváncsi lennék ezek közül mennyinél volt rendes business case, tudatos (architekt) döntés és működő kapacitás menedzsment mielőtt (!) felhőbe mentek. 

Kedvenc kérdéseim:

Tud skálázódni az alkalmazásod? Persze. Lefelé is? Ööö....

A fejlesztő csapat felelős anyagilag az elhasznált kapacitásért? Ööö....

Megkaphatnám milyen nem-funkcionális követelmények alapján terveztél? Ööö....

Állapotot hol tárolod? Db-ben. Oké, akkor nyomok egy redeploy-t az alkalmazásból, ugye nem szakad meg a felhasználó session? Ööö....

Szinkron a kommunikáció? Igen. Mi van ha megszakad és másik példányba talál be az ismétlés? Ööö....

Aszinkron a kommunikáció? Igen. Mi van, ha kétszer kapsz meg egy üzenetet? Ööö.... Kompenzációs tranzakciót tud az alkalmazás? Ha nem, mi történik a félbeszakadt művelettel? Ööö....

...

És még sok hasonló. A felhő baromi jó cucc, ha tudod hogyan kell használni és hogy mire. Minden más esetben drága

Ne is mondd, ahol én láttam, mindenféle fétudású balfaszok "terveztek" felhős alkalmazást. Akik képesek elhinni, hogy "az alkalmazás a felhőben automatikusan skálázódik". Még a sima tranzakciókezelés is magas volt nekik, nem az elosztott aszinkron rendszer.
Az az egy szerencséjük, hogy az egész így is elbazsevál valahogy. Ha meg elakad valami folyamat akkor: "előbb utóbb szól valaki, kitöröljük, aztán kezdik előlről".
A szakmai döntés meg úgy született hogy cégcsoport szinten megvették, aztán kiadták hogy oda kell menni. Ezen se csodálkozom egyébként, mert amilyen hozzáállású és/vagy tudású üzemeltető "szakemberekkel" találkoztam, vezetőként én is mindent megtettem, hogy amit csak lehet vegyünk ki a kezükből. Onnantól meg devops van, ami a gyakorlatban sokszor azt jelenti, hogy oldjon meg mindent a fejlesztő a felhőben, ami azért sokkal kevesebb munka csak "érteni kéne hozzá".

On-prem ha valami lassú vagy beledöglik az app egy kisebb infra döccenőbe, beeszkalálod az üzemeltetést, ők valamit varázsolnak, mindenki megnyugszik. Felhőben ez full elveszik, ott nem az infra tartja a rendelkezésre állást hanem az app alkalmazkodik ahhoz, hogy a felhő alapvetően gyenge és nem redundáns komponensekből áll, amiket az üzemeltetője kb értesítés nélkül újraindíthat vagy kivehet a működésből. On-prem környezetben a kutya nem veszi észre hogy az alkalmazásod csak egy példányban képes futni, mert az infra minden rétege redundáns, sima üzemeltetési esemény miatt nem is kell megállnia, a legrosszabb amikor a futtató szerver meghal és kell 1-2 perc amíg beindul a másik node-on (mondjuk egy vm esetén). Próbáld ugyanezt felhőben. A legtöbb környezet nem támogat live migration-t, magyarul pár hetente egy sima patch miatt is újraindulhat az alkalmazás, ez meg már szemet szúr. Nem opció hogy ha hangosabban hisztizel, hogy most nem érsz rá frissíteni, akkor majd az üzemeltető fenntartja neked a múzeumot, a felhő szolgáltató kiírja hogy mik a támogatott verziók, aztán aki lemarad, az így járt. Stb. 

És így ér vissza a tranzakció szintre a kérdés. Ha nem, vagy nagyon ritkán törik el a működése 1-1 komponensnek, akkor majd valaki javítja az adat hibát. Ha napi szinten vannak félállapotú tranzakciók, ott hamar kilátszik a kupleráj. 

a felhő alapvetően gyenge és nem redundáns komponensekből áll

lol, egy AWS/Azure/GCP infraja sokkal profibban osszerakott mint barki on-prem infraja. Nagyon ritkan hallani doccenest arrafele.

Egy Pistike Bt. on-prem infranal sokkal gyakoribb az aramszunet/ups meghal, internet uplink megszakad, storage/switch firmware upgrade soran kakukk, meg hasonlok...

A public cloudban akkor jellemzo a gyakori "nem tervezett" leallas, ha spot instance-okra epitkezunk. De azt nyilvan akkor lehet hasznalni, ha elsosorban stateless alkalmazasaink vannak azon.

+1, de ha jól értem, az az állítás, hogy a mindenféle minor patchet on-prem ki tudod sírni, hogy jajnecsináldmeg az üzemeltetéstől, míg az Azure bejelenti, hogy márpedig kedd 17 és szerda 06 között db restart lesz, és kész, nyasgem, akkor is patcheljük a minor verziót, ha az nálad leállást okoz.

ami nem baj, sőt :) 

nyoah, on-prem valszeg konstruktívabb lehet az üzemeltetés, mint az azure - rövidebb ablak, személyre szabottabb időpont (mondjuk egy adott héten rugalmas), stb.

jártunk úgy, hogy az ügyfél nagy kampányt tervezett adott dátumra, és ~2 héttel előre megjött, hogy az azure single server postgres aznapra bedobott egy 10+ órás ablakot (ráadásul nem is CET éjszakára, hanem ilyen CET 18-04 közé) , ahol db restartok lehetnek.
persze, csináljunk HA postgrest - nem technikai okokból nem volt.
(tudom, hogy azóta a flexible serverben már nem 10 órás ablakot mond az azure a szerinte jó napon, hanem az általad a héten kijelölt egy órában megcsinálják - ami jó, de ugyancsak, nem technikai okokból maradt single server)

na, egy on-prem infránál annyi rugalmasság van az üzemeltetésben (gondolom; sosem üzemeltettem on-prem infrát, és hála égnek nem is fejlesztettem rá komoly appot), hogy ezt eltolják egy nappal, ha az üzlet jelzi előre.

ha az üzlet jelzi előre

:DDD

 

Fejetlen csirkék módjára szoktak szaladgálni a menedzserek minden hülye közepes v. nagyobb cégnél. Az "előre jelzi" az kb. az "1-2 órával a leállás előtt jön örjöngve valamelyik team manager" , és akkor ez már istenesen jól működő információáramlásnak mondanám. A sok egymást utáló, egymással semmilyen módon nem érintkező, arrogáns, seggfej csapatok között. 

"lol, egy AWS/Azure/GCP infraja sokkal profibban osszerakott mint barki on-prem infraja. Nagyon ritkan hallani doccenest arrafele."

Persze, de másképp. Egy on-prem gépterem pár/triplet (nem Cér István kategória) szépen enterprise grade brand storage, hálózat, szerverek, alapszoftverek kupacából áll, minden rétegben minden alkatrész minimum dupla hogy ne legyen SPoF. Cloudban meg közepes minőségű (olcsó) célgyártott x86 szerverek vannak a végletekig kiherélve, és a "van másik" alapon működnek. 1-1 speciális szolgáltatás kivételével minden tcp/ip alapon megy, a storage is (ennek minden hátrányával együtt), minden ami lehet szoftveres, az is (pl. határvédelmi eszközök). A cloud maga működik hihetetlen magas rendelkezésre állással. De ez nem jelenti azt, hogy a téged konkrétan kiszolgáló szerver is. Ha nem osztod szét a szolgáltatást availability zone-ok és akár régiók közt átnyúlva, a te (fejlesztő, alkalmazás gazda)kizárólagos hibád és felelősséged. Ugyanez on-prem az üzemeltetés hibája, mert az infra kéne megoldja minél inkább transzparens módon

Ezzel szemben a realitas az, hogy konnyeden el lehet erni tobb 100 napos uptime-ot EC2 instance-okkal. Nehogy azt hidd, hogy az "enterprise grade" eszkozok nem olcso alkatreszekbol vannak osszerakva, azok inkabb a gyartoi support miatt azok amik.

Az jogos erv, hogy ha a public cloudban tervezett maintenance/upgrade van, akkor arra kevesbe lehet hatni, mint egy egy on-prem uzemeltetett infran.

De az irasodbol inkabb az jon le, hogy ha public cloud miatt van gebasz, akkor a DevOps/Cloud engineer lesz a bunos, on-prem esetben meg lehet mutogatni a helyi rendszergazdara.

( nagyjoco | 2024. 02. 18., v – 17:41 )

On prem ès cloud költsèghatèkony elegye a cèl. . Ez egy szakmaiságot nèlkülözö kèrdès.

( prion | 2024. 02. 18., v – 19:14 )

Nekem az jön le, hogy elvileg össz-vissz sok mindenre jobb, gazdaságosabb lenne a felhő valamilyen formája, viszont ez kiszolgáltatottságot jelent, mert a költözési költségek nagyok. Szóval ha valaki beköltözött, akkor ha biztonságban érzi magát, akkor emelhet a felhő szolgáltató, mert a kiköltözés költsége sokkal nagyobb lesz (azért is mert sok szakértelem egy idő után nem lesz meg helyben). És az is kérdéses, hogyha óriási anyagi erőforrás lesz a felhő szolgáltatónál, akkor a fejlődésben is nem felé billen e majd a mérleg. Szóval nem az történik e, hogy egy csomó cég megfinanszírozza, hogy a felhőszolgáltató föléjük nőjön annyira, hogy már nem egyenlő felek alkuja lesz, meg versenytársaknak nehéz lesz belépni a piacra.

( g3rg0 | 2024. 02. 18., v – 19:54 )

A már teljesen felhőben minden (már amivel én dolgozok) opció hiányzik. 

( Nickname | 2024. 02. 18., v – 22:49 )

egy jobb helyen a BCP/DRP resze az is, mennyi ido alatt szallsz le a foldre, mert epp meghal a felhod. Vagy a neted. Tapaszkodsz fel onprem valamelyik mentesbol. 

Tudom, ez csak utopia, meg akkor redundans net es felho szolgaltatas, provider fuggetlen megoldasokkal.

Es ekkor jon az  h. minek mekkora a bekovetkezesi valoszinusege es annak a karokozasa szembeallativa a fentiek kialakitasaval, havi gyakorlasaval, szamlaival. 

Es mindig az van, h mire az egesz megterul mar reg mas a management es masok a tulajok, de meg a felhoben is 4x kellene ujrarajzolni a Terraform scripteket meg migralni a megfelelo tier megfelelo grade-jebe az olyan legacy szrokat, amik valojaban egy dockerbe zart crontab-os bloat.exe , fooBar.py, esetleg makros excel. :-)

Az nem is mondom, hogy a legtöbb helyen a levelezés az SPF valójában...

Akkor lehetne azt mondani egy felhős projectre, h. "igen b+ bevezettük", ha megtörtént egy teljes onprem-klaud-onprem ciklus. Csakis akkor lehet tudni és látni a teljes képet, h. a klaud szolgáltató hogyan szopatta szarrá a kedves ügyfelet, mikor elfelé kell vándorolni az adatoknak, és mindenféle büntető-költségtételt beleraknak a kifele irányuló folyamat lefutásába.

Azert ne essunk at a lo tuloldalara, sok helyen onprem sincs semmi tervszeruseg, hanem ami igeny epp kiesik a csobol, arra probalnak ganyolni valami megoldasszeruseget. Igy azert ne az legyen a konkluzio, hogy a cloud azert szar, mert BCP, meg mittudomen, mert sok helyen onprem sincs.

Jajj, már, legtöbb cégnél hetekkel előre kezdik tervezni a BCP-tesztet, mindenkinek le van adva a dolog, hogy pontosan mikor lesz, satöbbi. Ilyenkor szoktam mondani, hogy a BCP-teszt az, hogy random időpontban villany leolt, aztán nézzük meg, hogy reagál az cég a helyzetre. A valós BCP-eset nem fogja megvárni a legjobb időpontot és nem jelenti be előre két héttel, hogy mikor tépi el a markoló az üveget vagy a betápot.

https://iotguru.cloud

Igen-igen, nalunk jo sok eve volt valami pentest, amit hazon belul csinalt volna valami security-s arc. A teszt ugy kezdodott, hogy elkerte az admin jelszot a projektunk szerverehez, amivel o majd tesztelni akar. Nem adtuk oda.

A teszten vegulis atmentunk, mert admin jelszo nelkul semmit nem tudott kezdeni a geppel, pentest kipipalva. :)

+1.

Vágd le a klímákat a szerverszobában (2*12 kW/db), legyen minimum 50-60 fok odabent fél órán belül. Mindezt hajnali 3-kor. Nézzük meg, hogy kezeli a készenlétes kolléga a helyzetet, mi működik a cégnél reggel 8-9 óra körül, hogyan kezeli a CxO a szituációt. (megtörtént eset, cégnevet nem írok)

Nem, ez normál esetben szimpla BCP (business continuity).

A DRP (disaster recovery) az már konkrétan egy nagyobb "katasztrófa" utáni helyreállítás, amikor valami eltűnt, tönkrement, inkonzisztens lett, elveszett, vissza kell tölteni, meg kell venni újra, satöbbi esete. A BCP dolga az, hogy az üzlet ne vegyen észre semmit az eseményből, a DRP az már az, hogy az üzlet észrevette, sőt és már a kármentés folyik, illetve a szolgáltatás helyreállítása.

https://iotguru.cloud

Akkor azon a jobb helyen kikapcsolva porosodik a felhő kiváltására alkalmas onprem HW környezet, és élő sw licenszek valamint készültségben amőbázik a felállítást, és az onprem rendszer menedzselését igény esetén elvégezni képes admin csapat.

Csak akkor miért jó nekik a felhő?

( Mik v | 2024. 02. 19., h – 07:40 )

Ha valakit érdekel a cloud vs. nem cloud témakör stratégiája ajánlom: https://architectelevator.com/book/cloudstrategy/

Valahol az elején van, hogy mit ne csinálj ha cloudba mennél? Pl. ne másold le a meglévő on-prem processzeket a cloudba. A nyitó cikket elolvasva az elégedetlenkedők pont azt csinálták, hogy megfogták az on-prem vackukat és áttolták a felhőbe. Csináltak egy másik adatközpontot maguknak anélkül, hogy használnák a cloud előnyeit...

( bennyh | 2024. 02. 19., h – 08:11 )

De amúgy van választás? (Tudom van, költői kérdés :D)

Most is a VMWare körül áll a bál, nem tudom, ez is pl nem-e tolja a jónépet a felhőbe.

( dyra | 2024. 02. 19., h – 10:36 )

Iparban ténykedek, az irodai alkalmazásokat mind kipakoltunk felhőbe a teljes supportot pedig külsős cég viszi. A gyárak szerverei viszont maradtak helyben mert a cég nem vállalta be, hogy hálózat kiesés miatt termelés kiesés is legyen. Így félig. És ahogy látom marad az irány. A termelés és kiszolgálás szempontjából kritikus alkalmazások helyben működnek helyi szerverekről.

( artifex | 2024. 02. 19., h – 12:38 )

Eddig távol tartottuk magunkat tőle, adatok érzékenysége miatt amit lehet a falakon belül tartunk. De mivel állami cég, ha Lölönek lesz ilyen szolgáltatása, biztos változnak a preferenciák a megfelelő szinten.

"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."

"Its easier to fool a man than it is to convince they have been fooled"

Ha ez a NISZ, mentek oda, de azóta ha jól láttam már az új magyar szuperbanknál vannak páran. Ami meglepő módon ugye Lölö terület. Amit biztosan tudok, nálunk jelenleg nincs akarat a felhőbe mozgáshoz.

"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."

"Its easier to fool a man than it is to convince they have been fooled"

( gee v | 2024. 02. 19., h – 13:15 )

mittudomén.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( KGer | 2024. 02. 19., h – 13:21 )

kicsit off

de ha jól látom saját nemzeti cloud szolgáltató kb kötelező lesz minden nyugati országban

a törvényi és gazdasági kényszer rá fogja vinni őket

Hány olyan cég van, ahol jól jön a cloud, de nem globális a szolgáltatásuk?

Egy példa: Simple. Magyarországon szolgáltatnak csak, és megéri nekik a skálázódás.

Vagy hasonló példa bármelyik tömegközlekedési vállalat IT rendszere. Lokális szolgáltatás, mégis a használati minták miatt megéri nekik az, hogy skálázható infrastruktúrát használjanak.

Senki nem mondta, hogy köteleznek a használatra. Azonban az szinte minden állam számára alapvetés lesz, hogy a (nem csak kritikus) infrastruktúráját valamilyen általa felügyelt felhővel kezelje, ehhez meg jó, ha van helyben is felhőszolgáltató, nem csak a 3 nagy.

Ha a Simple jó példa akar lenni a skálázódásra, akkor rossz példa.

Elfogadóként napi szinten akár több értesítés érkezik, hogy belassult, majd helyreállt: "a tranzakciók státuszát késve tudjuk visszaigazolni, ezért a tranzakciók egy része sikertelen lesz." A gyakorlatban ez azt jelenti, hogy semmi nem működik.

Illetve heti szinten a "Tájékoztatás a SimplePay fizetési rendszer tervezett fejlesztéséről", ami több órás tervezett leállást jelent.

Nyilván lehet(ne) ezt jól is csinálni, csak ne velük példálózzunk, hogy mennyire jó az automatikus terhelésfüggő skálázódás.

A felhőt is lehet rosszul használni.

A Simple arra akart példa lenni, hogy nem kell ahhoz globális játékosnak lenned, hogy felhőt használj, egy országon belüli szolgáltatásnál is van értelme a skálázható szolgáltatásoknak.

Ugyanis a kiindulás az volt, hogy "nemzeti alapon fragmentálódó cloud egy globális szolgáltatás alá" nem gazdaságos a felhőz. Viszont nem csak globális szolgáltatás számára hasznos a felhőalapú skálázható architektúra.

Ha a Simple jó példa akar lenni a skálázódásra, akkor rossz példa.

azt mondanám, hogy nekik kellene (de nem tudom, mennyire csinálják) :D 

egyébként a tömegközlekedést pont nem raknám mellé, mint akik majd jól kiegészítik egymást a nemzeti cloudon - hiszen a MÁV meg a BKK is a Simple-lel ad el jegyet (a felületeik alapján), és tippre a parkolás is akkor kap egy boomot, amikor mindenki más elindul...

( trey | 2024. 02. 20., k – 07:31 )

Ahogy a kolléga szokta mondani: az a felhő téma elég ködös még egyeseknek jelenleg.

trey @ gépház