DHH kiábrándult a felhőből

Egyéb

David Heinemeier Hansson a Ruby on Rails keretrendszer alkotója csalódott a felhő alapú szolgáltatásokban. A Basecamp és a Hey üzemeltetése során azt tapasztalta, hogy a felhős szolgáltatások nem tették egyszerűbbé az üzemeltetést, viszont drágák. Szerinte sokkal jobban járnak ha átállnak nem felhő alapú szerverekre és saját maguk üzemeltetik majd őket.

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. We've run on bare virtual machines, we've run on Kubernetes. We've seen all the cloud has to offer, and tried most of it. It's finally time to conclude: Renting computers is (mostly) a bad deal for medium-sized companies like ours with stable growth. The savings promised in reduced complexity never materialized. So we're making our plans to leave.

Részletek a blogbejegyzésben.

( _Franko_ v | 2022. 10. 25., k – 10:54 )

A felhő akkor hasznos, ha a terhelés előre nem látható módon változik, amire nem lehet előre megvenni a vasat. Ha a terhelés kb. azonos vagy értelmes keretek között változik, akkor a felhő egy kurva drága opció.

Arról nem is beszélve, hogy az Amazon-Google-Microsoft felhő pláne kurva drága.

--

1, Ha nem foglalkozunk teherszállítással, de néha kell teherautó, akkor olcsóbb bérelni -> felhő

2, Ha teherszállítással is foglalkozunk, szinte minden nap kell teherautó, akkor olcsóbb megvenni -> saját vas

3, Ha teherszállítással is foglalkozunk, minden nap kell teherautó, de néha kell sokkal több teherautó, akkor meg kell venni és a többletet bérelni kell -> saját vas + felhő

--

Minden más esetben jön a csodálkozó villámnyúl, amikor fizetni kell.

https://iotguru.cloud

A felhő akkor hasznos, ha a terhelés előre nem látható módon változik, amire nem lehet előre megvenni a vasat. Ha a terhelés kb. azonos vagy értelmes keretek között változik, akkor a felhő egy kurva drága opció.

Na ez az. Most épp egy olyan alkalmazást viszek felhőbe, amelyik 7/24-ben dübörög soksok cpu-n és foglal sok-sok giga memóriát (szevasz Java!). A terhelés valamennyit változik, talán a webszerverekbe 1 cpu-val több kell hétfő reggel, de kb ennyi, a DB és a alkalmazásszerver nagyjából mindig megy, és az alkalmazás természete miatt pluszminusz 20% ingadozás mellett nagyjából állandó a terhelés. A cég a gatyáját rá fogja fizetni, ha 3 környezet (dev-staging-prod) a felhőben fog pöfögni, és majd jönnek azzal, hogy mit lehet kikapcsolni hétvégére (amire azt válaszolom majd, hogy mindent, amiről hajlandóak lemondani az alkalmazást használó belső ügyfelek...).

De a cél ki van mondva, felhőbe kell vinni, ha jó, ha nem jó. 

Jo, amit irsz, de nem emeled ki elegge:

A felho csak folyamatos terheles kezelesere valo.

A "konzumer felho" (ertsd: nem devops balance-olasahoz kitalalt, hanem mediafajlok tarolasara kitalalt) pedig addig tunik jonak, amig AI-k at nem scannelik es a Sony WMG es hasonlok keresere ki nem torolnek egy csomo false positive-ot egy bug miatt, ne adj Isten letartoztatnak par embert AI tevedese miatt.

( uid_17626 | 2022. 10. 25., k – 11:03 )

Van egy másik probléma is vele. Az outsourcing mellékterméke, hogy tudásmonopóliumot hoz létre máshol, a kihelyező pedig elveszíti azokat a kompetenciákat. Hosszú távon ez hatalmas stratégiai hiba. Lásd USA<->Kína esetét most.

Nagyon jó az USA Kína hasonlat. Mert elvileg tényleg mind a kettő jó megoldás lehetne és ténylegesen olcsóbb. Csak amikor létrejön a kiszolgáltatottság, utána már nehéz lesz elhagyni kínát és a felhőt is, és ezt tudva a felhő szolgáltató már nem fogja az ügyfélnél hagyni azokat a valós megtakarításokat, ami miatt ténylegesen olcsóbb lehetne a felhő. Mert az érvek a felhő költség spórolási lehetőségei mellett valósak lennének, csak ellenérdekelt a két cég és a felhős cég magánál tart egyre többet az előnyökből.

És ha a technológiák is a felhő szolgáltatókon belül fejlődnek majd, mert ott van erre pénz, meg ott áll rendelkezésre az adat, amire alapulhat a fejlesztés, akkor aztán még nehezebb lesz majd nélkülük élni.

Nem álom, multi-cloud kulcsszóra keress. Egyre többen jönnek rá hogy a felhő is könnyen lock-in, ezért technikai "oszd meg és uralkodj"-ot játszanak. Lásd cloud native kubernetes workload csont nélkül mozgatható több szolgáltató közt. Csak ugye ingyen ebéd nincs, így kell pár nagyon felhő árazás és kapacitás optimalizáló automatizáló hozzáértő ember a cégnél, nem elég, ha a fejlesztő lekattintja ami jólesik

