"The sad state of web app deployment"

Tudom, old meg minden, de nagyjából jól összefoglalja, hogy tulajdonképp mekkora önszopatás az egész Linuxos ökoszisztéma egy webapp esetén:

http://eev.ee/blog/2015/09/17/the-sad-state-of-web-app-deployment/

(Megjegyzés: fingom nincs, hogy ASP.NET esetén mi a helyzet, nem is érdekel jelenleg.)

( Soultrane | 2015. 09. 27., v – 22:56 )

A tag az önszopatás, nem a Linux :/

> See, I actually have a 64-bit kernel, but a 32-bit userspace

De azért a docker kurva anyját mert nem működik out of the box a (szarul) széthakkolt rendszerén.

Állítása szerint 15 éve van a szakmában, szimplán inkompetens ami az új technológiák hibája ofc.

( kmARC v | 2015. 09. 27., v – 23:29 )

Gondolom a Fortune500 is épp önszopatja magát, és a microservicekre épülő és ezáltal skálázódni tudó mindenkit legyakó startupok (hint: netflix, spotify, de érzésem szerint lassan bármelyik nagyranőttet ide lehet írni), miközben hatalmas prémiumokat kapnak az épp önszopó developerek.

Ez a cikk eléggé mellément. Azért nem kell minden besavanyodott bloggernek sem hinni, aki képtelen találni maga körül valami cloud megoldást, hogy ne kelljen 32-64 bitet keverni, vagy egy nyamvadt dockert fel tudjon szenvedni magának. Nem tökéletes ez még, nincs itt a kánaán, viszont ő ahelyett, hogy ezt objektívan összefoglalná, a saját tudatlanságából kifolyológag csak picsogni tud.

Ha egy tanácsom lehet, ez alapján ne tájékozódj. Olvass el inkább egy normális könyvet a témában, és szűrd meg a blogoszféra okádmányait.

olvasd tovább, van ott még bőven, nem csak a dockerről, meg a 32-64 bit keveréséről (miért kellene ennek egyébként problémának lennie? Windowson az userlandom fele 32 bites, mégsincs ebből problémám) van szó, hanem leginkább arról, hogy nincs egy szabványos út arra, hogy egy webalkalmazást te egyszerűen deployolhass egy meglévő infrastruktúrába, hacsak dockerrel nem szállítasz egy kvázi önálló rendszert.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem tudom továbbolvasni. Ez színtiszta rinyálás.

Desktop appot egyszerűbb terjeszteni? Embedded eszközökre jobb toolchain van? Fenéket. Fel lehet ezt úgy is fogni ahogy az illető teszi, vagy lehet alkalmazkodni, és inkább örülni annak, hogy egyáltalán van bármilyen tool, ami megkönnyíti az életét. Igen, én is nvm-mel, npm-mel, bowerrel, és aztán a mindezek segítségével feltelepített csomagokkal kezdek, de most komolyan... kit érdekel? Egyszer megvan, futnak a unittesztek, az autoreload és pont. Minden együttműködik. Igen, fél nap is rámegy a prototípus hellowordre, még fél nap arra, ogy dockerizáljak / heatezzek, etc., de ezek elhanyagolhatók - főleg amellet, hogy régen aztán meg ezen toolok egyike sem volt, és maga a dev time emiatt sokkal hosszabb lehetett.

Kit erdekel desktop app, nem ez a téma. Az, meg, hogy az is fos (egyebkent nem, mert altalaban egy desktop app nem hoz ennyi konfiguralando függőséget), az ne legyen mar érv. (Egyebkent de, sokkal egyszerubb, nem emlékszem, hogy pl. egy Firefox telepitesehez egy ilyen leírást kellett volna vegigolvasnom, utana szopnom azzal, hogy ilyen gem, olyan gem, majd ircrol megtudni, hogy azt igazabol ne hasznaljam, hanem emezt hasznaljam es stb.: http://www.redmine.org/projects/redmine/wiki/redmineinstall

De mindegy, ha nem olvasod vegig, akkor nehez vitázni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Dehogy nem hoz konfiguralando fuggosegeket, csak a telepitok ezt rendszerint megoldjak. De ha minden webapphoz jarna telepito (script), akkor meg azon menne a nyigas, hogy ezt meg azt a kornyezetspecifikus dolgot nem kezeli le a telepito, a fejlesztok meg azert sirnanak, mert telepitot kell irniuk. Neeeem, jo ez a rendszer ahogy van.
--
Blog | @hron84
Üzemeltető macik

"ezt meg azt a kornyezetspecifikus dolgot nem kezeli le a telepito"

Ezekre szoktak szabványokat alkotni, aztán nem mehet a rinyálás, maximum azért, hogy ha valaki nem követi.

"a fejlesztok meg azert sirnanak, mert telepitot kell irniuk"

Most meg telepítési doksit kell. Amúgy meg kit érdekel? Írjon, a függőségekre meg legyen valami autodiscover.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Microsoft WebPI? Egy kattintással tudsz setup-olni külső függőségeket IIS mellé.
Nuget? Egy kattintással tudsz fejlesztés közben library szinten becsatolni függőségeket egy projektbe.
ClickOnce? Egy kattintással tudsz hozzáadni 3rd party függőségeket desktop appokhoz, amit telepítéskor letölt, ha hiányozna.

Mire gondolsz pontosan, mi hiányzik?

Otletem sincs, mit ertett a kollega a kifejezes alatt, olyat mar lattam, hogy egy C vagy Perl program "kemeny" fuggosegeit a csomaggeneralo script felderitette (a hasznalt osztott konyvtarakat/beimportalt modulokat elokereste a csomagadatbazisbol), ha ezt ertjuk autodiscover alatt, akkor igen, statikus (kod)elemzessel elerheto egy ilyen lehetoseg, azzal a kitetellel, hogy ebben 100%-ig megbizni nem szabad.
--
Blog | @hron84
Üzemeltető macik

Ennél azért tovább lehetne menni, pl. kell db a szoftverednek? Itt a lista, ezek vannak a gépen/clusterben/"tartományban"/whatever, válassz. Kell logger? Itt vannak. Kell SMTP, ha szerinted ez jó, nyomj entert, stb. Nem kézzel pöcsölni minden egyes esetben.

MSSQL-nél már láttam hasonlót AD-ben múltkor valami fotós bizbasznál, amikor a program telepítésekor a telepítő megkérdezte, hogy hogy a helyi MSSQL Express-t vagy a Foo gépen lévő rendest használja.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Itt a lista, ezek vannak a gépen/clusterben/"tartományban"/whatever, válassz."

Mintha a DB engine-k kompatibilisek lennenek egymassal... Tenyleg, hallod neha magadat, miket mondasz?

Ami az MSSQL-es peldat illeti, nekem van olyan kornyezetem, ahol az MSSQL autodiscovery olyan, mint az esti mese, hol megy, hol nem, es igazabol meg csak nem is gepfuggo a dolog. En erre inkabb nem biznek egy ~automata deployment folyamatot.
--
Blog | @hron84
Üzemeltető macik

> Mintha a DB engine-k kompatibilisek lennenek egymassal... Tenyleg, hallod neha magadat, miket mondasz?

Nem biztos, lehet, hogy csak látott már absztrakciós réteget. :)

