Názory k článku Odpovědi na nejčastější dotazy k našemu odchodu z předraženého cloudu

to by me zajimalo kdy je teda cloud vyhodnejsi?
nerikam, ze je to totez, ale premyslim mezi vps a nenarocnym serverem bezicim doma.

Cloud je výhodný pro jednorázové zátěže řádově přesahující běžný provoz. Například když firma vytvářející hry uvede novou hru, když e-shop dělá nějakou speciální slevovou akci nebo třeba pro prezentaci volebních výsledků v čase těsně po volbách. Nemá smysl kupovat železo, které je potřeba jen na pár dnů v roce, když by se drtivý čas jen zbytečně flákalo.

Kdy? Nelze takto obecně vyjádřit kdy a za jakých okolností. Jako ve úplně všem hraje zásadní roli umět počty a tedy strávit čas počítáním v zohlednění příjmy vs náklady a uvědomit si jestli něco skutečně potřebuji. A je jedno jestli se jedná o cloud vs vlastní hardware, levice vs pravice, vlastní auto vs sharing, smart house vs konvenční dům, linux vs windows, kryptoměny vs konvenční investice, euro vs czk, atd..

Já osobně jsem byli vždycky proti cloudu a to z principu "té monstrozní celoplanetární mediální marketingové kampaně" identické jako jsme zažily u kryptoměn, proGrétovské, protiRuské ale to neznamená, že mohou být případy třeba u začínajích firem kdy investice do vlastního hw a výkonného internetu prostě budou vyšší než využít cloud.

Umet pocty je v pripade cloudu bohuzel nedostatecne.

Ceniky cloud sluzeb jsou zcela zamerne zamlzene, chaoticke, plne pastti pasticek, "what ifů" a fuckupu.
Znam team lidi, kteri se velice dobre zivi tim, ze firmam optimalizuji cloudove ucty, dokazou se vyznat v tom zamerne chaotickem a bordelu a jsou schopni bezne stlacit ucty na polovinu.

Souhlasim s clankem, dlohodobe se vyplati vlastni reseni, stejne jako se dlouhodobe vyplati koupe vlastniho domu nad pronajmem. Je to stejny velice jednoduchy princip. V najmu platim za barak a zisk pronajimatele. Ve vlastnim platim jenom za ten barak.

"Umet pocty je v pripade cloudu bohuzel nedostatecne."

Ani ne. Proto mam nekolik "standardnich" pozadavku, a kdyz dorazi k nekteremu ze zakazniku nejaky frikulin, a zakaznik neodola (uz jsou vetsinou vytrenovani a posilaji je kamsi rovnou) tak vznesu prave takovy pozadavek, a tudiz pak je cena zcela srovnatelna.

Priklad - chci hloupe uloziste bez zaloh a jakychkoli garanci ... ;D. V idealnim pripade si tam nacenej jeste nejaky poplatek za prenesena data, coz pak zvedne tu cenu jeste o rad.

My si jednu takovou firmu jako korporat platime. Za dva mesice srovnavani ruznych cloud provideru (kde podminka byla lokace australie/japonsko) jsem nebyl schopen vyplodit lepsi rozhodnuti nez ze za konektivitu cloud providerovi si muzeme postavit vlastni datacentrum. To uplne stacilo. Instance byly uplne off a pak dalsich 200 polozek (zdravim AWS) zapocitavala uz externi firma ve sve appce.

Není to totéž, a závisí na Vašich podmínkách a nad tím, co chcete dosáhnout. Těch bodů k zamyšlení je víc.

1.Dostupnost. Datacentra bývají obecně připojena mnohem lépe než domácnosti, jak datově tak i napájením (doma asi nebudete mít diesel). Pokud je tohle Váš problém, tak jedině VPS/hosting.

2. Konektivita - víceméně to samé jako dostupnost, i když časy ses připojením mění.

3. Co chcete provozovat doma? Pokud jste zvyklý jen na nějaké APčko, tak bych šel cestou VPSky. Jestli ale máte doma nějakou NASku, která stejně hučí celý den, máte na ní UPSku atd. tak server doma moc problémů nepřidělá.

4. Spotřeba. Nejmenší VPS vycházejí pod stovku měsíčně. Pokud si nepostavíte něco s nízkou spotřebou, tak 40W spotřeba není tak moc, a dá to kolem 200/měsíc jen za elektriku. Ale jestli stačí malina nebo kontejner popř virtuál na NASce, tak jste zase úplně jinde.

Cloud má smysl využívat pro rychlý růst. Se správně napsanou aplikací můžete vyškálovat opravdu jednoduše. Nicméně v momentě kdy růst přestane být tak strmý začně mít smysl buď vyhrazené řešení s dostatečnou rezervou, nebo řešení hybridní, kdy do cloudu offloadnete pouze mimořádné špičky. Nicméně i na hybridní řešení musíte mít infrastrukturu a aplikaci připravenou.

Celé je to pouze o tom, že výpočetní kapacita večejného cloudu je mnohem dražší, než když si pronajmu či koupím vyhrazený server. Dokonce i pronajatý managed server vychází výrazně levněji, než veřejný cloud, který je by default bez supportu.

A odpoveď na Vaši otázku: cloud je výhodnější, pokud pohodlí tohoto řešení Vám ospravedlní vyšší náklady ( například ušetřený čas, který strávíte smysluplněji než správou doma běžícího serveru ).

"například ušetřený čas"

Cet si clanek? Zadny usetreny cas neexistuje. O ten virtualni server v cmoudu se musis starat uplne stejne, jako to ten fyzickej. A samotna obsluha ciste toho HW je nula. V korporatnim prostredi to vypada tak, ze me, jakozto adminovi prijde mail, ze neco poslo, za hodku mi prijde mail treba od toho dellu, ze vedi ze to poslo, a ze X je na ceste a dotaz, jestli ten disk v supliku zvladnu vymenit sam, nebo jestli maji poslat technika.

Nikoli, ten fyzický server musíte na začátku zapojit, zprovoznit. V cloudu jenom kliknete na tlačítko. V dlouhodobém pohledu už ten čas neušetříte, ale na startu ano. A to je důležité třeba pro startupy nebo pro různé pilotní projekty.

Ono to teď je trochu matoucí, protože spousta zátěže, která by byla normálně v cloudu, se do cloudu ještě migruje, vypadá to, jako by cesta byla začít s vlastním a pak migrovat do cloudu. Jenže ta cesta bude většinou přesně opačná. Začne se v cloudu, protože cloud je pro start rychlejší a levnější. A když se projekt rozjede a poroste, bude migrovat do vlastního.

Ono to plyne i z článku. Tam také migrovali do vlastního v situaci, kdy už stejně měli tým správců, mohli si dovolit předem nakoupit spoustu serverů –a kdy je ta „cloudová přirážka“ stála miliony ročně.

To je ten dnešní přístup. Ono taky dokud rostete, tak nevíte, kolik vlastního HW budete potřebovat.

Až na to, že se platí za egress a ne za ingress a tak je možné, že si firmy prostě migraci všeho najednou nebudou chtít dovolit. AWS snowmobile zatím datacentra opouští z hlediska dat prázdné a přijíždějí plné, ne opačně.

Cloud asi bude opouštět málokdo. Je možné, že ve skutečnosti přejdou na hosting nebo do vlastního, ale všechno to má dost velké výzvy a vyplatí se to/ je to nutné až se specifickými požadavky, značnou velikostí.

Hosting a cloud určitě umožňují spoustu věcí poměrně levně vyzkoušet díky různým kreditům a nízké ceně VM.