Lásd USA<->Kína esetét most.

Ez pont fordítva történt. Kína megkapta az alacsony hozzáadott értékű munkát, tudást viszont nem kapott hozzá és USA most megtiltotta a magas hozzáadott értékű anyag és tudás exportot Kína felé, ezért most Kína szopóágon van.

Az outsourcing mellékterméke, hogy tudásmonopóliumot hoz létre máshol, a kihelyező pedig elveszíti azokat a kompetenciákat.

Pont ezért van értelme csak az alacsony hozzáadott értékű munkát kiszervezni: összeszerelést és az alapanyag gyártást, megtartva a K+F és a tervezői munkákat. Ha az Apple azt mondja egyszer, hogy hazaviszi az összeszerelést, akkor lesz iPhone továbbra is, legfeljebb drágább lesz vagy kisebb lesz rajta a haszna. Kína viszont nem fog tudni iPhone-t gyártani, pusztán azért, mert korábban ott gyártották és szerelték össze, mert nincs meg hozzá a tudása.

https://iotguru.cloud

Nagyvonalakban kb egyetértek, de azért sajnos ennyire nem volt szép tiszta a helyzet. Az iPhone-okhoz a teljes ellátási lánc ott épült ki. Mikor pár éve felmerült, hogy USA-ba vissza kéne vinni a gyártást, olyan alapvető dolgokkal is gond volt, mint pl csavarok. (Ok, az Apple pont elmehet a szabványtalan pentalobe csavarjaival oda, ahol mindig sötét van... de a lényeg ettől még ugyanaz marad, a több évtizedes, Kínába kiszervezett gyártás után a beszállítói lánc teljesen elsorvadt az USA-ban.)

Régóta vágyok én, az androidok mezonkincsére már!

Nyilván nem megy egyik napról a másikra egy komplett logisztikai láncot határon belülre hozni, de ettől még a jelenlegi USA vs Kína helyzet egy USA -> Kína irányú magas hozzáadott értékű export tilalom, a tudás nem a kínai oldalon van, USA pont okosan művelte ezt, a szürkeállományt tartja határon belül.

https://iotguru.cloud

Szerintem a kínai szakemberek egyre jobbak, ráadásul ott van nekik a képzett orosz és indiai munkaerő. Ebből nehéz lesz az USÁ-nak fallback-elni...
Ha megeszik Taiwant reggelire, akkor pedig meglesz nekik a TMSC és a többi gyártósor is.

http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

Így van, teljesen felesleges a vita, mert írsz valami faszságot, aztán amikor kiderül, hogy például pont fordítva van, akkor elkezded elkenni a faszságot jó hosszan, behozva hozzá teljesen irreleváns témákat. Lehet, hogy ez a környezetedben jól működő stratégia, csak egy értelmes vitához épp semmi köze.

https://iotguru.cloud

Bármelyik UI megfelelő lehet. Akinek a MIUI jön be, annak az jön be, semmi probléma nincs ezzel.

A probléma az, hogy egy vanilla Android feletti UI skint és egy komplett operációs rendszert ökoszisztémával együtt vetsz össze úgy, hogy egyetlen értelmezhető vetélytárs... hát... mondjuk nem lepsz már meg ilyen kijelentésekkel és azzal se, hogy nem érted a problémát a kijelentés kapcsán.

https://iotguru.cloud

Na, megint jön az a stáció, amikor elkezded elkenni a faszságot jó hosszan, behozva hozzá teljesen irreleváns témákat... :D

Tehát az iOS kb egyetlen versenytársa egy iOS like Android skin? Kijelentve ezt egy olyan sub-szálban, ami arról szól, hogy tudnak-e a kínaiak iPhone-t gyártani, ha az Apple mégse velük akarja összeszereltetni?

https://iotguru.cloud

Szóval ezt értetted meg ebből. Értem.

Maximum ugyanennyi erőt -de inkább kevesebbet- igényelne az a verzió amikor megérteni akarsz és nem félreérteni, belém magyarázni. Elgondolkodtál már azon miért csinálod ezt? Így akarsz okosabbnak tűnni vagy többnek?

Szóval ezt értetted meg ebből. Értem.

Más se értette meg abból, amit leírtál... szóval igen nagy szignifikanciával faszságot írtál. :D

Elgondolkodtál már azon miért csinálod ezt? Így akarsz okosabbnak tűnni vagy többnek?

Elgondolkodtál már azon, hogy miért jó neked ilyen faszágokat írni, aztán elkenni, amikor kiderül, hogy faszság? Így akarsz okosabbnak tűnni vagy többnek?

https://iotguru.cloud

Szerintem fordítva gondolkozol.

Azért szervezték ki a gépsor építést is Kínába, mert annak kicsi a hozzáadott értéke, nem attól lesz a termék jó, mert meg tudjuk építeni hozzá a gépsort. Így csinálhatja Kína is, mert olcsón csinálja (amit olcsón lehet csinálni, és bárki tudja csinálni, annak alacsony a hozzáadott értéke, így a gépsor csinálásnak is).