A lafisoftos threadben éppen azon megy az ekézés, hogy a kernel API miért változik, és ez hogy érinti a desktop programokat. Közel sem biztos, hogy optimális megoldás, de pl. egy Entity Framework mögött elég jól cserélhető a DB engine.

Egyébként valószínűleg saxus nem úgy értette, hogy _minden_ létező DB engine-re fel legyen készítve az app, de mondjuk egy lokális MSSQL CE és egy online MSSQL instance között nincs olyan óriási különbség, akár lehetne mindkettőt is támogatni minimális befektetéssel.

Offtopic: MSSQL CE gyakorlatilag ki van vezetve amennyire nekem tűnt. Helyette van az MSSQL localDB, ami gyakorlatilag egy teljes értékű MSSQL Express, csak nem serviceként, hanem eseti igénnyel indítva per-user és per-app szinten tárolva az adatait. (Ami egyébként minden további nélkül - lévén, hogy teljes értékű MSSQL - oda-vissza mozgatható a "rendes" Express és a korlátozásoktól mentes verzió között.

Épp csak a pehelysúlyúsága nincs meg.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azért láttunk már olyat, hogy egy alkalmazás megy több RDBMS-sel is. De most ez hogy jön ide? Azt mondtam, hogy legyen már autodiscoverelhető a neki szükséges szolgáltatások. Ha a programnak PostgreSQL, MongoDB és valami syslog kell, akkor ne MySQL-t, HBase-t meg Windows Event Loggert dobjon már fel.

Egyáltalán honnan jött ez az ötleted?

(Azért, hogy valami trollkodás is legyen: http://andreas.scherbaum.la/blog/archives/657-PostgreSQL-9.0-Includes-t… )

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Jelen pillanatban senki nem dob fel semmit, a fuggosegek pedig specifikalhatoak. Szabvany nincs ra - pont, ahogy az SQL engine-kre sincs szabvany (az csak az SQL nyelvre van). Lattunk mar olyat is, hogy egy alkalmazas tobbfele deployment folyamatot is tamogatott, de nem ertem, az miert jonne ide.
--
Blog | @hron84
Üzemeltető macik

Hát az a helyzet, hogy a fejlesztő mindenképpen rendelkezik a függőségéről. import, #include, etc. szóval ennyi erővel akár lehetne is ilyen tool... Csak pont emiatt nem is lenne értelme. _mivel_ rendelkezik a függőségeiről a forrásfájlban, így azokat valószínűleg összegyűjti amikor fel is telepíti ezeket a függőségeket. Ezt emeli egész használható szintre az npm --save (és --save-dev) kapcsolója, de gondolom minden máshoz is van ilyen.

Na ez az, inkább a fejlesztő rendelkezzen a függőségekről.

Még ha technikailag össze is lehet hozni egy teljesen automata megoldást, nem mernék rábízni production környezetet. Tegyük fel, hogy az include-ok alapján be is lőné, hogy milyen library-kre van szükség, a pontos verziót már nehéz megcélozni. A fejlesztő inkább tesztelje le egy adott környezetben a cuccot, és vagy oldja meg, hogy ez telepítéskor létrejöjjön, vagy írja le, és bízza az üzemeltetőre. De azon ne csússzon el, hogy egy script PHP 5.4-ben működik, 5.5-ben már nem.

Hogy a fenti kollega stilusaban valaszoljak:

RPM Specfile/DEB csomagleiro? Python PIP requirements.txt? Ruby Gemspec? A Perl-nek is biztos van valami. Van egy csomo megoldas Linuxra is, pont ugyanolyan jol hasznalhatoak, mint a Windowsosok, csak aldozni kellene legalabb annyi idot a dolgok felderitesere, mint Visual Studio eseteben, ennyi. Sajnalom, de a fejlesztok helyett nem tudom elvegezni a hazi feladatot.
--
Blog | @hron84
Üzemeltető macik

Nem értelek. Ha hosting szolgáltató vagyok, akkor nem fogom az ügyfeleket egy gépre tenni, hogy gondot okozzanak a függőségek, neadjisten, verziókonfliktok.

Szóval valamit biztos félreértek, de nem látom itt a problémát. Ha hosting szolgáltató vagyok, akkor is az ügyfeleim a maguk által megadott dependency listát fogják maguknak telepíteni, leginkább külön gépekbe.

Szerk.: Közben lehet, hogy mégis megértettem

"Ha hosting szolgáltató vagyok, akkor nem fogom az ügyfeleket egy gépre tenni, hogy gondot okozzanak a függőségek, neadjisten, verziókonfliktok."

Ez azert nem ilyen egyszeru. Kezdjuk ott, hogy attol fugg, milyen hosting szolgaltato vagy, webhostingnal simal elofordulhat, de erre is van megoldas, PHP eseteben a composer (PHP verziokra a suPHP/PHP-FPM), Ruby eseteben a Bundler (Ruby verziokra az RVM/rbenv) ad megoldast, es majd minden komolyabb webszerver eseteben megoldhato a felhasznalonkenti szeparacio, sot, akar a chroot is.

De termeszetesen el lehet indulni az altalad korvonalazott iranyban is, minden attol fugg, mik az igenyek, amiket szolgaltatokent ki akarsz szolgalni.
--
Blog | @hron84
Üzemeltető macik

ha hosting szolgaltato vagy, akkor keszitesz egy jol definialt kornyezetet, amit faszan supportalni tudsz, es minden mas igenyt lepattintasz. Ha tul sok pattan le, akkor atgondoljuk, hogy van-e uzleti szempontbol ertelme a leggyakoribb/legzsirosabb lepattanokat is tamogatni - nyilvan kulon kornyzetben, ahol nem akadnak ossze massal...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Érdekes, hogy szétszapulod itt a linuxos webapp ökoszisztémát. Az még érdekesebb, hogy valami bugyuta bloggertől mindezt.

Az érvelésről meg annyit, hogy egyrészt többen is leírtuk, hogy nem annyira sötét a helyzet, mint ez a csóka maga. Elismerem én is, hogy nem optimális a helyzet, de messze van attól, amit ő hisztizik.
- Egyrészt igenis vannak egész jó toolok
- A linuxot emeled ki, mint a "sad state" egy okozójaként
- Elmondjuk, hogy ahhoz képest a világ 90%-ra mégis linuxra deployol
- Azt is elmondjuk, hogy sem más platfromokon (pl. Windows)
- Sem más szcenáriókban (pl. desktop app) nem jobb a helyzet.

> Kit erdekel desktop app, nem ez a téma
Igenis, az a téma, hogy egy adott technológiai stack milyen fosadék. Nem, nem fosadék, leginkább onnan tudod, hogy nem fosadék, hogy összeveted más toolchainekkel is. Ha "kitérdekelmás,nemazatéma" a hozzáállásod, az régen rossz. Amiatt van fejlődés, hogy a kapcsoló területektől is tanulunk.

Persze, hogy azt szapulom, mert azzal van dolgom, ergo az érint.

Saját webes rendszereinken meg látom, hogy szívás deployolni. Végigszívtam már 1-2 redmine telepítést, mindig volt valami baszakodás a gemekkel vagy azzal, hogy ennek ez vagy annak az a verzió kell. Függőségek dettó. Itt konfigurálni, ott konfigurálni, amott konfigurálni, semmire nincs egységes megoldás, stb. stb. stb. stb. Nem sokkal jobb a helyzet egy komplexebb PHP-s rendszer esetén sem, ahol sok-sok pontos leírásokat kell követni, ahelyett, hogy lehetne egyszerűen deployolni egy _meglévő_ infrastruktúrába.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Olyan embereket kellene felvenni, akik ertik is azt, amit a kezukbe adsz, es nem csak random emberekre kellene ralocsolni random dolgokat.

Mindettol fuggetlenul a Redmine deploymentje tenyleg szar - mert szarul van osszerakva. A legjobb deployment rendszer se tud az emberi hulyeseggel mit kezdeni.

A PHP-s rendszerekre van egyszeru deployment tool, csak a webpistikek nem ismerik, mert szamukra meg az OOP se tobb egy karomkodasnal, de ha valaki venne a faradsagot, es utananezne mondjuk a Composernek, vagy a Phing-nek, akkor azt latna, hogy olyan high-quality toolok erhetoek el ehhez az okoszisztemahoz is, mint az osszes tobbihez. Csak eppen meg kell csinalni a telepitest leiro fajlt (ami egy tetves JSON/XML, semmi specialis).
--
Blog | @hron84
Üzemeltető macik

( BaT | 2015. 09. 28., h – 01:13 )

Múlt héten fejlesztéshez lőttem be egy webes projectet a munkahelyi környezetemen, kb. ugyanez a szívás. A readme hiányos, egy (bash) script végzi el a munka nagy részét ami persze semmilyen hibakezelést nem végez, vagyis a lehaló lépésekből kell kitalálni, hogy mit kellett volna még elvégezni a script futtatása előtt. "Csak" négy software repositoryból telepít csomagokat (nuget lehetne az ötödik, ha ez így segít kitalálni melyik az első négy :)), és bár elvileg multiplatform eszközökről van szó, szinte kizártnak tartom, hogy egy nem unix-like rendszeren ugyanennyi munkával működésre lehetne bírni.

( sj | 2015. 09. 28., h – 09:40 )

ez mintha 2 evvel ezelotti cikk lenne. Csak par szosszenet:

Some digging revealed that Docker just doesn’t exist for 32-bit

./docker-latest -v
Docker version 1.8.1, build d12ea79

Ez amugy egy 1,5 honapos 32-bites binaris a gepemen, ami a fooldalrol kb. 2 kattintas utan letoltheto.

they just don’t bother mentioning this in their README or installation docs or shell script that runs as root.

azert nobody-kent csak nem kene telepiteni, nem?

After a git clone (because the app isn’t in rubygems??), I then spent maybe six hours fighting with RVM.

huzd ala a helyes valaszt!

a) szar a ruby-s alkalmazas
b) szar az rvm
c) emberunk bena