Pokud jde o velke korporaty, tak hlavni vyhoda cloudu je v tom, ze muzete dokonale vy*ebat s internima firemnima procesama. Pokud cekate mesic na to az vam nekdo vyklika virtualku ve vmware, tak se vam muze AWS zdat jako spasa. A je vam jedno kolik to nakonec bude stat.
Amazon na druhou stranu chape ze to peklo zakaznici vlastne chteji a security model AWS umoznuje na AWS vytvorit jeste horsi korporatni peklo, nez je to ze ktereho se snazite utect.

Ono to nemusí být taky jenom interní procesy, ale i použití i něčeho modernějšího co lidé v tom korporátu neumí provozovat.

... takze misto cekani vyklikani na instanci ve vmware misto toho cekate mesic az vam nekdo vyklika / deployne instanci v AWS. Mate-li spatne firemni procesy a metody v nastavovani opravneni cloud vam nepomuze.

Vyřešit špatné firemní procesy bude obvykle více práce než přesvědčit vedení, abychom přešli na ten cool cloud.

Muj kolega ten proglem popsal jako: "Nekteri lide by si mohli pripadat mene duleziti".

Dalsi vyhoda cloudu je DNS. Zatim jsem videl ve firme jen jednu jedinou implementaci automatizace pro DNS, bylo to interni reseni a neco podobneho v jinych firmach zoufale chybi.
Pokud nedokazete propojit CMDB, DNS a AD a neumoznite lidem vytvaret/menit a nicit DNS zaznamy(alespon CNAME) tak bude vzdy on-premise prohravat v porovnani s cloudem.

Ja jsem treba delal v korporatu, kde vytvorit stroj trvalo klukum v Indii mesic. Tak nam proste do kazdyho tymu koupili GPC / AWS a pres rok jsme zazival radost a produktivitu. Po tom roce se nekdo podival na ucty a na tom Cloudu zacalo vznikat stejny peklo jako mimo nej. Takze obcas, kdyz firma neumi nastavovat procesy, muze bejt cloud spasa i prave z toho duvodu.

10. 1. 2024, 07:55 editováno autorem komentáře

Viz predchozi, roky to pisu taky a netyka se to jen cmoudu. Jakykoli pronajem cehokoli je vyhodny, pokud je to pronajem kratkodoby = nevyplati se ti koupit vlastni reseni.

Takze pokud vis, ze budes pristi mesic poradat nejakou akci, ktera zvedne zatizeni o 1000%, dava smysl si na ten mesic pronajmout vykon. Ale rozhodne nedava smysl si to platit trvale.

Zvednuti zateze o 100%, presne jak je v clanku, s prehledem pobere ten provozovany HW, aniz by se to nejak negativne projevilo.

Legracni je, ze o fous vedle (NIC a jejich VIP DNS ...lol) se argumentuje presne tou stejnou kravinou = marketingovym zvastem, ze administrator ktery se o to DNS ... tech 5minut mesicne ... stara prece neni zadarmo ...

Delam admina a administrace HW je tak 1 promile toho co delam. Takze prave to fima "usetri", kdyz to deleguje na nekoho jineho. Mno a o ten SW se jaksi nikde nikdo v zadnym cmoudu nepostara, proste proto, ze kazda jedna firma pouziva jiny, jinak nastaveny atd atd.

(Ne)použití konkrétního cloudu je třeba vylučovací kritérium, pokud to má zákazník v podmínkách. Kdybyste provozoval nabízenou službu odjinud, tak se dost možná (hlavně v případě AWS, který není v bandwidth alianci) nedoplatí na poplatcích za egress. U High Frequency Tradingu zase v konkrétní lokaci v AWS prý chcete být, protože jsou tam ty banky, nebo jsou tato datacentra blízko bank a tedy máte konkurenceschopnou latenci.

Kolegové zmiňují různé věci, ale berme v potaz, že řada firem neprovozuje úplně vše čistě nad open source. V momentě, kdy řešíte licence, chcete nějaká SLA atd. může být cloud ve výsledku výhodnější i z hlediska dlouhodobého provozu. Pokud mě výpadek stojí hodně peněz, můžu takto pro zákazníky častokrát akceptovatelně oddelegovat část zodpovědnosti, resp. dostávám do ruky nástroje, jak i hodně náročné požadavky uspokojit. To vše má samozřejmě svoji cenu. Typicky si je řada velkých zákazníků také schopna vyjednat dost jiné ceny jak když kupuje, tak když pronajímá, což může s kalkulací také dost výrazně pohnout.

Chcete-li byt konkurenceschopny mate umisteny servery primo v miste kde probiha trading. Coz nemusi byt zrovna datacentrum nabizene cmoud providery. A uz vubec neovlivnite delay. 1ms je zatracene velky rozdil treba u forexu.

Jen prodávám, jak jsem koupil. Pochopitelně mi detaily dotyčná osoba, která to má z první ruky nesdělila. Ale předpokládám, že ví co dělají, resp. že jim to asi vychází aspoň lokálně optimálně s ohledem na poměr cena/ výkon.

Pěkný dokument: https://youtu.be/WWdXI1_En9A?t=1722
Máte to na čase o latenci.

Železo je levné, takže jde hlavně o lidské zdroje. Cloud se vyplatí, pokud je to tak malá aplikace, že by nevyužila fulltime tým pro správu. Ve chvíli, kdy takovový tým musíte mít, je levnější on-premises řešení.

Cloud může být také výhodný pro startup v ranné fázi. Za prvé ti v podstatě nevadí, když je řešení drahé, pokud je tvůj zisk na jednoho zákazníka větší než náklady, za druhé se můžou požadavky na produkt v čase dost lišit.

Např. budeš mít produkt, který vyžaduje hodně diskového prostoru pro zákazníka. Spočítáš si, že AWS S3 na průměrného zákazníka tě stojí $10 měsíčně, prodáš to za $15 a je ti jedno, že na vlastním řešení bys to mohl mít za $2, protože jsi furt v zisku a navíc nemáš lidi, kteří by ten storage dokázali provozovat.

Časem to buď nahradíš levnějším řešením nebo ti taky byznys řekne, že to vymysleli jinak, ten storage už nepotřebují tak velký a ty jsi rád, že jsi neinvestoval do nákupu železa a školení lidí na něco, co už nepotřebuješ.

Ten článek je o už stabilizované firmě, která přesně ví co chce a zároveň má náklady, kde se vyplatí optimalizovat, což je jiný případ.

Nejsem v zisku. Mám 1000 zákazníků, co platí $15000, já za ně zaplatím $10000 a zjistím, že místo dalšího vývojáře, který by vytvořil $30k, jsem nakrmil Amazon.

Ten cloud naklikáš a nějakou dobu trvá, než mezitím toho vývojáře seženeš.

A ten cloud "nakliká" kdo?

Predem uvedu, ze princip cloudovych sluzeb mi neprijde blby, ale rozhodne to neni univerzalni reseni pro vsechny.

Pred cca 10 lety jsem ucinil pokus presnout server pro firmu o 10 programatorech do VPS a dopadlo to tragicky. Za pozadovane penize jsem mel totalne nevykonny stroj, na kterem neslo rozumne provozovat ani postovni server. Nepamatuju si to samozrejme uz presne, ale tusim ze 10 - 15 mesicnich poplatku sem koupil prumerny neserverovy hadrware, ktery s velkou rezervou slouzil jako postovni server, antispam, ownCloud, gitlab a par dalsich kravin. Vrazil jsem to nejobycejnejsiho datacentra v blizkem okoli a spokojene to jelo cca 7 let. Nasledne dany hardware jeste dosluhuje jako PC, kam se odsypavaji zalohy.