Az iPhone hozzáadott értékében vajmi alacsony a kínai hozzáadott tudás. Bárhol lehetne a gépsor, mert ma már ilyen gépsort bárki tud csinálni, nem új technológia, nem különleges technológia és nem egyedi dolog. Nem ettől értékes az iPhone, nem ez adja a hozzáadott értéket.

Az iPhone kb minden alkatrésze nem saját fejlesztés.

Egyrészt miért kellene minden alkatrészt házon belül gyártani? Másrészt a főbb alkatrészek nem kínai tervezésű alkatrészek, a legfőbb alkatrészek meg mind saját tervezésű alkatrészek. Hogy épp ki gyártja, az már részletkérdés. Akárki is gyártja, az nem tud az Apple nélkül iPhone-t gyártani, pont a lényegi tudástranszfer nem történik meg, ahonnan indultunk.

Nem véletlen, hogy az iOS kb egyetlen vetélytársa a MIUI 

Ezt röhögés nélkül le tudtad írni? :D

https://iotguru.cloud

> Egyrészt miért kellene minden alkatrészt házon belül gyártani?
Nem kell, csak lehet. Például stratégiai okokból, hogy később ne sírjunk azon, ha pl kínai autókkal fogunk járni. Ahogy azon sem, hogy ma már a dolgaink nem csak Kínában készülnek, de ott is a fejlesztik őket. Nagyon közel vagyunk ahhoz, hogy már a tudást is onnan importáljuk.

Például stratégiai okokból, hogy később ne sírjunk azon, ha pl kínai autókkal fogunk járni.

Na, ismét egy éles U-kanyar, eljutottunk a kínai autókig abból, hogy iPhone-t nem tudnak gyártani a kínaiak Apple nélkül.

Ahogy azon sem, hogy ma már a dolgaink nem csak Kínában készülnek, de ott is a fejlesztik őket. Nagyon közel vagyunk ahhoz, hogy már a tudást is onnan importáljuk.

Annyira messze vagyunk ettől, mint amennyire a MIUI messze van az iOS-től...

https://iotguru.cloud

tiktok ;)

Egyebkent viccet felreteve:

Huawei (beleertve a modemeket es az 5G halozat nehany epitoelemet), Xiaomi, Geely (Volvo, Lotus) pl.

De vegyuk eszre, hogy otthon nekik van koltseghatekonyan kiepitett villamgyors magnesvasutjuk is. Az masik kerdes, hogy a BP-Belgradra ugy tunik abbol mar nem jutott.

Egyebkent ha csak egyetlen emberrel beszelsz, aki par hetet eltoltott Pekingben vagy Shanghaiban, rengeteg tevkepzetedet fel tudja oszlatani mar onmagaban. Idealis esetben egy ilyen beszelgetes utan azon gondolkodsz, hogy miert hiszi azt a Nyugat 90%-a, hogy ezek visszamaradottak lennenek.

Kicsit off, de a sanghaji maglev pont nem annyira jo pelda, mert egyreszt a Siemens epitette nekik, masreszt ez egy rovid "demonstrator" vonal Pudong repter es a belvaros kozott, ami arra keszult, hogy eladjak a maglev technikat a Peking-Sanghaj vasuti beruhazasra. A kinai allam koltseghatekonysagi megfontolasbol vegul elvetette es helyette hagyomanyos sineken futo gyorsvasutat epitettek. Szoval ez tortentesen se nem sajat fejlesztes, se nem koltseghatekony. (Amugy lattam eloben, csak sajnos nem jott ki ugy a lepes, hogy utazzak is vele.)

Régóta vágyok én, az androidok mezonkincsére már!

Nem limitalnam a Sanghajira, leginkabb hogy az egesz orszag milyen faszan bejarhato vonattal. Mikozben Nyugaton az autopalyan gyorsabban mehetsz, mint a vonat, ha epp nincs dugo, ott a vonat inkabb a repulovel versenyzik lassan. :)

Siemens epitette

Valojaban hazaik sincsenek, mert a betonkevere egy brit epitesz szabadalma volt, es hasznaljak a hazak epitesenek nagy reszehez a betonkeverot. ;)

Ha felre akarod erteni a hozzaszolasomat, akkor felre is tudod. En arra batorkodtam ramutatni, hogy konkretan a maglev nem volt jo pelda arra, amit mondani akartal. Nem tobbet es nem kevesebbet.

Egyebkent nyugaton is tudsz vonaton gyorsabban menni az autopalyanal. Van ahol mar 40 eve is. Az, hogy ez hozzank valahogy nem akar eljutni, az egy teljesen mas problemakor...

Régóta vágyok én, az androidok mezonkincsére már!

A brexit ota brit rendszammal igen, mert nincs kiadatas. :)

Viccet felreteve a francia TGV/RER pont egy ritka udito kivetel Europaban. Nem, meg a Eurostar sem kivetel, leginkabb mert Kinaban nem kell vegignyomkodnod a bankod appjaban a hiteligenylesi process-t, mielott felulsz a 400-zal kozlekedo vonatra. ;)

Pl spanyoloknál is van kb TGV-szintű vasút.