I actually have a 64-bit kernel, but a 32-bit userspace. (There’s a perfectly good reason for this.)

kivancsi vagyok, mi az? Egyebkent erthetetlen, hogy ha ennyire nem all neki kezre a docker, akkor miert nem huz fel egy 32-bites vm-et, amiben nem kell a 32/64 bites elteresekkel szenvedni? A masik dolog, hogy miert kell neki pont egy ruby-s web forum, amikor 2 millio masik (php/perl/...) van, ahol kicsomagolod, csinalsz neki egy adatbazist, letrehozod a tablakat, es fut, szalad? A 'What horror have we created' resz is megerositi azt, hogy rossz web forum implementaciot valasztott. Az valo igaz, hogy atlagbelanak nem git clone-nal kene leszedni a cuccot, bar emberunk felkeszultsegere utalhat az, hogy 30 pixellel lentebb van a gomb, hogy toltsd le zip-ben.

Rails is one of the most popular web frameworks in the world,

ezzel vitatokoznek. Nekem pl. eszembe nem jutott volna a piler gui-jat ruby-ban irni.

You want your app to start automatically, of course. You can add it to your crontab with @reboot, [...]

uhh...

Even RVM, which is designed for having multiple per-user Ruby installations, prompted me for my password so it could sudo apt-get install something.

lol

but I’m a developer,

ja, hat itt kezdodnek a gondok...

If I write a Python library that wraps a C library, there is no way to express that dependency. How would I? There’s no canonical repository of C/C++ packages, anywhere. Even if I could, what good would it do? Installing a shared C library locally is a gigantic pain in the ass, involving LD_LIBRARY_PATH

en ugy csinalnam, hogy nem a $HOME ala tennem, hanem az /usr/local hierarchia ala, ahova valo, majd csinalnek belole egy csomagot. De eselyes, hogy van olyan Linux disztro, amiben letezik ez a csomag. Egyebkent pont itt jonne elo a docker elonye, hogy a tisztelt developer minden fuggoseget belepakol a kontenerbe.

If you’re missing a service the app needs but failed to document, or you set it up wrong

