Új hozzászólás Aktív témák

• bambano titán

  #8548

  #8547 emvy

  2016-09-20 12:37:19

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bambano

  titán

  #8547 emvy

  #8547 emvy

  En uzemeltetek, per pillanat. Marmint ha valami osszefossa magat, akkor nincs mas, aki eletre keltse, csak en. Tehat pont azert vannak ezek, hogy az en eletem egyszerusodjon. Ez van.

  > elhiszed, hogy most nincs bennük hiba?

  Nem. De hiba mindenben van. Es kerdes, hogy mondjuk service discoveryt irjunk mi, vagy hasznaljunk software defined networkinget? Sajnos a realitas az, hogy ha mi megirjuk, azt joval nehezebb uzemeltetni a bugok miatt, mintha felrakok egy weave-t.

  Postgres vs. Consul: almat kortevel. Total mast tud a ketto, de tenyleg. Ha a Hashicorp csodbe megy, akkor a Consult kicserelni masra kb. semmi, de a Postgres ele olyan interfeszt rakni hogy tudja azt, amit nekunk kell, az sokkal tobb melo.

  > valójában kell-e docker neked.

  O, ezt a kerdest joparszor feltettem magamnak. A Docker nem tokeletes (sot, bugos fos), csak osszevetettem egy csomo minden massal, es per pillanat ez a kombo oldja meg a problemakat kozeptavon.

  A helyzet az, hogy a problemaim 90%-a nem technikai jellegu, ergo nem az a kerdes onmagaban, hogy mik a helyes architekturalis elemek technikai szempontbol. Hanem az, hogy a developereket hogy lehet ra megtanitani, meg lehet-e, mennyi ido, etc. etc., tehat inkabb human kerdesrol van szo.

  Ha az lenne a kerdes, hogy egy adott appot hogy lehet a leguzembiztosabban deployolni 2016-ban, akkor egyaltalan nem tuti, hogy a Docker lenne ra a jo valasz. Egy legacy rendszer atalakitasanal, durva skalazasnal (1000-szeres terhelesre kell atfabrikalni az egy eleg nagy rendszert kb. 1 ev alatt), massziv feature pressure mellett, elosztott csapatban (cseten tudsz kommunikalni, nagyreszt) -- tok mas problema.

  "Es kerdes, hogy mondjuk service discoveryt irjunk mi, vagy hasznaljunk software defined networkinget?": helyes válasz: egyrészt elkerüljük, hogy service discovery-re legyen szükség, másrészt ha nem kerülhető el, akkor alap oprendszer cuccokkal oldjuk meg.

  "De hiba mindenben van.": így van. vagyis a hibák össz-számát azzal tudod csökkenteni, ha a felhasznált komponensek darabszáma konvergál az elvi minimumhoz.

  "A Docker nem tokeletes (sot, bugos fos), csak osszevetettem egy csomo minden massal, es per pillanat ez a kombo oldja meg a problemakat kozeptavon.": bare metállal is összevetetted?

  egyébként is a docker meg az openstack környékén épp most tört ki egy orbitális balhé, úgyhogy bajban leszel.

  "tehat inkabb human kerdesrol van szo.": lehetett érezni, hogy pebkac van

  ha te üzemeltetsz egyedül, akkor nem elosztott csapat. maximum ki kell verekedned a csapatban a téged megillető pozíciót, ami szociológiai probléma. de sokat segít, ha csak nálad van root jelszó, a többi meg max. kibicel.

  a service discoveryre visszatérve: ezzel, hogy úgy működik a hálózat, hogy bedobsz egy service-t és azt a többiek majd felfedezik, szemléletbeli problémát látok. ha te felügyeled a teljes lomot, akkor nem discoveryt kell csinálni, hanem leltár alapján beállítani azt, amit felfedezni kellene. ha politikai irányból szabad példát hozni, akkor amit csinálsz, az a szabadversenyes kapitalizmus. elkezdődik egy szolgáltatás, a piac meg vagy észreveszi, vagy nem. amit én javaslok, az a komcsi módszer: központi tervintézet előírja mindenkinek, hogy pontosan mit kell csinálni. ez utóbbi szerintem sokkal egyszerűbb.

  a felskálázásról meg az a véleményem, hogyha 1000x teljesítményre kell felskálázni a cuccot, akkor bizonyára van már a plusz lóerőből valamennyi, ami majd ehhez kell. azon a plusz lóerőn kell felépíteni az új rendszert, új szemlélet szerint, nulláról, és nem a régi rendszer farigcsálásával konvergálni valamerre. ha meg nem tudnak pár plusz szervert biztosítani ehhez, akkor ott kell őket hagyni a fenébe.

  "Postgres ele olyan interfeszt rakni hogy tudja azt, amit nekunk kell, az sokkal tobb melo.": ha jól láttam, két dologra akarod használni a consult: egyrészt értesüljön a gép, hogy konfig váltás volt, másrészt megkapja a konfigot. mindkettőre triviálisan megfelel a postgres, különösebb fejlesztés nélkül. egyébként sem tudok elképzelni adatbáziskezelő nélkül ilyen projektet, tehát valami már úgyis van alatta. ha nem postgres, akkor mysql, teljesen mindegy, a postgrest csak példának mondtam.

Új hozzászólás Aktív témák