Másrészt azért tudnék mesélni arról, hogy Kínában hogy is ment a vonatjegyvásárlás. Ez a hiteligénylési process elég jó példa volt... csak ott társadalmi pontrendszernek hívják. Én még pont azelőtt jártam ott, hogy bevezették volna, nem tudom mennyi esélye volna egy külföldinek bármit elintézni azóta. További vicces dolog, hogy csak Alipay/Unionpay appal lehet fizetni (ami külföldinek nem nagyon lehet, legalábbis az adatok megadása után mindig visszadobta, hogy nem regisztrálhatok). Kp-vel, külföldi bankkártyával nem. (Ok, offline módon, az emberes jegypénztárban lehetséges, hogy tudtam volna fizetni kp-vel, de ott esély nem volt angolul is beszélő embert találni). Az viszont biztos, hogy városi tömegközlekedésre kp-vel csak vonaljegyet tudsz venni, kártyát (amiről minden utazásnál lehúzza az összeget) természetesen csak a Ali/Unionpay-el. Árban nagyon jelentős különbség volt a kettő között.

Ráadásként amikor kinn voltam, a vonatjegy vásárlásra éppen olyan captcha-t vezettek be, amit a helyi kínai kollégáim is sokadik próbálkozásra tudtak csak megfejteni (elég komoly felháborodás volt belőle, az újságok is tele voltak vele). Szóval ja, nem olyan egyszerű az Kínában sem...

Régóta vágyok én, az androidok mezonkincsére már!

Igen, ezt elbasztam. Elfelejtettem, hogy az Apple-t csak dicsérni szabad itt a mernők urak között. Isten ments, hogy bárki figyelmét felhívjam arra, hogy mi mindennek semmi köze nincs az Apple termékekben az Apple-hez. 

- kijelző
- memória
- háttértár
- kamera
- mikrofon
- hangszóró
- wifi
- 5g

Elfelejtettem, hogy az Apple-t csak dicsérni szabad itt a mernők urak között.

az életben nem volt apple eszközöm, és a hideg ráz akkor is, ha egy a kezembe került. de hajrá, remélem a többi megállapításod is legalább ennyire tényszerű, személyeskedésektől mentes, és right on the point.

Az Iphone két legfontosabb része, a CPU és az OS saját fejlesztés, ez adja a versenyelőnyét. Ezt nem tudja senki a világon replikálni, ez a tudás csak náluk van meg.

Pont a hozzáadott érték nem az alkatrészben van, hanem abban a tudásban, hogy: melyik alkatrészt válasszad, és hogyan integráld.

Nem az a fontos, hogy ki gyártja a memóriachipet és ki forrasztja az alaplapra. Ezt a világon nagyon sok cég meg tudja csinálni. A fontos az, hogy hogyan lesz az egészből rendszer és ökoszisztéma - ezt viszont csak egy cég tudja igazán megcsinálni.

 

A MIUI egy UI, a kompetitorok az Apple számára a Google és a Huawei, ők ketten akarnak még teljes app ökoszisztémát adni, meg fejlesztőknek SDK-t: ők csinálnak platformot.

Persze te mint fogyóeszköz-gyártó, ebben a koordinátarendszerben gondolkodsz, hogy a gyártósor a fontos, mert a jó gyártosoron lehet megfogni a profitot egy olyan szegmensben, ahol nincs már mit optimalizálni a terméken.

Miközben az Apple nem csak ebben gondolkodik, szolgáltatás, platform, ökoszisztéma, SDK, fejlesztők, stb. Nem a jó gyártósor a lényeg, mert nem ez adja a profitot. Megmondta anno Jobs is, amikor Obama kérdezte tőle, hogy miért nem az USA-ban gyártják az iPhone-t, drága lenne? Megmonda, hogy nem, bőven tudnának profitot termelni úgy is, csak éppen az amerikai munkajogi szabályok nem engedik meg azt a rugalmasságot, amit egy kínai cég megenged. Ha kell, ott egy hét alatt felvesznek ötezer embert és rúgnak ki két hét múlva, mert megtehetik, ugyanis le van szarva a melós. Az USA-ban nem tehetik ezt meg.

Veled értek egyet. Ha nem így lenne nem lenne a csomó minőségi kínai telefon pl. Szóval a full tudás valahogy mégis csak átment oda.

 

Meg eleve maga a gyártás technológia maga egy science, ahol részben a megszerzett tapasztalatokból lesznek fejlettebb költséghatékonyabb megoldások.

A csomó minőségi kínai telefon két dolognak köszönhető: nyílt forráskód és bárki által licencelhető és továbbfejleszthető ARM technológiák.

Az utóbbi adja a hardvert (kvázi szoftver formában), az előbbi a szoftvert. Mindegyik olyan, amihez hozzá lehet nyúlni és nem kell 0-ról kitalálni, meg lehet venni készen, sőt, fizetni sem kell érte. Eléggé kevés a hozzáadott értékük a kínai egyentelefonoknak.

 

És ha megkérdezi bárki, hogy ez miért jó így: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

 

A Google célja a sokmilliárdnyi olcsó Androidos telefon, amin keresztül az emberek fogyaszthatják a Google legfőbb termékét: a reklámplatformot.

Na meg az ismeretek közül is sok a nemkínai: Samsung, Motorola, Asus, Caterpillar, Sony.

Ami ismert nagy kínai márka, az a Huawei, a ZTE, az Oppo/OnePlus és a Xiaomi. Ebből a Huawei ki van zárva a Google ecosystemből.