ez az alkalmazas hibaja

I have over two thousand unread crash emails for my perfectly functional modest-traffic website

ehh, developer mentalitas: ha 2x elhasal, de minden 3. kerest mar ki tudja szolgalni, akkor az jo. Ertem.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"You want your app to start automatically, of course. You can add it to your crontab with @reboot, [...]"

Emberunk harminc evvel van lemaradva a vilagtol, legalabb. Monit, Runit, Upstart, Systemd, csak hogy a nepszerubb megoldasokat soroljam, nyelvfuggetlenul. De rubyra van ennel specifikusabbis, Foreman, Jungler, sot, a Thin-nek is van sajat cluster-inditoja.

"If I write a Python library that wraps a C library, there is no way to express that dependency."

Csinalj belole RPM csomagot, az majdnem mindenutt szol, ahol nem, ott aliennel majd csinalnak belole DEB-et.

"I have over two thousand unread crash emails for my perfectly functional modest-traffic website"

You holding it wrong. Tenyleg. Ez az ember meri magat fejlesztonek nevezni? Egy vicc.

"I installed postgresql-contrib, and then some funny things happened. Long story short, I was running Postgres 9.1, and the current Ubuntu version is 9.3"

Miert, o, mondd, miert? Az "apt-get install postgresql" hatasara feltelepulo postgres 9.3 mi a retkes francert nem jo neked? MINDEN psql install tutorial ezt hasznalja, MINDEGYIK. De neki okosabbnak kellett lennie a Deakne vasznanal. /o\

Kulon kerdes, hogy ha Ubuntuval van gondja, miert keveri ide az Arch-ot. Kicsit emlekeztet egy ismerosom baratnojere, aki segitseget kert, hogy neki Linuxon Google Chrome van, aztan mikor nagy nehezen kuldott screenshotot, kiderult, hogy Macen van Firefoxa. Majdnem ugyanaz a ketto, nem?
--
Blog | @hron84
Üzemeltető macik

> > Some digging revealed that Docker just doesn’t exist for 32-bit
> ./docker-latest -v
> Docker version 1.8.1, build d12ea79
Ez nem bizonyít semmit. AFAIK tényleg nincs 32 bites verzió belőle, pedig sokan szeretnék

> > Rails is one of the most popular web frameworks in the world,
>ezzel vitatokoznek. Nekem pl. eszembe nem jutott volna a piler gui-jat ruby-ban irni.
Érvelési hiba. Attól, hogy neked nem jut eszedbe, még lehet a legnépszerűbb. Inkább úgy fogalmaztam volna, hogy az egyik legnépszerűbb. BTW. nekem sem jutna eszembe hozzányúlni.

> > I have over two thousand unread crash emails for my perfectly functional modest-traffic website
No comment...

Tökéletesen látszik, milyen szinten mozog ez az illető. Még rosszabb az, hogy saxus bedől neki.

( carlcolt | 2015. 09. 28., h – 14:31 )

A Linux a legkisebb baj webfejleszteskor, van egy sokkal nagyobb:

Az, hogy a programozok egy sikeres szintaxisu join-os update utan azt hiszik, hogy ertenek az adatbazisokhoz, holott kozben kurvara de nem. Sokadik megrendelonel szopok azzal, hogy meg tranzakciot se latott a CTO peldaul. Nem hogy function/stored procedure-rol hallott volna olyan esetben, ahol 4-5 tablat konzisztencia miatt csak egyszerre illene modositani. Ezt konkretan mar erteni se szoktak. Regen nem ertettem hogy a jo Postgres helyett miert valaszt 90% fos MySql-t. Mara sajnos megertettem: "mert ehhez 'ertunk'". Kb annyira is

Off, ha már postgres-mysql: ma találtam egy olyan érvet, ami számomra -sajnos- egyelőre kizárja a postgres-t:
- https://wiki.postgresql.org/wiki/FAQ#How_does_PostgreSQL_use_CPU_resour…
- https://dev.mysql.com/doc/refman/5.5/en/faqs-general.html#qandaitem-A-1…

De azért jobban bele fogom ásni magam, mert vérzik a szívem a postgresért.
(A lényeg: nekem egy szoftver csinál rusnya hosszú query-ket, de egyszerre csak egy fut -> hasznos lenne, ha párhuzamosan tudná csinálni). Mondjuk én aztán végképp nem vagyok DB-guru...

Szerintem gyakorlatilag az összes SQL adatbázis sorban futtatja a query-ket egy sessionon belül (legalábbis alapértelmezetten), ennek nincs köze a fent idézett doksikhoz.

Párhuzamos query futtatáshoz párhuzamos session-ök kellenek, vagy specifikus támogatás a DB részéről.

Szerintem nem érted. Egy darab query futtatását szeretném több core-on végezni, nincs párhuzamosan több user, több hozzáférő, stb. Mert elvileg lehetne. Pl. valamelyik mező paritása szerint szétdobja külön core-ra vagy whatever. Lényeg: összetettebb query-t szeretném, ha gyorsítana. Valamikor ezer éve analizálgattuk az adott query-t itt a HUP-on, emlékeim szerint nem nagyon lehetett vele mit csinálni (jópofa többszörös join pár tízmillió adaton, nem vállalati/céges használat, hanem embedded CPU trace logok elemezgetése).

Aha, így már világos, mire gondolsz. Viszont ezt a mysql sem fogja neked párhuzamosítani, threadek ide vagy oda, mert egyszerűen nincs benne ez a technológia. Az MS SQL Server és az Oracle DB pl. tud ilyet - jó pénzért.

Upd.: esetleg kipróbálhatod ezt: https://mariadb.com/kb/en/mariadb/shard-query/

Várjál, ennek semmi köze egymáshoz. Ez az, hogy a MySQL egy worker threadet indít egy feladathoz, míg a PostgreSQL egy worker process-t indít egy connectionhoz. Utóbbi előnye a nagyobb izoláció, pl. egy megszaladt workert szinte minden további nélkül ki lehet gyilkolni akár egy kill-el vagy task managerből. MySQL-nél ilyenre esélyed nincs.

Ettől függetlenül egy-egy worker - miután egy teljes, önálló értékű process - még végezhet párhuzamosítást "házon belül". Plusz vannak ilyenek is: https://wiki.postgresql.org/wiki/PGStrom#Run_SQL_on_GPU

Mondjuk az tény, hogy OLAP-ra nem a PostgreSQL a legalkalmasabb.