Provozovatel VPS tenkrat nabizel zalohovanou linku, zalohovanou elektriku, ale pro nase ucely to vlastne bylo uplne zbytecne. Zdurazunuju, ze pro nase ucely, kdy to, ze to jednou za 3 mesice hodinu nejelo, neznamenalo zadnou hruzu. Nepotrebovali sme ani zadne necekane navysovani vykonu a podobne.

Od levnych poskytovatelu VPS me odrazovaly pribehy z okoli, kdy provozovatel pravidelne konkretni VPS vypinal, protoze se k VPS snazili pres SSH pripojit hackeri, coz kazdy, kdo provozuje server s SSH zna, ze se deje proste furt. Takze na prd.

Kdyz sem pak cetl, kolik dni cekali bezni zakaznici na to, az jim provozovatel cloudu obnovi sluzby po te, co datacentru utrpelo pozarem ci vytopenim, tak sem si u cloudu / VPS skrtnul dalsi udajnou vyhodu, ze o zalohy se nekdo dobre postara. Troufam si rict, ze ze par jednotek dni bych si svuj tehdejsi "server" na obyc hw zvladl ze zaloh rozjet sam i kdybych si mel znovu kupovat cely hardware. Za tu samou rychlost nemusim nikomu pravidelne platit.

Jiste budou aplikace, kde cloudove sluzby smysl maji, ale urcite ne pro kazdeho. Navic jak tu take nekdo zminoval - internet mela byt sit ruznorodych sluzeb a provozovatelu. Ne ze vsichni narvou vsechno do chrtanu 3 firmam a pak se budou divit, ze 1/3 internetu nejede, kdyz jedna z firem lehne.

" ci vytopenim" https://www.lupa.cz/clanky/casablanca-int-ma-problemy-nektere-sluzby-nejsou-dostupne/

jj, to je nezapomenutelny. Predevsim situace, kdy po netu kolovaly fotky kyblu a tekouci vody, zatimco support vesele tvrdil lze se nic nedeje. A ty 100% garantovane geograficke zalohy nebyly nejspis nalezeny dodnes.

"ze 1/3 internetu nejede"
Staci kdyz prestanou odpovidat DNS googlu, a internet prestane existovat uplne ne?

Jeden VPS ale není cloud.

Lidi co blbnete. Komentare o VPS a hostingu jak kdyby byl rok 2000. Cloudem se mysli treba AWS, uz je 2024.

Jestli přemýšlíte mezi VPS a nenáročným serverem běžícím doma, pokud ten "nenáročný server" nebude zrovna něco ve smyslu Raspberry Pi, VPS má prakticky jenom výhody (nemusíte se o něj starat, maximálně jednou za čas zazálohovat, rychlost připojní je násobná co většinou doma, IPv4 adresa v ceně, výkon pro nenáročné aplikace naprosto dostatečný) a pořídíte ho za pár eur měsíčně což by vás stála elektřina taky. Tady není moc co řešit. Záleží, jaké máte požadavky na hardware.

Cloud se vyplati na spicky, proto i RH OpenStack umi rozsirit podman do AWS/AZURE - vyrobi tam Linux virtual a do nej to nasype a expanduje.
Na druhou stranu, ano HW je dnes tak levny, ze si to uz dnes radeji koupite.

Obecne 3 mesice cloudu stoji tolik, kolik novy HW vcetne diskoveho pole.
1 mesic jako koupit jety HW z ebay - tolik mala firmicka - vyplati se HW skoro zadarmo bez supportu - ANO - koupite si spare servery, budou v clusteru samozrejme, proc by se mely flakat.

No a pak firme, co nema u AWS server, ale jen apku v tom jejich API, neskladuji tam ani data - a nic velkeho nestahuji, nebot data do cloudu jsou vcene a neuctuji se, data z cloudu se uctuji - to kdyby jste si chteli vse stahnout sobe ;-)) - mi delame backup emailu u M$ a oni nam omezuji rychlost a ukoncuji spojeni, az na suppoort req. nam to skrceni zrusili - no skrti mene ;-)
No a tahle firma ma svoje servery, ale jendou mesicne potrebuji udelat slozite analyzy nad daty a na to potrebuji opravdu nabuseny server s 1TB RAM ... no takze jejich script se prihlasi do AWS, udela tam ty paku, do 3S nasypou data - asi 20 min tam bezi ten proces, posle zpatky reporty nad daty a vse se pak skartuje, neplati tak ani za rezervaci dat ani za rezervaci moznych prostredku - tahle standa je stoji neco mezi 10-20 USD a tim to konci, tohle zaplati kazdy mesic a rozhodne tak usetri, nebot takovy server si kupovat nebudou - naopka na zber tech dat staci slaby server a tam se vyplati mit svuj.

jakmile ale začneš dělat globální projekt (či ho budeš chtít mít pro zákazníky globálně dostupný), náklady na vlastní HW rostou strmně nahoru.

Tvůj příklad s velkým server v cloudu je takový super use case, v praxi ale narážíme na to, že ingress linka do třeba AWS má daleko nižší kapacitu než potřebuje, z "nalití" dat do cloudu je několika denní problém. Ten pak řešíme tak, že ty data tam lijeme průběžně, dělá se z toho pak takový hybridní storage. Stejně tak šířka pásma třeba u S3 zrovna není tomu nakloněna a musí se to opět řešit nějakými procesy navíc. Pak narazíš na to, že ty velké servery nejsou ve všech lokalitách vždy dostupné a někdy na ně musíš hodiny, dny čekat. No, je s tím spousta zábavy.

Při čtení článku jsem byl velmi zmatený. Nechápal jsem, kdo je to "my". Autor: Redakce, první odkaz na blogpost o dvou na první pohled nesouvisejících službách (mailhosting a ticket tracker), druhý na nějaké 37systems, což jsem pak zjistil že je skupina, která ty služby provozuje. A ani potom jsem si z článku moc neodnesl, protože uvedené služby bohužel neznám, takže nevím, jakou mohou mít náročnost, kolik uživatelů je používá atd., a tak si uvedená čísla (3.2M, 600k USD) vůbec nedokážu dát do kontextu - je to málo? Je to hodně? Chápu, že přiblížení výkonnosti softwaru a tedy představy o tom, zda jsou náklady „rozumné“, je složité napsat, ale alespoň nějaký pokus by proběhnout mohl. Nepomáhá tomu že ani netuším, jestli jde o provoz těch dvou zmíněných služeb, nebo ještě něco dalšího (Stejní lidé, kteří provozovali HEY, Basecamp a další aplikace v cloudu, je nyní provozují na našem vlastním hardwaru.) Zmíněných 3.2M tak může být hrozně moc ale i velmi málo.

Článku podle mě chybí nějaký úvod, kde se napíše, kdo je autor a co řešil za problém.

Pokud má být článek poloreklamní, pak jsem ani nepochopil, jestli to má propagovat ty služby, nebo se snaží sehnat pracovníky (operují v ČR?).

No tak to jsi jej zjevně celý nedočetl. I já to tak ze začátku vnímal ale na konci jsem si všiml tohoto url : https://world.hey.com/dhh/the-big-cloud-exit-faq-20274010 (originální blog) Ale je pravda taky jsem nezjistil v jaké firmě ale podle url by se to mohlo týkat projektu https://www.hey.com/

Přehodil jsem zmínku o autorovi nahoru, aby bylo jasné, co je to za text.

Žádné „poloreklamní články“ tu nevycházejí a nikdy nevycházely. Buď to je text označený jako reklama nebo je to běžný článek v redakční režii.

Díky.
Sice jsem to do konce ráno dočetl, ale můžu potvrdit, že to působilo velmi zmatečně, jako by to bylo vytržené z delšího článku a chybí úvod.

