Vlákno názorů k článku Odpovědi na nejčastější dotazy k našemu odchodu z předraženého cloudu od Martin Koníček - V cloudu jsem tedy spravoval mnohem větší účet...
-
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.
-
Adam KaliszStříbrný podporovatelNo, 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.
-
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.
-
nargStříbrný podporovatelVe skutečnosti většině klientům by stačilo staré řešení na PHP & Mysql & Linux / LAMP
A pro to přesně chcete vyvíjet, aneb vracíme se 10 let zpět ;-)... Každý vývojář bude mít na lokále LAMP, sem-tam nějaká jiná verze PHPka. Jeden vývojář raději nginx, druhý apache -- tak proč si to nedat na lokál. Je úplně jedno že se to chová jinak. Aplikace nepůjdou řádně otestovat, protože nebude existovat image s produkčním kódem a produkčními komponenty... Druhou nečastější větou když to spadne (až na produkci) bude: "Ale mě to na lokále fungovalo". Jsem rád že tyhle doby mutable LAMPů, WAMPů a podobných blbostí máme za sebou a uchytili se immutable kontejnery které fungují všude "stejně", takže vývojář/tester může otestovat a garantovat správnou funkčnost aplikace. -
nargStříbrný podporovatel
Nicméně ten samý problém Vám vzniká i mimo kontejnery. Nebo si myslíte že když na VMku upgradujete PHPko tak Vám všechno magic bude fungovat? Mnohem větší pravděpodobnost je že se Vám všechno sesype. V takovou chvíli bude muset přijít developer a opravit to.
-
My se ve skutečnosti nákladovostí v IT moc nezabýváme, všechno by mělo nějaké řešení, mohli bysme updatovat jen to nejnutnější security patchema, spousta systémů ve velkých firmách ani moc změny nepotřebuje, stačí když to poběží 10 let, třeba banka vydá nějaký produkt - hypotéku, 3 roky jí bude nabízet, a pak bude potřebovat, aby to 30 let běželo a bralo peníze, dnes není jiné řešení než mainframe a obstarožní software, bance nepřinese žádnou výhodu za 10 let aktualizace produktu na hypotéku, co se už nenabízí.
Jenomže to nikoho z nás nezajímá, protože v tom není byznys, nezajímá to dodavatele, nezajímá to lidi v IT, protože celý ten byznys je postavený na nových verzích, za starou funkční verzi si prostě nemůžu moc účtovat a my všichni víme, že 90% lidí by stačil Word 97.
Ne, že by to nešlo technologicky řešit, ale spíše si nikdo pod sebou nepodřeže větev.
-
Adam KaliszStříbrný podporovatel
Tak na konfigurační management ale Docker opravdu nepotřebuju. Stejně v praxi vypadá vývojové prostředí jinak, než produkční. Protože ten Docker/ Kubernetes jede na nějakém, typicky jiném železe, pod jinou zátěží, evtl. s jiným host operačním systémem. Vývojáři taky tíhnou k tomu mít v produkčním kontejneru věci, které jsou potřeba jen ve vývojovém prostředí. Většina s sebou tahá celý userspace Debianu, nebo co zrovna obsahoval základní image. Když je aplikace tlustější, tak se kolem toho stejně chodí po špičkách a běží to ve své vlastní virtuálce, protože čistě Docker není úplně dostatečné bezpečnostní rozhraní tak, jak bychom si ho přáli.
Pokud někdo žije v nepořádku, bude mít nepořádek nezávisle na technologii, jen to někde bude mít více vrstev, které nemají přidanou hodnotu.
Zrovna nedávno jsem dělal poradenství ve firmě, kde programátoři mají zcela nekoncepčně jakýsi NUC mimo virtualizační infrastrukturu, kde mají snad nějaký minimální Kubernet, možná K3S nebo tak a nějak si to lepí sami "aby to bylo". Mezitím firemní admin o tom ví jen to, že to má běžet a jakou to má IP. Místo aby si ty lidi sedli dohromady a dohodli se, že třeba potřebují nějaké kapacity a koncepční virtualizační platformu, tak se takto dodávají krabičky a hasí různé ad-hoc požáry. V Digital Oceanu to běží všechno na nějakém managed Kubernetes clusteru, takže ten NUC je opravdu velká aproximace.
-
nargStříbrný podporovatel
Tak na konfigurační management ale Docker opravdu nepotřebuju.
Vy ne, nicméně developerovi budete těžko spravovat notebook nějakým firemním konfiguračním managmentem aby měl stejné verze balíků jako jsou na PRODukci
Protože ten Docker/ Kubernetes jede na nějakém, typicky jiném železe, pod jinou zátěží,
Jede, nicméně se Vám pod rukama nemění závislosti které potřebuje aplikace a jako developer dokážete garantovat že ten image který jste dodal bude běžet stejně jako na lokále (nebo na CIčku). Jestli pak bude problém zátež je věc jiná, od toho Vás kontejnerizace neodstíní a jako developer s tím budete muset počítat. A jestli bude problém hostitelský operační sysstém, protože třeba admin neumí nastavit síť, to už tak úplně není problém developera
Vývojáři taky tíhnou k tomu mít v produkčním kontejneru věci, které jsou potřeba jen ve vývojovém prostředí
V tom případě vývojáři mají blbě nastavené procesy, architekturu a neumí pravděpodobně s CI a/nebo dockeremV Digital Oceanu to běží všechno na nějakém managed Kubernetes clusteru, takže ten NUC je opravdu velká aproximace.
Furt je to mnohem lepší, než že developer píše svůj kód na svém oblíbeném Ubuntu, Nixu, Windows whatever v PHP 8.0 a apache. Otestuje to na nějakém staging prostředí na PHP 8.1 a nginxu (kde to už nemusí imho fungovat). A pak to pošle na PRODukci kde mezitím nějaký agilní admin změnil verzi PHP na 8.2 ;-) A ono to nemusí být jen PHP, může třeba vyjít aktualizace kupř. takové věci jako imagemagick nebo kterékoliv další knihovny (ideálně se tam dostane živelně přes unattended-upgrades) a celý se to rozbije ;-)
Místo aby si ty lidi sedli dohromady a dohodli se, že třeba potřebují nějaké kapacity a koncepční virtualizační platformu
Ano, to by rozhodně měli ;-) -
Adam KaliszStříbrný podporovatel
V rámci moderního DevOps nevidím důvod, proč by vývojář nemohl mít na laptopu, nebo např. ve VM na svém laptopu či jinde prostředí se stejnými verzemi. Od toho je tradičně správce balíčků, či konfigurační management, aby to zajistil. Docker je v tomto ohledu spíše módní výstřelek. Jestli někam nahrávám obraz v podstatě operačního systému bez jádra, nebo JAR nebo nějakou binárku je až na velikost skoro jedno. Všechno se to na něco spoléhá a já to musím nějak zajistit, nastavit, monitorovat, udržovat a případně debuggovat. V hodně případech mi vychází, že je tam Docker prostě navíc.
Postupně jsme dokonvergovali k tomu, že čistý vývojář a čistý admin už úplně není. Mícháme to v DevOps dohromady - tedy že vývojář zcela hodí nastavení sítě na někoho jiného už úplně nefunguje. Minimálně se spolu admin a vývojář domluví, případně výsledek domluvy rovnou zakotví v DCIM, konfiguračním managementu, DNS atd.
Poslední roky vyvíjíme software, kde vývoj běží dle potřeby nativně na Windows, Linuxu i macOS a klientská část případně ještě na Androidu/ iOS/ iPadOS. To vše především kvůli testování prohlížečů. Máme navíc samozřejmě staging, kde jsou verze všeho stejné s produkcí a celková odlišnost minimální. Build a deploy je udělaný přes GitHub Actions. Tato složitost navíc má samozřejmě i výzvy, ale člověk je zase opatrnější a trochu více modularizuje.
-
nargStříbrný podporovatel
V rámci moderního DevOps nevidím důvod, proč by vývojář nemohl mít na laptopu, nebo např. ve VM na svém laptopu či jinde prostředí se stejnými verzemi.
Koukám že máte rád vývojáře ;-). Když už tak VM. Ono pokud máte víc projektů nebo fungujete např. na mikroservisách tak každý projekt/mikroservisa má(může mít) jiné dependy. Mno, a mezitím co vy budete pomáhat chudákovi juniorovi instalovat 3 VMko za pomoci třeba puppetu z těch 5 co potřebuje aby mohl pustit frontend na kterém zrovna má pracovat, já budu mít za sebou jeden docker-compose up, kompletně běžící stack, 3 kafe, jednu pizzu a hotovo.
Jestli někam nahrávám obraz v podstatě operačního systému bez jádra, nebo JAR nebo nějakou binárku je až na velikost skoro jedno.
Tak zrovna o Javě se nebavíme (která se moc nespoléhá na externí knihovny) a pokud se provozuje s otestovanou verzí JRE tak je tam minimum problémů (aspoň pokud vím). Držme se něčeho víc obskurdního co mění spoustu věcí v každé verzi: třeba to PHP, nebo Cčko které spoléhá na další systémové knihovny ;-)Mícháme to v DevOps dohromady - tedy že vývojář zcela hodí nastavení sítě na někoho jiného už úplně nefunguje.
Neznám vývojáře který by se chtěl ve svém čase starat o nastavení routování, switchů a sítě. A ne každý vývojář je DevOPS. Za mě, vývojář který něco umí chce odevzdat k8s yaml s deploymentem a určitě ho nezajímá jestli se budou packety routovat přes switche ABCD nebo DCBA (a těch znám opravdu dost). Vývojář který toho moc neumí chce odevzdat kód ;-). A vývojáře který by chtěl řešit nudnosti typu proč se mi ztrácí packety při cestě do MariaDB, těch teda moc neznám...Docker je v tomto ohledu spíše módní výstřelek.
Mě naopak docker přijde jako de-facto standard v oblasti vývoje webového software. -
Adam KaliszStříbrný podporovatel
Vážím si Vašeho názoru a že se dělíte o vlastní zkušenosti.
Čistě hypoteticky, to ten docker a docker compose musí mít rozjetý a vydefinované image atd. Možná je to lehčí, než to samé řešit zrovna s Puppetem, Chefem apod. ale není to tak, že by ta práce zcela odpadla.
Mimochodem, zrovnatak jak se dá udržovat repozitář docker obrazů se dají udržovat i balíčky a celou řadu věcí vyřeší jejich instalace.Všechny ty věci, které píšete někdo i v tom Dockeru musí rozchodit a je to klasická administrátořina/ DevOpsárna. A příčetný člověk, který slyšel někdy něco o bezpečnosti tam asi nedá kompilátory a binárky s debug symbolama apod. takže pro vývoj ten obraz vlastně vypadá jinak a vývojář nemůže do produkce prostě poslat to, co vyvíjel, ale musí to minimálně projít přes staging, kde už ta podobnost či v ideálním případě identita s produkcí snad bude.
Nakonec ale narazíte na to, že nezávisle na tom, jestli použijete Puppet nebo Docker je spousta dalších věcí, které doopravdy otestujete jen v produkci. Třeba specifické chování, když jede pod tlakem garbage collector přesně v momentě, kdy Vaši VM pozastaví a live-zmigrují na jiný stroj. Samozřejmě, že packet loss/ občasně vysoká latence mezi aplikačním serverem a databází je něco, co poměrně spolehlivě zabije výkon. A může to klidně být proto, že někde něco zahazuje buffery v hardwaru síťových prvků po cestě. Prostě taková věc o které běžný vývojář nemá ani páru, ale hlavně že mu někdo nakukal, že když něco napíše jako Infrastructure as Code, že se těmto věcem nějak magicky nadobro vyhne. Možná je to nebaví, ale to neznamená, že to neexistuje. Na debugging těchto věcí jen spouštění a restartování kontejnerů stačit nebude.
Přesně z těch důvodů je posun směrem k DevOps docela fajn věc, více lidí chápe, že za svoje výtvory do určité míry ručí od začátku do konce a že se dějou nepředvídatelné věci, i když používáte Docker. Jsem si jistý, že tomu pochopení a větší provázanosti mezi vývojáři a adminy Docker, Kubernetes apod. pomáhá, ale opravdu je nutné mít napaměti, že na konci veškerý kód běží v cela mutabilním, extrémně stavovém prostředí, které nemůžete kompletně dohlédnout. Vývojová a testovací prostředí jsou jen model, u kterého většina z nás prostě doufá, že je dostatečně blízko produkci.