Szerk.: viszont ahogy nézem, van ilyen: https://github.com/citusdata/pg_shard

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mindamellett hogy ennek igazat kell adnom, azért ebben az sql-nek is része van. Pl. a linkelt kód viselkedése egy nem sql guru fejlesztő számára annyira váratlan, hogy egész egyszerűen nem fog felkészülni rá: http://sqlfiddle.com/#!9/3a79c/1/0 (A handlerre csak az SQL Fiddle miatt van szükség, a példa anélkül is ugyanígy működne.)

( Gyuszk v | 2015. 09. 28., h – 16:25 )

"Long story short, I was running Postgres 9.1, and the current Ubuntu version is 9.3. I’d originally installed the postgresql package, and using Arch Linux on my desktop has spoiled me into thinking that that will keep me on the latest version, but Ubuntu cares about trivialities like “not breaking your entire server” and had just kept me on 9.1 the whole time. "

Itt abbahagytam :( ez egy gyoker. Ertsd, azt se tudja hogy mit hasznal es az hogy mukodik. A tobbirol amit mar kitargyaltunk mar nem is szolva. Hogy jon ide a Linux egyebkent? Na mindegy, dolgozok tovabb a Linuxommal :)

--
arch,debian,openelec,android

( khiraly | 2015. 09. 29., k – 12:43 )

Szerintem meg sose volt olyan egyszeru webszervert "deploy"-olni, mint most, linux alatt.

A docker tenyleg egy aldas, van am neki restart=always kapcsoloja, lehet a cikkiro nem tudta (reboot utan ujraindul a kontener).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

jobban belegondolva 2 lehetoseg van, ha kell pl. egy webes forum:

a) tudod, hogy mitek van (os, php, perl, ... verziok, lib-ek verzioi, etc), es olyat keresel, ami illik ebbe a kornyezetbe -> nem szivas a deploy
b) kineztel valamit, ami rohadtul nem illik bele a meglevo kornyezetbe, de akarmilyen oknal fogva ragaszkodsz hozza -> ebben az esetben sem szivas a deploy (normalis doksi mellett), mert keszitesz egy olyan kornyezetet, ami kell a cuccnak

Akkor szokott szivas lenni, amikor emberunk (ez inkabb a dev-ekre jellemzo betegseg) root jogot kap (kezere utni, akitol kapta), es elkezdi eszetlenul reszelni a *meglevo* kornyezetet. Ilyenkor szokott lenni 3 verzio ugyanabbol a szoftverbol, lib-bol, es mas hasonlo labon lovesek...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Miért kellene ezeket egyáltalán kézzel telepítgetni, konfigurálni, mikor a sima programoknál már eljutottunk odáig, hogy telepítse a megfelelő függőségeket? Miért kézzel kellene nekem vadászni, hogy x-ből az 1.2.3 y-ből a 666.999 kell, mikor ezt egy gép is el tudná dönteni, hogy ami van/elérhető, az jó-e?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Akkor még egyszer: Nem kell kézzel telepítgetni. Az kell, hogy a developer (méginkább a devops engineer) értelmesen előkészítse a szoftvert. De ez minden platformra igaz.

1) A szoftver szintjén is vannak "csomagkezelők", függőséggel. Maven, Biicode, Cabal, Pip, Npm, Bower, etc. Ha az operációs rendszerrel konfliktol, akkor ezek mellé minden futtatókörnyezet verziómanagere/virtualenvje: virtualenv, rvm, nvm, cabal-sandbox, etc. Kezel függőségeket
2) Az operációs rendszer szintjén természetesen ott van a csomagkezelő (99%-ban alaptelepítésben, de akár még a Windowst is fel lehet erre a szintre hozni). Web app deployra nem biztos, hogy ez a legmegfontoltabb, de ez is lehetőség, láttam már ilyent. apt-get, yum, etc. Kezel függőségeket
3) Konténer szinten is gondolkodhatsz, a deploy valószínűleg ezzel a legegyszerűbb. Bare lxc, docker. Kezel függőségeket
4) Ha infrastruktúra szinten mozogsz: Amazon CloudFormation, OpenStack Heat. Ezekkel aztán vagy magában a deploy szkriptben definiálod a függőségek telepítését, vagy méginkább chef, puppet, ansible. Bár ezzel a módszerrel is helyre kerülnek a függőségek (reprodukálható módon, nem kézzel installálgatva), de itt mégsem feltétlenül deklaratív módon mondod meg "a gépnek, aki el tudja dönteni, hogy ami van/elérhető, az jó-e."

A webhez ISZONYATOSAN nagy mennyiségű, és sok programozási nyelvhez elérhető toolchainek vannak, igaz, a Windows-világból kibújni nem szeretők ezzel nem annyira szembesülnek. Biztos megvan a maga oka, hogy ezeknek a tooloknak a nagyrésze miért nem, vagy csak nehézkesen működik Windows alatt, és miért könnyedén, egyszerűen linux/OSX alatt. (Igen, egy részük mégcsak nem is BSD kompatibilis). És nem holmi hupperprolik vagy bloggersenkik építenek erre Pistike Bt-t, hanem facebookok, netflixek, stb. milliárdos vállalkozásokat. (Ez továbbra sem azt jelenti, hogy a toolok tökéletesek, csak azt hogy eléggé prod. readyk).

Számomra még mindig érthetetlen, hogy ahelyett, hogy körülnéznél, hogy mégis mi a valóság, még mindig ebből a szerencsétlen flótásból indulsz ki, aki elakadt a rubykájával 32/64 biten, és ezért a linuksz szar...

Ezek közül,a szabványos megoldas, amelyiket a webalkalmazasok döntő többsége támogat ugy, hogy a meglévő nginx, randomsql környezetbe egy sor parancs kiadasaval feltelepitheto egy tetszőleges php/ruby/python/whatever cucc (az elterobb kornyezetet igénylő javas dolgokat most direkt nem említem), anelkul, hogy nekem kellene baszakodni azzal, hogy a megfelelő verziójú php modul/ruby gem/kiscica van fen, a: .........

(Válaszát kérjük kommentben irja le).

Egyebkent nagyon uncsi ez a Windowsos személyeskedés, miutan tobbszor kifejtettem a topicban, hogy fingom nincs mi van e teren Windowson, mert erre a célt nem hasznalom. Ez magában implikalja, hogy mast (segitek: Linux, FreeBSD) igen. Barmilyen hihetetlen, nem homogén Windows only környezetben dolgozok es meg csak nem is Windows only környezetre fejlesztem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Egyebkent nagyon uncsi ez a Windowsos személyeskedés
LOL. Úgy kezdődött az egész, hogy a Linux ökoszisztéma önszopatás. De akkor ezek szerint nem a Linux ökoszisztéma, hanem minden ökoszisztéma önszopatás. Ennyit a személyeskedésről.