Poloreklamni clanky tu vydaval Microrisc ;)

A byl by nějaký technický/licenční problém namísto "Redakce" napsat přímo do kolonky autor "David Heinemeier Hansson"?

Ještě než byla informace o překladu přesunuta nahoru, článek začíná větou kde je odkaz."Před více než rokem jsme oznámili svůj záměr opustit cloud"
I když firmu neznám, článek je pěkný a myslím že přínos je v tom, že pokud je pro někoho výhodný cloud, který časem nabobtná tak ve finále je pak zase výhodné vrátit se na vlastní HW.

Jenom s tim detailem, ze v clanku-blogu je receno, ze to pro ne nikdy vyhodne nebylo, ze jen podlehli tem marketingovym zvastum ze bude.

„...podlehli marketingovym zvastum...“

Hezký eufemisus pro nekompetentní managerské rozhodnutí.

Tak ono na jisté, hlavně počáteční, startupové úrovni moc neděláte "kompetentní" nebo "nekompetentní manažerská rozhodnutí". Děláte prostě rozhodnutí, často navíc dost ad-hoc a kolektivně.

A pokud v ten okamžik podlehnete marketingovým žvástům, je to blbý.

V cloudu jsem tedy spravoval mnohem větší účet než zde zmíněný autor, a mohu potvrdit, že se o výhodnosti moc nedá mluvit.

Hlavně ani z pohledu trhu nás lidí v IT v tom není trh, firmy spíše chtějí Kubernetes než certifikace v cloudu.

A co se týká serverless, klasicky v AWS je moje zkušenost, že to bylo velmi komplikované to vyvíjet.

Dneska vidím, že firmy o cloudu spíše uvažují v logice hybridního režimu, a přiznám se, že se jim ani nedivím.

A na co ještě netřeba zapomínat je cena za traffic, která je fakt hodně vysoká, jako 90 USD za 1TB trafficu od cloud providera, to si málokdo uvědomuje, že platíte i za tohle.

To, že chtějí Kubernetes je správně. Není nic horšího než se locknout na jednoho cloudového providera.

Podle mě se serverless hodí jenom pro hrozně málo případů. Ono to vypadá hezky na jednoduchých příkladech, ale pak když zkusíte něco reálného, tak je to nepoužitelné.

No, ono Kubernetes je z mého pohledu také jen obezlička a další "líné" polořešení, aby se nemusely řešit robustnější základy v IT obecně.
JIT kompilace prokázala, že jsme schopní měnit program za běhu. Operačnímu systému, natož procesoru nemusí být dopředu známy veškeré instrukce programu, stačí určité penzum instrukcí dopředu. O něco horší je to s pamětí, kde tradičně bojujeme s tím, že nešikovně pracujeme se stavem resp. že mutabilní práce se stavem je na současném hardwaru rychlejší. Technologie na strukturální sdílení, či jiné copy-on-write techniky existují a běžně se využívají. To umožňuje stav lépe kompartmentalizovat a tedy se případně starat o mnohem menší rozsah dat, které je v případě updatu za běhu nějak více řešit.

Poměrně slušnou výzvou práce se stavem, persistencí a znovu updaty mezi více uzly v clusteru. Většina programovacích jazyků na takové věci není moc dobře připravena, řeší se to převážně kódem, který pokud vím není součástí jazyka či standardní knihovny. V momentě, kdy u zásadních kusů softwaru řešíme zcela fundamentální problémy např. s pamětí, přetékáním rozsahů datových typů, různých polí atd. což je pořád v rámci jednoho počítače, se asi nemůžeme divit, že je práce napříč vícero počítači stále opravdu velkou výzvou.

Celé situaci nepomáhá, že to, co považujeme za hardware je protkané různými více či méně pochybnými firmwary, kde jsou znovu zásadním problémem kvalita kódu, často nedostatečná dokumentace a updaty za běhu jsou taky minové pole, pokud jsou vůbec možné.

Korunu tomu samozřejmě dává, že jsme velmi kompetentní v tom vystavět nesmyslnou komplexitu tam, kde není potřeba, pokud bychom průběžně trochu poklidili, ohladili pár rohů a jednou za čas udělali pořádnější úklid. A já to chápu, nikomu se nechce fundamentálně předělávat běžící systém, když ten nový přístup je lepší spíše marginálně.

Schválně se ale zamysleme, jestli by řada bezpečnostních problémů vůbec v takové míře existovala, kdyby se Windows, běžné distribuce Linuxu a základní software jako prohlížeče, SQL databáze, Office standardně updatoval kompletně za běhu, prakticky bezešvě a nebyl potřeba žádný restart. Celá řada clusterů by dost možná neexistovala, protože se jich řada ve skutečnosti nastavuje hlavně proto, aby někdo mohl dělat updaty ve standardní pracovní době. Menší firmy bez možností clusteringu by třeba začaly spíše updatovat, nebo updatovaly dříve než někde mezi svátky.

Ale nikdo netvrdí, že Kubernetes je řešení pro všechno a pro všechny. Naopak Kubernetes je dost složitý a spoustě projektům by stačilo něco mnohem jednoduššího.

Jestli někdo má cluster kvůli updatům, tak je problém někde jinde.

Ono kdybychom byly u toho co by stačilo, to je úplně jiný level diskuze, ale to se se zaměstnavateli nebo klienty tahle diskuze nevede.

Ve skutečnosti většině klientům by stačilo staré řešení na PHP & Mysql & Linux / LAMP na jejich intranet a jeden silnější server s KVM (Kernel Virtual Machine), kde by se pravidelně dělali snapshoty pro zálohy a jednou za týden to rsyncnulo, klidně třeba do Deep Archive v AWS a k tomu dva solidnější ajťáci, které by si firma dobrou mzdovou politikou držela i s know-how.

Jenomže v reálném světě HR chce obhájit svoji existenci, takže nutí fluktuaci, dodavatelé chtějí obhájit svojí existenci, takže nutí nové řešení, securiti specialisti chtějí obhájit svoji existenci... Pak tu vidíme ty šílené případy, kdy přijde Elon Musk do Twitteru, z 80.000 zaměstnanců si nechá 500 a ono to světe div se furt funguje.

No to je jiste situace v CR firmach...co nadnarodni korporaty, Nemecko, US...

Velmi pěkné a užitečné!

Ano, konecne mozem klientom ukazat ze nie som lietadlo ked im ukazujem ze mikroservisy nie su riesenim kazdeho SW problemu tak ako cloud nie je riesenim kazdeho behoveho problemu. Zatial to boli tak jasne smery ze bolo tazke tomu odolavat a kazdy si skor tukal na celo ked sme tvrdili opak. Ved vsetci to tak robia nie?

Veřejné cloudy od Googlu, Amazonu a Microsoftu musí pracovat s obrovskými ziskovými maržemi, když jsou dražší, i když mají úspory z rozsahu, kterým se nemůže žádná firma s vlastním řešením ani přiblížit.

Však je to vidět ve výročních zprávách, jak jim v posledních letech cloud táhne zisk.

"když mají úspory z rozsahu"

Prave ze nemaji. Zauvazuj nad tim, jaky HW potrebujes ... nadoma vs mala vs stredni vs ... google.

Takze ano, jeden disk urcite koupi levneji, ale ta infrastruktura kolem bude cenove jinde, nez to co si koupi ten potencielni zakaznik pro sebe. Takze mozna a hypoteticky ses na exaktne stejny cene per jednotku(at uz uloziste, ram, MHz ...), ale rozhodne to nestoji min.