A többinél meg nem látom azt a fenenagy innovációt, amit hozzátettek ahhoz, hogy mit tudnak az okostelefonok manapság. Nem igazán tudok olyan dolgot mondani, amit nem a Samsung/Google vagy az Apple talált volna ki, akár hardveres, akár szoftveres vonalon.

Kína leszarja a copyrightot, emiatt aztán ha egyvalamelyikük kitalál valamit, bárki más ellopja gond nélkül. Van erről egy jó cikksorozat itt:

https://www.bunniestudios.com/blog/?page_id=3107

https://www.bunniestudios.com/blog/?p=4297

Teljesen máshoz állnak hozzá a szellemi tulajdonhoz, annak felhasználásához, mint Nyugaton.

Érdemes tőle az egész Made In China szekciót elolvasni: https://www.bunniestudios.com/blog/?cat=7

( persicsb | 2022. 10. 25., k – 11:28 )

Szerkesztve: 2022. 10. 25., k – 11:30

A legtöbb cég legtöbb használati esetére nem is kell a felhős skálázódás, jól beméretezett VM-ek kellenek. Cserébe sokan azt hiszik, a felhő majd megold mindent, és a szarul megírt alkalmazás is hirtelen skálázódni fog végtelen magra. Nem, nem fog.

A felhő ugyanaz a management bullshit lett, mint a NoSQL, a blockchain, az agile, a microservice architektúra vagy a k8s volt pár éve. Megoldás egy olyan problémára, ami a cégek 99.9999 százalékánál nem létezik.

microservice architektúra

Az nem is bullshit. Tökéletesen alkalmas annak az alkalmazásnak a megnevezésére, amelyikre 16-64 GB memóriával és 8+ cpu core méretezéssel ellátott podokat írnak elő, de mivel nem ISO fájlban, hanem docker image-ben érkezik, ezért már hirtelen új és menő lett. 

/s

1. Kb mindenből management bullshit lesz, amit valaki valakinek nagyon el akar adni. :)

2. A felhő célja eredetileg kb az lenne, hogy ne kelljen annyi pénzt fizetni az IT-nek, a szoftveresnek és a vasasnak, mert megoldja más egyben, tömegben, olcsóbban. A skálázódás már csak a hab a tortán. Mindig van egy sweet spot, de azt a pénzügyes látja, nem a rendszergazda.

:)

Bérelni (pénzügyi lízing is ez) vagy megvenni valamit nem ugyanaz. A vásárlás rontja a mérleget. Egy olyan cég esetén, ahol a tulajdonos valami heterogén massza lásd tőzsdei cégek, ott más döntések születnek, mint egy olyan vállalkozásnál, ahol a CFO is tulajdonos.

Az is, de nem annyira.

"A(z állóeszköz-) vásárlás több évre elosztva eredményezi ugyanazt. Ha úgy nézzük, akkor az OPEX és CAPEX közt elsősorban a cash-flow hatásban van különbség mindössze."

Nem. Az adózásra is. Valami beszerzése 1 milla ennek indulója legyen nulla a törlesztője meg legyen  évi 200e.
A bérlés éves díja is 200e ami az eredményre nézve nagyon nem ugyanaz.
Ha bérli, akkor  az első évben 800e-rel több profit mutatható ki. Lehet pont emiatt kap prémiumot a döntéshozó. 

Cashflow szinten a két példa lehet tök ugyanaz 5 éven át.

Van egy másik probléma is az egésszel. Ha CAPEX, akkor az eladottsági mutató a hitel miatt 1:1 arányú súlyozott rontást is eredményez a likviditási mutatóban. 
Van még egy olyan probléma is, hogy a tőkearányos megtérülést is rontani fogja a saját tulajdon. 

Vagyis a tulajdon több általánosságban használt mutatót leront, ami a vezetőség prémiumát fenyegetheti. Mindezt úgy, hogy a tulajdonosi érdekkel ellentétes tevékenység e mutatók javulását hozza el.

 Valami beszerzése 1 milla ennek indulója legyen nulla a törlesztője meg legyen  évi 200e.
A bérlés éves díja is 200e ami az eredményre nézve nagyon nem ugyanaz. Ha bérli, akkor  az első évben 800e-rel több profit mutatható ki. 

Feltéve, hogy az egy milliós eszközt a megszerzése évében leírsz nullára, ami állóeszköz-beszerzésnél nem jellemző. Legfeljebb kis érték esetén.

 Ha CAPEX, akkor az eladottsági mutató a hitel miatt 1:1 arányú súlyozott rontást is eredményez a likviditási mutatóban. 

Feltéve, hogy hitelből megy a beszerzés

tőkearányos megtérülést is rontani fogja a saját tulajdon.

A cég alaptőkéje/törzstőkéje nem változik egy eszközbeszerzés miatt. Az eszközarányos megtérülés az, ami saját tulajdon esetében romlik, cserébe a vagyon meg növekszik.

Kevered a nyilvántartott értéket az adózással. 

Opciók tulajdonlás esetén:

- az adóból levonható, nem kell értéket nyilvántartani, de lehet

- értékcsökkenés vagy azonos az adózási leírással vagy nem