De lassan kezdem megérteni (így a másik, hosztingos hozzászólásod is kezd értelmet nyerni), neked az a problémád, hogy nincs arra szabvány megoldás, hogy a meglévő nginx, randomsql környezetbe tudj deployolni. Válaszomat kommentben leírom: erre csak gányolós megoldásokat ismerek. Nem csak linuxon, bármely platformon. Az említett Java picit más tészta, ott egész szépen megy a .war fájlt betolni (gondolom egyéb EE kategóriában amúgy, pl. asp.net esetén is van ilyen szép megoldás).

Más kérdés, hogy manapság a IaaSok, PaaSok és mikroszervizek korában miért akarna bárki ugyanazon a hoszton apache alá több appot beheggeszteni...? Ugye pont erre születnek a fent már összeszedett listám, de főképp a CloudFormation / Docker jellegű dolgok. Ha nagyon nyalni akarnék, minden topikba be is linkelném a BlueMixet, ami a problémára elegáns megoldást nyújt. (gelei és mrceeka gyakorlata alapján inkább nem teszem, ha érdekel, keress rá).

Valami legacy szart kell tákolnod ezek szerint? Vagy más kényszerítő hatás (pl. menedzsment) miatt kell a 10+ évvel ezelőtti deploy hozzáállás?

meglevo [...] kornyezetbe egy sor parancs kiadasaval feltelepitheto egy tetszőleges [...] cucc

orok elet nem kell? :-)

Egy a fejleszto szamara ismeretlen (=meglevo) kornyezetbe 'tetszoleges' cuccot csak A/NI tud feltenni. Azaz vagy termeszetes vagy mesterseges intelligencia. Pl. a piler telepitese is ugy 1 parancs (regebben volt ra egy shell script, de ma mar egy (felparameterezett) ansible playbook vegzi a melot), hogy tamogatok 2 linux disztribuciot, 2 fele webszervert, es en telepitek fel minden komponenst a php-tol kezdve az sql szerverig. Pont azert, mert a kornyezetnek is jol definialtnak kell lennie, hogy minden, ami kell a cuccnak, az a helyen legyen.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

ooo, idonkent zavarba jovok, hogy most is csak onmagad adtad, vagy ez most vicc akart lenni...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Ha parodizalok masokat, vagy latvanyosan kisarkitom a mondanivalojukat (hint: egy kicsit olvass vissza) az altalaban mindig az ironia jele nalam. Ezt kulon szoktam is jelezni ezzel a !!!44negy! -jellegu vegzodessel, ami - ha megfigyelted volna az irasi stilusomat - nem az atlagkommunikacio resze nalam.

Egyebkent ha elolvasnad neha amit irok (akar csak ebben a szalban is), akkor lathatnad, hogy messze nem ertek egyet ezzel a tipusu velemennyel.
--
Blog | @hron84
Üzemeltető macik

Miert nincs az SQL Engine-kre szabvany, miert mas minden SQL szerver? Miert nincs a programnyelvekre szabvany, miert kell minden programnyelven maskepp megoldani ugyanazt a feladatot? Miert nincs az eg keksegere szabvany?

Nem mondom, hogy a mostani rendszer hibatlan, de inkabb ne akarjanak mindent szabvanyokkal szabalyozni.
--
Blog | @hron84
Üzemeltető macik

"Nem mondom, hogy a mostani rendszer hibatlan, de inkabb ne akarjanak mindent szabvanyokkal szabalyozni."

De, akarjanak. És kényszerítsék is ki. Tudod milyen élmény egy n+1. csatolót megírni pl. egy kereskedőcégnél, mert nincs egy egységes szabvány adatcserére, hanem mindenki tákolja az egyedi szarját?

De ha nem akarnak egy ilyet szabványokkal szabályozni, mint egy szaros alkalmazás telepítése, akkor minek .deb meg dpkg?

Egyébként meg breaking news: SQL-re is van szabvány, elég nagy részét implementálja minden RDBMS.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ha egy webdeveloper kimenete egy docker kontener, akkor a deploy az tenyleg csak egy docker start.

Igy a mondat masodik fele ertelmet veszti. Mert kb. pont ugyanolyan nehezkes, mint mondjuk egy nyomtatonal beallitani a helyi ip cimet a halozaton.

En minden kis kulonallo feladatot kulonallo kontenerbe teszek. (pl. biztonsagi mentes keszitese egy kulon kontener vegzi, pl. egy email kikuldeset egy kulon kontener vegzi, pl. egy kep tomoriteset (kep elonezete) egy kulon kontener vegzi, pl. egy pdf generalasat egy kulon kontener vegzi). Innentol kezdve nem ertem, hogy mi ez a "meglevo infrastrukturaba". Mindenkinek sajat homokozoja van, abban homokozzon.

Ezzel a docker infrastrukturaval vegre eljutottam oda, hogy egy programot be lehet fejezni, fizikailag lehetseges keszrejelenteni. Az emailkuldo programom annyit csinal, hogy ranez a szerverre 5 percenkent, hogy van-e email amit el kell kuldeni, ha van elkuldi. Ezen nincs mit fejleszteni, ez a feladata es elvegzi. Ha lyukat talalna valaki rajta, befoltoznam uj kontener es megy az elet tovabb.

Ez par eve nalam ugy zajlott, hogy az email kuldes *egy resze* volt csak a fo weboldalamnak. Egy alfunkcio. Ami neha elromlott (kod refaktoralas, masik bug beakasztott ennek, stb), ha a fo weboldal megfekudt, akkor az a funkcio is fekudt vele. Mostmar nincs ilyen problema.

Az adatbazis is egy kontenerben van az en esetemben. Most akarom egy flottaba (swarm) tenni, hogy tobb instance-bol alljon.

Szoval nincs ilyen nalam, hogy meglevo infrastrukturaba hogyan teszem bele, mert nincs ertelme a kerdesnek.

Nincs ilyen, hogy fuggosegkezeles, mert ami a programnak kell, az benne van a kontenerben.

De persze en egyszemelyes hadsereg vagyok, igy biztos hulyeseget beszelek:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Omg, az komolyan innovalas, hogy poolozunk esemenyvezereltseg helyett? Nemar... :)