Stejne tak jsou naivni predstavy, ze si zakaznik koupi neco co nebude vyuzivat. Jako ze si koupim 100TB prostoru a budu tam mit 10TB dat? Jako proc? Koupim 10, a kdyztak prikoupim dalsi 1. Totez opet plati o ram, cpu ... proste platim jen to, co aktualne pouzivam, v tom prece spociva vyhoda cmoudu. Tudiz zadna agregace.

Koupím 100 TB, i když dneska potřebuju 10 TB, protože to pak nemusím během životnosti serveru řešit. V cloudu to nakonec platím taky. Ty servery, které tam sedí a jsou připraveny být okamžitě využity, tam nesedí zadarmo.

"Koupím 100 TB, i kd"

Co nechapes na tom, ze v tom CMOUDU si nekoupim vic nez co pouzivam? Tudiz provozovatel cmoudu nemuze to cokoli prodat nekolikrat jako to delaji treba ISP?

prakticky se ale pleteš. Naopak rezervace zdrojů dopředu i na měsíce je v čmoudu běžná, ony totiž ty spot/ephemeral zdroje nejsou ve špičkách, když je potřebuji nejvíc, zrovna k dispozici, takže stejně si na core části ty věci předplácíme ve větší míře než je reálně potřeba.

Právě čmoud je přeborníkem v rozmnožování plateb, u databáze zaplatím za cpu, zaplatím za lokální disk, pak ještě zaplatím za s3, připlatím si za síť a při vysokém provozu ještě doplatím vyšší sazbu na IO. Přitom navenek jsem chtěl jen uložit změnu nastavení z mobilní aplikace a koupil si na to nějakou tu SaaS databázi.

V tom "CMOUDU" si zaplatíš X TB a v těch X TB platíš i to, že si můžeš kdykoli přidat dalších Y TB. Nebo si myslíš, že tam Amazon točí těmi nevyužitými disky jen tak zadarmo? To je docela naivní.

Popravdě se moc nechytám. Jakou infrastrukturu musí Google platit navíc? Jasně, pokud pokud si rozjedete mail server na 10 let starém vylítaném počítači pod stolem, tak nemáte takové náklady na infrastrukturu, ale to jaksi nejde považovat za srovnatelné řešení.

Pokud firma chce mít srovnatelné fyzické zabezpečení, záložní zdroje energie, propojení do Internetu atd. atd., tak si ho musí zajistit, nebo zaplatit serverhousing, který má podobnou infrastrukturu jako ten Google.

A pokud ten Google takových datacenter provozuje po světě 100, tak prostě bude mít úspory z rozsahu oproti firmě, která provozuje jedno. I to řízení vytíženosti se bude lépe řešit na takové úrovni. Nakonec i tady lidi píší, že když si jedou servery na vlastním železe, jede jim to na půl plynu, aby měli trvale výkonnostní rezervu. Firma, která takových serverů provozuje statisíce a má sotisfikované nástroje na balancování zátěže, může jet s podstatně menší rezervou a pořád být připravená na nové zákazníky nebo na náhlé požadavky na více výkonu.

"Google platit navíc"

Mas pocit, ze trebas storage pro 10 disku stoji totez, jako storage pro 10 000 disku? Nebo mas pocit, ze elektricka pripojka 10kW stoji totez co 10GW? A ne, ty ceny opravdu nejsou prostym nasobkem, jak se ostatne kdokoli muze presvedcit.

Kdyz takovych veci budes provozovat hodne, tak se mozna na ten prosty nasobek dostanes.

Kdyby byl provoz velkého datacentra na jednotku výkonu/kapacity drážší, tak Google těch datacenter nemá 100, ale 10 tisíc. Tak jednoduché to je. ;-)

201x : Vy to jeste nemate v cloudu?
202x: Vy to jeste mate v cloudu?

202x: Vam to jeste nedela AI?
203x: Vam to jeste dela AI?

Jde taky o to na co mate lidi, HW potrebuje peci spravcu, na SW staci vyvojari.

To je nesmysl. Cloud potřebuje úplně stejnou péči jako ten HW. Jen když se mi kvůli chybě rozmnoží kontejner na mém HW, tak za to nezaplatím $50k.

Jak se spravuje tisíce kusů serverů, switchů, diskových polí si komentovat nedovolím, protože to je mimo můj obor a prakticky o tom nic nevím. Údržbu zázemí (rozvodná síť, požární zabezpečení, záložní zdroje, …) si umím představit více než dobře. Nepřísluší mi diskutovat o něčem, čemu nerozumím a neznám realitu praxe.

Rozumím myšlence, ale přesto formulace působí nešťastně. Přece jen se mi příčí nechat vývojáře SW spravovat i servery např.: Exchange, ADDS, DB … tedy dělit práci mezi lidi s různými znalostmi a to budete dělat tak jako tak, bez ohledu jestli máte HW pod vlastní střechou, v datovém centru, nebo u poskytovatele cloudu.

V malém měřítku si také raději zaplatíte schopného správce (firmu), který se vám o to postará, protože není vždy oboustranně efektivní platit schopného člověka na plný úvazek. Drahé a kousal by se třeba nudou. Stejně tak si můžete zaplatit jednorázovou, nebo paušální službu lidí, kteří se fyzicky o ten HW postarají v případě problémů.

Nabídky „s neskutečnými výhodami“ přejít do cloudu pro malé firmy, nereálně nízkými náklady, přicházejí neustále a když si to spočítám, vždy se dopočítám, dostávám se k trojnásobku. Jednou za 5-6 let koupím potřebný počet fyzických serverů (psal jsem v malém, tak se nesmějte), náklady na správu, licence, úpravy mi zůstanou tak jako tak a nic dalšího kromě energií a připojení neplatím, protože zázemí už mám vybudované. Z cloudu se podle mého názoru stalo módní slovy a při těch nabídkách to budí dojem, že firma, která není v cloudu patří do historie a neexistuje. Nějak mi přijde, že Cloud se bere jako všespásné řešení, přitom to není pravda.

4. 1. 2024, 12:50 editováno autorem komentáře

kdykoliv necháš dělat někoho, kdo to neumí, koleduješ si o problém.

Nedávno nám v jednom datacentru v asii vyhořely primární UPS, pár zahořelých vedení, nic velkého, ale spustila se tím velká kaskáda problémů, která vedla k odstávce celého DC. A tady se ukázala slabina vlastního HW, obejít tisíce serverů dělalo těch pár lokálních adminů skoro dva týdny. V cloudu tohle jsme schopní naškálovat v podstatě hned.

Znáš to asi sám, jak musíš něco udělat fyzicky, tak se to strašně blbě škáluje a automatizuje, ale zase máš čas u toho přemýšlet a kontrolovat se.

Na druhou stranu to špatné škálování a automatizování má své výhody, pokud udělám botu, chvilku trvá než jí fyzicky udělám všude a je čas si toho všimnout a zachránit to. Pokud při správně cloudu udělám botu, velkou botu, mám minimum času na záchranu a důsledky jsou fatální.

Proč jste ty servery museli obcházet?

Bez důkladné a pečlivé kontroly nikdy nezjistíš, s jakými následky se potýkáš v případě závažné poruchy silových rozvodů. Nakonec ty skříně musíš otevřít a podívat se dovnitř.

Příště tedy zajistit redundanci v jiném asijském DC :-)

malý požár způsobil zapnutí požárního systému v celém sále, ten způsobil masivní podtlak, spousta serverů a aktivních prvků to neunesla a přestaly reagovat (plotnové disky to nemají rádi), odpadly i věci jako vzdálená správa, musel se každý server obejít, vypnout zapnout, zkontrolovat, vyměnit porouchané disky.