Mindkét esetben a teljes  költség megjelenik capex oldalon, míg a bérlés opex és csak annyi látszik belőle ami az adott évhez tartozik.

Tény, hogy régen foglalkoztam adózási kérdésekkel, de annak idején nem volt engedélyezett egy nagyobb értékű állóeszköz azonnali leírása az adóból. Ugyanakkor ha nem írod le egyből, akkor nem jelenik meg a teljes költség a beszerzés évében. Ami a CAPEX oldalon megjelenik, nem az az évi teljes költség.

Mondom, hogy kevered a két fogalmat.

Amúgy van beruházási adókedvezmény is. Pl azonnal elszámolod az adóalapból és tetszőleges idő alatt amortizálod a nyilvántartásban. A nyilvántartott érték nem azt jelenti, hogy az a rész még nincs levonva az adóalapból.

Szóval adóalapból levonni a beszerzés költségét az nem azt jelenti, hogy csak az amortizációval arányosan lehet.

Emlékeim szerint a társasági adó 1. és 2. számú melléklete rendelkezik a leírási kulcsokról, szóval minden szinten aszerint kell tolni a könyvelőknek. Nem lehet bármit az első évben egyszerűen egyben leírni költségként az adóalapból, mert olyan kedve van a cégvezetésnek...

https://iotguru.cloud

A felhőnek mindig is a skálázódás, az on-demand a lényege, nem véletlenül léteznek privát felhők. Az, hogy kiszervezed az IT üzemeltetést más cégnek, és csak bérelsz, az nem felhő még, csak IT outsource-olás, hogy valamely ASP-től SaaS-t veszel. Attól még a vett szolgáltatás nem feltétlenül felhő módon van implementálva.

Na azért van különbség a "felhő szolgáltatónál API-val létrehozom a resource-okat" illetve "a kiszervezem egy külsős IT cégnek az onprem üzemeltetést" között. A különbség alap mértékegysége 1 Kumar. Nagyobb cégeknél simán összejöhet kiloKumar nagyságrend is. :)

Egész más a szituáció, amikor hetekig kell ticketezned az outsource-olt IT-val egy tűzfal port nyitásra. (Amit utána kvázi-rendszeresen visszacsuknak, mert Chandragupta éppen nem tudta, hogy annak nyitva kell lennie, és amúgyis az "úgy secure" ha minden csukva van. Hogy prod szolgáltatás áll miatta, az nem az ő baja. Ellenben a visszanyitásért megint ticketet kell nyitnod nekik, ami megintcsak nekik pénz...). Meg amikor valami hálózati problémánál 3-4 különböző cég pingpongozza egymás között a ticketet. Mert akinek te outsource-oltad, az is továbboutsource-olta más cégeknek az üzemeltetés különböző részeit és persze senki nem látja át az egész rendszert, senkinek nincs jogosultsága semmihez, mindenki csak hárítja a felelősséget.

Na ehhez képest a cloud megváltás. És olcsóbb is, sokkal.

Emlékszem olyan esetre kettővel korábbi munkahelyemen, ahol a céges IT havi 1000 euroért adott egy VM-et DMZ-ben. Ebből 500 euro volt a gép, második 500 volt a "support" amit persze kötelező volt megvenned. A gép erőforrásban kb egy havi 50 dolláros AWS-es instance-nak felelt meg. Cserébe oprendszerből választhattál valami elavult RHEL5 és RHEL6 verziók között. Ja és persze tele volt cseszve az IT cég különféle agent-jeivel, root-ot nem kaptál rá, csomagokat nem frissíthettél (mert törné az IT cég agentjeit). Sok szerencsét a saját szoftvered telepítésére. Ha függőség rpm-ek kellettek: ticket, attachment excel táblában, hogy mik kellenek a gépre. Az autentikáció Active Directoryból ment (onnan tudjuk, hogy rendszeresen leállt a sasl daemon vagy mi, ilyenkor ugye ticket... aztán pár nap alatt megjavítják. Addig persze ráérünk, nyilván nem volt sürgős belépnünk a gépre... Persze az SSH kulcs alapú autentikációt nem tiltották le, úgyhogy elég gyorsan "bypass"-oltuk a hivatalos bejárási módot. Senki nem szólt érte.) Ne tudd meg hány embernek hány munkaórája ment el feleslegesen az IT cég hülyeségeivel küzdésre.

Régóta vágyok én, az androidok mezonkincsére már!

Ezek nagyrésze rossz szervezésre vagy rossz partner cégre vezethető vissza. Ha a felhőt is egy ilyen rossz külső cég tutujgatta volna, ugyanúgy jártatok volna.

A felhőt most azért látod rózsaszínben, mert kaptál egy másik staffot hozzá vagy magad lettél a staff. Ha az előző IT cég is adott volna egy olyan vezérlőpultot a kezedbe és rendes vasat, akkor ugyanúgy meg tudtad volna csinálni.

Ti korábban nagyon drágán nagyon xart kaptatok, most meg csak drágán, de talán jót. Azért sok eset van, amikor az igényeket olcsóbban is le lehet fedni. Pl. a cégek nagyrészének felesleges a skálázódás, tényleg konstans terhelésre vannak beállva. Egy sima VPS megoldja.