szegeny ember queue-ja :-) ha nem meri/akarja real time elkuldeni az emailt a weboldalrol...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Itt nem ez az innováció, hanem, hogy erre az egyszeru feladatra is saját virtuális gép van.

Ezt Windows alapon nem adod elo.

Persze nem muszaj poolozni, lehetne websocket is, de pont ennel a feladatnal az 5 perc kesleltetes teljesen belefer.
Es a skalazodas abszolut trivialis.

Ez a pdf generalonal jon ki, ahol van olyan pdf amit 30 percig general (optimalizacio elott 46 ora volt).

Van websocket alapu is (esemenyvezerelt, kep elonezet az ilyenn pl.), de nem hiszem, hogy architwkturalis donteseimet ebben a forumban kellene bizonygatnom.

De ne haggyatok abba, omoljon a cucc, van ott meg, ahonnan ez jott:-D

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Itt nem ez az innováció, hanem, hogy erre az egyszeru feladatra is saját virtuális gép van."

Persze, az erőforrások meg korlátlanok. De egyébként láthatóan nem sikerült megérteni a siralmam: mindegy, hogy külön VM, vagy csak összehányva egy gépre: jelenleg nincs túlzottan megoldva egy random webappnál, hogy ha akár csak kipróbálás szintjén fel akarod rakni egy meglévő infrastruktúrába (ami ismételten mindegy, hogy egy halom VM egy public/privát cloudbna, docker konténerek hada vagy csak egy halom apt-get install biz baz foo bar -al felrakott cucc), ninsc kezelve, hogy minek mi kell. Meg, hogy ezeket ne egyesével - tökegyedi - config megoldásokkal kelljen beállítgatni.

"Ezt Windows alapon nem adod elo."

Egyébként már hogy ne adnám elő.

"Persze nem muszaj poolozni, lehetne websocket is, de pont ennel a feladatnal az 5 perc kesleltetes teljesen belefer."
"Ez a pdf generalonal jon ki, ahol van olyan pdf amit 30 percig general (optimalizacio elott 46 ora volt)."

Mondjuk jobb helyeken erre alkalmaznak valami message queue megoldást, nem poolozással meg websockettel tákolnak IMHO.

"de nem hiszem, hogy architwkturalis donteseimet ebben a forumban kellene bizonygatnom."

Na de ha egy szerintem rosszabb megoldást akarsz beállítani egy jobbnak, akkor hadd érveljek már ellene.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> > "Persze nem muszaj poolozni, lehetne websocket is, de pont ennel a feladatnal az 5 perc kesleltetes teljesen belefer."
> > "Ez a pdf generalonal jon ki, ahol van olyan pdf amit 30 percig general (optimalizacio elott 46 ora volt)."
> Mondjuk jobb helyeken erre alkalmaznak valami message queue megoldást, nem poolozással meg websockettel tákolnak IMHO.
Amúgy a jobb helyeken nem az agyonhype-olt MQ-t használják minden szarra plusz függőségként telepítve, hanem nem félnek egy sima cron-jobtól (vagy akár bármi mástól, ami már 40 éve bizonyít), csak azért, mert az régi. IMHO.

Egyik projektünkben a kezdeti gyors fejlesztés miatt a meglévő módszerhez illesztettük a szoftverünket: imap-on ránéztünk, jött-e újabb adat. Telt-múlt az idő, és végülis úgy maradt*. Aztán valaki meg is fogalmazta: "Az IMAP kellően jól definiált protokoll, nekünk meg x időintervallumonként kell megnézni, hogy jött-e új adat. Igazából nem is kell ide más".

* Mindig úgy marad.

X idointervallumhoz hozzatennem, hogy nalam az 5 percenkentaz mindig random 0-5 perc, hogy ne adjon "terhelestusket" a masik oldalon.

Altalaban mindenhova randomot teszek, hacsak valami nem masodpercre idokritikus.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"X idointervallumhoz hozzatennem, hogy nalam az 5 percenkentaz mindig random 0-5 perc, hogy ne adjon "terhelestusket" a masik oldalon."

OMG, folytasd még kérlek az antipatterneket. Az, hogy egy Msg Queue-t használnál arra a célra, hogy szépen eseményvezérelten és elosztottan fusson le minden csak akkor, amikor kell, az gáz, mert plusz függőség, de az, hogy random időközönként, ahol semmi nem garantálja, hogy ne induljon random egyszerre minden folyamatosan poolozol még akkor is, amikor semmi dolga nem akadna az adott servicenek, az neked megoldás. Persze, randomizálsz a terheléstüskék ellen. Grat. :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Btw, azt ujsagoltam mar neked, hogy 4GBos node-okbol epitek egy 48TBos tarhelyet? Ez idei cel,remelem belefer.

Persze messaging queue nem lesz benne. Szurkolj nekem:)

Remelem, hogy 12ezer kontenernel mar ki fognak jonni azok a gondok,
amiket itt emlitesz.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Jó, nem tudom, hogy nálatok mi a volt a requirement, nálunk nincs 12000 konténer, ellenben látom, hogy egy elég szép nagy konstans terhelést ad/adott a szervereknek a sok legacy pooling rész.

Arról nem is beszélve, hogy igény, hogy minél előbb látszódjon a végeredmény, ne akkor, amikor egy-egy poolozás épp oda jut. Igaz, nálunk volt olyan is, ami percenként, 10 mp-nként poolozott.

Normális event-drive módszerekkel láthatóan jóval kisebb lett az erőforrás igény, gyakorlatilag csak az maradt poolozásban, ami nem oldható meg máshogy, mert olyan az alkalmazás, amivel kapcsolatot kellett teremteni. És az ügyfél is elégedettebb, hogy nem csak x idő múlva tudja meg a végeredményt.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"nincs kezelve, hogy minek mi kell"

A dockernel pont hogy igen, mert ket dolog kell hozza: egy uzemelo host dockerrel, meg halozat. Vagy ezt is le akarod specifikaltatni? Tenyleg, mi az a szint, ameddig le kell specifikalni a fuggosegeket? A gepben mindenkeppen legyen CPU meg nemi RAM, meg esetleg be lehessen kapcsolni?
--
Blog | @hron84
Üzemeltető macik

> Tenyleg, mi az a szint, ameddig le kell specifikalni a fuggosegeket? A gepben mindenkeppen legyen CPU meg nemi RAM

fyki, elég sok alkalmazásnál veszik ezeket számításba. Nem azt, hogy "legyen benne némi RAM", hanem hogy ennyi és ennyi RAM per párhuzamos user, és hasonlók.