Všechny ty automatizace a monitoring systémy fungují dobře, pokud vypadne jen něco málo, když se ale sesype celá lokalita, bez ruční práce se neobejdeš, zprvu totiž nemáš vůbec informace, co vlastně nefunguje a co se stalo.

Kdezto v Google cloudu jsou data v suchu a bezpeci. Oh wait..
https://www.datacenterdynamics.com/en/news/water-leak-at-paris-global-switch-data-center-causes-fire-leads-to-outages-at-google/

Jo jasne. Mam zkusenosti ze vyvojari obvykle nerozumi moc sitim a ani tomu jak vystavit vyssi funkcni prvky proti nespolehlivosti infrastruktury. Naproti tomu docela dobre se vedou embedaci a neni treba je az tolik usmernovat. Idealni je proste mezoborova spoluprace s asistenci architektu.

Infrastrukturu postavenou developery jsem takhle do funkcniho udrzovatelne stavu dostaval po kouskach 5 let. Nejhorsi jsou ty diskuse kdy devel si mysli ze si zvoli treba libovolnou ip adresu v libovolne siti a UDP paket vzdy musi pres internet dojit. Idealne do par ms. Nebo ze bude admin na deployment studovat zdrojak aby vedel kde co nastavit. Pripadne ze prenaset data nesifrovane je preci normalni :-/

A presne toto je nesmysl, ktery vyvraci prave mimo jine tenhle clanecek.

HW zadnou spravu nepotrebuje, tech clovekohodin je naproste minimum a mozna kdyz je toho HW za 600k dolaru, tak to stoji za hovor, ale to uz je opravdu velka hromada HW.

Ten HW musi nekdo nainstalovat a zprovoznit. To je vse. Kdyz strelim ze za 600k to bude rekneme 60ks zeleza, tak to obnasi mozna sakumprask 200 clovekohodin prace. Jednou za 5 let. Radove vic casu bude trvat na tom zprovoznit SW. A ten se musi zprovoznit a udrzovat i na tom cmoudu ze?

"na SW staci vyvojari."
Jiste, a pak to vypada tak, ze vsichni vsude maji roota, a pod rootem i vsechno bezi. Videl sem, a ne jednou.

Slušný server (zde Dell) by mohl fungovat i 5 let nonstop. Pokud jsou pro provoz slušné podmínky (teplota, vlhkost, napájení, prašnost), pak se vlastně jedná o ideální podmínky pro provozování daného železa. Když DC zajistí tyto podmínky + slušnou konektivitu, je to prakticky ideální stav pro HW.

5? Mame tu 12 rocne servre. Uz ich odpajame koli tomu ze zeru vela elektriny. Ked sa server 1-2 roky nepokazi uz sa na nom nema co pokazit.

Dell uz bydefault dava 7 let, a nejspis to i o 2-3 roky prodlouzi, takze 10. Ale v realu, pokud se nebudem bavit o supportu ... mam u nekterych zakazniku stroje co jedou 15+. Umim je snadno nahradit pokud by umrely, ale neni k tomu duvod, typicky na nich neni nic kritickyho a kdyz to funguje ...

On by to hlavně měl dělat někdo kdo ví co dělá...

Akce vezmeme něco a někam to přelejeme jsou jednoznačně odsouzené k velkým nákladům.
Pokud odmítám používat cloudové služby (jako reálný cloud) a provozuju si tam jen VPSky (často legacy-SW) tak ta cena bude vždy docela vysoká.

Musí se prostě počítat a počítat... pokud to člověk umí často se dostane na podobné náklady jako kdyby si to provozoval celé sám. Nicméně mnoho věcí si nebude muset pak dělat sám.

Pokud si to nedokáže už na začátku spočítat, měl by se na to vykašlat to není cesta pro něj. Tyhle hajpy - všichni jdeme do cloudu a nebo je to největší zlo jsou zcela směšné a hloupé. Jen to ukazuje na to, že ten člověk neví co dělá a nepromyslel to.

Jenže ten reálný cloud je vendor lock-in jako Everest. To pak cloudový provider může dělat úplně cokoli a mě potrvá roky se ho zbavit.

Článek v podstatě shrnuje můj přístup, který mám k Cloudu po delší dobu. Cloud providerům se ale prozatím pořád daří přesvědčovat - hlavně managery - o "výhodnosti" cloudu. A zástupci providerů argumentují tím, že do cloudu musíte přejít kompletně, aby se projevily úspory. Že je to nesmysl je evidentní. Takže palec nahou za takovéto články.

Existuje ale i třetí cesta - hlavně pro menší firmy / jednotlivce: pronajmout si "surové železo" od některého ze slušných providerů - ať už ve formě VPF, VDS nebo dedikovaných serverů.
Těchto firem není zatím moc, ale zde si dovolím propagovat evropského (německého) providera "Contabo.com", u kterého mám virtuálky už několik let - spolehlivost 100% (za tu dobu ani jeden výpadek), a ceny? Například malá virtuálka na experimentování (4VCPU, 8GB RAM, 200G SSD) kolem €6/měsíc. To samé by v Azuru (M$) stálo cca 20x tolik. Další je český "hukot.net" - ten je v přepočtu na HW trochu dražší, ale daleko za AWS, Azure nebo Google.
A pro mě hraje roli i to, že firmy nají sídlo v Evropě.

> zástupci providerů argumentují tím, že do cloudu musíte přejít kompletně, aby se projevily úspory

Ano, "ušetříš si práci" použitím všech jejich featur, a pak nejenže nebudeš moci odejít z cloudu, ale ani přejít na cloud konkurence.

Jsem tady jediny, komu ten clanek prijde sepsany dost tendencne?? Ten clovek porovnava hrusky s jablkama, velkou cast jejich spendu tvorili PaaS sluzby, takze srovnavat to s cenou HW v onpremu uplne nedava smysl. PaaS sluzba se supportem, ktera nema za smysl byt levna, ale sejmout ze zakaznika urcitou cast jejich prace, za kterou plati providerovi. Smysl by davalo spocitat to proti EC2 treba s balancery na kterych bezi stejne technologie, ktere provozuji v DC.
To same plati o clanku, ktery ten pan sepsal k lambdam, jasne ze plati, ze lambda, pokud ji utilizuju 24 hodin denne je draha, ale to preci neni jeji usecase, pouziju ji tam, kde potrebuju narazove spousteni nejakeho kodu. Navic kolik zakazniku svym workloadem utilizuje HW na 100%(pokud pominu fakt, ze HW na 100% realne provozovat nejde) 24 hodin denne??
Rozhodne si troufnu tvrdit, ze zpusob vyuziti cloudu jaky ten pan popisuje neplati pro vetsinu zakazniku v CR.
Jinak tema ceny u public provideru je tema, ktere me hodne zajima, takze pokud mate nejake realne pripady, kdy byl cloud presneji AWS drazsi nez onprem budu rad kdyz mi je hodite do mailu.

Diky vsem.
Lukas

Prijde, dokonce si myslim, ze kdyz odchod byl tak jendnoduchy a v textu jsem.nekde videl ze nepremysleli o vyuzivani saas, tak jsem nabyl nazoru, ze implementovali onprem logilu na cloud. Tym rozsirovat ani menit nemusel, jinymy slovy, udelame migraci z onprem do cloudu a budem tam dal pouizivat ten bambilion virtualek.
V cloudu delam jiz delsi dobu, predtim jsem byl server admin. Neda se to srovnavat s provozovanim saas.
Je smutne kolik firem a lidi ai mysli, ze prenesou virtualky do cloudu a zaskrtnou si cloud fajfku :D. Ale neprekvapuje me to.

