From the start, companies that offer cloud services have promised simplicity and cost savings. Basecamp has had one foot in the cloud for well over a decade, and HEY has been running there exclusively since it was launched two years ago. We’ve run extensively in both Amazon’s cloud and Google’s cloud, but the savings promised in reduced complexity never materialized. So we’ve left.
The rough math goes like this: We spent $3.2m on cloud in 2022. The cost of rack space and new hardware is a total of $840,000 per year.
Leaving the cloud will save us $7 million over five years.
At a time when so many companies are looking to cut expenses, saving millions through hosting expenses sounds like a better first move than the rounds of layoffs that keep coming.
Apa, kezdodik! Most, hogy a tokekoltseg egy ici-picit magas lett, kezdenek raebredni a cegek, hogy tul draga az olyan kiserletezgetes, hogy "just migrate to this new workload bro, trust me bro, just use our managed k8s cluster bro, then you will save so much" - avagy a libak megdoglottek, de otleteim lennenek meg.
Az en joslatom a kovetkezo ot evre:
- sokkal jobban kulonvalik az IT mint commodity es az IT mint core tevekenyseg
- a commodity ki lesz szervezve ugyanugy mint eddig - Exchage Online 4 dollar per fo per ho, aki azt allitja, hogy ennel olcsobban kihozza, ahhoz lennenek kerdeseim :)
- core tevekenysegekre tobb onprem, de megtobb hibrid cloud - pl. black friday elott belokni plusz nehany node-ot a k8s ala egy public cloudbol szinte ingyen van, az egeszet kivinni viszont mar feleslegesen draga
- YMMV ha kkv vagy startup vagy, es nincs penz CAPEX-re
Hozzászólások
Egy perc néma csend azokért, akikkel egy monolitot kierőltettek felhőbe, és utána gondosan platformspecifikus api-kat kezdtek el használni.
Az se egészen jó amikor mindenáron "platform agnosztikusok" akarunk lenni, merthogy "cloud-exit-stratégia".
Na ebből jön a tipikus (német) pver-engineered hulladék.
Lehet cloud-exit stratégiát úgy is implementálni hogy xy cloud specifikus megoldáshoz megnézzük hogy "nagyjából így és így lehet helyettesíteni máshol". És majd ha konkrétan helyettesíteni kell - mert tényleg exit van abból a cloudból - na akkor megnézzük konkrétan. Például azért mert addig 26x változik az implementáció vagy akár kiderül az is hogy nem kell már és mehet a kukába.
Ehhez kell egy kis előre gondolkozás és hosszú távú konzekvens kivitelezés.
Ez a kettő együtt biztosan hiánycikk mert egyik sem jól eladható a menedzsment felé.
Gábriel Ákos
Dehogynem. Az otlet maga imadnivalo. Ezert ujra es ujra eladhato. Elj ebbol! Csak ne probalj senkit rakenyszeriteni, hogy csinalja is...
Minden további nélkül írható az esetek egy jelentős részében olyan szoftver, ami mindenfajta erőlködés nélkül cloud-agnosztikus, és az életciklusa 5+ éves.
Az tok mindegy jelenleg / rossz szal. Nem abbol elek jelenleg :)
De, ha mar SW, akkor az igaz, hogy lehet olyat irni, foleg nullarol, ami kb. agnosztikus. Azaz nem hasznalunk magasabb szintu szolgaltatast (analitikak, automatizmust segito megoldasok, security dolgok) a kornyezetbol, hanem hozzuk magunkkal mindezt. Sot ne nagyon vegyuk figyelembe a SW hasznalat kozbeni karaketerisztikait, mint teljesitmeny, security, availability stb. Ha mindezekre szukseg, akkor nem igazan agnoszikus, hanem inkabb tobb platformot tamogato megoldasrol beszelunk.
Viszont olyan SW is van, amely eletciklsa akar 20+ ev, es volt mar vason speci oprendszerrel, majd virtualizalva, aztan kontenerekben. Az alapkovetelmenyek meg inkabb szigorodtak az eletciklus alatt. Az ilyenhez azert kell egy kis erolkodes.
Vitatkozhatunk az agnosztikus kifejezés értelmezésén, szerintem ennek kielégítéséhez elég, ha nem egyetlen cloud szolgáltató (szoftveres) infrastruktúráján tud futni valami.
Nyilván nem az "applikáció(k)" agnosztikussága a probléma, egy springboot izé bármit elfut.
A probléma az IaC agnosztikussága.
Gábriel Ákos
Ott is vannak megoldások - csak néha átlicencelődnek :D
Aztán forkolódnak.
Igen, csak innentol megint megkerdojelezodik* a cloud letjogosultsaga a projektben, mert a vege az, hogy VM-eket berlunk, dragan.
szerk: * jo, nem teljesen, mert ha alapbol modularisra irod meg, akkor elmeletileg cserelheto mondjuk egy datastore backend, a gyakorlatban meg mire elesben ki kell szamolni, hogy mekkora effort megcsinalni, addigra az eredeti szerzo jo esellyel ugysincs mar a cegnel :)
Másról beszélünk. Egy "jól" megírt szoftver tud onprem és különböző felhőkben is futni, különösebb hókusz-pókusz nélkül. Macera és tervezni kell? Persze.
Sok projektet láttam, ahol "spórolni" kellett - pénz nem számított -, és iszonyatos munkával kitolták felhőbe, aztán az adott provider összes csillivillijét agyatlanul elkezdték használni, amikor meg kiderült, hogy drága (ezt persze előre kellett volna kiszámolni, de az ugye black magic), akkor ment a kamillázás, hogy _sz@r_ a felhő.
Örökbecsű, hogy feladathoz kell eszközt választani :)
vótmá?
https://hup.hu/node/182137
Szerintem ez az egész folyamat (a cloud szolgáltatók felfutása) erős összefüggésben van az IT-t használó startup-ok elszaporodásával. Elhitték, hogy egy ötlettel, tőke nélkül is bármit meg lehet valósítani, mert ott a cloud. Nem kell semmit venni, nem kell hozzá a szó régi értelmében vett szakember, csak nyitni kell egy fiókot, és már fut is minden. A kockázati tőke meg nem a fejlődést finanszírozta, hanem a pénznyelő cloud szolgáltatást egyenlítette ki. Aztán pár év és pármillió dollár után ott tartanak, hogy továbbra is csak az ötlet van, valami féligmeddig működő megvalósítás, de semmi saját nincs továbbra sem, így nem termel pénzt, csak viszi. De a kockázati tőke egy idő után nem akarja fizetni a havi költséget... Ilyenkor jön, hogy akkor bevetjük az aduászt (ami ellen látványosan tiltakoztuk végig, de az elejétől tudta mindenki, hogy kelleni fog): a reklámot. Aztán vagy van elég user (reklámfogyasztó), hogy a működési költség megjöjjön, vagy megy a levesbe a startup, megveszi egy nagy és kiszívja belőle az ötletet, majd eldobja.
A kisebb-nagyobb cégek hozzá nem értő Excel diagramos managerei meg rákaptak, hogy hát ha másnak is van "ingyen" IT, akkor nekik is az kell. Mert a felhős IT költsége az Ő diagramján rajta sincs, az onprem IT meg nagy szelet, így jobban néz ki, hogy meg-managelte az onprem IT költség csökkentését.
Egy csomó mindenre kiváló a felhő. Csak sajnos ez is olyan, mint az IT-ben (pontosabban a világon) minden, hogy akinek kalapácsa van, egy idő után, mindent szögnek néz.
"black friday elott belokni plusz nehany node-ot a k8s ala egy public cloudbol" - változatlan szoftverrel (architektúrával) ezt ugyanúgy _nem_ fogják tudni megtenni ezután sem.
Ha tisztán a pénzügyeket nézzük akkor rájöttek hogy "át lettünk baszva" és most mennek a kisebb rizikójú cost saving irányába (standard menedzsment eljárás).
Közép- és hosszútávon viszont valószínűleg nem fogják tudni megúszni a szoftverük modernizálását.
Ha ezt nem ismerték fel (és a megspórolt összeget vagy annál többet) nem fordítanak a modernizálásra akkor nem most hanem 5 év múlva csukhatják be a boltot. Minden szoftver eléri az életciklusa végét. Ha szarul van csinálva / el van hanyagolva akkor hamarabb.
Gábriel Ákos
Igazad van, bar nem volt ilyen peremfeltetel. :)
Onprem es cloud platformra is lehet jo es szar architekturat fejleszteni.
Csak on-prem nem látszik, mert már megvan a vas, a felhőben meg már a következő havi számlában érzed a fájdalmat.
Amíg kísérletezel, felhő. Ha beállt a workload szintje, akkor on-prem. Ha ugrál a workload (karácsony, black friday) vagy ügyesen rugalmas akarsz lenni, akkor hibrid. Ha nagyon ügyes vagy, akkor hibrid multi-cloud mert akkor tudsz költséget és go to market sebességet optimalizálni.
Mindegyik: kapacitás menedzsment nélkül mind kupleráj és drága lesz, csak a költség dinamikája különbözik.
No, hát olyan szakember meg aki egy ilyent átlát és megtervez, koordinál meg mennyi van a világon? Tíz?
Sajnos ehhez őrületes tudás kell, ami még több összedolgozó embertől is szép teljesítmény. De ilyen tudást csak ilyen munkákkal lehet megszerezni. De ilyen munkák nincsenek, mert a managerek nem így gondolkodnak sajna...
Kétségtelen, hogy mázli kell hozzá, hogy ilyen munkák közelében legyen az ember, de azért jóval több, mint 10 ember van akár itthon is, aki ebben a ligában mozog. Ha végtelen időt/energiát szánsz rá és mersz kockáztatni, meglepően gyorsan is felépíthető: volt olyan kollégám, akiről nekem kellett meggyőzni a HR-t, hogy 30 évesen nemcsak hogy pariban van a szenior architektjeimmel, de a top 3 közt van (és nem a többiek voltak gyengék). Tudatosan cserélgette a munkáit és pozícióit, mindig ahol a legnagyobb fejlődési lehetőséget érezte. Nem is tudtam sokáig megtartani, pedig európai szinten kifejezetten érdekes és nagy munkákat tudtunk bezsákolni, de ezt is kinőtte.
Azt ne felejtsd el, hogy a managga is ember, ugyanúgy, ugyanolyan tempóban képes fejlődni, mint egy szaki, de neki ezt más területen kell tennie, így nem várható el, hogy a szaki helyett is jobban ért a felhős kérdésekhez. Csak amikor a Gartner hihetően megmutatja neki, hogy a felhő jó, a saját tekije meg közli, hogy a felhő sz@r, de közben a mindennapi problémára (az igénytől a leszállított megoldásig annyi idő telik el, hogy addigra nem is ezt a lovat akarjuk) a Gartner ígér megoldást, a helyi szaki meg mindig csak sír, hogy nincs elég ember, pénz, tanfolyam, és amúgy is hülye managgák, akkor szerinted mit fog dönteni? Azt egy minimális műszaki érzékkel megáldott managga is ki tudja próbálni, hogy felhőben percek alatt kap valamit és fizet érte havi 5 dollárt, a helyi drága emberekből álló csapat meg ugyanezt hetek alatt szállítja le (10+ milla) és élesítés után még a managgára mutogat, hogy a kis pénz és az időnyomás miatt lett ilyen szigszalagos.
Érdemes nyitott füllel meghallgatni egymást és megoldást keresni, nem elzárkózni a másik oldal kérése/véleménye elől, mert feltételezhető hogy ő is jót akar (van egy feladata, amit jól el akar végezni), csak más információk és tudás birtokában. Javaslom a Phoenix project című könyvet. Ritka, hogy valamit többször is elolvasok, de ez annyira rezonál a napi tapasztalataimmal, hogy mindig más része miatt érdekes.
Hatalmas +1
Egy csomoszor hallottam mindenfele IT-teruleten, hogy a managereket eloszor be kene ultetni "igazi munkat vegezni" (lol), hat szerintem forditva, minden nagyszajunak kene adni egy projektet, hozza penzt, paripat es fegyvert, aztan mutasd, mire jutottal.
Dehogy, tök jól le lehet szűrni, van az a kategória, akinek két (számára valamiért nem) tök egyértelműen összeakadó alap igazság van a fejében:
És ez jól felismerhető, szóval azonnal lehet tudni, hogy ezeket az embereket teljesen felesleges bárminek a közelébe engedni, ahol betüremkedik a valóság, mert semmi hasznosat nem fognak hozzátenni, jó esetben csak ők frusztrálódnak, rosszban még destruktívak is mint a picsa, szóval be kell tolni nekik a pizzát az ajtó alatt, rá kell írni, hogy mit kell megcsinálni, aztán hagyni kell, hadd morogjon, hogy ez egy faszság, és közben szenvedjen azzal, hogy mennyire clean a code, hogy épp hogyan kell szépen szervezni öröklődést, hogy mi van a commit message-be írva, hogy túl sok-e az unsafe a rustban, vagy melyik subsetjét lehet a cpp-nek használni. Ez utóbbikban, ha jó, akkor fog hasznosat csinálni, de bármit, ahol a bizonytalanságból ki kéne jelölni egy irányt, na, abban úgyse.
De ha direkt elküldöd őket valóságföldére, akkor még véletlen ráragad annyi, hogy nem derül ki rögtön, hogy semmi keresnivalója ott. :)
Ezt akkor én most kinyomtattam 72-es betűmérettel.
rezonál?
Elég sok mérnököt láttam már sikeresen helytállni management feladatkörökben. Ezzel együtt kizárólag felsült manager-t aki bármiféle mérnöki munkába próbált fogni.
A managerbol lett mernok is annyi idot toltott az uj szakterulet megismeresevel, mint a mernokbol lett manager?
szerk: Csak mert amikor nekem lett egyszer tele a hocipo a management feladatokkal, es hands-on feladatokat akartam, akkor odamentem a fonimhez, es szo szerint azt mondta, hogy "egy tollvonas", es atulhetek fejlesztonek. Nekem ez nem lett volna gond, mert elotte is dev voltam, de ha ennyi a szint, amit meg kell ugrani, hat ja, akkor ugy nem megy.
Természetesen nem. A műmanager mindentudónak képzeli magát.
Szerintem sokkal több ilyen ember (inkább csapat) van mint gondolnád. Csak elég ritkán hagyják őket érvényesülni mert (céges) politika.
Minden ilyen projektet (mert ezek már nem pici projektek) végletekig befolyásol a céges politika.
Egy ilyen melóhoz a vezetői szinten inkább széles tudás kell és nem mély. Kell egy csapat aki jól tud együtt dolgozni és megvannak a képességei mindegyik "szinthez". Mondjuk 4-8 ember. 8 emberrel komplett bankot lehet kirakni a felhőbe jól.
Ami még (vezetői szinten) kell:
- mérnöki látásmód (mindent bizonyítani kell, mindent mérni kell, tényekben gondolkozni, mindent szétszedni, elrontani és összerakni)
- szakmai alázat: nyitottság az új ötletekre, nem szégyen a tanulás, nem szégyen azt mondani hogy "nem tudom"
- mindig vissza kell nézni a "big picture"-re, nem szabad elveszni a részletekben
- ugyanakkor rendes őszinte "backlogot" kell vezetni ezekről a dolgokról (majd visszatérünk rá)
- a határidőnél sokkal jobban kell érdekeljen a minőség
- a belső, megszerzett tudás mindig sokkal értékesebb mint a leszállított black box
- ugyanakkor a black boxokkal is kezdeni kell tudni valamit
- nyílt rendszert kell építeni, az alapelveket előre, transzparensen lefektetni és sokszor elmondani
- aki nem ért egyet az alapelvekkel azzal nem tudunk együtt dolgozni
végül mint minden rendes rendszerintegrációs projektnél a rendszerhatárokat kell nagyon pontosan, alaposan lefektetni. Leírni, aláíratni, elfogadtatni.
Az interfészeket ezután majd definiálja minden rendszer(páros) magának mert ez lesz az elemi érdeke.
Az okos darabolással lehet jól skálázni bármit, onnantól mindenki fogja tudni hogy mettől-meddig tart az ő dolga.
A Phoenix projektet én is ajánlom mindenkinek.
Gábriel Ákos
Ha nem írnak róla explicite akkor egész nyugodtan kiindulhatsz abból hogy nem változtattak semmit.
A tipikus "cloud migration" az úgy néz ki hogy "lift-and-shift" azaz kidobják az egészet EC2 instancokra, berakják egy loadbalancer mögé aztán hajrá.
Az már "advanced" amikor elkezdenek mondjuk menedzselt adatbázist használni.
Gábriel Ákos
Sajnos tényleg gyakori, és ezek miatt igaz a statisztika, hogy a felhő drága.
Lehet olyan konstelláció hogy mindig kell legyen egy működő rendszer.
Ilyenkor az időt vesszük meg pénzért, valamint cseréljük le a capex-et opex-re.
Lehet az ilyenekből jól továbbmenni és valódi "cloud fit"-et csinálni.
Gábriel Ákos
Abszolút, de ennek feltétele hogy mindenkinek tiszta legyen az elején, hogy ez egy átmeneti állapot. Amikor ezt úgy adja el a technika felfelé, hogy siker, már felhőben vagyunk, managga örül, pénzt paripát átcsoportosítja üzletileg láthatóbb témákra, és onnantól ez a végállapot
Régen volt a "cloud migration specialist", akik nagyon is keresettek voltak.
Mostantól lesz "onprem migration specialist" is. Fel is veszem gyorsan a Linkedin profilomra. :)
Meg olyan is kéne, aki mondjuk átlátja, hogy miért az a felhő, és azon belül mit érdemes megvenni, nem csak észnélkül összeklikkelni, aztán kamillázni a havi számlától.
Ezt "finops"-nak hívják mostanában.
Gábriel Ákos
Amikor felhőbe migráltunk 2015-ben azt komoly tervezés előzte meg. A monolit architektúra lebontását előre megtervezték, megírták a különböző adaptereket és libeket hogy az alkalmazás felhőképes legyen.
Minden csapatba kellett solutions architect, vagy olyan tudású csapattag (lényegében cloud specialista), át kellett látni mit hogyan kell vagy lehet helyettesíteni.
Ezt a tervezős megfontolt trendet aztán valahogy bedarálta a vállalati kultúra, és olyan szintre jutott mint a DevOps meg az összes többi irányzat.
Kíváncsi vagyok mi jön a Kubernetes után.
A cloud is egy trendi hype. Van a szomszédnak nekünk is kell. A tipikus irány, hogy érkezik az igény a management részéről, hogy irány a cloud, mert az jó, meg olcsó. Ennél a pontnál nem mindegy, hogyan lesz használva a cloud. Tipikus első lépések, hogy átesik a cég a ló túloldalára és mindent cloudba erőltetnek. Utána realizálódik, hogy a cloud drága, tehát vissza házon belülre minden. Ennek is költsége van és nem csak időbeli, mert sokszor már nem olyan egyszerű visszatérni a régi útra.
Normálisabb cégeknél, ilyenkor jön egy technikai ember, aki levezeti, hogy a "mindent a cloudba" nagyon drága tud lenni hosszú távon. Ezért egy középutat javasol, ahol bizonyos szolgáltatások mehetnek cloudba és van, ami marad házon belül. Tehát a megoldás ismét középen van valahol és a cloud tud nagyon jó lenni a hirtelen felmerült igényekre, amit házon belül nem tudnak kiszolgálni és a bővítés időbe telik vagy csak meg akarnak nézni valamit, pl. egy PoC. Tehát a cloud-ot véleményem szerint hibrid megoldásként célszerű alkalmazni a legtöbb nagyobb cégnél. A kisebb cégeknél, a terméktől függően lehet olyan, hogy olcsóbb a cloud. Tipikusan ilyenek a startup-ok, ahol kezdetben nincs keret egy komplett operations csapatot, illetve architekteket felvenni minden területre még a termék be nem fut.
Ez a "trendi hype" 15 éve is necces mondás lett volna, de ma inkább sajnálatos, hogy sokan még mindig így érzik. Bevált technika, stabilizálódott piac. Csak nem ezüst golyó, arra kell használni amire való
Racionális indoklás nélkül bármit csinálsz az azt jelenti hogy felültél valami trendi hype-nak.
Ha cloud migráció akkor az. Ha vissza on-prembe akkor az!
Régebben az Indiába offshore volt hasonlóan trendi hype, sokan ráfáztak arra is.
Gábriel Ákos
Ad absurdum a technikai ember levezeti hogy a szoftverpark jelen állapotában al-kal-mat-lan a cloudban való épeszű üzemeltetésre.
És igazából a cloud migráció miatti kényszerű modernizáció az ugyanaz a technical debt amit az elmúlt 10 évben basztál megcsinálni csak másképp nem derült volna ki.
Gábriel Ákos
Mockosz kisz hobbitkák rájöttek, hogy az ígéret földjén is csak a drágaszááág fogadja őket
Most kellene pár új buzzword, mondjuk jöhetne az "AI-val támogatott üzemeltetés": akármit is mondjon a hablatyolószoftver, azt kell csinálni. (Régebben a PHB-k töltötték be ezt a szerepet.)
Itt is volt bőven "szakértője" és evangelistája a témának, nem tudom most hol vannak ....
trey @ gépház
Feljebb már megszólaltak a szakértők.
Én csak azt furcsállom, hogy elég kevés ilyen bejelentés van. Hozok is gyorsan egy friss ropogós 2012-es prezentációt (12 éves!) https://www.slideshare.net/internap/top-10-data-centersuccesscriteria
6. slide
és
Ehhez képest a vállalatok nagy erőkkel megindultak a cloud felé a startupok közül viszont (érzésre) kevesebben választották a saját infra utat. A prezi régi de a kérdés amit feszeget ma is ugyanaz, bár a cloud szolgáltatások időközben jóval olcsóbbak lettek. (lehet ezért gyengébb a cloudból lejövő irány...)
Szerk: aki a claudban nem tudott számolni az a saját infrán se fog. Sőt a saját infra költség egy sokkal bonyolultabb dolog és könnyen abba a hibába lehet esni, hogy nem a teljes költség képet nézegeti valaki. (lásd ~rack+szerver és készen is vagyunk - ennyi a költség...)
Egy rakás fajsúlyos, valaki(k) által a ködös felhőbe gyömöszölt magyar céget rángattunk vissza az elmúlt években a földre, privát vagy hibrid cloud-ba. Ezekről nem feltétlen születik bejelentés, de a trend létezik.
trey @ gépház
Ők nem ez a két kategória. Ezek voltak a jóslatok, hogy pl a startupok a cloudban kezdenek de lejönnek a költség miatt. És itt látni is, hogy van aki megteszi.
Akikről te beszélsz nem voltak tisztában a felhőbe migrálás következményeivel, vagy elszámolták magukat (vagy nem is számoltak csak felültek a trendekre).
A cégekre amikre rálátok mélyebben (egy KKV és egy nagy nemzetközi multi) nagyon bejött a cloud világ. Mind költségben mind lehetőségekben sokkal jobb lett nemcsak az IT rész de az üzlet is jobban működik az új leehtőségeket kihasználva. 😉
Nyilvánvaló, hogy ha nem lennének egyáltalán elégedett cégek, az egész felhősdi már rég a múlt lenne, az azonban érdekelne, hogy ezek kizárólag felhős, vagy inkább hibrid cloud cégek-e? Mert rohadtul nem mindegy ...
trey @ gépház
Akkor kezdhetjük is a hybrid-cloud fogalom definíciójával.
Kapásból néhány alternatíva:
- egy környezeten belül (mondjuk prod) van egy folyamaton belül cloudban és onprem futó rész is
- egy környezeten belül (mondjuk prod) van cloud és onprem is, de egy folyamat mindig vagy onprem vagy cloud fut. A folyamatok egy része ki van téve a cloudba
- a környezetek szeparáltak (mondjuk dev, test, preprod, prod) és van teljes környezet a cloudban és van teljes környezet onprem
... s.í.t.
Gábriel Ákos
Szerencsére, ezek nem titkosak:
Mit szerettél volna mondani?
trey @ gépház
Elolvastam a microsoft definícióját. Egyáltalán nem mond ellent a felsorolt alternatíváknak, ezek az alternatívák az alap definíció lehetséges implementációi. Nagyjából egy lépéssel van tovább kibontva.
Gábriel Ákos
A microsoft definíciós oldalán olvastam egy hasznos dolgot, leírja a "privát felhő" fogalmát.
Segít megérteni a valódi problémát.
A valódi probléma az, hogy a tipikus magyar KKV közelébe nincs a privát felhőnek.
Tehát számára nem "csak" az a megugrandó feladat hogy a privát felhőjét összekösse a public-al és valahogy elossza a dolgokat, hanem először is "cloud-ready"-vé kellene válnia (és majdnem mindegy hogy kívül vagy belül).
Ha ez nincs meg "fejben" akkor a public cloudba költözés biztos kudarc és ebből jön a "megváltottság" érzése amikor "visszakerülnek" az ismerős közegbe. Aminek köze nincs a cloudhoz, nem is volt soha.
Gábriel Ákos
A KKV kompletten felszámolta az infrastruktúráját és az ITját is (beleértve egy idő után az irodát is ahonnan dolgoztak) csak a laptopjaik vannak és külső szerződésük azok karbantartására és az egyéb IT kérdéskörökre.
Csoportmunkaügyileg M365, weblap hosting cégnél, alapműködéshez szükséges call-center szintén SaaS-ként (a telepített helyett). Az egyéb szoftvereik is SaaS alapúak. Ott gyakorlatilag megszűnt a hosztolási igény...
A nagy cég az termelő cég így természetes, hogy hibrid de a központi rendszerek (Purdue L4) már mind cloudosak (rengeteg SaaS + a hyperscalerek). Még Purdue L3-on is van cloud. Persze finops van a kezdetektől (már akkor volt amikor nem is tudtuk, hogy így hívják 😉)
Ebből indultunk. Azért előttem van, ahogy nagy ipari vállalatok (öntödék, szerszámgyárak, autóipari vállalatok stb.) felszámolják gyártelepeiket és home office-ba hazaviszik a gyártani valót :D Azt hiszem, más fogalmaink vannak a "vállalat"-ról :D
trey @ gépház
A nagy cég a példámban ipari vállalat kb mindene van a felsorolásodból. A gyárak nem kerülnek felszámolásra viszont a klasszikus IT infrastruktúra egyre vékonyabb a telephelyeken. (persze az IoT meg tör előre)
Bátor dolog ez de nem lehetetlen. Remélem van mindegyik témára előre kidolgozott "exit stratégia", ne akkor kelljen kapkodni amikor már késő.
Az személyes véleményem hogy a SaaS a világ egyik legnagyobb átb@szása ami igazán hosszú távon senkinek sem jó, cserébe ügyfélként jó kiszolgáltatott vagy. De lehet hogy én vagyok a nagyon boomer.
Gábriel Ákos
Egyetértek, de lassan nincs más. És még érthető is. Nem válthatod meg mindig a világot az alkalmazásod új verziójával, akkor meg a régi ügyfelek nem upgrade-elnek, nincs miből etetni a fejlesztőket, mert ahogy telítődik a piac, új ügyfelet már alig szerzel. Ha van backend szüksége a cuccnak, akkor azt is fenn kell tartani valamiből, ráadásul a franc akarja végtelen legacy verzióval párhuzamosan kompatibilisan tartani az új backend verziókat, márpedig az az egyetlen ügyfél számára fájdalommentes módja a kötelező verzió frissítésnek, ha nálad fut.
Mint pl. h a G szolgáltatja a levelezést?
Indokolnád, h mi abban az atbaszás?
Arra kell figyelni, hogy hiába van a felhőben a bármi, illetve bárhol külsősnél, egy saját mentés legyen. Ezt szeretik elfelejteni, és amikor a bármelyik felhőben villámlik, és mondjuk az 50-ből 2 fiók hirtelen elfüstöl, vagy csak 4 hónappal ezelőtti állapot jön vissza, akkor pislogás van, hogy dehát hogy lehet, az ott a felhő!!!!!négy!!!. Aztán megtudják a supporttól, hogy az ászf épp melyik pontja szerint nowarrantyfordata sorry, restorefrom backup.
Ez viszont pusztán tájékozatlanság, és a szokásos MVP hozzáállásból jön.
Térjünk vissza a kérdésre. Miért átbaszás?
Elmagyarázhatjátok a fenti, backup témát is felhasználva, bár az alapján még annyira sem értem.
Mert egy idő után azt fogod gondolni hogy "a tiéd" mert megszoktad.
Aztán egy-egy váratlan húzásnál (akár üzleti akár technikai) rájössz hogy bizony baromira nem a tiéd.
Nem tulajdon hanem használati jog.
Full tervezhetetlenül és váratlanul jön egy ki-tudja-mekkora-költségű változási, változtatási igény amit követned kell ha az üzletedet fenn akarod tartani.
Egyszóval kockázat, ami nagyon nehezen menedzselhető.
Egy e-mail szolgáltatás az kevésbé gond (mint saas) mert ott azért 90-95%-ban ugyanarról beszélünk, egyszerűen lecserélhető másikra és meg is vannak a "migrációs scriptek". De akár egy full customizált, szénné integrált webshopot lecserélni az non-trivial.
Erről szólnak a "technológiai exit stratégiák".
Gábriel Ákos
Te honnan tudod, h én mit fogok gondolni? Nem értelek.
Maradjunk az email-nél példaként. Konkrétan fejtsd ki pls, h ebben az életben miért átbaszás nekem, h a G szolgáltatja?
Általánosítva írtál, ezért pls ragadjunk meg ennél az egyszerű és teljesen alap példánál, mivel nagyon sokan használják (a G-tő és más szolgáltatóktól igénybe véve) a vilagon, tehát mind át vannak baszva.
Nem kimondottan jó szó az átb***s, hanám mondjuk, úgy erősen váraltan helyzetek adódhatnak. Különös tekintettel, a mikró és kkv szektorra. Az emailfiókos mentős példa csak egy, de mondjuk emelhetik az árat, változtathatják a szolgáltatást (kivehetnek belőle alkatrészeket) ésatöbbi, mindezt akkora erőfölényből, hogy egyáltalán nem biztos, hogy érdemben tudsz máshova váltani. Eleve ott indulnak, hogy bazira elkényelmesítik a juzert, hiszen 25-50-100GB-os vagy mégnagyobb emailfiókokkal lehet csapatni. Ha van 25-30 ilyen felhasználód, akkor nem teljesen triviális a máshova költözés (most azon hogy, hogy lefut az imapsync lépjünk túl), mert már elég érdemes kimaradás, és kavarást okoz. Bőven elmúltak az idők, hogy POP3 ide, és akkor mostantól oda, puff az MX változik és kész.
A másik dolog, hogy egy tipikus amcsi felhőszolgáltatónál olyan szintű jogi felkészültség van, amivel igen nehéz versenyezni, mindezt úgy, hogy esetleg a székhelyük szerinti bíróságon hajlandóak bármire (lásd ászf), ha vita van. A veretes angol ászf-eket érdemes megnézni, pláne a kimondottan nagybetűvel szedett felelősség kizárási részt, ami gyakorlatilag azt jelenti, hogy hiába felhő.
Aki ezt nagyjából látja, próbál rá készülni, például rendszeresen menti a felhőben lévő saját fiókjait (valójában a bárhol lévő kéne valamilyen formában, mert adatra sehol sem fognak felelősséget vállalni), azért az tudatos felhasználó.
Én itt nem látok semmi átbaszást. Riskek vannak, amikkel érdemes tervezni. Konkrétan ez az email esetén tipikusan nem egy nagyon bonyolult feladat és megugorható, vmint kb. kijelenthető, h a döntő többség amellett döntött/dönt, h vállalja az "átbaszást".
Nade tegyük fel, h tényleg átbaszás esete forog fenn, ami nekem kb. azt jelenti, h rosszul jár, mert nem tud olyan érdemi információkról, amiket amúgy relatív egyszerű befektetés cserébe tudnia és értenie kéne.
Mi az alternatíva, amivel nem jár rosszul? Tegyük fel, h egy forprofit szervezetről van szó. Onnan indultunk, h a SaaS átbaszás. Melyik alternatíva az, ami nem átbaszás, tehát megéri?
Illetve ugye sokszor szolgáltatáscsomagot veszel, nem csak levelezést. Ott a Microsoft, ad neked levelezést (app és böngésző), üzenetküldés (teams), dokumentum szerkesztést és kezelése (office + onedrive), felhasználó managementet stb., mindezt egy integrált rendszer részeként.
Az szerintem független attól, h SaaS v. más.
Mire értesz az alatt hogy független? Van alternatíva ami hasonló összegért ezeket a képességeket biztosítja egy cég számára?
Ez a kérdésem, h milyen alternatívák vannak, ami megérősebb.
Ah, oké, így értem :D
Az átbaszás az ezekben, hogy a döntéshozó managerek azt látják mindenhol a hirdetésekben a mai napig (vagy most még jobban az AI miatt), hogy menjd ide vagy oda a felhőbe, és minden gondod meg van oldva. És ez az átbaszás. Mert annyi történik, hogy ilyen gondokat olyanra, ilyen költséget olyanra cserélünk mindössze. Nem úgy kezeli senki, hogy más riskek vannak, hanem úgy (a reklámok miatt), hogy onprem vannak riskek, felhőben meg nincsenek, mert ott megoldja a szolgáltató az összeset, csak fizetni kell.
Ezen átvert állapot miatt nincs senkinek még mentése sem a felhős adatairól (mert - hibásan - maximális a bizalom), nemhogy stratégia az átköltözésre, vagy onprem visszaköltözésre.
Ráadásul a felhős adat mentése is átbaszás, mert míg egy onprem rendszer esetén készítesz mentést, aztán valamikor a rendszer meghal, felteszed a nem-havidíjas-bérelt, hanem megvett szoftvereket egy másik hardverre, visszatöltöd a mentést és mész tovább.
Ellenben a cloud mentést hová töltöd vissza? Csak és kizárólag ugyan oda tudod visszatölteni, mert egyedi a szoftver, semmivel sem kompatibilis. Ha eltűnik az adott szolgáltató (tudom, nem tűnik el az MS meg a G, de mondjuk megemeli az árat amit a KKV már nem tud kigazdálkodni), akkor kezdődhet, hogy a mentésből kicsemegézed amit tudsz, de komplett a szisztéma elveszett (usereket, jogokat, összefüggéseket, szabályokat nincs hová visszatölteni kompatibilitás hiányában), azaz nincs hová egyben visszatölteni.
Én nem az átbaszás kifejezést használnám erre. Hanem a csőbe húzást (egy fokkal finomabb, kulturáltabb).
Azt gondolom, hogy olyan mentéseket, BCP / DRP stratégiákat kell kidolgozni, amik helyfüggetlenek. Mindegy, hogy SaaS, onpremise, hibrid cloud van. Az XY mentést (pl: Postgresql adatbázis) vissza kell tudni tölteni másik rendszerbe is. Nagyon nem triviális ez a platformfüggetlenség. Még a nagy multiknak sincs ezekre jó megoldásuk.
Ha eljutunk oda, hogy egyszerűen lehessen csinálni onpremise SaaS-t, akkor talán végre lesz jó megoldás a problémára.
Én sem az átbaszás kifejezést tartom a legmegfelelőbbnek, de ebben a szálban ez a terminológia lett bevezetve. És végül is sajna fedi azt, ami történik.
A legtöbben mondjuk előfizetnek M365-re levelezés és csoportmunka miatt (kis cégeknél ez a legjellemzőbb felhő felhasználás). Na, abból - ha ügyes a rendszergazda, és van még egyáltalán, mert a felhőhöz ugye nem kell -, akkor a levelezést IMAP-on és a doksikat fájlként ki tudják menteni. Ha nagyon nekifekszik, akkor a a naptárat meg a címtárat (ha egyáltalán használják) kimenti *DAV-val.
Csak a legtöbb ezt, ilyen módon igénybe vevő cég úgy oldja meg a mentést, hogy vesz egy Synology NAS-t, és azzal ment a beépített szoftverrel. Azt meg kb. ugyan oda lehet visszatölteni (ha sikerül egyáltalán úgy is...).
Itt nem csak a nagy cégekről érdemes beszélni, ahol több vagy több 10-100 közreműködő van a felhős/IT folyamatokban, hanem a kisebbekről is, ahol legtöbbször nincs dedikált szakember egysem. Pláne azért, mert a felhős szolgáltatók a marketingjükkel azt hitetik el a döntéshozókkal, hogy nem is kell, az SaaS megold minden ilyen jellegű feladatot, problémát. Szóval csak átbaszás az a végén.
Linkelnéd, ahol azt állítja az MS, h nrm kell backup?
Ill. miben értékesebb, az a backup amit te csinálsz, mint amit az MS? Mitől vagy te hitelesebb?
Ezen kívűl hogyan jellemeznéd. mekkora a kockázata annak, h szükség van rá (nem gondolom, h elhanyagolható, de kíváncsi vagyok a te megítélésedre).
Linkelnéd azt ahol írja hogy kell backup?
Megsaccolnád annak a költségét hogy megreccsen a szolgáltatás és (legyen mondjuk üzletfolytonossági okból) szükséges hogy másnapra működjön _ugyanaz_ a szolgáltatás az 1000 kliensed számára? Mondjuk valahol máshol.
Azt meg tudom válaszolni miben értékesebb az én backupom a Microsofténál: nálam van, én rendelkezem fölötte.
Bármilyen okból kell disaster recovery-t csinálnom, nálam van. Nem megy azzal idő hogy "előálljon a backup".
Gábriel Ákos
Teljesen kiadják az adataik feletti kontrollt akik elhiszik a felhős hype-ot. Tehát a hype-ot, mert természetesen nagyon jó felhő szolgáltatások vannak, nagyon jól használhatóan. Ugyanakkor ez nem csak a felhőre, hanem bármilyen külsősre bízott dologra vonatkozik. Sokszor látom, elég szomorúan, hogy ilyen N éves dolgokat keresgélnek, hogy vajon hol lehet, sőt sokszor követelik, hiszen készül _mentés_, amit meg kevernek az archiválással. Ráadásul sok esetben olyan adatokat keresnek, ahol már a szolgáltatást is lemondták.
Egy nagy(obb) vállalatnál lehet, hogy tudatosak, meg egy multi hazai leányánál, de azért a mikró és KKV szektor finoman szólva se az előre látásáról, és felkészülségéről híres. Természetesen tisztelet a kivételnek, mert látni jó példát, csak ők a szűk kisebbség sajnos.
Az az adat, ami fontos, és nincs róla valamilyen mentés, sőt igény esetén archiv, saját telephelyen, hatókörben, az valójában nem fontos. Az még elfogadható, hogy "A" szolgáltatónál van az éles adat, és "B"-hez mentenek, szóval már van valami legalább.
Az ugye megvan, hogy te is felhő vagy az ügyfeleid számára? :)
https://iotguru.cloud
Mindenképp az, de nem mindegy, hogy a szomszéd utcába/városba kell átszaladni a mentésért baj esetén, vagy az MS csetrobottal harcolni, hogy tegyék letölthetővé, mert pl. áll a szolgáltatás, de nayon kellene ami benne van...
Azt érti mindenki félre, hogy az IT-nek nem csak arra kell készülni, ha minden fasza, hanem arra is, amikor nem, bármilyen kicsi is ennek előfordulási esélye.
Amit leírtál, az hangosan szirénázó villogó red flag, hogy kurva nagy kupleráj van a cégnél. :D
Így van, pont erről van szó, hogy on-prem, helyi cégnek kiszervezett szolgáltatás és felhő esetén pont ugyanúgy fel kell készülni, hogy gebasz jön. Viszont - ha jól csinálod, akkor felhő esetén sokkal-sokkal egyszerűbb erre felkészülni, mert a tervezett és felépített architektúra olyan, hogy bármelyik komponensét átviheted bárhova maximum egy kis módosítással. De ezt már írták többen is.
https://iotguru.cloud
Nade nem készülnek fel. Elmondod hogy ez meg az kéne, meg ugye pénzbe kerül, meg ilyesmi, és így áll a projekt. Van ahol negyedévente van erről emailváltás és utána hümmögnek, és akkor marad ahogy van.
A meg lehet rendesen csinálni, nem jelenti azt, hogy hajlandóak. Ott indul a probléma, hogy át sem érzik, látják, hogy mennyire egy adott valamin múlik a mindenük. Persze amikor "nemmegy" a bármi, akkor _azonnal_ kell megoldás. Egyszerűen nem lehet mindenkinél folyamatos IT consultingot nyomni, hanem ugye vesz valamit, akkor megvette, de nem olvas ászf-et meg semmit. Aztán ha bárhol beüt valami, mert akárhogy figyelsz beüthet, akkor nagy szomorúság van.
És? Szar a cég működése, láttunk már ilyet, mi köze ennek mindenhez?
És?
A meg lehet rendesen csinálni azt jelenti, hogy nem a körülmények szarok, mert ugyanazon körülmények között más cég rendesen megcsinálja. Ha jön az apály, akkor meg látszik, hogy a korábbi nyakig érő vízben kinek pucér a segge.
Hulljon el, amelyik szar, de ne akarjuk már ráfogni a körülményekre.
--
Nem a felhő, az on-prem vagy az egyéb a szar, hanem a körülményekhez alkalmazkodni képtelen cégek. Ez ilyen, ha jól mérik fel, jól csinálják meg, akkor lehet, hogy 1 millió USD évente, ha rosszul, akkor 10 millió. De ez nem csak IT területen van, bármilyen más beszállítói területen mellé lehet nyúlni, egy összeszerelő cégnek minden egyes beszállítója felhő, amit vagy le tud cserélni, vagy nem. És minden egyes helyi gyártása on-prem, aminek szintén vannak kockázatai is ugyanazon problémái, hogy megvett kapacitásban áll a pénze, ha épp nem tudja használni.
Az IT-ba került be a legkésőbb ez a felhős szemlélet, az iparban ott van már két évszázada minimum, amióta áttértünk a céhes manufaktúráról a sorozatgyártásra, csak az IT-ban ez furcsa, mert abba nőttünk bele, hogy céges manufaktúra van minden cégnél, ahol mindent meg kell írni nulláról, fel kell találni a meleg vizet és a többi.
https://iotguru.cloud
És még vannak akik elhiszik, hogy a "kézműves" IT szolgáltatásai jobbak és ugyanakkor olcsóbbak mint a "tömeggyártott" (felhő) IT...
De van ám olyan IT-s akinek olyan ügyfél jut, aki nincs a megfelelő szinten. Merthogy egy cég sem úgy jön látre, hogy bejegyzik az E.V.-t aztán az IT az felhő-, mentés-, exit-, stb. tudatosan elindul a vállakozónál, mert úgy született Ő is, hogy mindezzel tisztában van.
És ezeknek a nem kis számú vállalkozásoknak a szintre hozása nem kis feladat. Persze van, aki azt mondja, hogy aki ilyen gagyi, azzal én nem üzletelek, nem dolgozok neki. De valakinek el kell ezt a munkát végezni (ezt a szívást végig csinálni). És ez nem könnyű ám akkor sem, ha egyébként nem utálják az IT-t mint a sz@rt... Könnyű kihúzni magunk ez alól, hogy mennyémá' milyen képzetlen cég vagytok. De ettől nem fognak előrébb lépni.
Ezen gondolatok alapján hasznos lenne, ha az SaaS szolgáltatók sokkal alaposabban tájékoztatnának, óvatosabban reklámoznának, hogy legyen mozgástere az IT-nek felhozni a céget az ehhez szükséges szintre, ne az legyen, amit én és többen írtunk, hogy kifizetik az SaaS-t és azt hiszik minden le van tudva, mert hozzáértés és érdeklődés nélkül a marketingből ez jön le nekik.
Kinek áll az érdekében ezeket a cégeket "szintre hozni"? Mert valójában ez számít. Nem az, hogy hasznos vagy nem hasznos.
A cégtulajdonosnak talán érdeke, de még ebben sem vagyok feltétlen biztos.
Gábriel Ákos
Mindenkinek.
Pont ezeknek a kis balfasz cégeknek áldás a cloud, hogy nem kell végre custom IT szarokkal szopniuk, hanem belátható fix költségért kapnak szolgáltatást, ami tényleg működik. Nem kell nekik szintrehozás, kapnak működő rendszereket, amit ő maguk képesek alapszinten beállítani és használni.
A cloud vs on-prem olyan cégeknél jön fel értelmesen, akiknél az IT létszáma ~50 fő feletti, akkor már képesek talán on-prem értelmesen működni. Ez alatt nagyjából cloud vagy on-prem oroszrulett, vagy köztes megoldásként valami helyi cég, de az is cloud, csak valamiért nem úgy hívjuk.
https://iotguru.cloud
Ugye olvastad: Ugyanakkor ez nem csak a felhőre, hanem bármilyen külsősre bízott dologra vonatkozik.
Nem mellesleg ugyanezt folyamatosan mondom a kedves Ügyfeleknek, ahol olyan a kapcsolat, meg felmerül, meg mindenkinek, ahol előjön. Az más kérdés, hogy nagyon kevés a foganatja. Egy külső HDD, egy NAS nem egy egetverő "beruházás" azért.
Hol írtam olyant, vagy mivel céloztam arra, hogy az MS szerint nem kell backup? Sehol, semmivel.
Ellenben nem is mondják kifejezetten, hogy "de azért mentést csinálj időnként", max. az apró betűből lehet indirekten kiolvasni, hogy érdemes mentést csinálni, mert semmilyen adatvesztésért nem vállalnak felelősséget (egyébként szerintem érthető olkból). Azért nem mondják, mert rontaná annak az üzenetnek a hitelét, hogy a felhő megoldja az IT gondjaikat. Mertugye ha megoldja, akkor miért is kellene nekem menteni...
Az általam készített mentés azért értékesebb, mert 1) én csináltam és tudom mi van benne, 2) ki tudom próbálni, hogy visszaállítható-e, 3) ha elveszik a SaaS szolgáltatással a kapcsolatom bármiért, a mentésben akkor is benne vannak az adataim (ha nem is triviális hozzáférni, de legalább kézben van). Én nem hinnél el, ha az M365 admin felületen ki lenne írva zöld betűkkel, hogy "a mentés sikerült, szükség esetén kattints erre a linkre a visszaállításhoz". Mert az a link csupán addig elérhető, amíg az MS elérhetően tartja... És ha megáll valami központi szolgáltatás (pl. hitelesítés), akkor az éles adattal együtt a mentés is elérhetetlenné válik...
Szerintem jelentős kockázat a csak felhőben tartott adat mentés nélkül. Még az is jobb, ha valami más felhő szolgáltatóhoz készül mentés (ami az eredetitől teljesen független és valószínűsíthető, hogy nem együtt múlnak el). De még jobb egy kézzel fogható (helyi, onprem) mentés példány bármi más mentés mellé pluszban.
Mondasz egy konkrét, akar fiktív esetet? A leírásod alapjan így képzelem:
KKV István, egy klasszik és sikeresk, 50 fős, forprofit cég CEO-ja, keres vmire a zinterneten, ahol X szolgáltató (pl. Google, MS) hirdeti a szolgáltatását, h de fasza.
Arankával, aki a COO szerepkört toltik be. megbeszélik, h mivel látták a reklámot és tetszett, erre váltanak és kiadják utasításba Linux Ferinek, h az onprem levelezést és a doksi kezelést csinálja át.
Első kérdésem, h te tényleg annyira lenézed egy sikeres cég management-jét, h egy banner alapján dontenek?
Megyunk tovább, X árat emel. István nem tudja/akarja kifizetni a sarcot már a következő hónapban sem. Mivel nincs mentés az adatai elvesznek és tépik a hajukat.
Erre semmilyen felvetést nem tudok írni, annyira nem realisztikus.
Van viszont egy reális felvetésem. Ha egy cég sikeres, az amiatt van, mert olyan emberek dolgoznak benne. Tegyük fel, h a ceo nem jár utana, se a coo és csak felülnek a hype-ra. Akkor nem a ggallo (IT guy) usernek kellene felhívnia erre a figyelmet? De megtha nem is. Nincs ott transzparensen a szükséges információ? Talán bottal kergetik, h váltania kell?
Ezen kívül nemcsak ilyen gondokat és költségeket cserél az ember olyanra hozzáadott érték nélkül.
> onprem rendszer esetén készítesz mentést, aztán valamikor a rendszer meghal, felteszed a nem-havidíjas-bérelt, hanem megvett szoftvereket egy másik hardverre, visszatöltöd a mentést és mész tovább.
Ez pl. egy remek példa. Egy CEO szempontjából riskekről van szó és végeredményben egy kérdésre keresi a választ: ár/érték arányban ki csinálja meg jobban, figyelembe véve az igenyeket: a szolgáltató, aki ebből él specifikusan és specialistája az adott témának, v. ggallo, aki mindenhez is ért. Mindegyiknek opciónak megvannak a maga korlátai.
Személy szerint pl. adatvesztést többet lattam helyben, mint cloudban (láttam ott is, nagytól is, pl. Gitlab). Emellett még van 10000 opció. Ezt csak azért írtam be, h elkerüljük, h megint szélsőségesen valaszolsz, mert ig n, lehet szarul is csinálni, pl. magát v. a főnöködet átbaszbi.
> Ha egy cég sikeres, az amiatt van, mert olyan emberek dolgoznak benne.
Nem. Az már egy következmény.
Ha igazad lenne, akkor kurva egyszerű lenne sikeres céget csinálni. Menjenek el ezek az emberek és csináljanak saját céget.
értsd: olyan emberek, akik tettek érte, h az legyen
Az a stratégiai vezetés zsenialitása, minden más megvehető alkatrész. Ha tetszik, ha nem.
Ugye milyen jó érzés hinni ebben? ;)
Hívj el egy hálózat kutató céget, hogy világítsa át a céged és meg fogsz lepődni, hogy valójában kik miatt működik.
Persze nem lebecsülve a vezetést, mert egy jó vezető szinte bármilyen társaságból csapatot formál és eléri, hogy maguktól akarjanak többet. De sokkal könnyebb, ha van egy lojális társaság aki megsokszorozza a vezető erejét és őt képviseli a többiek felé.
Igaz. De az nem ok, hanem következmény.
Az "átbaszás" ott van, hogy a döntéshozó managerek akinek fogalma nincs a technológiáról hoznak döntést a mérnökök helyett aki azért vannak felvéve hogy problémákat oldjanak és kitapossák az ösvényt amin keresztül az üzleti folyamatokat meg lehet újítani.
Fentebb már írtam, ezt is bedarálta a vállalati kultúra.
Pont azt írtam hogy az e-mail kevésbé gond - mert az igazi tömegtermék és eléggé szabványos (bár a Microsoft ugye ebbe is bele tud sz@rni természetesen). Tehát ott nagyon váratlant nem lehet húzni.
De mondjuk egy CRM-nél, "marketing automation"-nél, "content management"-nél bőven lehet variálni, nincs szabvány.
Gábriel Ákos
Azt írtad, h átbaszás. Azt fejtsd ki pls az emailre vonatkozóan. Ne azt, h miért ne.
Utána erdekel a crm téma is, csak haladjunk sorjában.
Rosszul fogalmaztam, pontosítok.
Az e-mailre nem átbaszás mert az szabványos és egyszerűen költöztethető az információ-tartalom (ami itt kb. egyenlő a puszta adattartalommal).
Ami ennél kevésbé szabványos (és az adatok közötti kapcsolatokban is van rengeteg információ) na az veszélyes.
Gábriel Ákos
Nade akkor a CRM v. pl. a webshop a service sem átbaszás?
Igazad van, elengedtem. A SaaS jó, a SaaS szép.
Gábriel Ákos
Sokat segítene a megértésb n, ha egyértelműen fogalmaznál.
Az az érzésem, h kevered az átbaszást és a veszélyt.
Az átbaszás lehetséges (beetetés, ASZF be nem tartása), vannak is róla cikkek. Ez egy olyan dolog, amit be lehet árazni.
Mint ahogy a tobbi kockázatot is (pl. elveszik a mailbox v. a tartalmának egy része), ill. lehet rá preventív lépéseket tenni.
A leginkább visszatetsző viszont az, h nem írtál alternatívát. Ha nem SaaS, akkor mi? Milyen áron, mennyire lesz az jobb és rosszabb? Meg is lepne, ha írnál, mivel az adott szituációra vonatkoztatva lehet értelmezni a kérdést, mivel a SaaS abszolút reális és nagyon gyakran a leginkább megfelelő alternatíva.
Fogalmazhatunk úgy is, h ez figyelmen kívül van hagyva, az át van át van baszva:)
Az SaaS egyáltalán nem a megfelelő alternatíva minden esetben, hanem az az alternatíva, ami a legolcsóbban oldja meg az adott feladatot adott minőségben. Már ott el szokott csúszni a kérdés, hogy olyan minőséget tűznak ki az alternatívák elé teljesítendőnek az összehasonlíthatóság okán, ami a felhőben természetéből fogva adott, az igénybe vevőnek viszont nincs rá szüksége, de muszáj onnantól ahhoz mérni mindent (pl. 24/365 support 9-17/5-ben dolgozó cégnél).
De lehet van olyan cég, ahol nem az az egyetlen cél, hogy a legolcsóbb legyen, hanem számításba veszik a biztonságot is, beárazzák, és azt választják. Pl. onprem megoldásokkal, vagy olyan felhős megoldással, amikor nem SaaS-t vesznek igénybe, csak IaaS-t, amin saját kezelésű, könnyen máshová mozgatható rendszert használnak, nem fuggenek a felhős szolgáltatók egyedi, semmivel sem kompatibilis megoldásától.
Ezt az enyémre akartad válaszolni? Mert meg nem cáfoltál, viszont úgy írtad, mintha. Azt irtam, h nagyon gyakran és nem azt, h mindig.
A többit sem értem, miért írtad be, ellenérvként akarod felhozni, h a legolcsóbb?
Te hozzászólásodra szerettem volna, de nem ide.
Ez lett volna az, és nem tudom miért ide került/itt nyomtam a választ (ezek szerint).
A lényege a mondandómnak az, hogy nem mindig/mindenki azt nézi csak, hogy hol a legolcsóbb(nak tűnő) megoldás per pillanat. Az onprem vagy az IaaS egész valószínű nem olcsóbb, sőt, de lehet olyan helyzet (amire tervezni kellene szerintem), hogy egycsapásra eltűnik az SaaS addigi árelőnye (pl. egy váratlan költözési igény adott SaaS-ről máshová, amire senki sincs felkészülve, de valamiért elkerülhetetlen).
A senki egy nagyon erős kifejezés ahhoz képest, h cégek vannak, akik cloudos service-ek backupjával és migrálásával foglalkoznak.
Basszus, hogy minden mondatomat (amik ráadásul nem elharapott tőmondatok) magyarázni kell.
Tehát: annál a cégnél, aki nagyon hisz az SaaS-ben és _náluk senki nincs felkészülve_ egy hirtelen változás miatti költözésre, mert fel sem merül, hogy ilyen előfordulhat, mert elhitték, hogy az SaaS szolgáltató megold mindent IS.
Akinek már van valami contract felhőt mentő/költöztető céggel bármi okból, az már fel van készülve, az nem ez a kategória...
Tök más értelme van ennek, mint az előtte lévőknek.
Hívjuk "csőbe húzás"-nak, igazából mindegy. A baj a marketingkommunikációval kezdődik: megveszed xy SaaS-t 3-4-5 dollár per user per hó és _minden_gondodat_megoldottuk_.
Kivéve amelyiket nem.
Amikor elolvasod a szerződést akkor azért kiderülhetnek dolgok. Ha elolvasod. Ha rákérdezel.
Eltelik 1-2 év, beintegrálod az anyám kínjába is, majd a SaaS vendorodat megveszi az y cég.
Aztán mi lesz?
- Cash-cow-nak használják? (licenszárak mennek az égbe)
- Piacszerzésre használják? (termék megszűnik, migrálhatsz)
Számtalan ilyen sztorit láthattunk már, az aktuális ügyfelek sosem jöttek ki ezekből jól.
Azt érteni kell(ene) hogy ezek mögött a cégek mögött mindig tulajdonosok (emberek) állnak akik egyszer csak szeretnének egy jó exitet (pénzt) csinálni.
Nekik akkor jó az exit ha sok ügyfelük van, mert attól értékes a cég - sokszor az exit előtt azért pumpálják fel az ügyfélszámot diszkontált árakkal, amit az exit után áremelés (ez a legjobb eset) követ.
Persze, vágom, van az ideális eset: a teljes használati idő alatt problémamentesen használt SaaS-nál nincsen jobb. Ekkor jöttél ki TCO szempontjából a legjobban. De ugye beleszámoltad az "elmigrálás" költségét is? - már persze ha kellett.
Van mondjuk egy 6 hónapos projekt, 5 userre kell ticketing. Megveszed az atlassian cloudot, TCO 60 USD, nincs ennél jobb.
Lényege a mondandónak: TCO-t kell számolni és a licenszdíjnál jóval több dolgot (és annak költségét) kell ebbe a TCO-ba beleszámolni.
Az élettartam végén az elmigrálás költségét is.
Gábriel Ákos
Ami még szintén érdekesség / paranoia? :
- az összes adatod a SaaS vendorodnál van
- legyen ez mondjuk egy CRM
Még ha be is tartják (nem tudod ellenőrizni) hogy ők istibizi bele se néznek az adatbázisod tartalmába ezt a metaadatok tekintetében _sosem_ ígérik meg. A kapcsolatokból, akár csak a kapcsolatok számából, annak alakulásából is lehet jó kis következtetéseket levonni.
Ezek a "másodlagos adatok" is komoly értéket képviselnek, ezt szintén eladják. Nem is gondolnád hogy áru vagy, de az vagy.
Arról nem is beszélve ha véletlenül "hibáznak" egyet és valahogy csak belenéznek a primary adataidba.
Gábriel Ákos
Az on-prem esetén is fennáll, hogy jön a beszállító és azt mondja, hogy jövőre háromszor annyiba fog kerülni a core-licenc vagy átállsz egy kétszer annyiba kerülő másik licencpolitikára.
Ha ilyen csak felhő esetén van, az baj.
https://iotguru.cloud
Az már nem tervezhetetlen.
Azt is teheted hogy felkészülsz és határidőre átmigrálsz. Vagy egy évre még megveszed aztán migrálsz. Ezek mind tervezhetőek - "csak" pénzbe kerülnek.
Tudhatsz még alkudni is a beszállítóval - mert nem vagy teljesen kiszolgáltatva neki.
Végül ha valamiért úgy döntesz hogy nem tartod be a szerződést akkor te nem tartod be, te vagy kontrollban - legfeljebb beperelnek, megbüntetnek. Ezek rizikók, költségek. De te vagy kontrollban, az üzlet megy.
Ez így van. Bajnak baj, tud "belső pánikot" okozni de talán nem annyira látványos mint amit egy SaaS offering bedőlése tud produkálni.
Lásd a sok küzdést a "lejövünk a mainframe-ről" témában. Vagy a "lejövünk a desktop windowsról banki szinten" témában ... oops, ilyet még _sehol_ sem láttam.
Gábriel Ákos
Ennyi erővel a felhőből leköltözés is tervezhető.
Felhő esetén se szoktak egyik napról a másikra változni dolgok, ott is hónapok múlva lép életbe valami változás, legalábbis a nagyoknál.
Hát, ööö... ritkán szokott az IBM külön licencelést létrehozni egy molyfing magyar cég miatt...
Melyik nagy dőlt be? Ja, hogy valami marginális piacú kicsit tetszett választani, mert olcsó? Hát van ilyen.
Aham, erről beszéltem például odafenn. Ez ugyanúgy vendor lock in, mert nem tudsz átállni másik beszállítóra és nem tudsz érdemben alkudozni velük.
https://iotguru.cloud
Nem kell "kulon licenceles", barmi is legyen az. Altalaban van egy kalkulator, amibol kiesik az arajanlat, es abban mindig szokott lenni olyan sor, ahova be lehet irni a kedvezmeny merteket.
Igazabol eddig egyszer sem lattam olyat, hogy valaki listaaron vett volna valamit, pedig dolgoztam mar corporate presales-ben.
Olyat én se láttam, olyat viszont igen, hogy konkrétan zsarolnak ezzel a kedvezménnyel: ha nem veszel ezt-vagy-azt vagy többet kellene fizetned, akkor ez a kedvezmény tud csökkenni. Másrészt licencpolitika váltásnál hiába van ott, ha ki van adva, hogy több bevétel kell. Akkor több bevétel lesz. Ne tegyünk úgy, mintha on-prem esetén nem lenne komoly vendor lock-in, sokkal durvább vendor lock-in szokott lenni, mint felhő esetén, ahol gyakran van polcról levehető adapter, emulátor vagy migrációs tool gyakorlatilag bármiről-bármire, sokszor ingyen.
https://iotguru.cloud
Igy van, csak olyan garazscegek projektjei dolnek be, mint az Azure Media Services, vagy az AWS DeepLens, utobbinal meg egy hardvert is radmelegitettek.
Ezek egyike se bedőlt a szó értelmében, hogy előjel nélkül kivezették vagy megszűnt és nem volt többet, hanem szóltak jó előre és aztán kivezetik vagy idén kivezették.
Ugyanígy tudsz járni on-prem szoftverrel, amit kivezetnek és nincs többé, sőt, hardverrel is. Szóval továbbra se látom, hogy hol van az a rettentő nagy kockázat az on-prem-hez képest, ahol ugyanígy tudsz járni, ha nem te magad csinálsz belső erőforrással mindent az utolsó csavarig.
https://iotguru.cloud
De azert erted a kulonbseget, ugye? Marmint hogy kozli veled a szolgaltato, hogy (a) 3 honap mulva rm -rf / az adataidra, vagy (b) 3 honap utan nincs tobb support a nalad levo termekere, de azert meg mukodni fog tovabb. Ha most nem akarom megujitani a vmware licencet, mert tizszer dragabb lett, de nem is vegzek teljesen a migracioval a support szerzodes vegeig, akkor mi van? Semmi. Majd vegzek egy honappal kesobb.
A (b) eset sem idealis, de messze nem olyan erzes, mint amikor pisztolyt fognak a fejedhez egy ultimatummal.
Ezek továbbra is random általad megállapított peremfeltételek, amelyekkel jobb helyre tudnád áthúzni a vitát, holott van on-prem esetén is olyan, hogy megkapod az adataidat binárisan vagy úgy se, aztán mehetsz, ahova akarsz. Láttam ilyet, anekdotázzak? Jutunk azzal valahova, hogy ki látott nagyobb szart?
https://iotguru.cloud
Vendor lock-in mindkettő (mindhárom) bizony. Csakhogy a standard SaaS hozzáállás esetén (balfasz ügyfél) még a saját adataid felett sem rendelkezel.
Sokkal nagyobb üzletfolytonossági rizikó mint hogy x perpetual licenszről nem tudsz upgradelni (vagy nem kapsz több supportot) mert nem vagy hajlandó megvenni.
Microsoft példa:
Office 2021-et megvetted, újabbat nem veszel mert csak, so what, dolgozol a régivel.
M365-t nem fizeted, ha nem volt backupod oda van az összes doksid is.
Gábriel Ákos
Ha MS felhő, akkor illik a full licenszet venni, ami adja az office-t havidíjasan. Mondjuk ha 10x EUR 20 per hónapot ki akarsz fizettetni a kedves fővezérrel, akkor meg sziszeg, hogy jajjdedrága. Na mind1. Bár hozzátenném, hogy a böngészős történet sem rossz, nem kell feltétlenül a telepített fix alkalmazásokba bezáródni, de ez megint dolgozói hozzáállás kérdése.
Feltétlen kell, hogy az adat csak nálam legyen? Nem elég belőle másolat?
És hova mentem az adataimat? Saját gépre?
Ja, hogy on-prem esetén az a default, hogy van mentésem, cloud esetén meg az a default, hogy nincs? Ha van backup stratégiám, akkor az van on-prem és cloud is. Ha nincs backup stratégiám, akkor az nincs sehol se. Nem értem a lényegi különbséget.
https://iotguru.cloud
Hat persze, lattuk is, nemreg epp a vmware jatszotta ezt be. Csak hat a targyalasok hangvetele egesz mas, ha fizikailag is nalad vannak az adataid.
Az Oracle JAVA őrületét se felejtsük a dolgozói szám alapú licenszekkel. https://redresscompliance.com/decoding-oracle-java-licensing-java-licensing-changes-2023/#:~:text=How%20Oracle%20Java%20Licensing%20works,significant%20licensing%20change%20since%202019.
A tárgyalás hangvétele nem különbözik nagyon. Ha jogtalanul használod a szoftvert az következményekkel jár.
Az elmúlt két évben a cloud sokkal nyugisabb volt mint a szoftvergyártók meglepetésszerű lehúzásai... (Oracle, VmWAre)
pont ma merült fel munkahelyen, egy új aws stack-et kellett összerakni
mi van ha a dev generál egy 8 miliós aws számlát? Senki se felügyelt rá mit csinál
ezt jobb cégeknél hogy védik ki?
Dev csak erőforrás és költség limitált cucchoz férhet hozzá, és érettségtől függően vagy kézi limites környezetbe engedi az üzem a deployt vagy a cd pipeline-on van policy enforcement ami a kezére csap annak akinél megszalad a cerka. Pénz vonzatú változásról csak pénztárca gazda dönthet, azaz ő húzza a limitet, azon belül lehet gazdálkodni
Hah. Azért hányszor látni, hogy a fejlesztő adja a lovat a mindenféle horror "megoldás" alá, merazjólesz, aztán se nem jó, se nem lett olcsó, és villognak a szemek a menedzsmentben. A nagyobb probléma, hogy mára alig-alig tartják szem előtt a fejlesztéskor, azért ne a világ összes erőforrása kelljen a bármihez, ne fusson (kvázi) végtelenciklusra a valamijük.
A jól-gyorsan-olcsón háromszögből mindig max kettőt választhatsz.
Gábriel Ákos
agilisan megspóroltuk a rendszer tervezését különös tekintettel a nemfunkcionális követelményekre, és ennek ez lesz az eredménye. Mivel a fejlesztési költség brutál drága, a cég szempontjából egyébként sokszor jóval olcsóbb plusz erőforrást rakni a szerverbe, bármennyire is fáj ez az üzemeltetésnek.
Nem a pluszerőforrásról van szó, hanem hogy ezt olyan léptékben csinálják, hogy az villanyszámlában, szerverszámlában több lesz 1-2 év alatt, mintha odafigyteltek volna csak egy kicsit. Aztán mi lesz? Hát miért ilyen béna az üzemeltetés, hogy ez ilyen drága, meg hát lassú az alkalmazás, és nyilván az üzemeltetést fogják nyesztetni, hogy "csináljon valamit", teljesen writeonly szokott lenni a kommunikáció.
No de ezért kell(ene) foglalkozni az nemfunkcionális követelményekkel és bevonni az ops csapatot is, mert simán lehet egy valid döntés az hogy ez olcsóbb lesz így vagy úgy, de tegyük már mögé a számokat.
Egyébként pont ezért szoktam én még a tervezés folyamatában bevonni mindenkit: tesztelő csapatot, fejlesztőket és devops-ot is (most engedjük el hogy a devops az..).
Ez az esetek 99+ százalékában kommunikációs probléma, ahol mindenki igyekszik nagyobb hangerőn kiabálni a saját fájdalmát, de nem hallgatja meg a másikét.
https://iotguru.cloud
De amúgy ez azt jelenti, hogy az Amazon és a Google is ekkora profittal tolja? Mert amúgy a költségeik ekkora léptékben kisebbek kellene, hogy legyenek, mint amikor a 30 fős cég végzi a beszerzést, és ott kell a tudást fenntartani, egy cég kedvéért. Szóval valahol az tűnne a logikus megoldásnak hosszú távon, hogy beálljanak az árak oda, hogy a nagybani kölségcsökkenés eloszoljon a felhőszolgáltató és az ügyfél között. Ha szabad a verseny környezet. Szóval elvileg az, hogy felhőben olcsóbb kellene, hogy legyen nem csak hype kellene, hogy legyen.
A felhős cégeknek jó ez a sok balfasz, akik megfogják a 20-30 éven át organikusan fejlődő skálázhatatlan szarkupacuk négy sarkát és úgy-ahogy-van beviszik azt a "felhőbe", hogy ott majd milyen jól és olcsón fog futni. Aztán meg néznek, mint a kiszántott egér, hogy drága, mert a felhő rosszul használva bizony drága.
Három kérdésből el lehet dönteni, hogy érdemes-e felhőbe menni:
1, a felhő megold problémákat, amelyek most jellemzőek a céges IT területre?
2, meg tudod becsülni, hogy mennyit nyernek az alkalmazottaid időben/produktivitásban a felhős megoldással?
3, ki tudod számolni, hogy mennyi a TCO a jelenlegi és a felhős megoldás esetén? Valóban ki tudod számolni?
Na, ezek azok a kérdések, amire a legtöbb felhőre lelkes cégnél nincsenek értelmes válaszok.
https://iotguru.cloud
#nemakarokbeleszolni, de ez 4:P
Csak az kérdés, hogy a nem gazdaságosság oka az, hogy rosszul van használva, megtervezve a migráció. Vagy pedig az, hogy nyeregbe kerülnek a felhőszolgáltatók, mert arra gondolnak, hogy költözni költséges, tehát nyugodtan lehet emelni az árakat, amit megtudnak csinálni olyan módon, hogy nehezen látható, hogy mik az okok. (Vagy akár lehet itt az is, hogy eleve azt is összetett, elvégezni a számításokat a költségekről. amihez ugye a felhő szolgáltató ajánl eszközt, ami kiszámolja, hogy mennyire fogja meg megérni költözni)
Szóval a kérdés az, hogy lehet e gazdaságosabb e a felhő. És a válasz lehetőségek lehetnek ilyenek:
(1) - igen, mert nagy méretben olcsóbb, rugalmasabb biztosítani ezeket a szolgáltatásokat. (már eleve beszereni is a hardvert, kiépíteni az infrastruktúrát, logisztikát, tudást fentartani, fejleszteni stb) kb mint a háztáji vs nagybani mezőgazdaság.
(a) - (1) igaz. de rosszul használják az ügyfelek
(b) - (1) igaz. de az ügyfél kiszolgáltatottá válik a költözés költségei miatt, és ezzel viszsaél a szolgáltató, és árazza azt, hogy be van lockolva a cég. azaz, ha jól használná az ügyfél sem lenne gazdaságos a végén.
(c) - (1) nem igaz. ha jól használná az ügyfél, ha nem élne vissza a helyzetével a cloud szolgáltató, akkor sem lenne gazdaságosabb.
Mindegyik. Egyik sem. Nem tudom. :)
nagy méretben olcsóbb - igaz
rosszul használják az ügyfelek - sokszor igaz
az ügyfél kiszolgáltatottá válik a költözés költségei miatt - a szolgaltato csak addig emelhet arat, amig az olcsobb mint a visszakoltozes ara, viszont letezhet olyan szolgaltatas, amit helyben lefejleszteni nagyon-nagyon draga lenne
Úgy mondod ezt a vendor lock-in dolgot, mintha az nem létezne on-prem esetén, pedig hogyne létezne, sőt, hatványozottan létezik, mert több rétegben is vendor lock-in van on-prem, mint felhőnél.
Felhőnél - ha kicsit is jól tervezed meg, akkor egyszerre több felhős céget is használhatsz, éppen melyik a jobb, olcsóbb, szebb, kényelmesebb egy adott szolgáltatást tekintve. Nem vagy egy szolgáltatóhoz kötve, ha igen, akkor valamit rosszul csinálsz.
https://iotguru.cloud
1. igen, óriási profittal tolják
2. abszolút nem az az infrastruktúra van a datacentereikben mint a te SME szerverszobádban, nem összehasonlítható
3. a felhőben (konkretizáljuk: aws, azure, gcp) szerintem a nagyon pici és a nagyon nagy ami olcsó lehet
- a nagyon nagy sokszor akkora hogy normál cégként kb lehetetlen megcsinálni
A közepes méretnél kell nagyon észnél lenni hogy ne legyen nagyon drága. Itt jönnek be amúgy az IaaS és PaaS szolgáltatók (akik nem a fenti cloudszolgáltatók), ezekkel ügyesen kombinálva (hetzner, digitalocen, backblaze és társai) lehet hatékony dolgokat csinálni.
A georedundáns rendelkezésreállása egészen más szintű lesz mint bármi amit SME szinten össze tudnál rakni értelmezhető pénzből.
Tulajdonképpen "for free".
Gábriel Ákos
és mi az oka annak, hogy a közepesnél nem olcsóbb? nem tűnik egy természetes oknak.
meg azure, aws is lehet Iaas és Paas, itt az általad említett cégeknél egyszerűen ár előny lenne vagy más?