Nem hittem volna, hogy ez egy informatikai fórumon meglepetést okozhat. :)

Szerintem el tetszett teveszteni a szalat, itt az automatikus deployment es a kovetelmenyek leirasarol beszelgetunk. Allitolag pont az a gond, hogy mindenfele leirasokat kell olvasgatni, meg fuggosegeket osszeszedni, saxus ehelyett szeretne valami automata utat. Ehhez viszont eloszor meg kell hatarozni azt a pontot, amit meg adottnak tekinthetunk a specifikalas soran, ugyanis altalaban mindig van valami alapvetes, amit annyira axiomanak tekintunk, hogy mar nem megyunk bele annak a reszletes specifikaciojaba, peldaul hogy a processzornak hany laba van, es hogy kocka alaku, semmikeppen sem kerek (nem mintha lenne ilyen). Ezt probalom meghatarozni, hogy mi az a szint, ameddig le kell menni, mert tobbfele szinthez letezik tobbfele, kvazi-standard tool, az igenyek alapjan kell kivalasztani.

Ami a eroforras per parhuzamos user kerdeskort illeti, en akarhanyszor talalkoztam ilyennel (MS es mas forrasbol is) azok az adatok mindig fals laboradatok voltak, semmikeppen sem valos kornyezeti ertekeket tukroztek. Normalis helyeken ezert nem szoktak egybol tobbszazezer usert engedni valamire, hanem betateszteltetik, merik az aktualis terhelest, es abbol szamolnak atlagot, amire radobnak meg valamennyit.

Egy szoftver eroforrasigenyenel rettenetesen sokat szamit a konfiguralas modja, ezt statikus modon nem tudod lespecifikalni, csak akkor, ha a szoftvernek legfeljebb keves szamu allapotvariacioja lehet, leginkabb ezert szoktak ezektol a dolgoktol tartozkodni a gyartok, vagy csak az ilyen "minimum ajanlott kovetelmeny" kategoriaval ovatoskodnak, es lehetoleg messze kerulik a felelossegvallalas latszatat is, mert ezek baromira nem egzaktul meghatarozhato szamok.
--
Blog | @hron84
Üzemeltető macik

A message queue az plusz egy fuggoseg, ha nem muszaj nem teszem be.

Egyebkent az eroforrasok pont hogy vegtelenek docker eseten, vehetsz meg par amazon node-ot, ha kifogynal.
Az egesz optimalizaciot at lehet tolni a penzugyre... Majd ok eldontik, hogy kell-e.

Szerintem dockerhez foghato egyszeru deploy nem volt elotte egyik platformon se.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"docker eseten, vehetsz meg par amazon node-ot, ha kifogynal."

Ehhez nincs szukseg a dockerre btw.

"Az egesz optimalizaciot at lehet tolni a penzugyre"

Tegye fel a kezet, akinek hozzam hasonloan felallt a szor a hatan erre a mondatra. Nagyon sokmindent bizunk a penzugyre, terhelesoptimalizaciot szinte soha, nem erre valok. Ha az ufel nem fizeti ki azt a mennyisegu szervert, ami kell az uzemelteteshez, akkor oldja meg, ahogy akarja, ugyanis onnantol kezdve kezdodik a ganyolas meg a taknyolas vegelathatatlan vilaga, amibe meg belemenni se szabad.
--
Blog | @hron84
Üzemeltető macik

> Ha az ufel nem fizeti ki azt a mennyisegu szervert, ami kell az uzemelteteshez, akkor oldja meg, ahogy akarja, ugyanis onnantol kezdve kezdodik a ganyolas meg a taknyolas vegelathatatlan vilaga, amibe meg belemenni se szabad.

Egy tökéletes világban, ahol végtelen erőforrás áll rendelkezésre (felhő? :)) talán igen.

Abban a fizikai univerzumban viszont, amiben mi lakunk, sajnos ez csak egy utópia lehet. És ez nem is mindig egy rossz dolog: az egyik előző helyemen, amikor még inkább fejlesztéssel foglalkoztam, volt egy projektünk. Volt a cégnél egy számlázórendszer (havi több százezer számlával), ami alatt Oracle futott. A napi munka során nem volt vele baj, de a (többek között) a riporting része nagyon durván erőforrásigényes volt, nem győzték tenni alá a vasat.

A projekt maga arról szólt, hogy fejlesztettünk egy megoldást, amiben a leggyakrabban használt 8-10 query-t "outsource-oltuk". Írtunk egy szerveroldali appot, ami minden hajnalban kimásolja az Oracle-ből az utolsó X időszak összes adatát, ez pár giga volt. Az appban implementáltuk ezeket a query-ket, nagyon-nagyon optimalizálva, majd mindezt egy WCF service-en keresztül kiajánlottuk. Ez a megoldás, az eredeti, 10-60 másodperces futásidőket 0.1 MÁSODPERC ALÁ csökkentette. Ami, önmagában sem kevés, de ezek a query-k etetnek több customer-facing rendszert is, ahol azért rohadtul nem mindegy, hogy az előfizető egy percig nézi a homokórát, vagy 1 másodpercig.

A szarul tervezett 3rdparty programokkal persze nincs tul sok lehetoseg mit kezdeni, de en meg folyamat olyan projektekkel kerulok szembe, ahol egy belsoleg fejlesztett cuccos van, aminek akkora az eroforrasigenye, amekkora, es hiaba mondogatom, hogy ez egy 20%-os novekedestol is kihal, nem akarjak kifizetni a rendszer boviteset, inkabb tancolnak pengeelen.

Arrol nem is beszelve, hogy ket kulonbozo oldalrol latjuk ugyanazt a problemat. En uzemelteto vagyok, sosem fogok a mrendelonek appot irni, ami SQL queryket futtat, azert van neki fejlesztoje, h ezt megoldja. A gond altalaban az szokott lenni, hogy az ufel se insource se outsource nem akarja megoldani, mert az penzbe kerul, inkabb "ugyes vagy, meg tudod oldani". Hat nem.
--
Blog | @hron84
Üzemeltető macik

> A gond altalaban az szokott lenni, hogy az ufel se insource se outsource nem akarja megoldani, mert az penzbe kerul, inkabb "ugyes vagy, meg tudod oldani".

Ha van pénz optimalizálni, az jó. Ha van pénz vasra, az is jó. Ha pénz egyikre sincs, de várjuk a csodát, na az tényleg rossz. :)