No ja som sa nikdy nestretol s tym ze by AWS bol lacnejsi. Iba ze to bolo pohodlnejsie.

Tohle tvrzeni je trochu vystrel do prazdna, pokud nevime, jak jste vypocet delali. Spousta lidi ma tendenci porovnavat cloud proti nakupu HW a zapominaji, ze nakupem HW to pouze zacina. Potrebujete zaplatit datacentrum, elektriku na napajeni,chlazeni, vybaveni DC atd. Pokud clovek na tohle vsechno zapomene, pak to nemuze nikdy vyjit.
Pouzivali jste pro vypocet tooly, ktere naskanuji Vase prostredi a rovnou navrhnou optimalizaci jednotlivych VM?? Nebo jste to sizovali 1:1??

Mám na jednom projektu dva servery, jejichž pořizovací cena byla dohromady cca 220k Kč. Oba 256 GB RAM, 32 jaderný EPYC a 4x2 TB NVMe v RAID 10. Housing v DC stojí cca 6k. Servery rozpočítané na dva roky vychází na 9.2k měsíčně. Když se budu hodně snažit, tak EC2 instanci, která zastoupí jeden takový server, budu mít za $1300 měsíčně, tedy cca 30k Kč. Za dva servery 60k Kč a to ani nepočítám trafik, který by vycházel na stovky dolarů. V tomhle případě je ten rozdíl úplně absurdní. Jak člověk má nějaký významnější baseload a nedejbože provozuje třeba větší databázi, tak cenově cloud nemůže konkurovat ani vlastnímu ani pronajatému HW.

Ten server ale není vytížený 24/7, že ne?

Dokud k tomu budeš přistupovat tak, že potřebuješ velký server, protože škáluješ jen vertikálně, cloud se ti asi nevyplatí.

V cloudu se dá ušetřit, když potřebuji výkon nárazově, když umím workload škálovat horizontálně, když umíš svoji aplikaci přizpůsobit.

U jednoho klienta ve finančním sektoru jsme měli cluster podobně nadupanách serverů s sql databází, smysl byl jediný, sloužil jako backend pro power BI na generování reportů. Ten projekt nám byl uveden tak, že nelze ušetřit, že se data počítají kontinuálně a je nutné je mít co nejdřív napočítané. Když jsme se do toho zanořili, zjistili jsme, že se počítají kontinuálně jen proto, že exporty z různých core systémů tam jedou náhodně v dlouhé smyčce a že 90 % vstupních dat jsou vlastně denní snapshoty. Dnes se hlavní data počítají 4x denně, na to se spustí instance v cloudu, data jsou uložena v parquet souborech na ADLS a power bi na ně přistupuje přímo, těch pár rychlích dat se tam nahrává každých 15 minut. Úspora je neuvěřitelná, i s 30 TB historických dat za 10 let se vejdeme měsíčně do 200 EUR a přitom response time v power bi je výrazně nižší, reportů je dnes už přes deset tisíc a přistupuje k tomu stovky uživatelů.

Takže ono to vlastně záleží. Podobnou úsporu by šlo ale udělat i na vlastní HW, výhoda cloudu je schopnost dělat rychlé iterace, experimentovat. Při nákupu HW to je těžké rozhodnutí na roky dopředu, ty nakoupené servery se prostě špatně upgradují a nikomu se do toho nechce.

Na tech serverech nebezi virtualizace?? Je to OS s databazi??

Suhlasim mne to pride tiez tendecne.

zatial vsetky priklady, ked cloud bol vyrazne drahsi ako on premise riesnie bolo, ked firma sluzby cloudu pouzivala na nieco na co neboli urcene, alebo si vybrala zbytocne drahe riesnie (IaaS namiesto SaaS).

Prejit z OpenSearch na ElasticSearch kvuli opensource ? Nema nahodou OpenSearch Apache licenci ? Vetsinou to je presne obracene.

Stejny pocet lidi na cloud jako na on-prem znamena, ze provoz delaj hlavne vyvojari (pokrocile CI/CD), a hw a infrastrukturu nejaka externi firma (vcetne SAN a zalohovani) v pronajatych DC.

Ceny v public cloudu (AWS) se drasticky lisi dle toho, jak moc komplexni sluzby poskytovatele cloudu pouzivate, a jak komplexni topologii tam z nich vytvarite.

Cim vetsi komplexita poskytovane sluzby, tim drazsi, protoze se do ceny u tech komplexnich zahrnou nikoliv jen pouzite zdroje, ale i odbavene pozadavky. Mezi komplexnimi sluzbami AWS jsou casto zavislosti, a platba za transakce/pozadavky se pak uplatni na kazdou jednotlivou z pouzitych sluzeb.

U komplexnich sluzeb se "hw" zdroje nevoli dle Vami pozadovaneho vykonu, ale podle preddefinovanych sablon cloud poskytovatele . Chcete 30 db v RDS, zaplatite za tolik a tolik pameti (bez ohledu na to, jak moc budou realne zatizene).

Nebo rychlejsi disky s garantovanym I/O, platite i za namerene I/O. Zalohujete je ? Pak zaplatite i za I/O potrebne k nacteni snapshotu. Presouvate ta zalohovana data mezi lokalitami ? OK, zaplatite i za ten datovy prenos. Nacpat data do cloudu lze v podstate zdarma proti tomu, kolik stoji prenest je z cloudu zpet na on-prem.

Z toho, ze cloud provider disky virtualizuje, ze pouziva deduplikaci dat nebo differential snapshoting, on-fly komprese (i prenasenych) dat, nemate zadnou financni ulevu. Prenest 10GB muziky a 10GB logu je brutalni rozdil ale stejna cena.

U vlastni infrastruktury extra cena za transakci/request neexistuje, a dokud hw staci, nemusite to resit.

Pokud nestaci, pak je super, pokud dokazete aplikace na kazde vrstve skalovat horizontalne, abyste mohli postupne pridavat dalsi cihly, misto menit stavajici cihly za vetsi tvarnice. Ne vzdy je to trivialni a mozne (SQL databaze, SAN).

u HW řešíme výkon, když nestačí, koupí se nový a jsou jasné náklady. U cloudu to je jedno velké dobrodružství, pro nás dobře placené.

Rozmohl se nám tady třeba takový nešvar, všichni dnes tlačí streaming, microbatching, což vede k vytváření kilobajtových souborů na s3 a je běžné, že se platí za každý IO na s3... Ty diskuze jsou pak vtipné, najednou uživatelé musí řešit něco, co vlastně nikdy neřešili a čemu vlastně nerozumí, takže se nad tím dělají nádstavby, reporting atd.

Člověk si řekne, nevadí, udělám si resource group, nastavím tam denní limit na platbu a bude vše bezpečné. Pak příjde obyčejný nepoučený power uživatel, spustí úlohu, udělá milion souborů za minutu a já s denním zpožděním zjistím, že se rozpočet na resource groupu překročil 10x, protože limit je počítaný s 5 minutovým zpožděním. Zjištění, že měření spotřebovaných zdrojů na cloudech je asynchronní, v nějakých intervalech a ještě k tomu u každé služby jiné je taková pěkná studená sprcha u každého nového projektu.

Vlastně mám pocit, že cloud tlačí poskytovatelé cloudu, integrátoři a lidé, které to živí, klienti do toho skákají a jen tak každý pátý vlastně tuší rizika a chce to dělat rozumně a ne hrubou silou.