Egyaltalan nem latom rozsaszinben a felhot (en elsosorban a "you're using someone else's computer" -> "your data is now someone else's data" problemakor miatt), pontosan tisztaban vagyok vele, hogy nagyon szar volt a kiindulopont. Nem valami lepukkant zug-IT szolgalato ceget kell elkepzelni, a top5 legnagyobb ilyen profilu cegbol ketto is megfordult nalunk (nem akarom megnevezni oket).

Azt viszont latom mar tobbedik cegtol, hogy egy bizonyos meret felett akar outsource-olt, akar cegen belul kulon szervezeti egysegekbe szetszervezett IT uzemeltetes valahogy mindig ugyanebbe az iranyba konvergal. A megoldas-orientaltsagbol elobb-utobb ticket-tologatasi bajnoksag lesz, mindenbe mindenki beleuti az orrat, de valahogy a vegen senki nem lesz felelos semmiert. Ehhez kepest a cloud pont a self-service jellege miatt egy nagyon hatarozott elorelepes. Persze tudok korabbi ugyfeleink kozul olyanrol, ahol kemeny munkaval kepesek voltak "bastardizalni" a private cloudjukat is, hogy ugyanolyan korulmenyes ugymenet legyen a hasznalata, mint ahogy korabban az IT dolgozott. A compliance, meg ITIL meg hasonlok neveben, barmit...

Régóta vágyok én, az androidok mezonkincsére már!

( STP | 2022. 10. 25., k – 12:38 )

Ez a felismerés másoknál 5-7 évvel korábban már eljött.

( ricsip v | 2022. 10. 25., k – 12:39 )

A másik dolog, amiről általában soha nem esik szó: a hazaköltözést mennyire gáncsolja az aktuális felhőszolgáltató? Ugyebár a beköltözéshez mindent megadnak, lefejlesztik a mindenféle konkurenciától való átmigráláshoz szükséges kényelmes toolkitet, csak gyere már hozzánk és nekünk fizesd a lóvét, a seggedet is kinyaljuk amíg birtokon belülre nem kerülsz hozzánk. (Majd meg lesz ennek a böjtje, de ezek mindig csak utólag derülnek ki.)

Aztán mikor évek multán csalódik az üffél, és menne máshová, a temérdek felhalmozódott adatot kényelmesen átmigrálós tool-ok helyett azt mondja neki a felhőszolgáltató, hogy lufaszt a te seggedbe, ha nagyon kellenek az adataid, nesze itt van egy 7terabajtos .csv, oszt bogozd ki belőle magadnak amit akarsz, csá!

Ezen mi a meglepő? Amikor odaköltözöl, akkor a cél infrastruktúra üzemeltetője biztosítja a tool-t. Amikor leköltözöl róla, akkor is a (másik) cél infrastruktúra üzemeltetőjének kell(ene) ezt biztosítania. Ha ez on-premise és te vagy az üzemeltető, akkor neked, ha másik felhő, vagy bérelt infra, akkor nekik.

( zsolt | 2022. 10. 25., k – 17:43 )

Teljesen érthető:

We're paying over half a million dollars per year for database (RDS) and search (ES) services from Amazon. Yes, when you're processing email for many tens of thousands of customers, there's a lot of data to analyze and store, but this still strikes me as rather absurd. Do you know how many insanely beefy servers you could purchase on a budget of half a million dollars per year?

Ilyenkor azért felmerül bennem pár kérdés:
1. hány devops-ost vagy DBs engineert kell felvennie, hogy üzemeltesse a fizikai infrastrukturát?
2. mennyi azoknak a "beefy" szervereknek az áramszámlája?
3. mennyi a hűtési költség? mennyi a szerverszoba bérleti díja?
4. mennyi a redundáns ISP uplink költsége?
5. hány különböző régióban kell ugyanezt megismételni?
6. ha esetleg úgy adódna, hogy az opensource DB engine nem elég "beefy" a sok-sok customerhez és kénytelenek valami commercial DB-t venni, annak mennyi a licenszköltsége?

Tévedés ne essék, nem zárom ki, hogy ez alaposan át van gondolva és végig van számolva a részükről és az jött ki, hogy tényleg jobban megéri az on-prem. De azért itt messze nem csak a szerverek ára, ami költség. USA-ban 5-6 komolyabb senior Devops-os vagy DBA bérköltsége elvisz évente félmillió dollárt. Commercial DB-k éves licenszköltségénél is pillanatok alatt félmilliónál vagy.

Régóta vágyok én, az androidok mezonkincsére már!

Nem zárom ki, hogy ez a helyzet, de a cikkből szerintem sokmindenki levonhatja a téves tanulságot, aztán pislognak, hogy az on-prem üzemeltetés nem is annyira egyszerű, különösen ha nem vagy multi cég, csomó országban telephellyel.

Régóta vágyok én, az androidok mezonkincsére már!

Igen igazad van a csomó telephely problémás lehet, de én személy szerint sem vagyok "felhő" párti talán azért érzem így. Remélem nem lesz bukta, én szurkolok nekik, ha tényleg meglépik. Gondolom csapat is van hozzá akik üzemeltetik és kiszámolták már. Sokszor érzem, hogy meg lehetne oldani "helyileg" simán, de elmegy cloud irányba mert az menő. Valahogy soknak érzem manapság az ez irányú hype-ok tömegét.

