HW nároky malých aplikací

tnr

Re:HW nároky malých aplikací
« Odpověď #75 kdy: 03. 03. 2017, 14:04:21 »
Za prvé, se musím trochu omluvit tnr, protože o tom ví víc, jak minimálně 95% dnešních "vývojářů".
Dodal bych k tomu, že základním předpokladem téměř každého vývojáře je mylný dojem, že pokud běží jedna databáze (nebo cokoliv jinýho) na více místech, bude na 100% dostupná, což bohužel neplatí.
Manager rozhodující o nákupu systému je většinou nekompetentní a rozhodne se na základě ceny, ignorujíc absolutní většinu ostatních argumentů. V případě, že se to potom celý rozsype, tak brečí, že se k ničemu několik dní nedostane, protože se obnovuje 50TB databáze. To je přesně ten moment, kdy je typickej vývojář v řiti jak Baťa s dřevákama, není schopnej poskytnout jakoukoliv podporu a manager chystá výpovědi smluv, matně si začíná vzpomínat, že ho někdo varoval a začíná řešit, jak to napravit. Po incidentu se udělají analýzy, který se velmi pečlivě zlikvidují, zůstane se u starého řešení, protože kdyby se dostalo na vyšší místa, že celej systém stojí za starou bačkoru a bylo by potřeba začít znovu, jelikož je vše špatně už od návrhu, tak by to managora stálo teplý místo.

Proc je to mylny predpoklad ? Vysoce dostupnou DB zajistit lze, na SQL i NoSQL databazich. 100% samozrejme ne, ale velmi tomu se blizici se samozrejme ano. Od toho mame prave ruzne replikace, log shippingy, clustering, atd. Ze si to nekdo blbe rozhodne je samozrejme vec jina, my na to nase zakazniky bezne upozornujeme, nekdo to chce, nekdo si rekne, ze se mu HA reseni nevyplati (naklady > skoda pri vypadku - coz je samozrejme zcela OK rozhodnuti z pohledu firmy). Samozrejme to neco stoji, melo by se s tim idealne pocitat uz od zacatku vyvoje SW (ale pokud se rozhodneme jen pro hot standby reseni, tak to neni nezbytne problem, pokud se s tim na zacatku nepocitalo).

Ale souhlas s tim, ze rozhodovani podle ceny, je neskutecny mor. Ale to neni nic specifickeho pro vyvojare, managery, adminy, tenhle mor je trochu v cele spolecnosti - uplne stejne kroutim hlavou nad tim, ze si nekdo koupi parodii na maslo ci sunku v Tescu, protoze "to bylo tak levny, no nekup to voe", jako kdyz podobne vystrelky dela C level v korporaci pri nakupu HW/SW/vyvoji. Ale je to kazdeho vec, urcite bych to negeneralizoval.


Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:HW nároky malých aplikací
« Odpověď #76 kdy: 03. 03. 2017, 15:58:14 »
Paradoxně nejvíc problémů v HA prostředí způsobuje HA prostředí, nicméně většina se nedotkne uživatelů a tak to má být. Ale když to pak přijde doopravdy, je potřeba s tím počítat.

Kit

Re:HW nároky malých aplikací
« Odpověď #77 kdy: 03. 03. 2017, 16:59:16 »
Ale nepouzivat moderni frameworky, high level jazyky (Java, C#, Python, ....), to uz spada pouze do kategorie nesmyslne optimalizace pro drtivou vetsinu aplikaci, jelikoz by z toho plynulo oprovske navyseni pracnosti.

GC opravdu z Javy či C# high level jazyk neudělá...

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:HW nároky malých aplikací
« Odpověď #78 kdy: 03. 03. 2017, 17:05:55 »
Ale nepouzivat moderni frameworky, high level jazyky (Java, C#, Python, ....), to uz spada pouze do kategorie nesmyslne optimalizace pro drtivou vetsinu aplikaci, jelikoz by z toho plynulo oprovske navyseni pracnosti.

GC opravdu z Javy či C# high level jazyk neudělá...
GC dělá tak akorát z patlalů mistry a z mistrů patlaly :D Kdo si nedokáže ohlídat ani vlastní bordel, ten asi jen s těží vytvoří něco kvalitního.

tnr

Re:HW nároky malých aplikací
« Odpověď #79 kdy: 04. 03. 2017, 04:56:26 »
GC opravdu z Javy či C# high level jazyk neudělá...
Kde v mem prispevku vidis formulaci, ze HLL z Javy ci C# dela GC ?:-D

GC dělá tak akorát z patlalů mistry a z mistrů patlaly :D Kdo si nedokáže ohlídat ani vlastní bordel, ten asi jen s těží vytvoří něco kvalitního.
Jasne. A poradny ridic nepotrebuje automatickou prevodovku (proto ji kazdy lepsi sportak spolu s launch control :-d). A skutecni programatori nepouzivaji fortrtan. a 640 kB pameti musi stacit kazdemu :-D wait a moment...

Hele nevim, kolik si toho naprogramoval uz za zivot, ale tenhle nazor povetsinou slysim od lidi, co o tvorbe SW maji predstavu asi jako ja o stavbe jaderne elektrarny (je tam nejaky reaktor, okruh, to prece nemuze byt tak slozity :-D). Je to pitomost. Ja dodnes porad programuji v C/C++ nejaky high performance kod a u komplexnich systemu stejne vetsinou skoncil u toho, ze nejakou primitivni formu automaticke spravy pameti jsem si naimplementoval musel (jednoduse z toho duvodu, ze ty data se musi sdilet, casto mezi X vlakny a kdy se maji uvolnit nejde uplne rict staticky). Stejne tak nemam pocit, ze moji praci v Haskellu a LISP, ktere pouzivame na nejake research projekty, snizuje fakt, ze se tam pouziva GC :-D

GC je proste nastroj. Usetri spoustu prace, zabrani spouste chyb, za cenu drobne CPU latence a lehce zvysene pametove narocnosti, coz je vec, ktera v 99.9% pripadu nevadi (resp. je opodstatna temi vyhodami). A fakt me netrapi, jestli treba konkretne jeden system, ktery jsem delal, ktery pracuje nad 60 TB Oracle databazi, pouziva 30 GB RAM misto 29 GB (kdyby nemel GC) a netrapi to ani zakaznika :)