GE může vyprávět, s cloudem chtěli ušetřit a první rok byly na trojnásobku nákladů, dnes přestali myslet na cloud jako levnější alternativu k HW, ale zjistili, že mít realtime přehled o infrastruktuře, být schopný dělat okamžitě změny a udržovat vše aktuální a pod kontrolou je vlastně ten největší přínos cloudu, už žádná iLO hesla na papírkách, už žádné přímé připojování klávesnice a monitoru k serveru s důvěrnými daty, už žádné dilema jak šifrovat dat i na nvme, když server podporuje pouze SED.

"už žádné přímé připojování klávesnice a monitoru k serveru s důvěrnými daty"

... a uz zadna duverna data, data v cloudu === data v coudu.

Nejlepsi je predat data do pekel horoucich a nemit nad nimi naprosto zadnou kontrolu. Samozrejme vsichni naslibuji jak jsou prave u nich data v bezpeci, ale staci si precist smlouvu... a nikde tam zadne miliony eur splatitelnych v pripade ztraty/zverejneni tech dat ... nevidno ...

Potvrdzujem vsetko co som tu v diskusii cital. Mam korporatnu skusenost s AWS. Security IAM manazment je obrovske peklo. Vela casu stravim len hladanim a nastavovanim IAM roli, ak vobec mam prava ich zmenit, lebo defaultne je vsade vsetko zakazane.
Vyvijat nieco na nativnych servisoch a hlavne debbugovat to, je dalsie obrovske peklo. Dopatrat sa k spravnym logom v CloudWatch... skor najdem ihlu v kope sena.
Jednoducha aplikacia, ktora nacita data z csv a spristupni ich cez API. Stacili by na to 2-3 docker kontajnery. Pri tom malom mnozstve dat hoci aj SQLite. Nie, musi to byt serverless, musi to bezat na nativnych AWS servisoch, S3, Lambda, Glue, Athena, SNS, DynamoDB(lebo lacna aj ked nevhodna na tento ucel) , API gateway.... V Terraforme je vdaka tomu x krat viac kodu ako by bolo npr v Pythone vo Flasku + Docker compose.
A este dalsie ceresnicky okolo Glue, klasifikatorov... ked zmazana tabulka v skutocnosti nieje este zmazana, ale az po nejakom case... Alebo update Glue klasifikatora ho neupdatne, ale vytvori novu verziu, len ta nova verzia sa automaticky nepremietne do dalsich veci, treba ju rucne prepnut.
Moj prvy a zaroven posledny projekt, ktory mal nieco docinenia s tym AWS peklom. Nikdy viac.

6. 1. 2024, 15:15 editováno autorem komentáře

No taky se nás každou chvíli ptají, jestli nechceme přejít do cloudu. Ale nevychází to dobře, protože potřebujeme úložiště cca 500 TB a k tomu linku optimálně 10 Gbit, aby se s těmi daty dalo nějak rozumně pracovat a nebyla neustále zatížena na 100 %. Denní objem přenosu je v řádu jednotek TB v součtu oběma směry. V cloudu to jsou úplně jiné počty, než když to máme u sebe v baráku. A hlavně - výkyvy v zátěži máme malé.

Článek zajímavý.
Nicméně konkrétní firma má vždy konkrétní náklady.
Porovnávat výhodnost či nevýhodnost ve firmě která má existující dvě datacentra, a s velkou pravděpodobností i mají odborníky je principiálně zavádějící.
Znám totiž plno malých firem do max. 50-100 počítačů které nic takového nemají a pro ně cloud je v podstatě řešení o několik levelů výš za velmi rozumnou cenu.

"Znám totiž plno malých firem do max. 50-100 počítačů které nic takového nemají a pro ně cloud je v podstatě řešení o několik levelů výš za velmi rozumnou cenu."

Znam takovych firem 30+ jsou to mi zakaznici, toto je presne ten marketingovej megazvast.

Uz jen zajistit zcela jakoukoli rozumne garantovanou a zalohovanou konektivitu je casto zhola nemozne. Vsechy ty firmy vicemene bez problemu funguji offline. Jak to udelaji v cmoudu? Jo aha, nebudou fungovat vubec.

Ježe cloud může být, a v takto malých společnostech celkem často bývá nastaven jako hybridní. Tzn. máš své servery, ale část jedeš i na Office 365 atd.
Ano, i Office 365 je cloud, stačí používat služby jako AAD, a nebo použiješ Intune.
Stačí aby ta firma měla dvě-tři střediska a po republice několik obchodníků.

Tento clanok je zavadzajuci a v podstate poskodzujuci myslienku cloudu.
Ano, cloud neni pre kazde riesenie - jeho najvacsia (hlavna) vyhoda je v skalovani - skalovanie peakov a noveho loadu. Ktory pokial nepotrebujete (mate +- flat load a nerastiete vobec alebo minimum), nechodte do cloudu.
Tiez sme migrovali do cloudu (a hovorime tu o radovo vyssich ciastkach) - cenovo sme asi 2-3x vyssie nez ked sme boli vo vlastnom - ale tie moznosti co mame nam to zaplatia. Mozeme stavat nove environmenty kdekolvek po svete, za zlomok casu potrebneho oproti vlastnemu datacentru...

Clanok ale popisuje:
cena hardwaru $600k, co je pri 4-rocnej amortizacii $150k
cena cloudu $3,2M

Jako, seriozne ste platili cca 21x viac za cloud?
Verim, ze autor z toho chcel spravit tak trochu 'senzaciu', takze naschval neuviedol cenu za vlastne riesenie za mesiac...

Ale rozhodne by som negeneralizoval, ze sa cloud neoplati.
Uz len ked si spominam, ako sme vo fazach nakupovali novy hardware, cakali sme na SSD-disky, ktore proste neboli, nasi zakaznici trpeli ci dokonca odmietali ist do naseho riesenia, pretoze kvoli nedostatku hardwaru sme mali obmedzenu performance (rastli sme asi 30-50% rocne - ale nakup hardwaru trval od objednavky po nainstalovanie kludne 9 mesiacov).

Přesně toto je v článku zmíněné. Tak v čem je zavádějící a poškozující myšlenku cloudu?

Pozkozuje to ksefty, protoze zakaznici dostanou odkaz a prectou si to tu ... ;D A kdyz to horem a dolem nekomu tlacej s tim jak je to pro nej uzasne vyhodny, a on si pak nekde precte, ze to stoji 10x vic nez vlastni HW ...

Ten článek jen popisuje realitu jedné konkrétní firmy. Ty si zjevně z nějaké korporace s desítkami vývojových týmů. Tam jsou trochu jiná pravidla než u malých firem jako je 37signals o cca 40 zaměstnancích. Pokud takové studio máš, tak už přemýšlíš, jestli budeš platit $1M ročně navíc Amazonu nebo si radši půjdeš koupit nové Ferrari.

Mi se libi nazor, jak vse v cloudu funguje ;-)
To jsme tak sel na 1 tydenni skoleni na Azure, vyrobil jsme windows server a na ten se neslo prihlasit, proste u toho spadl, takze smazat, ouha, smazat nesel, on se pustil proces, pak vubec nevidite v jakem je stavu a najednou se proces ukoncil, ale server tam byl - takze 10 min pockat a pustit znova a heureka ;-)

nebo ze jsme si tam vyklikal tu automatizaci, dopsal hodnoty, a vyrobil to - casto to proslo, ale po konci labu jsme si to vzdy mazali, nebot jsme meli regulerni kredit i na to skoleni - sice jsme dostali kredit zdarma, celkem vysoky, i tak jsme kvuli rezervaci zdroju - za ktere se plati i kdyz nic nedelaji vse nakonec smazali - a tam to padalo dost

a to je přesně to know-how, které se musí platit nebo draze získat. Ono toho nefunguje spousta, resp. musíš přesně vědět, jak to funguje a jak to spolehlivě dostat do fungujícího stavu.