Érdemes az egész cikket végigolvasni. Két szolgáltatásuk van. Az első még a felhős idők előtt indult, a másikat pár éve indították, eleve felhőben. Pontosan tudják melyik mit jelent és minek mi a haszna. A második szolgáltatás indításánál jól jött a felhő, mert eleve tized akkora induló felhasználószámot becsültek, mint ami bejött induláskor. Ilyenkor jó, ha azonnal tud a dolog skálázódni, viszont azóta beállt egy stabil növekedésre. Értelmetlen egy csomó pénzt feleslegesen égetni, mikor teljesen stabilan folyamatosan van terhelés. Üzemeltetni pedig a felhős rendszert is kell és ahhoz képest a vasakkal nem sok dolog van, nekem is ez a tapasztalatom.

"Két szolgáltatásuk van. Az első még a felhős idők előtt indult" 

Igen, szerintem pont ez a lényeg. Ők - ha jól veszem ki a szövegből - igazából sosem számolták fel az on-prem szolgáltatásaikat. Így nagyságrendekkel egyszerűbb visszahozni valamit, mintha 1) sose lett volna on-prem tapasztalatuk 2) volt, "de már elmúlt" és 0-ról újra kell építeni.

"Üzemeltetni pedig a felhős rendszert is kell és ahhoz képest a vasakkal nem sok dolog van, nekem is ez a tapasztalatom."

Egyrészt nagyon más expertise kell hozzá (csináltam többféle felállást: fizikai infrát üzemeltettem, dolgoztam devopsosként olyan cégnél ahol volt on-prem infra de más részleg üzemeltette a vasat, dolgozok most is AWS-t használó helyen, sőt üzemeltettem cloud-ot is fizikai infra felett - szóval azt hiszem láttam egy pár oldalról ezt a kérdéskört). Egy AWS-hez szokott devopsosnak nagyon nagy kultúrsokk lesz hirtelen a Cisco/HP/Juniper/Nortel stb. switcheken VLAN-okat konfigurálni, fibre-channel-el először találkozni, brand szerverek proprietary nyűgjeit remote management, hálózat/storage virtualizációs technológiáit megtanulni, PXE-bootos remote installt csinálni. Időbe kerül áttanulni egyikről a másikra.

Másrészt eddig akárhány cégnél voltam, mindig orbitális szívás volt az on-prem infra részeit üzemeltető külön szervezeti egységek vagy esetleg külső cégek közötti együttműködéssel. Sosem sikerült világosan elkülönített felelősségi határokat húzni. Visszagondolva rengetegszer volt outage a fizikai infra vagy felette a VI réteg üzemeltetési hibáiból ("oops, rossz szervert állítottunk le", "oops rossz kábelt húztunk ki", "tönkrement az SFP modul a FC porton, és valamiért nem ment a link failover", "nem vettük észre, hogy ezen a hypervisoron még fut egy prod vm és leshutdownultuk", "nem teszteltük, hogy működik-e a routeren az ISP failover és kiderült hogy nem", stb. stb.). És akkor még nem beszéltem az akár 1 évig nyitva álló ticketekről, amit a network operations-nek feladtunk (vicces volt, mikor azzal zárták le, hogy mivel átálltunk AWS-re, így ezt már nem is kell megcsinálniuk :) ). Rengeteg szervezési overheaddel járt egy rutin site failover is. Az AWS-re átállás és ezáltal a dolgok saját kézbe vétele óta az ilyen jellegű problémák teljesen megszűntek.

Megintcsak nem állítom, hogy ez mindenhol így kell hogy legyen, de néhány elég nagy multinál eddig ezeket tapasztaltam. Van egy gyanúm, hogy ez lehet az általánosabb, és DHH-ék cége inkább a pozitív kivétel.

Régóta vágyok én, az androidok mezonkincsére már!

( Mycrobi | 2022. 10. 26., sze – 10:43 )

Nem fejlesztési szemszögből hanem irodai szempontból az O365 megváltás. Megvan mondva hogy Dokumentumok és még pár user file auto szinkronban van így gépcsere esetén nincs IT oldalról adatmozgatás amúgy is GDPR problémás. Közös munkára Sharepoint és Teams, viszont az tényleg problémás amikor a korábbi fájlszervert akarják Sharepointra rakni, attól a hajam égnek ál valahogy.

- Az élet, a világmindenség, meg minden (DA) -

Persze. Senki nem mondta egyébként, hogy a felhő rossz, mert megvannak az előnyei. Csak sok soydev évekig ezt hajtogatta, hogy mindent felhőbe, mert akkor ez volt a legújabb buzzword, teljesen bele voltak szerelmesedve, hogy világmegváltás lesz, ha minden felhőben lesz. Nem, nem lesz, vannak előnyei és hátrányai, arra kell használni, amire való, amire nem való, ott meg nem kell erőltetni, hogy pl. helyi infrastruktúrát váltson ki. O365 azért sikeres, mert online felületen teszi lehetővé a kollaborációt, így ennél valóban van értelme a felhőzésnek, nem csak hájpként szolgál.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”