Kéž by se z toho lidé a firmy poučili a hostovali své aplikace buď na vlastní infrastruktuře nebo alespoň na evropské či české. Momentálně totiž cpou peníze megakorporaci, pro kterou je většina jejích zákazníků naprosto bezvýznamných, takže na ně nikdo nebere žádné ohledy, a když se něco stane, tak jsou naprosto bezmocní.
To je to, oni to maji jen v EU ;-) dokonce rikas, kde to mas, ale CIA chce smirovat a tak vse fyzluji z USA - data asi nereplikuji ale US servery sahaji na EU data ... jak jinak si vysvtlit, ze jeden region v USA ovlivnuje DC v EU a ne treba v Cine ;-) - protoze Cinsky cloud nesmi sahat do USA - proto je Cinsky AWS i Azure zcela jiny produkt, zvlastni autentifikace nekompatibili se zbytkem sveta, ale muzete si to do Ciny replikovat
A zapocital si cenu lidi co se o to staraji? Ja jsem zaryty odpurce cmoudu, a pokud me vlastni hosting stoji v ramci teamu max par jednotek clovekohodin tydne tak je to mega levnejsi nez cokoliv co se da koupit. I bych rekl ze bezpecnejsi a spolehlivejsi.
V okamziku kdy na to myusis mit dedikovnaeho clvoeka, nedejbzoe team, coz od jiste velikosti je afaik nezbytne, tak se ty krivky protnou a je po srande. Kvalita pak zalezi na tom tvem teamu, ktery muz ebyt lepsi, a nebo horsi nez to co dostanes v amazonim prumeru....
Není to spíš tak, že od jisté velikosti je, co se týče nároků na práci těch lidi, úplně jedno, jestli ten provisioning to vytočí v lokálním DC nebo úplně někde jinde?
Takže kromě člobrdy, co jednou za 5 let vymění HW popř udělá nějaké RMA (ten je navíc, vs člověka, co má na starosti cloudy, optimalizace mezi nimi etc.) můžeme z obou stran nerovnice ty lidi zase odečíst, ne?
20. 10. 2025, 15:21 editováno autorem komentáře
A to si jako myslis, ze na cloud nepotrebujes mit lidi ;-) a ted se podrz, pokud mas linuy, jsou ti lidi drazsi, pokud mas windows, tak clovek na cloud je drazsi nez win admin ;-)
Cloud se sam nespravuje, nepotrebujes jen lidi na HW - a velka firma je stejne ma, nebot jsou lokalni a stredni hold necha tyhle veci delat i drazsi lidi, neb je to parkrat za mesic, nekdy za rok.
Treba mi si vse instalujem sami, ale v ramci DC mame v cene facility - takze treba vymenu naseho kabelu udelaji sami, prace na HW dela vendor i bez nas.
Ja to reknu takhle, pro jeden projekt potrebovali nutne NetApp Metro cluster - dokud tam meli 400GB tak se vyplatilo to pronajmout - IO se nepocitalo, v momente kdy to narostlo na 200TB tak jsme nakupem vlastniho reseni setrili 30k euro / mesic - za 4 mesice se nam zaplatil vlastni full flash - tedy inline deduplikace i komprese a misto rozsireni se zjistilo, ze se tam vejde pres 300TB.
V jine firme jsme meli vlastni podzemni DC a pronajimali jsme si 2 mistnosti v jinem DC - zvazovali, zda by nevyslo levnejsi mit DR site v cloudu - a nevyslo ;-) a pokud by se tam nedej boze neco spustilo, tak by byla veskera uspora fuc ;-)
Kdyz spictali 600TB PureStore - tedy full flash, co delal miliony IOPS s latenci pod 0.5ms - a ten job tam jel kazdy den skoro cely a 1x mesice se zastavil a tyden to delo dalsi job - tak jen ta masina by nas stala vice nez cele DC i s lidmi ...
Tak především záleží, co je to za cloud. Když si pronajímám VM, tak mám náklady na lidi skoro stejné, odpadnou jen starosti se železem, jinak se řeší přesně to stejné. Pokud si pronajímám přímo službu, tak mám sice menší náklady na lidi, ale zase platím za tu sluźbu samotnou ještě více než v případě IaaS.
Třeba Basecamp migroval z cloudu - viz https://basecamp.com/cloud-exit - a ušetřil prý hodně peněz
Ani se nedivím - trochu výkonnější železo je v cloudu extrémně drahé. Cloud byl zajímavý pro firmy, které hodně rostly nebo jejich zátěž kolísala. Dneska mají cloud i zdejší velké korporace - jestli jsem to pochopil - jeden z důvodů je, že bezpečnost a dostupnost mohou předat někomu dostatečně velkému a nemusí se o ně starat. Reputační riziko nese někdo jiný, a to je pro ně důležité. Ve smyslu letitého tvrzení, že nikdy nikoho nevyhodili, když koupil Oracle, DB2, SAP, ...
Když se podíváte na ceny databázových serverů, které mají mít trochu slušnější výkon (větší než minimální), tak je to hodně drahé. Slušné fyzické železo (s řádově lepšími parametry) by se vám zaplatilo během roku.
Presne tak a to i s platy EU lidi ze zapadu, ktere tak jako tak musis mit taky, nebot ani cloud se nespravuje sam, usetris jen na facility - btw instalace jsme delali mi az prepojovani kabliku atd. delala facility
Jediny scenar kdy vyjde AWS velmi levne je, kdyz jsi mala firma a 1x mesicne potrebuje nabusenou masinu treba za 1 mega - pak ji vytvoris, narves data, nechat si na tech 200cpu a 4TB RAM spocitat, vyplivnes vysledek a zkartujes masinu - abys neplatil za rezervaci - prersenji ani masinu nechces, chces AWS API aplikaci, tedy bez OS - cili efektivne linux jen o tom nevis a data v S3
Jinak platis za odeslana data, kdybys chtel nahodou odejit a treba AZURE pak dela zajimave veci, ze ty data nejdou stahnout zpet ;-) ... a v cloudu platis za vsechno, za rezervaci HW co nic nedela (CPU, RAM, disky i prazdne misto), za kazdou IO na CPU i disku - kdyz mas SSD, neplatis za I/O disku, ale platis vic za data i za rezervaci prazdneho mista, platis za odeslana data.
"pro většinu scénářů vyšel cloud x-násobně dražší."
To neprekvapive plati zcela vseobecne, ze pronajem cehokoli je dlouhodobe vyrazne drazsi. Kdyz si chces vyvrtat jednu diru, pak si asi nebudes kupovat vrtaci kladivo, ale pucis si ho ... pokud vrtas kazdej den ... tak te typicky to pucovani zruinuje asi tak za tyden.
To ano, ale z hlediska provozovatele služby je lepší mít služby levnější a s menším počtem výpadků. Dokonce je i lepší, když vypadne spousta dalších služeb – za prvé je to menší reputační problém (uživatelé vidí, že toho vypadlo spousta a že to tedy asi není chyba dané služby), za druhé pak zákazníci nemůžou utíkat ke konkurenci, protože ta také nefunguje.
Protože tam nebudou fungovat úspory z rozsahu, takže za stejné peníze budou mít horší služby od dodavatelů, méně a méně zkušených odborníků.
Amazon ten problém samozřejmě řeší, a nemyslím si, že kdyby to někdo provozoval na vlastní infrastruktuře, vyřeší to rychleji. Takže to „mohou něco dělat“ je dost pochybná výhoda, nanejvýš jde o ten pocit, že „se něco děje“.
Ona je taky dost nedoporučená strategie viset na jedné lokalitě. us-east je cenově nejdostupnější takže asi i nejzatíženější lokalita.
Je docela s podivem, že výpadek DynamoDB má tak extrémní dopad. U S3 bych to čekal.
Pokud si to někdo bude hostovat sám, bude ho to stát pro něj myslím dost neuvěřitelné peníze (pokud by se pokusil nasimulovat podobné podmínky - což ani nezkusí - myslím, že většina ani nechápe co to je).
Proto téměř neexistují evropští poskytovatelé - dokážou stěží oživit OpenStack.
To mne nejvíc překvapilo, že i velké a známé firmy poskytující služby celosvětově to odstřelilo – myslel jsem si, že používají více regionů. Ony to ale často přenášejí na koncové uživatele – poskytují jim služby ve stejných regionech, jako AWS nebo Azure a tudíž je nechají, ať si případně regiony řeší sami.
On je ten výpadek zjevně větší, než jen DynamoDB – možná AWS interně používá DynamoDB pro další služby. Každopádně už samotný Amazon potvrdil, že to má dopad i na EC2, a dopady to má i na Lambda služby.
Na to jste přišel jak? Všechny zprávy od Amazonu byly o tom, že se problém týká regionu US-EAST-1.
Navíc replikaci mezi regiony si podle mne zákazník musí řešit sám – cloudoví provideři záměrně dělají jednotlivé regiony jako oddělené světy, právě proto, aby se minimalizovalo riziko, že půjde dolů celý cloud.
Tohle neni uplne jednoduchy je to takovy chicken-egg problem.
DNS je z principu globalni sluzba a potrebovalo by nejake globalni uloziste.
Jenze globalni uloziste by nesmelo zaviset na DNS.
Cele to je takova vyjimka v konceptu cloudu.
Kazdy region by mel byt nezavisly, kazda sluzba sluzba by mela mit vlastni lokalni Control plane s vlastni lokalni databazi. U nekterych sluzeb to ale neni mozne.
DNS samo o sobe je vcelku robustni protokol, ktery dokaze odolat i vypadkum vice uzlu. Postavit to distribuovane je trivialni a dokaze to bezet omezeny cas i autonomne... samozrejme nemam v zone posledni zmeny, ale to co tam je nemusi nutne umrit proto, ze nejake centralni uloziste prestane fungovat... kdyz se tohle stane, tak to DNS proste delaji blbe. A sorry, typicky za tim stoji frikulinsti mladosi, co fungujici veci "rozbiji", treba uz jen proto, ze nechapou historicke duvody nejakeho reseni a zvoli svou novou a neotrelou cestu. Ale za to DNS uz nemuze...
Danny: Vy si vždycky vezmete nějaký komentář jako záminku, na jeho základě vymyslíte nový problém, který s předchozím komentářem souvisí jen metodou volných asociací, pak napíšete, že tenhle problém má triviální řešení a že jsou všichni ostatní hlupáci, jenom vy to děláte správně.
Takže tu pořád řešíte výpadky DNS serverů, a vůbec vám nevadí, že problém AWS začal podle všeho špatnými nebo chybějícími záznamy v DNS zóně, což jaksi vaše komentáře vůbec neřeší.
Tomu, že nějaký záznam v zóně není nebo je špatný, žádný DNS server nezabrání. Můžete mít nějaké kontroly a/nebo testy DNS zóny, ale pak je samozřejmě otázka, proti čemu se ty testy nebo kontroly provádějí. Asi budete chtít mít jeden zdroj pravdy – no a když někdo udělá chybu v něm a projde to přes kontroly, neodhalí pak problém ani kontroly DNS zóny.
Zase jsme u toho samého problému. Nejdřív dokola melete o nedostupnosti DNS resolverů, přičemž vůbec nic nenasvědčuje tomu, že v tom byl problém. Když vám konečně dojde, že střílíte špatným směrem, vystřelíte náhodně někam jinam. Ale hlavně že si nezapomenete do někoho kopnout. To je pro vás totiž to nejdůležitější, že. Tak si tu dál okopávejte kotníky komu chcete, já vám u toho asistovat nebudu.
Je to tym, ze us-east-1 bol dlho predvoleny a boli tam centralizovane sluzby AWS ako IAM, SSO alebo aj nejake ulozisko S3 metadat. Preto support zvykol spominat, ze vypadok us-east-1 je "koniec sveta" a nepojde nic. A rovnako tvrdenie ako "ked si ulozim subor do S3, tak uz bude ten subor dostupny cez S3" platilo iba pre us-east-1; inde mohol fungovat caching a az po nespecifikovanej dobe to malo zacat fungovat.
To sa teda postupne opravuje, ale zakaznici sa stale spoliehaju na us-east-1.
Je to nedoporucene, ale je to tak.
Mohlo a nemohlo ;-) - vypadky se moc nedeji, od toho je cluster - a pokud neco zmrvis, rychle to opravis - a necekas az to zjisti nejaka firma i kdyz je profi a ma to - ale nikdy nevis, zda ti nelze, do AWS se na svoje servery nepodivas ;-)
Treba mi delali ten cloud jeste drive, nez to bylo cool ;-) a ve smlouve bylo, ze zakaznik ma pravo to videt, ma pravo zadarmo na nahodnou obnovu dat i masiny v ramci testu atd.
Podelat se muze cokoliv, ale zalezi jak moc setris, kdyz mas redundanci, tak jsi v klidu a ver ze Azure i AWS setri fest ;-) a na vsem
Viz casablanca, ti tvrdili lidem ze se nic nedeje, kdyz se po netu povalovaly fotky jak jim tece voda do racku.
A to nejsou zdaleka jediny ... kdy ze to byla ta "zaplava" na morave? Jeden ze zakazniku ma nekde v ostrave web ... a ackoli nebyl zaplavenej, tak byl off ... to jsou henti profesionalove ...
"ver ze Azure i AWS setri fest "
Predevsim vubec netusis co jak kde vlastne bezi a jak to je (nebo spis neni) zajisteny.
" budou ty výpadky častější"
Tohle umi mr JIrsak zcela jiste dolozit, nelepe nejakou verejne auditovanmou statistikou ze?
Je to totiz nehorazny blabol. U vetsiny svych zakazniku umim v pripade libovolnyho vypadku rozjet nahradni reseni v radu maximalne nizkych desitek minut, a to v situacich, kdy neco totalne failne. V tom uplne nejmensim meritku to umi kazda uklizecka, staci zapnout to rezervni pc.
No a teraz tu o Snehurce.
Toto, co pises je blbost. Mozno to vies tak rychlo zobehat za urcitych okolnoti ale urcite nie v pripade akehokolvek vypadku.
Urcite niesi dostupny 356/24, ak by si nahodou aj bol, tak vsetko, co k tomu potrebujes nemusi byt vtedy dostupne. To rezervne PC nemusi ist zapnut/nemusi fungovat a dalsie scenare, kde sa to nepodari rozbehat v kratkom case tebe alebo tej uklizecke.
Je to len iluzia. Na vsetky scenare nemozes byt pripraveny.
Predpokladam, ze to tvoje riesenie/produkt nieje nijak komplexne. S komplexitou narasta riziko a mozne problemy.
Akorát předvádíte, že vůbec netušíte, o čem je vlastně řeč. A jenom to potvrzuje příklad, kdy se tváříte, že reprezentativním vzorkem je jedno PC, ke kterému se dostane uklízečka.
Chtěl bych vidět, jak to náhradní řešení rozjíždíte v řádu nízkých desítek minut třeba v situaci, kdy vám budou servery v datovém centru plavat. Pochybuju, že máte pro většinu svých zákazníků hot standby v jiné lokalitě.
Ostatně ona je dostatečně vypovídající i ta první osoba „já umím“. HA řešení závislé na jednom člověku?
Jinak samozřejmě můžete technicky nic nebrání tomu provozovat si sám stejně spolehlivé prostředí, jako nabízejí cloudy. Nebo i spolehlivější. Akorát to bude ve většině případů podstatně dražší.
Tohle porovnání je trochu zavádějící.
Ve vlastním datacentru obvykle provozujete/řešíte servery
, zatímco v cloudu to budou mnohem spíše kontejnery
. V in-house datacentru platíte za kapacitu, v cloudu obvykle mnohem spíš za spotřebované zdroje.
On se nechá vybudovat i in-house cloud - a tak při správném škálování bude provoz levnější, než v pronajatém cloudu. Ale vybudování (datacenter pro cloud) bude určitě dražší, než pronájem, kde se o investici dělí více zákazníků...
Zrovna ten výpadek AWS se týkal služeb a virtuálních serverů, ale kontejnerů (v AWS) ne. Navíc v tom vlastním datacentru na těch serverech nejspíš také budete provozovat nějaké služby, kontejnery a virtuální servery.
Podstatou odpovědi ale bylo to, že je naprosto zcestné porovnávat počítač a vedle něj druhý záložní počítač, který může zapnout i uklízečka, a když se tam něco rozbije, má to jediného správce – a naproti tomu AWS.
nám přestaly fungovat i kontejnery.
Ano, zapnout další server může i uklízečka (proč by to ale dělala, že), problém je hlavně jak ten server dostat na produkční cestu, jak na něj přivést produkční provoz a zajistit, že bude mít aktuální data atd.
Mám ještě dost práce vybudovat tohle trochu robustnější.
Skalovat vykon v jednom DC je odlisna uloha nez skalovat pres nekolik DC.
Vyhoda cloudu je ze je vsechno self-service.
V cloudu muzete obejit vsechny korporatni procesy kteryma si sami sobe komplikujete zivot. V cloudu spustite terraform a za par minut mate infrastrukturu v jednom DC, ten samy .tf vam vytvori identickou konfigurace v jinem DC.
Pokud pouzivate ITIL tak vam ten samy process muze trvat nekolik tydnu nez vsechno vytorite pomoci ticketu zadanych nekolika ruznym tymum. A nakonec ani nemate jistotu ze obe DC jsou nakonfigorovana identicky.
Tady je par duvodu proc HA nefunguje v korporatu na on-premise
- nikdo vam to nedovoli otestovat HA failover nez to pujde do produkce, protoze je to "nebezpecne"
- nekoho napadlo filtrovat vsechny IMCP packety vsechny ICMP host unreachable(i nikdo nevi proc)
- na zmenu DNS je potrebujete ticket, automatizece DNS se neplanuje
- dodavatel dodal aplikaci s archaickymi JDBC drivery, ktere nepodporuji switchover
Mám opačnou zkušenost. Většinou já jako bezpečák naopak vytýkám, proč je ICMP tak utažené. Hlavně jsou na to specialisti správci serverů v kombinaci s IPv6, kde vypnou i ICMP zprávy, které podle RFC musí být zapnuté. A nakonec doiterujou do stavu, kdy celou IPv6 vypnou, protože to je nespolehlivé a nefunguje to.
A co mi brání k on-premu přistupovat jako ke cloudu?
Stejně už máš ty korporátní Terraformy, které pak používáš, a bez toho tě nepustí ani do cloudu. Pokud už ta znalost je, tak je jedno, jestli je to z pohledu vývojáře cloud nebo on-prem.
PS.: Zažil jsem i reálné trhací testy na produkci, kde se testovalo správné fungování HA. A byly pravidelné. Myslím, že je to jen o tom, co kdo chce mít na triku, když dojde na lámání chleba.
Jaky problem ?
Docker je HA uz z principu.
SAN - mam 2x fabric a multipath
Netapp MC - mam syncronni repliku do 2 lokalit
Oracle RAC - to same
Vmware - tam snad ani neni treba nic rikat i pidi lokace maji 3 servery uz jen kvuli upgrade
LAN - zase sestackujes switche, udelas LACP a 1 kabel das do jednoho, druhy do druheho
Pokud chces aplikaci v clusteru mas stale moznosti, od RHEL peacemakru, pres jine reseni - dnes to uz ale nahrazuje casto docker, vmware atd.
Vim ze jedna firma mela hodne Oracle RAC a casto i primo na serverech - kdyz jim odesel kriticky clovek tak zacali zvazovat, ze ustri na licencih, koupi si single a nechaji to vmware, ze by RAC nechali jen na 2 instacich - tedy 4 servery + testovaci servery - kazdy upgrade se delal nejdrive na testu i vyvoj se tam nejdrive daval, oni jeste meli dev ktery jako ze musel bezet a test, ktery se mohl cely znicit
Nedosažitelné je to tak leda v něčí hlavě. Jediný problém v on-premise je údržba. Musí se updatovat SW, FW, občas nahradit kritické prvky. To bývá problém protože někdo může mít špičku v grafu a může mu jebnout.
Jenže jakmile máte něco víc, než jen webový ksicht (HW řekněme 2-3 chassis a víc), tak už v cloudu platíte násobně víc, než za HW i s výplatami adminů.
Já mám ještě lepší nápad, vykašlat se na model služeb, co potřebuje server. Já nevím, proč prostě? Však můžeme běhat na decentralizovaní síti nebo servelss.
Třeba pro chat existuje Jami, SimpleX... dneska jsem zjistil, že Signal používá AWS, takže v mojich očích klesly na úroven odpadu jako WhatsApp nebo Messenger.
Jedna věc jsou kecálci a podobné věci které by mohli běžet decentralizovaně... Druhá ostatní appky -- předpokládám že asi nechcete mít databázi s historií Vašeho účtu distribuovanou po náhodných nodech po světě... případně se kouknout jen na půlku filmu na Netflixu protože se zrovna odpojil nějaký node který má druhou. A to nemluvě o lékařských záznamech (ano v aws jsou i některé nemocnice) ;-)
20. 10. 2025, 19:06 editováno autorem komentáře
Ono by v podstatě mělo platit kritérium: co potřebuješ nejvíc, měj nejblíž
. Firma (nemocnice...) by prostě neměla být závislá na tom, jestli funguje jeden (jediný) externí dodavatel.
Jenže pak se udělá výběrové řízení, a vybere se řešení od té firmy, která to slíbí podle zadání za nejnižší cenu. S výsledkem, že je to buď na podstřelené interní infrastruktuře nebo v tom nejlevnějším cloudu.
Tak o torrentu se nebudeme bavit, sdílet autorsky chráněná díla není zrovna úplně v pohodě. Osobně by mě zajímalo (kdyby se přešlo na "legální" torrenty), kdo těm lidem co sdílí bude platit za konektivitu a data (space) která poskytli? Dejme tomu onen Netflix, platíte autory, kameramany ... a z druhé strany IT, konektivitu, space na úložišti atd. Krom toho by to úplně nefungovalo, protože osobně např. Netflix používám na televizi. Momentálně tam mám volno tak 1GB navíc bych asi nechtěl aby mi televize odesílala kvanta dat do internetu.
Ve finále to AWSko má taky nody takže když spadne jeden server, tahá data z jiného. Myslím si že legální torrenty by opravdu nebyly řešení (stačí se podívat kolik lidí brbralo na windows update delivery optimalization, osobně nevidím důvod proč by společnost které platím peníze měla ještě využívat zdarma můj uplink)
"případně se kouknout jen na půlku filmu na Netflixu protože se zrovna odpojil nějaký node"
Ty asi moc nevis o tom jak fungujou distribuovany systemy ze? Vis, rika se temu matematika, v tomhle pripade pravdepodobnost. A libovolny obsah je v takovy siti zmutiplikovan prave tak, aby pravdepodobnost, ze nebude dostupny byla miziva.
Slovo "mizivá" bych nahratil "škoda vzniklá možnou nedostupností byla nižší, než náklady na další zvýšení dostupnosti", což v naprosté většině případů má do epsilonu opravdu daleko ;-).
Matematika mě zajímá dlouho, a slova jako "mizivá" tam opravdu nepatří (přestože používá exaktně definované termíny jako "continuous almost everywhere").
Vlastní infrastruktura je často interně příšerně drahá: aby se omezilo plýtvání zdroji, účtuje si firma za servery nesmyslné částky (z kapsy do kapsy
, takže reálně to nebolí), což naopak vede k tomu, že se často zvolí levnější externí řešení (které se už ovšem platit musí).
Jakmile je jednou část infrastruktury hostovaná venku, nastává problém, že sice může být celé řešení HA, ale nakonec k němu vede (obrazně!) jen jeden kabel
, takže nemusí být dostupné (a napojené na ostatní části).
Kupříkladu po převodu e-mailů z (interního) Exchange/Outlook serveru na O365 se typicky zhorší rychlost doručování a přibyde reportovaných výpadků, protože na interním serveru bylo nastavení podle potřeb firmy
, zatímco externí řešení využívá nastavení podle šablon
; a menší problémy se daří doma řešit rychleji, než stihne Microsoft reagovat na zadání ticketu, případně rychleji, než někdo ten ticket vůbec zadá (vyřešeno na první zavolání
).
(Stručné shrnutí analýzy převodu služeb z interních serverů do cloudu: Bude to umět půlku věcí, stát dvojnásobek - ale konkurence to už má dávno!
)
No, to je napad za vsechny prachy a nevim jestli jste si toho vedom. Ale mit vlastni data centrum stoji hodne penez, ok asi mene nez si ho hostovat. Jenze v cem je problem? Lidi, za prve v cr nemame dostatek odbor iku, kteri to.u rozumi a tudiz jsou schopni to delat na urovni 'AWS' a za dalsi, pikud by tady uz takovych odborniku bylo, tak by je nikdo nezaplatil. Je potreba mit treba 2 - 3 a kazdy za 200 cisteho a k nim dalsich treba 6 lidi za mi imalne 80 cisteho. To jste kolem 1.5M v hrubem jen za lidi. Jakmile date min penez, lidi nevydrzi, budou se to it, kvalita bude kolisat. Jakmile bude mene lidi, za nete ty stavajici zdimat, zakazovat dovolene a dlouhodobe se to neudrzi, bud budou chtit vice penez a nebo opet odejdou.
Takze jednodussi je zaplatit mega mesicne AWS a at si lidi a tyhle starosti resi ona, navic vam to jde z jineho baliku penez, ktery obvykle je stedrejsi, nez ten na vyplaty delniku.
Jeden pripad za vsechny, nejmenovana K banka nechala odejit ajtaky, protoze dat jim 80tis hrubeho jim prislo moc, dopadlo to tak, ze jim bankovnctvi neustale padalo, do toho si vymysleli migraci na novou verzi, ktera totalne nefungovala... Hlavne ze maj novacky za 60 taliru a platej externi firmu na odborniky.
Pokud to je ta banka, co myslím, tak jim to reálně a stoprocentně stále nefunguje. ;-D
Tohle je problém všech non-IT
firem: celá IT infrastruktura, od hardware po lidi, jsou jen náklady
. Pak máte na jedné straně pracovníky (telefonní/on-line) podpory klientů, skladníky, a různé odborné kancelářské síly, které pracují za minimální mzdu, a vedle toho přeplacené ajťáky s platem 80 tisíc hrubého, kteří neustále zcela neloajálně pokukují po lépe placené práci jinde.
Je jasné, že když (tak či onak) o IT infrastruktuře rozhodují obchodníci a manageři, mají priority nastavené na koruny
a radši objednají řešení od externí firmy, která jim slíbí 90 % toho, o čem si myslí, že to potřebují.