[Update 1] Kubernetes-re épülő technológiák használata ma Magyarországon

Közösségi kerekasztal

Itt a HUP-on és a HWSW-n (nyilván nem véletlen az áthallás) rengeteg szó esik (hónapok-évek óta?) a Kubernetes-re, konténerezésre épülő technológiákról és (én úgy látom) aránylag sok előadás szól ezekről felületesen vagy részletesen.

Ezen felül napi téma a DevOps, ami azt gondolom ezek kapcsán "jött létre", került előtérbe. Amivel lassan ott tartunk, hogy van a fejlesztő, meg a devops, és ennyi az IT egésze, a számítógépes munkát végző maradék 60-70% már nem is IT-s a köznyelv és a szakma szerint.

Engem két kérdés(kör) foglalkoztat jelenleg ezzel kapcsolatban. Persze teljesen elméleti síkon, mert egyszeri, KKV-knek dolgozó üzemeltetőként nem vagyok jelenleg érintett:

  • Valójában ki és mire használja ezeket a technológiákat itthon, hogy ilyen sokat kell róla beszélni és ilyen sok ingyenes és fizetős oktatást érdemes rá szervezni? Hol vannak olyan komoly rendszerek, amik ilyen mértékű skálázhatóságot igényelnek?
  • Tényleg hatékonyabb, gördülékenyebb és kevesebb munkával feljeszthetőek és üzemeltethetőek ezek a rendszerek? Takarékosabbak vagy jobbak ezek bármi téren, vagy csak mások?

Én leginkább a kelet-nógrádi kisebb-nagyobb cégeket ismerem IT területen valamennyire, de amennyi rálátásom van, egynek sincs olyan jellegű IT feladata (sőt, kitalálni sem tudnék nekik, hogy ráerőltethessük a technológiát), amit ezekkel az eszközökkel lehetne hatékonyan megoldani, vagy amikhez kifejezetten ilyen eszközök kellenének. Persze egy elmaradott, aránylag ritkán lakott régió nem mérce még országon belül sem, ezért érdekődök.

A másik terület (ami a most futó service mesh előadás kampány olvasása után gondolkodtatott el), hogy valóban könnyebb, nagyobb teljesítményű, sok újra felhasználható "univerzális" építőkockából valósulnak-e meg ezek a mai modern alkalmazások? Vagy csak a régi monolitikus rendszert izzadják ki magukból az új dolgokra épülve? Amiket aztán sem nem könnyeb elkészíteni, sem nem nagyobb teljesítményűek, sem nem üzemeltethetők könnyebben és semmiképp sem erőforrás-kímélőek, meg nem is igazán használható fel egy részük sem máshol.
Ugyanis jól hangzik ez a service mesh meg mikroservices, meg a többi kapcsolódó technológia, de valóban vannak olyan fejlesztők (itthon, itthoni projekteken dolgozva), akik olyan rendszereket terveznek, amik tényleg "fejlettebbek" architektúrájukat tekintve? Amire ha a tervezett 100 felhasználó helyett valamiért 100 ezer csatlakozik (befut a startup), akkor felpörög a rendszer, és kiszolgálja? A Kubernetes világában már minden absztrakció is absztrahálva van, amit nehezebb felfogni (laikusként pláne) mint a PHP vagy JS framework-ök végtelen sorát, és ami nem a (futási) hatékényságot, erőforrás-gazdaságosságot segíti elő, hanem valami mást, ami számomra eddig nem derült ki. Igazából nem is látom át, mit segíthet elő valójában a Kubernetes és csatolmányai a multiknál és a felhőszolgáltatóknál kisebb cégek esetében.

Szóval ebben aki jártas, - vagy nem jártas - és van véleménye, gondolata, megoszthatná velem.

Update 1

Köszönöm a nagyon sok hozzászólást! Jobb rálátásom lett arra, hogy szerintetek mire jó a Kubernetes, ki szerint mit jelent a CI/CD és kapcsolódó technológiák. Megtudhattam, hogy hol lenne értelme használni, és hol élvezhetnék az előnyeit.

Ellenben egyetlen hsz.-ben nem olvastam arról, hogy ma Magyarországon ennek hol van olyan létjogosultsága, valós felhasználása, ami indokolja azt, hogy az összes induló képzés a felhőről, Kubernetesről és hozzá kapcsolódó techológiákról szó. A sok hozzászóló közül csupán néhányról derült ki számomra, hogy nem csak véleménye van a témáról, hanem a valóságban a közelébe is került, látott már ilyen élesben, és azon írásai sem a diadalmenetről szólnak ,hogy mindenki hülye, aki nem dolgozik lázasan a felhős átálláson.

Ami kiderül, hogy a mikro- és kisvállalkozások nem használják, mert drága az áttérés és az üzemeltetés, plusz nincs szakember (-re pénzük) hozzá. A nagyvállalatok nem használják, mert infrájuk meg pénzük ugyan lenne rá, de nem tudják kimutatni, hogy megérné elkölteni a pénzt az átállásra, hogy lenne annyi hozadéka ami kompenzálná a pénzt és időt (vagy már nekifutottak, és kiderült, sokkal drágább a tervnél és sokkal kevesebbet hoz a vártnál). Ami a kettő között van (van itthon a kettő között valami?), arról nem tudunk semmit. Ezek szerint ha léteznek, ott sem használnak ilyen komoly, cloud natív rendszert.

Viszont az eredeti kérdésemre a válasz nincs meg (vagy megvan, és nemleges): ahogy most 150 hsz. után látom, ezek a technológiák valójában nincsenes sehol itthon napi használatban, és aki beiratkozik ezekre a képzésekre, az szakmai érdeklődés képpen teszi, hogy valamivel kielégítse a szakmai kíváncsiságát (mint amikor az olvasni szerető ember elolvas szórakozásból egy újabb regényt), nem azért, hogy valójában megtanulja a technológiát, mert használnia kelljen éles projekten.

Jól látom a helyzetet, vagy nem igazán értettem meg, amit írtok?

Azért feszegetem ezt a témát, mert üzemeltetőként azt tapasztalom, hogy a jelenleg itthon használatban lévő technológiákhoz sem ért sok kezdő (és "haladó"), rengetegem máig a bare metal-ra Windows Server-t teszünk, mert azt GUI-n könnyű kattintgatni szintnél járnak, és valójában sima virtualizációról, hiperkonvergens rendszerekről sincs ismeretük (pedig szerintem jóval könnyebben emészthetől, és sok helyen napi használatba vehető ez a tudás), mégsincsenek ilyen képzések nyomva, csak a cloud native, buzzwork-okre épülő trendek, amit az eddigiek alapján igazából nem lehet sehol használni a gyakorlatban, mert senki egy példát sem írt, hogy hol van élesben ilyen rendszer...

Az meg pláne nem tesz jót, ha a használatban lévő, aránylag modern és hasznos technológiákat átugorjuk oktatás szinten, és kapásból a jövő technológiáját toljuk a tanulóknak, mert akkor lesz egy lyuk , amit nem tud senki betömni. Az újak olyanhoz étenek ami majd lesz, a jelenlegiek meg olyanhoz értenek ami régen volt. Ahhoz meg, ami most van, alig értenek ehhez képest páran (annyira, amennyire jó lenne hozzá érteni).

  • 4299 megtekintés

( asm v | 2023. 04. 25., k – 08:54 )

Szerkesztve: 2023. 04. 25., k – 08:56

A Kubernetes onmagaban nem csodaszer. Erdemes az egesz rendszert egyutt vizsgalni.

Ha mar Kubernetes, akkor ezek kihagyhatatlan szempontok:

  • kontenerizalt app futtatas
  • az appok legyenek cloud native szempontokat koveto microservice-ek, jol skalazodjanak, konnyu legyen oket upgrade-elni
  • kontener image-ek kozpontilag tarolhatoak, vulnerability scannelhetoek
  • logok kozpontilag begyujthetoek, tarolhatoak, kereshetoek (pl.: Fluentd, ElasticSearch, Kibana)
  • performance metric-ek begyujtese, vizualizalasa (pl.: Prometheus, Grafana)
  • alerting hiba eseten (pl.: AlertManager + vmi kulso on-call rendszer: PagerDuty)
  • bejovo REST hivasok lancolatanak (tracing) gyujtese (pl. Jaeger)
  • bejovo forgalom Ingress-szen keresztul vezetve lehetoseg van HTTPS terminalasra, rate limitre, extra authra, cache-elesre, URL rewrite-ra (pl. Nginx alapu ingress controller)
  • security policy-kat lehet enforce-olni vagy scannelessel felterkepezni a problemas teruleteket
  • redundans architektura, infrastruktura (barmelyik public cloud managelt K8s megoldasa tobb AZ-n futtatott node-okkal)
  • mindezt ugy, hogy barmely komponens upgrade-je leallas nelkul vegezheto (nyilvan elotte leteszteljuk azert egy teszt kornyezeten)
  • backupot a cloud szolgaltato rendszerevel vegezzuk (adatbazisok, block volume-ok es tarsai)
  • popec CI: minel tobb tesztet futtassunk deploy elott, hogy hibas szoftver ne menjen elesbe, deploy utan is futtassunk teszteket, hogy ne az ugyfel vegye eszre elobb
  • popec CD: automatizalt pipeline, ami elvegez minden szukseges teendot a deploy soran (minimalizalva az emberi hibat, raadasul gyorsabb is)

Mindezek mukodhetnek on-prem infran is, de sokkal egyszerubb public cloudban uzemeltetni. Ha jol vannak implementalva a microservice-ek, akkor szepen skalazodik, cloud-bol tovabbi node-ok kerhetoek igeny eseten.

Ebbol nyilvan kovetkezik az, hogy ez nem az a KKV kategoria, ahol a sarokban fut par szerver, amire Jozsika felmasolja idonkent a sajat fejlesztesu exe filejait, hogy kiszolgalja a ~100 ugyfelet.

Par fontos dologgal meg kiegeszitenem a fentit:

A K8s nem csak a terheles lekezelesehez valo skalazasrol szol. A microservice-eket kulon emberek/csapatok fejleszthetik "fuggetlenul", ezert jol alkalmazhato agilis szoftverfejlesztesi kornyezetben. A forraskodok es IaC konfigok mind git repokban vannak tarolva, a valtozasok PR/MR-eken keresztul reviewzhatoak. A K8s deklarativ konfigokkal rendelkezik, mindig torekszik arra, hogy teljesuljon az elvart allapot, tehat hiba eseten megprobalja megoldani (self-healing).

Ha a fentivel "megvagy", akkor jon kepbe az opcionalis service mesh temakor. Szukseges-e szamodra, ad-e hozza vmi hasznosat, mennyire noveli a techdept-et, stb.

Ha ezen technologiak es knowhow-k birtokaban vagy, akkor mar nem szivesen valt vissza az ember regimodi deployment modszerekre (kezzel telepiteni szoftvereket vagy VM-eket, frissitgetni OS-eket). Ha en ujra kezdenem egy teljesen uj cegnel uj termekkel, akkor is ilyen alapokon raknam ossze a cloud infrat, akkor is ha a kozeljovoben nem lesz hozza jelentos forgalom. Mert ha kesobb lesz, akkor nem kell ujraepiteni az egesz cloud infrat, architekturat, alkalmazasokat.

ezek mind nagyon szépen hangzanak... elméletben.

Én a gyakorlatban leginkább azt látom, hogy ugyanezen 'fícsörök' eredményeként vastag csövön ontják a sz*rt az arcunkba.

Megszűnt a stabil verzió fogalma, mert egyből ~minden commit megy is élesbe. bug javítás sincs, hanem majd a köv release tartalmazza a javítást (meg újabb bugokat persze)

Persze vannk beépített tesztek, meg minden... meg devsecops... szóval elméletben minden jobb és biztosnágosabb is.

 

De biztos caak rossz a merítés, és csak a sötélt oldalt látom :D

zrubi.hu

Megszűnt a stabil verzió fogalma, mert egyből ~minden commit megy is élesbe. bug javítás sincs, hanem majd a köv release tartalmazza a javítást (meg újabb bugokat persze)

Igen, erről szól a CI/CD. A lényege az, hogy ha elbaszol valamit, akkor nem két-három hetet-hónapot kell visszagondolnod, hanem arra, hogy mit csináltál aznap. A bug akkor is belekerül, ha több hetes release ciklus van.

De biztos caak rossz a merítés, és csak a sötélt oldalt látom :D

Megöregedtél.

https://iotguru.cloud

Ennek egyébként nincs köze se a kuberneteshez, se a ci/cd-hez.

A Kubernetes-hez valóban nincs, a CI/CD-hez viszont nagyon is, mert a CI/CD az, ami miatt minden commit (potenciálisan) megy is élesbe.

Ezekkel is lehet release ciklusokat, stabil verziókat kezelni. Az, amiért nem ez történik független probléma. 

Nyilván, viszont vannak rá remek eszközök és folyamatok, például: https://github.com/semantic-release/semantic-release

https://iotguru.cloud

mert a CI/CD az, ami miatt minden commit (potenciálisan) megy is élesbe.

Nem értek egyet. a CI/CD egy eszköz, nem muszáj élesbe Deployolni és integrálni Continously :)  

Dolgozok olyan rendszeren ahol pl a CI arról gondoskodik, hogy teszt környezetre kikerüljön minden automatikusan, de ugyanúgy periodikus release folyamat van az éles környezet(ek)re.

És nem elképzelhetetlen egy olyan rendszer ahol a CI vezérel több verziót is akár. 

Az egy más kérdés, hogy van ahol trendet csinálnak abból amiről te beszélsz, mert a CI jó eszköz arra is. 

De nem muszáj a kettőt egybemosni.

Dolgoztam ott is, ahol CI/CD pipeline-ok és megoldások nélkül ment minden prodra a fejlesztő gépéről, csak mert pont nem akartak egy ilyenbe invesztálni.

Nem értek egyet. a CI/CD egy eszköz, nem muszáj élesbe Deployolni és integrálni Continously :)  

Nem érthetsz egyet, de az CI/CD az arról szól, hogy minden commit potenciálisan élesbe megy. A D különben sem deploy, hanem delivery. Ha a pipeline nem viszi el a kódmódosítást az élesig, akkor az egy félmegoldás, az csak CI, ahogy írod is a példákat rá.

Continuous Integration is the practice of merging all developers' working copies to a shared mainline several times a day.

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

https://iotguru.cloud

Rendben, de ez továbbra sem azt jelenti, hogy egyenesen, agyatlanul megy ki prodra amit a fejlesztő commitol.

De, egyenesen megy ki, az "agyatlanul" nem része a CD-nek, de az igen, hogy ha egy commit átment minden teszten, akkor bizony élesbe kerül. Naponta többször is.

Ugyanúgy része ennek a folyamatnak a review, a köztes környezetek, automatikus és manuális tesztelések, stb.

Ez és amiről eddig írtál, az csak CI és annak se az egésze.

https://iotguru.cloud

Mindegy, hogy most az szabalyos CI/CD vagy sem, attol meg nem feltetlen kell prodba deployolni minden egyes kommitot.

Nem, nem mindegy. Ha a commit nem juthat el a production környezetig, akkor az csak CI, ilyenkor CD nincs. Próbáljuk meg úgy használni a fogalmakat, amit azok fednek.

https://iotguru.cloud

Senki nem mondja, hogy nem juthat el, azt mondjuk, hogy nem azonnal és agyatlanul. 

https://continuousdelivery.com/implementing/patterns/

Versions of the software that pass all the automated tests can then be deployed on demand to further stages such as exploratory testing, performance testing, staging, and production, as shown below.

Wikipedia:

Continuous integration
Frequent merging of several small changes into a main branch.

Continuous delivery
When teams produce software in short cycles with high speed and frequency so that reliable software can be released at any time, and with a simple and repeatable deployment process when deciding to deploy.

Continuous deployment
When new software functionality is rolled out completely automatically.

De, basszus, azt jelenti. Kiemelsz egy mondatot a környezetéből és ráfogsz valamit. A végét is olvastad?

Kiemelek egy kurva fontos részletet: "When each deployment consists of tens of lines of code or a few configuration settings, it becomes much easier to perform root cause analysis and restore service in the case of an incident."

Igen, a CD ezt jelenti, hogy pár soros commit is kimegy élesbe, ha minden teszt zöld. Minden egyes bekezdésből az kiabál ki, hogy soha-de-soha ne várj össze két változást, pláne, ha egymástól függetlenek.

--

  1. Low-risk Releases are Incremental. Our goal is to architect our systems such that we can release individual changes (including database changes) independently, rather than having to orchestrate big-bang releases due to tight coupling between multiple different systems. This typically requires building versioned APIs and implementing patterns such as circuit breaker.
  2. Decouple Deployment and Release. Releasing new versions of your system shouldn’t require downtime. In the 2005 project that began my continuous delivery journey, we used a pattern called blue-green deployment to enable sub-second downtime and rollback, even though it took tens of minutes to perform the deployment. Our ultimate goal is to separate the technical decision to deploy from the business decision to launch a feature, so we can deploy continuously but release new features on demand. Two commonly-used patterns that enable this goal are dark launching and feature toggles.
  3. Focus on Reducing Batch Size. Counterintuitively, deploying to production more frequently actually reduces the risk of release when done properly, simply because the amount of change in each deployment is smaller. When each deployment consists of tens of lines of code or a few configuration settings, it becomes much easier to perform root cause analysis and restore service in the case of an incident. Furthermore, because we practice the deployment process so frequently, we’re forced to simplify and automate it which further reduces risk.
  4. Optimize for Resilience. Once we accept that failures are inevitable, we should start to move away from the idea of investing all our effort in preventing problems, and think instead about how to restore service as rapidly as possible when something goes wrong. Furthermore, when an accident occurs, we should treat it as a learning opportunity. The patterns described on this page are known to work at scale in all kinds of environments, and demonstrably increase throughput while at the same time increasing stability in production. However resilience isn’t just a feature of our systems, it’s a characteristic of our culture. High performance organizations are constantly working to improve the resilience of their systems by trying to break them and implementing the lessons learned in the course of doing so.

https://iotguru.cloud

Szándékosan félre akarod érteni amit írok?

SENKI NEM MONDTA HOGY NEM AZT JELENTI, HOGY PÁR SOROS COMMIT NEM MENNE KI ÉLESBE.

Amit írtam, hogy nem FELTÉTLENÜL automatikusan teszi ezt, és linkeltem is rá konkrét documentációt ahol leírják, hogy ON DEMAND.

Ki is emeltem neked, de ha szerinted ez a két szó mást jelent, akkor magyarázd már meg... 

A hülyeségen vitatkozol, szemantikán lovagolsz, írsz oldalakat, és próbálod magyarázni az igazadat olyasmiben amit nagyrészt nem is cáfoltunk...

Szándékosan félre akarod érteni amit írok?

Igazából az a baj, hogy azt se olvasod el, amit linkelsz.

A hülyeségen vitatkozol, szemantikán lovagolsz, írsz oldalakat, és próbálod magyarázni az igazadat olyasmiben amit nagyrészt nem is cáfoltunk...

Jajaja. Igen. Így van.

https://iotguru.cloud

Nem érthetsz egyet, de az CI/CD az arról szól, hogy minden commit potenciálisan élesbe megy.

Igen, "potenciálisan", de nincs olyan előírás, hogy csak az lehet igazi CI/CD, ahol minden egyből megy prodra. Sokszor igény sincs rá, a biznisz nem kommitokat akar látni, hanem értelmes, piacra vihető feature-öket.

+ manual release to production

És ha a pipeline egy adott ponton megakad (adott dátumig/kapcsolóig/triggerig minden nap elbukik a teszt) és onnantól automatikusan kitelepül? Gondolj rá úgy, hogy adott pontokon "megakad". (pont ahogyan amikor egy bármilyen több-szereplős teszt bukik és nem javul ki "még aznap".)

Értem én, hogy gőzgép, de mi hajtja?

És ha a pipeline egy adott ponton megakad (adott dátumig/kapcsolóig/triggerig minden nap elbukik a teszt) és onnantól automatikusan kitelepül?

És ha a fejlesztést teljes egészében megelőzi a részletes specifikáció, aztán a tervezés, viszont onnantól csak fejlesztünk?

Gondolj rá úgy, hogy adott pontokon "megakad". (pont ahogyan amikor egy bármilyen több-szereplős teszt bukik és nem javul ki "még aznap".)

Gondolj rá úgy, mintha csak egy sprint lenne. Attól még agilis, nem?

https://iotguru.cloud

Én értem: dolgoztam így is-úgy is :). Csak nem mindegy, hogy -saját- szolgáltatást fejlesztesz vagy esetleg olyan terméket amit pl lehet, hogy az átvevők nem akarnak folyamatosan teríteni.. ..persze a hotfix-ek kivételével..

A kérdés, hogy a *képesség* megvan-e rá, hogy ha kell menjen automata rollout. Az már döntés kérdése, hogy érdemes/szükséges/életszerű-e.

Én értem: dolgoztam így is-úgy is :)

Nem, nem érted. Nem lesz attól valami agilis módszertan, hogy annak nevezzük a vízesés modellt és mindenki játssza az agilis szerepét, de közben meg vízesés modellben megy a fejlesztés.

A kérdés, hogy a *képesség* megvan-e rá, hogy ha kell menjen automata rollout. Az már döntés kérdése, hogy érdemes/szükséges/életszerű-e.

Nem, ez nem képesség kérdése. Ez hozzáállás kérdése. Ez annak a kérdése, hogy érted-e, miről szól a CI/CD esetén a CD, vagy csak a meglévő negyed évente egy release szervezeti kultúrára lesz rámondva, hogy "nálunk CD van, csak adott dátumig minden nap elbukik a teszt". Lófasz van CD. A CD nem attól CD, hogy _milyen_ gyakran megy élesbe egy release, hanem arról szól, hogy _hogyan_ megy élesbe egy változás. Ehhez kell hozzá a CD gondolkodásmód, nem csak a fejlesztőnél, hanem a teljes szervezetben.

https://iotguru.cloud

Nem lesz attól valami agilis módszertan, hogy annak nevezzük a vízesés modellt és mindenki játssza az agilis szerepét, de közben meg vízesés modellben megy a fejlesztés.

Nem lennék ennek a szalmabábnak a helyében, jól megmutattad neki! :D

Ehhez kell hozzá a CD gondolkodásmód, nem csak a fejlesztőnél, hanem a teljes szervezetben.

Nyugodtan illusztráld egy példával, hogy például a lenti mini-esettanulmány hogy nézni ki igazhitű agilis CI/CD módszerrel.

Nem lennék ennek a szalmabábnak a helyében, jól megmutattad neki! :D

Nem szalmabáb, ez ugyanaz: nem csinálunk CD-t, mert kéthetente élesítünk nagy csomagokban, aztán vagy hotfix vagy a következő két hétben bugfix, de azt mondjuk rá, hogy CD van, csak a tesztek "két hétig törnek". Lófaszt van CD.

https://iotguru.cloud

Ez egy szintetikus példa volt számodra olyan esetre, hogy valaki vagy valami miatt a folyamat megakad(balfékség, hiba vagy a fentebb tárgyalt esetekben szándékosan: pl jóváhagyásig/feature kész/stb.) . "két hétig"-ről nem volt szó. Még oda is írtam utána: és nem javul ki "még aznap"

Nem értem a szőrszálhasogatásodat.

Van egy staging branch, ide jönnek a PR-ek a fejlesztőktől. A PR merge előtt lefutnak a tesztek, van peer review, és kvázi prod-ready kód kerül bele a stagingbe, ahonnan a pipeline automatikus rakja ki a change-eket QA-be. Bizonyos időközönként (lényegtelen - lehet sprintforduló, minden páratlan hét keddje, akármi) készül egy staging->master PR. Itt újabb, még részletesebb (és hosszabb) tesztek futnak le, a PO sign-offolja megfelelő indoklással az esetleges eltéréseket, aztán merge után viszi a pipeline az egészet prodba, megcsinálja automatikusan a release notes-ot, stb.

Én elfogadom, ha szerinted a fenti nem igazi CI/CD (lol), csak mert van 1 db manuális sign-off a sztoriban (ami btw jogszabályi kötelességünk), de tudnod kell, hogy a világ nagyobbik része nem ért veled egyet. 

miért ne menjen ki élesre a változás?

Mert nem volt ilyen kérés a PO-tól. Lehet gondolkodni ezen, de aki fizeti a zenészt, az rendeli a nótát. :)

Amúgy meg miért ne lehetne olyan igény, hogy PO signoff kelljen prodba menetelhez? A quant-világ határán dolgozunk valahol, teljesen mindennapos, hogy ha változik egy modell, akkor a regression tesztben hibák lesznek, de ez normális. Ilyenkor nem az IT-nak kell kalapálnia a teszteken, hanem a PO-nak kell elfogadni/elutasítani a változást. Annyi a különbség, hogy stagingben az IT signoffol, hogy ez szándákos volt, prodban a business, hogy az eredmény az, amit vártak.

Mert nem volt ilyen kérés a PO-tól. Lehet gondolkodni ezen, de aki fizeti a zenészt, az rendeli a nótát. :)

Akkor ne mondjuk rá, hogy CI/CD, ha ez egy CI + manual release workflow.

Amúgy meg miért ne lehetne olyan igény, hogy PO signoff kelljen prodba menetelhez?

Nem mondtam, hogy ne lehetne ilyet, annyit mondtam, hogy ez nem CI/CD. Ennyi erővel nevezhetjük vízesés modell alapú szoftverfejlesztést is egy sprintből álló agilis fejlesztésnek, csak át kell nevezni ezt-azt.

--

CI/CD esetén ennyi a kérdés: ha van egy commit, a build lemegy, minden környezetben zöld minden teszt, akkor miért ne menjen ki élesre a változás?

https://iotguru.cloud

Akkor ne mondjuk rá, hogy CI/CD, ha ez egy CI + manual release workflow.

De, nyugodtan mondjuk rá, értelmetlen az a gatekeeping, amit művelsz. Mi nem automata abban a folyamatban, amit leírtam? Hogy valakinek le kell okéznia a reg tesztet, ha változik az egyik output? Ne szórakoztass már. :D

Ennyi erővel nevezhetjük vízesés modell alapú szoftverfejlesztést is egy sprintből álló agilis fejlesztésnek, csak át kell nevezni ezt-azt.

Hát nevezd, max kiröhögnek.

CI/CD esetén ennyi a kérdés: ha van egy commit, a build lemegy, minden környezetben zöld minden teszt, akkor miért ne menjen ki élesre a változás?

Mert feature-öket telepítünk ki, nem commitokat. Ha már behoztad az agile-t a fenti hülyeséggel:

"Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale."

Az agile sem mond olyan baromságot, hogy minden commitot egyesével release-elni kell. Working software-ért kapjuk a pénzt, nem commitokért.

Hát nevezd, max kiröhögnek.

Látod? Pont ez történik, ha a CI/CD-nek nevezel valamit, ami nem az, max kiröhögnek, akik tudják, hogy mi a CI/CD.

Mert feature-öket telepítünk ki, nem commitokat.

Ismét megkérdezem: ha van egy commit, a build lemegy, minden környezetben zöld minden teszt, akkor miért ne menjen ki élesre a változás?

Mitől félsz? Nincsenek tesztek? Hiányosak a tesztek? Nem jók a tesztek? Nem jó a deployment? Kockázatos a deployment? Kieséssel jár? Mi a félelem alapja?

Az agile sem mond olyan baromságot, hogy minden commitot egyesével release-elni kell.

Nem is írtam ilyet sehol, hogy ezt az agile mondja. Ez a CD sajátossága. Ahogy nem lehet agilis fejlesztést csinálni úgy, hogy az egész szervezet ne gondolkodna agilis módon, úgy nem lehet CD-t se csinálni úgy, hogy az egész szervezet ne gondolkodna a CD módon. A CI könnyebben emészthető, annak nagy részét meg szokták ugrani sok helyen, a CD-t nem, csak rámondják, hogy CI/CD.

https://iotguru.cloud

Hogy automatizálod a test signoff-ot? A sor végén bármit csinálsz, valakinek oda kell ülni a géphez, be kell csatolnia a signoff evidence-t, és egy ijesztő weboldalon cserkész-becsületszavát kell adnia, hogy ez rendben lesz, nem fogja elrúgni a pöttyöst a felügyeletnél.

Nem mondtam, hogy ha törik a teszt, két hétig kell várni a signoffra. Ez a hülyeség az agilis projektekről meg a negyedéves release-ekről csak utólag került be a sztoriba. Két dolgot mondtam eredetileg:

  1. nálunk az IT nincs felhatalmazva arra, hogy önállóan elfogadjon egy modell output változást prodban. Stagingben oké (= szándékos a változtatás), prodhoz meg kell várni azt, akinek ehhez joga van (= helyes a változtatás), és
  2. nincs olyan üzleti igény, hogy minden commitból release legyen. 

Ez az 1 commit = 1 release önmagában nem teremt értéket. Az 1 feature = 1 release már igen, és felőlem ebből is csinálhatsz tetszőlegesen sokat egy nap, ezzel már semmi problémám nincs.

Hogy automatizálod a test signoff-ot?

Miért, hogy agilizálod a teljes előzetes specifikációt, rendszertervet, anyám tyúkját és toronyórát lánccal? Lesz egy sprinted és agilis az egész? Tudod, ez egyszerű: nincs nálatok CD, sose lesz CD, csak rámondod, hogy nálatok CD van.

nálunk az IT [...] nincs olyan üzleti igény [...] prodhoz meg kell várni [...] bla-bla-bla

Segítek: nálatok nem volt CD, nincs CD és sose lesz CD. Csak CI van.

https://iotguru.cloud

Élvezetes volt, könnyek szöktek a szemembe, mert eszembe jutott 10-15 évvel ezelőtti ugyanilyen viták a vízesés-agilis kapcsán, amikor agilist soha nem látott emberek próbálták megmagyarázni, hogy ha átnevezik a szervezőt PO-ra, a PM-et scrum master-re, a sprint pedig három hónapos, akkor ők voltaképpen agilisen dolgoznak, de mindent ugyanúgy csináltak, ahogy régen.

https://iotguru.cloud

Én még azt is elhiszem, hogy többet tud nálam a témáról, de az sem egy haszontalan képesség, ha az ember egy háromsoros problémaleírást tud értelmezni, és arra érdemben válaszolni. Mármint azon kívül, hogy "ez nem CD, biztos waterfallban dolgoztok és ez nem is CD!".

Szóval mi a CD? Az, hogy az utolsó junior commitol valami szart, akár veszélyeset, és megjelenik automatikusan prodon?

Igen. Ha van egy commit, a build lemegy, minden környezetben zöld minden teszt, akkor miért ne menjen ki élesre a változás? Mitől félsz? Nincsenek tesztek? Hiányosak a tesztek? Nem jók a tesztek? Nem jó a deployment? Kockázatos a deployment? Kieséssel jár? Mi a félelem alapja?

https://iotguru.cloud

Azért mert lehetetlen, de legalább is irreális olyan szintű és méretű automatizált folyamatot írni, ami egy teljesen új funkcióról eldönti, hogy az megfelel az üzleti elvárásoknak. Vagy hogy egy UI-ról eldöntse, hogy szépen és pontosan másolta-e a dizájnt.

Azért, mert egy commit nem jelent egy elkészült funkciót. Jelenthet egy próbálkozást, egy félkész állapotot, ami akár át is mehet a teszteken, attól még nem kéne kikerülnie prodra.

Azért mert lehetetlen, de legalább is irreális olyan szintű és méretű automatizált folyamatot írni, ami egy teljesen új funkcióról eldönti, hogy az megfelel az üzleti elvárásoknak.

Aham, akkor ott nem lesz CD, a CD alapjait vitatod.

Vagy hogy egy UI-ról eldöntse, hogy szépen és pontosan másolta-e a dizájnt.

Vannak UI tesztek, azon át kell mennie, az, hogy jól néz-e ki, az üzleti döntés, nem a CD része, lásd a deployment és a feature release különválasztása.

Azért, mert egy commit nem jelent egy elkészült funkciót. Jelenthet egy próbálkozást, egy félkész állapotot, ami akár át is mehet a teszteken, attól még nem kéne kikerülnie prodra.

Ha a build lemegy, minden környezetben zöld minden teszt, akkor miért ne menjen ki élesre a változás? Szerintem ott van az egyik alapvető problémád a dologgal, hogy szerinted, ha kimegy élesre, akkor attól az üzletileg is élessé válik.

https://iotguru.cloud

Sírok. Tényleg kezd olyan lenni ez a szál, mintha egy rakás 30 éve vízesés modellben dolgozó emberrel beszélnék arról, hogy mi az agilis fejlesztés.

Nem, nem kell minden egyes változtatást feature flag mögé tenni, de mindegy egyes feature esetén kell flag és egy környezetben élhet egymás mellett több feature is egyszerre.

https://iotguru.cloud

Kapom azt a feladatot, hogy alakítsak át egy űrlapon egy mezőt, ami ezentúl egy input helyett egy listányit kell hogy kezeljen. Hogy kerül ki ez prodra úgy, hogy azonnal ne látszódjon?

Feature verzióval. Pont ugyanúgy, ahogy például lekezeled, ha egy mobil alkalmazásról van szó, amit nem lehet egymillió felhasználónál ma délután 13 óra 12 perckor ütemezetten frissíteni, ki kell tolni egy-két héttel korábban a változást és amikor az üzlet úgy látja, hogy mehet a feature élesbe, akkor billen a feature flag, aki nem frissített, annál lehet jelezni, hogy frissítsen, a többiek pedig 13 óra 12 perctől azt látják, hogy textbox helyett list van. Ugyanígy A/B tesztet és canary release is csak így mehet.

https://iotguru.cloud

Ezt elmagyarázhatnád pontosabban, mert nem értem.

Az volt a kiindulási alap, hogy amit én lekódolok (átmegy az automatizmusokon) az kimegy prodba automatikusan.

Csak hogy biztosan egy lapon legyünk: Azt mondod, hogy a frontend amit a prod kiszolgál a felhasználónak tartalmazza a kódom.

Illetve még azt mondtad, hogy "nem kell minden egyes változtatást feature flag mögé tenni"

Nem teljesen értem mit értesz feature verzió alatt. Ugyanazt a koncepciót, mint a feature flag, csak nem boolean hanem szám, és a kódomban nem azt írom hogy if (featureenabled) hanem if (featureversion >=4)? 

Ha igen, akkor vedd úgy hogy amit eddig mondtam a feature flagekről az ugyanúgy vonatkozik erre.

Tehát még mindig nem látom hogy oldod meg a fenti problémát anélkül, hogy lényegében minden dolognak a működését minden egyes változtatásnál duplikáld és ifekkel rakosgasd körbe. 

Szerintem ez nem konkrétan így nézne ki, hanem ami mondjuk eddig egy statikus SPA volt, amit kiszolgáltál egy S3 / Blob Storage / akármi (+ CDN) kombóval, az elé kell most valami logika.

Ami nem feltétlenül baj, vannak járulékos előnyei, meg hátrányai is, ennyi. Ez nem is annyira érdekes, csak amikor nem one man show-ban fejlesztesz, hanem össze kell hangolni mondjuk 800 (nem typo - nyolcszáz!) fejlesztő munkáját egy terméken, akkor azért ez sem olyan triviális feladat. És akinek a kötözködés a hobbija, az máris nyithat egy új frontot a monolith-monorepo-microservice-konténer-nemkonténer-stb. vonalon. :)

Az volt a kiindulási alap, hogy amit én lekódolok (átmegy az automatizmusokon) az kimegy prodba automatikusan.

Igen.

Csak hogy biztosan egy lapon legyünk: Azt mondod, hogy a frontend amit a prod kiszolgál a felhasználónak tartalmazza a kódom.

Nem feltétlenül. Csak akkor, ha kell látnia.

Illetve még azt mondtad, hogy "nem kell minden egyes változtatást feature flag mögé tenni"

Igen. De nem kell minden változáshoz külön feature flag.

Ugyanazt a koncepciót, mint a feature flag, csak nem boolean hanem szám, és a kódomban nem azt írom hogy if (featureenabled) hanem if (featureversion >=4)? 

Igen, ilyesm.

Tehát még mindig nem látom hogy oldod meg a fenti problémát anélkül, hogy lényegében minden dolognak a működését minden egyes változtatásnál duplikáld és ifekkel rakosgasd körbe. 

Úgy, hogy ez nem feltétlenül a kódba kerül, hanem az infrastruktúra határozza meg, például gyakori, ha a mobil alkalmazás különböző verzióiban különböző cert van, ezt a cert-et lebontja az infrastruktúra valahol és ahhoz a verziójú service-hez kerül a kérés, ami az adott mobil verzióhoz tartozik. És ez tetszőlegesen működik bármivel is. Az van, hogy teljesen másképp kell gondolkodni CD esetén, mint ahogy most gondolkodsz.

https://iotguru.cloud

Nekem eszembe jutott egy példa: jogszabályi megfelelés.

És?

Persze ezt is körbe lehet programozni rendszerparaméterekkel, vagy időzítéssel, de talán ez egy gyakorlati eset.

Ez nem körbeprogramozás, hanem a CD egyik princípiuma, hogy a technikai élesítés és az üzleti élesítés külön van választva. Ahol ez nem történik meg, vagyis az üzleti élesítés azzal történik meg, hogy egy deployment történik production környezetben, ott nincs CD.

https://iotguru.cloud

Tehat akkor a Staging (ami Prod-like) kornyezetre rafogjuk, hogy az a technikai elesites, a Prod kornyezet pedig az uzleti elesites. A feature switch pedig a kliens oldalon van, hogy melyikhez kapcsolodik.

Hinnye. Nálatok az A/B teszt is úgy megy, hogy az A verzió a production környezetben van, a B verzió meg a staging környezetben?!

https://iotguru.cloud

Nincs nalunk olyan A/B teszteles, hogy az ugyfelek X%-at a B fele terelnenk. Szerintem igeny sincs ra. A "B" verziot a QA teszteli, majd ha mindenki rabolintott, akkor a "B" verzioval felulcsapjuk az "A" rendszert. Igazandibol ugy is mehetne az elesites, hogy swapoljuk az A es B szerepet. Csak hasznalunk nehany 3rd party backend rendszert, amik bekoteset szinten swapolni kellene, ami eleg macerasnak tunik. Egyszerubb "A"-ra deployolni azt, amit az ugyfelek fele elesitunk.

Ertem en, ebben vannak waterfall-szeru lepesek.

Szerintem igeny sincs ra.

De látod, ezt hiába magyarázod. Azt kéri például nálunk a biznisz, hogy ha nem megy át a regression teszten, akkor az IT ne kezdjen akciózni, hanem kérdezzék meg, hogy az új számok az elvártak-e. De nem, a bizniszt be kell csicskítani, különben nem lesz CD meg agile!!! :)

Ezért nagyon szórakoztató, amikor a hupon rendszeresen előkerül, hogy a köcsög menedzser nem érti, hogy mit kell csinálni. Közben az IT az, aki nem érti, hogy a menedzsert a "net income" felirat melletti számsor érdekli, a CI/CD csak egy eszköz arra, hogy ez a szám nagyobb legyen.

Ertem en, ebben vannak waterfall-szeru lepesek.

Ezt a waterfall baromságot eleve kár volt belekevernie Frankónak, az agile egy büdös szót nem szól arról, hogy mindennek prodba kell mennie. Pont ellenkezőleg, working software-t kell gyártani, nem commitokat.

De látod, ezt hiába magyarázod.

Nézd, én teljes mértékben értem, hogy nincs rá igény, se üzleti, se IT oldalon. Annyit mondtam, hogy a legtöbb helyen CI van + valamilyen manual workflow az élesítésre, nincs CD. Azóta folyamatosan jönnek azok az "igen, de..." hozzászólások, amiből az derül ki, hogy tényleg nincs CD. Csak valami maszatolás van, amit valamilyen hülye okból CD-nek neveznek, leginkább azért, mert mindig együtt látják leírva, hogy CI/CD.

Ezt a waterfall baromságot eleve kár volt belekevernie Frankónak, az agile egy büdös szót nem szól arról, hogy mindennek prodba kell mennie.

Analógia volt arra, hogy nem lesz attól valami agilis, hogy egy sprintből áll a projekt, van daily stand up és átnevezzük a szerepköröket. Azért volt analógia, mert pont ezt próbáljátok eladni, csak a CD kapcsán: összevárjuk a változásokat, egy nagyobb csomag megy ki, van release naptár, a deployment és a feature release ugyanakkor van, satöbbi. Minden olyan dolgot felsoroltok, ami CD antipattern, de ragaszkodtok hozzá, hogy nálatok CD van. Nem, nincs CD. Maszatolás van, amit CD-nek hívtok. Ugyanúgy, ahogy sok helyen nincs agilis fejlesztés, csak maszatolás van, amit agilisnek hívnak, de egy scrum master sírva és röhögve tépi fel az ajtót az első nap után.

https://iotguru.cloud

Nincs nalunk olyan A/B teszteles, hogy az ugyfelek X%-at a B fele terelnenk. Szerintem igeny sincs ra. A "B" verziot a QA teszteli, majd ha mindenki rabolintott, akkor a "B" verzioval felulcsapjuk az "A" rendszert.

Ez nem A/B teszt.

 Igazandibol ugy is mehetne az elesites, hogy swapoljuk az A es B szerepet. Csak hasznalunk nehany 3rd party backend rendszert, amik bekoteset szinten swapolni kellene, ami eleg macerasnak tunik. Egyszerubb "A"-ra deployolni azt, amit az ugyfelek fele elesitunk. [...] Ertem en, ebben vannak waterfall-szeru lepesek.

Nem, nem waterfall, egyszerűen ez nem CD.

https://iotguru.cloud

Nem. Van egy konfigurációs modulod ami megmondja, hogy a rendszer mely funkciói vannak bekapcsolva és ez runtime változtatható adott esetben.

Ez persze hozzáadott komplexitás.

Szerk: ez egyel följebb akart menni csak közben valaki más is kommentelt valszeg.

Szóval mi a CD? Az, hogy az utolsó junior commitol valami szart, akár veszélyeset, és megjelenik automatikusan prodon?

Amúgy erre külön írnám még azt, hogy igen, a system fragility test az akár az is lehet, hogy egy juniort odaengedünk, ugyanis nem mehet ki élesig olyan commit, ami problémát okozhat. Ha ilyen ki tud menni és bajt okoz, akkor az a rendszer fragile. Ahogy az infrastruktúra ott a chaos monkey vagy a toxiproxy is egy fragile teszt, úgy a forráskódra ott a junior, akinek a hibás kódját meg kell fogja a pipeline.

https://iotguru.cloud

Mert vannak olyan szituaciok, amikor egy bizonyos idopontban akarjuk elesiteni az uj feature-t, mert a PR reszleg ahhoz igazodik marketingileg, stb.stb.

Persze lehetne sok-sok kis feature switchekkel elrejteni az ujdonsagokat, de egyszerubb a stagingen elokesziteni/elotesztelni mindent es egy adott pillanatban deployolni prodra.

Nyilvan vannak olyan backend microservice-ek, ahol korabban deployolhatunk prodra, mert nem torjuk meg a backward compatibilitast, de vannak olyan frontend kodok ahol a JS kimegy bongeszobe, amibol kiderulhet korabban, mire keszul a ceg.

Mert vannak olyan szituaciok, amikor egy bizonyos idopontban akarjuk elesiteni az uj feature-t, mert a PR reszleg ahhoz igazodik marketingileg, stb.stb.

CD esetén antipattern ezt a release folyamattal csinálni.

Persze lehetne sok-sok kis feature switchekkel elrejteni az ujdonsagokat, de egyszerubb a stagingen elokesziteni/elotesztelni mindent es egy adott pillanatban deployolni prodra.

Látod? Van rá tiszta megoldás, tudod is, hogy mi az.

Nyilvan vannak olyan backend microservice-ek, ahol korabban deployolhatunk prodra, mert nem torjuk meg a backward compatibilitast, de vannak olyan frontend kodok ahol a JS kimegy bongeszobe, amibol kiderulhet korabban, mire keszul a ceg.

Miért kellene kimennie a JS-nek a böngészőbe? Igen, tudom, "mi így szoktuk". Ezért mondom, hogy a CD jelentős változtatást igényel a szervezet gondolkodásmódjában. A régi beidegződésekkel nem lehet CD-t csinálni. Ahogy nem lehet agilisen fejleszteni, ha mindenki a vízesés modellben tud csak gondolkodni. Másrészt mobilra nem tudsz másképp kampánnyal kimenni, ott jó előre teríteni kell a változást, mert semmi nem garantálja, hogy majd a naaaagy napon délben mindenki frissít.

https://iotguru.cloud

Miért kellene kimennie a JS-nek a böngészőbe?

Mert a kliens oldali JS igy mukodik. Azert fut vmi kliens oldalon a bongeszoben, mert vannak dolgok, amit nem akarunk backend oldalon processzalni, static JS kodra raadasul meg CDN is van. Ilyen kozegben pedig nem igazan jo a feature switch modszer, mert a JS kodbol az kinezheto.

Nyilvan a tokeletes CD miatt visszavalthatnank PHP-re, de inkabb akkor a tokeletes CD plecsnit nem kerjuk :)

Mert a kliens oldali JS igy mukodik. Azert fut vmi kliens oldalon a bongeszoben, mert vannak dolgok, amit nem akarunk backend oldalon processzalni, static JS kodra raadasul meg CDN is van. Ilyen kozegben pedig nem igazan jo a feature switch modszer, mert a JS kodbol az kinezheto.

Hogyne lenne jó a feature switch, ami megmondja, hogy melyik verziót fogja betölteni, satöbbi. Ne tegyünk úgy, mintha ez valami igen komplex dolog lenne, attól, hogy ott van CDN-ben vagy a szerveren egy adott JS, attól még nem kerül a böngészőbe.

Nyilvan a tokeletes CD miatt visszavalthatnank PHP-re, de inkabb akkor a tokeletes CD plecsnit nem kerjuk :)

Így van. Csak PHP-val lehet tökéletes CD-t csinálni.

https://iotguru.cloud

Ahhoz, hogy a bongeszo tetszoleges JS-t tolthessen le, expose-olni kell publikusan az osszes JS verziot.

Egyrészt miért kellene? Pontosan tudja a backend, hogy mikor kell odaadni az új verziót és mi az új verzió. CDN esetén is kezelhető szépen a verzió.

Ha eppen a v3.4.5 verzio az aktiv, attol meg a v4.0.0 is letoltheto es elemezheto a tartalma, hogy milyen ujdonsagok jonnek majd egyszer.

Nézd, láttam már pár ilyet, CDN-ben hash a verzió, ki nem találod csak úgy. Tényleg nem komplex dolog, van szakirodalma, nem kell feltalálni a meleg vizet sem, vannak rá kész megoldások, nem komplexebb, mint több API verziót tartani egyszerre.

https://iotguru.cloud

És egy önálló commit nem értelmezhető egy deployolható egységként, mert vagy hiányzik a funkció másik fele egy másik repóban, vagy egyszerűen egy befejezetlen munkáról van szó.

És? Akárhányszor meg tudom kérdezni, hogy ha van egy commit, a build lemegy, minden környezetben zöld minden teszt, akkor miért ne menjen ki élesre a változás?

Befejezetlen munka nem megy el az élesig, mert a teszteken nem megy át.

Ha hiányzik a funkció másik fele, akkor
a, az API verzió miatt ebből semmi gond nincs, kimehet élesbe,
b, addig nem megy át a teszteken, amíg nincs kész a másik fele.

Az egyik legfontosabb CD princípium az, hogy nem várunk össze két változást, minden változás deployable production környezetben automatikusan, ha minden teszten átmegy. A második legfontosabb CD princípium az, hogy a technikai élesítés és az üzleti élesítés nem egy időben történik. Ezek amúgy jól le vannak írva azon az oldalon is, amit beidéztél, csak szerintem nem olvastad el végig. Az üzleti terület nem akasztja meg a CD folyamatot. Az üzlet arról dönt, hogy egy feature mikor élesedik üzletileg.

https://iotguru.cloud

Hogy döntik el a tesztjeid, hogy a félkész munka ami amúgy buildel és a tesztek futnak sikeresen félkésznek számít üzleti oldalról?

Egyszerű: amíg félkész, addig a tesztek nem lehetnek sikeresek. Ha a tesztek sikeresek, akkor a módosítás nem befolyásolja az éles működést, mert más verzión érhető el, vagy használva valamilyen circuit breaker pattern, vagy egyéb pattern, ami erre jó.

https://iotguru.cloud

( trey | 2023. 04. 25., k – 08:58 )

Valójában ki és mire használja ezeket a technológiákat itthon

Én, mi semmire.

trey @ gépház

( andrej_ v | 2023. 04. 25., k – 09:17 )

Hogyne. Sajnos rendre őrült overkill dolgokkal találkozom/zunk ennek kapcsán. Képesek egyesek egy kisebb forgalmú belső céges weboldalt is konténerezni, hiszen az mindenre jó. Amikor cluster kell, meg ilyen bűvszavak jönnek, akkor pedig hátast dobnak a költségektől, hiszen a fejlesztő azt mondta, hogy csak úgy feldobják... hát fel, legfeljebb a felhőbe, aztán majd ott fizetik amennyit kell.

A skálázódás jellemzően ott hal meg, hogy maga az app nem kezel normálisan dolgokat, vagy annyira szuboptimális, hogy megy a veszekedés a fejlesztőkkel, hogy mégis hogyan gondolták a dolgokat. A helyzet pedig nehéz, mert marhára nyeregben vannak a vendor lockin miatt, és hogy brutál pénz szaladt már bele a projektbe, és nagyon nem akarnak velük összeveszni...

Képesek egyesek egy kisebb forgalmú belső céges weboldalt is konténerezni, hiszen az mindenre jó.

 Éppen tegnap kellett ránéznem egy olyan virtuális gépre, amire felzsúfolták a világ összes szoftverét. De, tényleg ... nagy buli volt  :D :D :D

trey @ gépház

Azt amúgy érted, hogyha konténerezés van, akkor a virtuális gépen pont hogy semmilyen szoftver nincs össze-vissza telepítve, csakis a container runtime? És akkor nem kell package verziókkal és inkompatibilitásokkal meg hasonlókkal játszani az üzemeltetésnek. Helyette minden konténer saját magán belül kezeli ezt, a konténer (pontosabban konténer image) mint egy kész szoftver, csomagokkal és függőségekkel együtt készen érkezik.

Saját maguk a vendor. Amikor a megrendelő elpattint pár milliót, vagy akár 10 milliót, akkor te mint sysadmin már mondhatsz bármit, lepattan róluk, hiszen a fejlesztő aszondta. Közben a fejlesztő azt nem vette észre, hogy 2 millió rekordos táblán futtat olyan lekérdezést, hogy egy 3x erősebb szerver is szétolvadna, hát például az ilyet. Aztán legyen HA, meg 101%-osan azonnal működjön. Nagyon bele vagyok fáradva, ahogy az legalább 1-2 hetente kiderül itt.

Én csak azt nem értem, hogy ennek mi köze van a konténerezéshez.

A fejlesztő specifikálja hogy neki mi kell, milyen paramétereket használ a konténer, de egyébként azt ugyanúgy ops feladat belőni, főleg magát a Kubernetes clustereket fenntartani, menedzselni, mint amikor kézzel telepítgeted meg frissítgeted a PHP-t a szerveren.

Speciel nem én szoktam belőni a konténert, ha egyáltlalán kérnek olyat, csak felülről látom. Úgy jön ide, hogy egy minioldal, egy világspecifikációt adnak le rendszerint, és amikor látják, hogy mi a valóság, akkor csodálkoznak. Egy google felhő sem két fillér, ha minden megfelelő HA cuccot megveszel hozzá.

A másik kapcsolódási pont, hogy épp a skálázódás, meg a rendelkezésre állás lenne a lényeg, és nem pont az, hogy felrántasz egy random konténert, és örülsz neki. Egy szem konténerrel nem vagy előbbre, mint egy VPS-sel. A skálázódáshoz kapcsolódik a fent említett fejlesztői hozzáállás az esetek többségében. Érdekes módon ahol a fejlesztők rendesen állnak hozzá, ott látják, hogy nem érdemes (még) elmenniük konténer irányba.

A kontéres technika előnyeit, meg jogosultságát nem vitatom, sőt lehet azt jól használni, de egyrészt van azaz igény amihez passzol, másrészt az egy komoly havi költséget jelent.

Egy szem konténerrel nem vagy előbbre, mint egy VPS-sel.

Dehogynem!

A konténer nem csak üzemeltetésnél de fejlesztésnél és tesztelésnél is rohadt nagy segítség. Ha nincs is szükséged skálázásra, akkor is van létjogosultsága a konténereknek.

Például hogy nagyon egyszerű felhúzni új környezeteket akár ideiglenes tesztelésre, akár állandó dev/staging környezetnek.

Vagy hogy nem kell teleraknod a fejlesztői géped "azzal az egy verzióval" az adott nyelvből, adatbázis kezelőből, stb, hanem az adott projekt igényeihez igazított környezett tudod fellőni nevetségesen egyszerűen (és lelőni amikor már nem kell).

Vagy hogy nem vagy egy adott oprendszerre limitálva fejlesztésnél, csak mert windows alatt nem működik az adott script / kód (vagy hogy nem kell multiplatform kódot írnod egy olyan apphoz ami úgyis linux szerveren fog futni, csak azért, hogy a windows-os fejlesztő gépén is menjen a cucc.

Ha csak annyit látsz a konténerezésből, hogy skálázni jó, meg hogy a VPS alternatívája, akkor nagyon nem látod a lehetőségeket benne.

Milyen jelentős költségről beszélünk amúgy?

Hogyne, ha ehhez megvan minden (iron to dev ,hogy úgymondjam). A költség úgy jelentős, hogy mire összeáll egy sokgépes rendes cluster, hiszen igény volt a HA, addigra a mondjuk havi 100k körülre számító kedves megrendelőt már kétszer élesztették újra. A dolog vége egy ízben az volt, hogy ja akkor végülis a fejlesztők a saját onprem clusterükön mégiscsak vállalják, miután azelőtt meg tiltakoztak...

Nekem nem kell ezt bemutatni, pusztán a kevéssé edzett megrendelői oldalt látom rendszerint. Ahol tényleg komolyan gondolják, ott vagy kifizetik a valamelyik cloud-ot, vagy beleöntik a pénzt a vasba és mindenbe, ami kell hozzá.

Jelentős == sokszorosa annak, mint amit a projekt alapból indokolna, vagy amit a megrendelő erre gondolt szánni.

Hát pedig van az a nézőpont ahol igaza van.
A konténer ott "nagyon más" mint egy VPS amikor a networkinget meg a perzisztenciát rendesen (cloud native) adod oda neki.
Attól hogy a "legacy jóska" be van pattintva egy konténerbe még inkább csak nagyobb szívás (prodban) (például) menteni mint ha egy vps lenne.
Kicsiben gondolkozunk, értsétek jól.

Az utóbbi hónapokban én is a saját kis (prod) docker compose-os okosságaimat (legacy jóskáimat)  költöztetem VPS-ekbe, mert sokkal egyszerűbb menteni és restartolni.
Nem változik annyit, nincs akkora terhelése hogy megérje a K8S.
A docker-compose szeret host restartkor felborulni, az lxc-vel meg semmi gond nincsen.

Van K8S is, de az még messze van az élestől.
 

Gábriel Ákos

Te nem érted a nézőpontot. Nem arról van szó, hogy van egy konténeres infra, és abban valaki 1-1 konténert kér. Hanem van egy zéró konténeres történet, majd úgy bele a semmibe legyen konténer, mert van egy hello world weboldalunk, amihez ám nagyonkell.

Igen, ezek nagyon pici igények, csak a buzzword végigment. Persze van olyan is, aki bérel VPS-t, magának szépen (remélem legalábbis) megcsinálja, és akkor úgy neki az jó. Ez megint egy másik történet, ezt ő tudja, kezeli, gondolom illeszkedik neki a többi dolgába.

Te nem érted a nézőpontot.

Értem a nézőpontot.

Hanem van egy zéró konténeres történet, majd úgy bele a semmibe legyen konténer, mert van egy hello world weboldalunk, amihez ám nagyonkell.

Ahhoz is nagyon hasznos, hogy konténerben gondolkodjon az ember, ha csak egy konténere van. Az, hogy konténerben gondolkodsz vagy sem, az meghatározó: ha nem konténerben gondolkodsz, akkor sose lesz kényelmes a konténer, mert ahhoz vagy szokva, hogy bármit át lehet írni bárhol, mert épp úgy kényelmes és ez az átírt állapot megmarad. Lásd: pet vs cattle devops mese.

https://iotguru.cloud

Egy szem konténerrel nem vagy előbbre, mint egy VPS-sel.

-1, uh dehogynem, a Dunába is ugranék, ha újra VPS-eket kellene terelgetnem

Még a saját kis hobbiprojektjeimnél is megváltás, hogy a teljes környezet egzaktul definiálható, és mondjuk tesztelésnél annyit kell csinálnom, hogy Githubon megnyomom az "ebből a branchből kérek egy játszóst" gombot, pedig ott semmi HA vagy skálázódás nincsen.

egyrészt van azaz igény amihez passzol, másrészt az egy komoly havi költséget jelent.

Az igények tekintélyes részével akkor még nem találkoztál. Van például egy kis házi felhasználású webappom: egy minimális JS frontend, egy MongoDB és a kettő között egy Python/Flask API. Ez eddig egy ötdolcsis VPS-en futott. Nemrég csináltam belőle konténerizált változatot (kb. egy óra meló, automata teszteléssel, minimál CI/CD-vel, stb.), a MongoDB-t meg bezavartam egy Azure-os CosmosDB alá. Most az 5 dollár helyett a havi költségem ~0.3 euró.

( _Franko_ v | 2023. 04. 25., k – 10:03 )

Valójában ki és mire használja ezeket a technológiákat itthon, hogy ilyen sokat kell róla beszélni és ilyen sok ingyenes és fizetős oktatást érdemes rá szervezni?

Kurva sokan, úgy képzeld el, hogy már egy utolsó pletykalap sportrovata is K8s alapokon fut hibrid felhőben, külön fejlesztői, teszt és éles rendszerrel, auto-scaling alapokon, mert a forgalom hullámzó, ha van egy-egy nagyobb sportesemény, akkor is ki tudják szolgálni, ha nincs, akkor meg visszaskálázva alig kér enni. Ez konkrétan azt jelenti, hogy havi szinten 50-100 dollárból elfut az egész automatikusan.

Ahol nem használják: nagy mamut cégek, ahol évek kellenek, mire technológiát váltanak; állam és közigazgatás, ahol nincs erre pénz/ember; kis lófasz cégek, ahol nincs erre igény, de amúgy is egyre több felhős szolgáltatást használnak; vagy olyan helyek mindenféle méretben, ahol a CTO megállt a fejlődésben 10-15 éve és/vagy ezért nem követelmény az, hogy a szolgáltatás úgy általánosságban működjön, függetlenül a terheléstől. Lásd a "megtámadták" az X állami/kormányzati szolgáltatást, mert kurvára nem igény a skálázhatósága.

Tényleg hatékonyabb, gördülékenyebb és kevesebb munkával feljeszthetőek és üzemeltethetőek ezek a rendszerek? Takarékosabbak vagy jobbak ezek bármi téren, vagy csak mások?

Tényleg. Ahol már van fejlesztő és nem dobozos terméket kell felpakolni, ott mindenképp. De a dobozos termékeknél is érdemes megnézni, hogy van-e container image és azt használni.

Én leginkább a kelet-nógrádi kisebb-nagyobb cégeket ismerem IT területen valamennyire, de amennyi rálátásom van, egynek sincs olyan jellegű IT feladata (sőt, kitalálni sem tudnék nekik, hogy ráerőltethessük a technológiát), amit ezekkel az eszközökkel lehetne hatékonyan megoldani, vagy amikhez kifejezetten ilyen eszközök kellenének. Persze egy elmaradott, aránylag ritkán lakott régió nem mérce még országon belül sem, ezért érdekődök.

Szerintem ott válik ketté a dolog, hogy az adott cégnek kell-e magas rendelkezésre állás vagy nem. Ha nem, akkor sok értelme nincs, viszont olyan szempontból meg hasznos ilyenkor is, hogy a virtualizációnál kevesebb overhead mellett lehet jól elszeparálni a szolgáltatásokat. Viszont, mivel eléggé kevesen értenek a területhez, ezért nem egyszerű embert találni a feladatra.

https://iotguru.cloud

Ez nem K8s miatt van, amióta rendszereknek kell beszélniük egymással M2M, azóta probléma az interfészek fejlesztése. Másrészt az eltúlzott microservice irány okozza inkább, mint a K8s, szoktam javasolni, hogy rajzoljuk fel a kis dobozkákat, kössük össze őket vonalakkal és nagyon gyorsan kiderül, hogy melyik dobozkák vannak egy domain-ben és beszélnek leginkább egymással, azokat nincs értelme külön tenni, mert csak szopás lesz belőle.

https://iotguru.cloud

Ez konkrétan azt jelenti, hogy havi szinten 50-100 dollárból elfut az egész automatikusan.

Inkabb 500-1000 dollar lesz az. Csak egy EKS magaban $0.1/ora, amihez azert kell nehany EC2 instance, hogy legyen tisztesseges monitoring, logging, stb. Kell meg nehany EBS PV-knek, cross-AZ es egress koltsegek, ELB, NATgw, DNS, miegymas.

Inkabb 500-1000 dollar lesz az. Csak egy EKS magaban $0.1/ora, amihez azert kell nehany EC2 instance, hogy legyen tisztesseges monitoring, logging, stb.

Miért is kell sok node EKS-ben, ha megveheted FaaS is a szolgáltatás jelentős részét? Static megy CDN-re, backend megy Lambda, satöbbi.

Kell meg nehany EBS PV-knek, cross-AZ es egress koltsegek, ELB, NATgw, DNS, miegymas.

Ezek aprópénzek.

https://iotguru.cloud

Most akkor vagy EKS, vagy Lambda, a 2 együtt nem megy. Szerintem te inkább Fargate-re gondolsz. Amúgy ez mind workload függő, simán lehet, hogy egy horizonal autoscaling jobban megéri mint Fargate alapú worker node (akár mondjuk reserved, előre fizetett instance-okkal, ami elég jelentős megtakarítást tud jelenteni (akár >50% is lehet), főleg, hogy azonos workload mellett a Fargate drágább. De szinte mindegy is, jobb közelítés néhány statikus node-dal számolni, nem nagyon hallottam olyan projektről még, akik nem úgy migráltak, hogy először csak működjön, mert még így is sokkal olcsóbb, mint a self-hosted infra, aztán majd később lehet rajta reszelni, hogy olcsóbb legyen. Szóval ha így számolsz az 500-1000 USD/hó egész jó közelíés, annál kevesebből nem lesz meg (és ugye normális esetben az egész legalább x2, mert kell nem árt egy teszt környezet is :) ). Ha meg ennyire szűkös a budget, hogy ez nem fér bele, akkor az a projekt tényleg nem k8s-re való, az az 1000USD az kb 25 munkaóra költsége lehet.

Persze, használhatsz Lambdát és EKS-t egyszerre, de egymástól függetlenül, bár lehet, hogy akkor félreértettem, amit írtál. De akkor nem értem, hogy hogy jön ide, hogy mi van még az EKS mellett, amikor arról beszéltünk fentebb, hogy egy k8s cluster mennyibe kerül. 500 USDből nagyjából 3 worker node jön ki, ennél kisebb clustert szerintem nem érdemes csinálni.

Persze, használhatsz Lambdát és EKS-t egyszerre, de egymástól függetlenül, bár lehet, hogy akkor félreértettem, amit írtál.

Akkor se értem azt, hogy "vagy EKS, vagy Lambda, a 2 együtt nem megy". Írtam, hogy hibrid felhő, van benne minden is, épp mi az olcsóbb vagy egyszerűbb.

De akkor nem értem, hogy hogy jön ide, hogy mi van még az EKS mellett, amikor arról beszéltünk fentebb, hogy egy k8s cluster mennyibe kerül.

Mert nem csak EKS van és nem csak EKS-t érdemes használni felhőben, van sok FaaS és SaaS cucc, ami olcsóbb, mint ugyanazt EKS-ben futtatni. EKS-ben azt érdemes futtatni, ami SaaS vagy FaaS drágább lenne, vagy nehéz lenne megoldani.

500 USDből nagyjából 3 worker node jön ki, ennél kisebb clustert szerintem nem érdemes csinálni.

Worker node-ból nem kell három, control-plane kell három vagy több, de az az Amazon dolga, adott esetben az auto scaler vagy manual scaler megoldja azt, hogy mennyi worker node kell, egy a minimum. Másrészt 3 kis worker node + egy EKS is csak ~100 USD havonta. Arról nem is beszélve, ha a cégnek van több alprojektje, akkor az EKS cluster költsége is többfelé oszlik el, mert nem feltétlen kell minden egyes fityfaszhoz külön EKS cluster.

https://iotguru.cloud

( gabrielakos v | 2023. 04. 25., k – 10:35 )

"Valójában ki és mire használja ezeket a technológiákat itthon, hogy ilyen sokat kell róla beszélni és ilyen sok ingyenes és fizetős oktatást érdemes rá szervezni? Hol vannak olyan komoly rendszerek, amik ilyen mértékű skálázhatóságot igényelnek?"

Mindenhol lehet értelme K8S-t használni ahol "szezonalitás" figyelhető meg a terhelésben - és ez a szezonalitás akkora hogy komoly skálázódást igényel.
Lehet ez egy nagyon pici site napon belüli terheléssel, de pl. ahol a kgfb váltást intézed (és állatira szezonális) ott a szezonalitás éves.

Aztán van az a nagyon ritka projekt amikor mainframe-et kell leváltani, na azt mással nem nagyon lehet. Ez persze nem KKV-téma.

"Tényleg hatékonyabb, gördülékenyebb és kevesebb munkával feljeszthetőek és üzemeltethetőek ezek a rendszerek? Takarékosabbak vagy jobbak ezek bármi téren, vagy csak mások?"

Kicsiben-közepesben biztosan nem. Van egy csomó más lehetőség ami ugyen nem skálázódik "az égig" de sokkal egyszerűbb.
Ahol én most a K8S hátrányát látom (egy a sok közül) az a nagyon gyakori release ciklus és rövid end-of-life. Ezért aztán funkcionális változások nélkül is folyamatosan updatelned kell.
Ha managed K8S-ed van akkor "csak" az alkalmazásodat, ha saját K8S akkor még az infrastruktúrát is.

Ami nagyon befolyásolni tudja a sikerességet az (itt is, jé) a hozzáértés.
Azaz legyen egy tényleg a K8S-hez passzoló, végiggondolt architektúra, megfelelő fejlesztési irányelvek betartva, megfelelő technológiák használva.
Nem a "legacy konténer beleb@szva" és "a legalján ott figyel egy single mysql" színvonal. 

És persze ezt folyamatosan, hozzáértően kell tutujgatni. CI/CD-t is, ahogy _Franko_ már leírta.
Hozzáértőt meg nem egyszerű fakasztani, általános hiány van. Ezért is van tere a képzéseknek, de K8S pro se máról-holnapra lesz az ember.
 

 

Gábriel Ákos

( secretx v | 2023. 04. 25., k – 11:38 )

Mi tervezzük a jövőben használni közepes-nagyobb környezetben főleg a skálázás illetve az elosztott rendszerek előnyei miatt.

A nagyobb feladat inkább meglátásom szerint azokat a folyamatokat, ci-cd dolgokat is beállítani, illetve leszokni az eddigi berögzült dolgokról, főleg fejlesztői oldalon :)

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

illetve leszokni az eddigi berögzült dolgokról, főleg fejlesztői oldalon

Én jártam sok-sok cégnél ahol K8s és CI/CD bevezetést támogattam, nos, a leggyakoribb négy mondat:

- [üzemeltető]: mi ezt nagyon szeretnénk, de hát a fejlesztők nem tudnak alkalmazkodni.
- [fejlesztő]: mi ezt nagyon szeretnénk, de hát az üzemeltetők nem tudnak alkalmazkodni.
- [menedzsment]: mi ezt nagyon szeretnénk, de hát az IT nem tud alkalmazkodni
- [IT]: mi ezt nagyon szeretnénk, de hát a menedzsment nem tud alkalmazkodni

--

Aztán az van, hogy mindenkinek van egy rakat szokása és berögzült hülyesége, amiről nem tud leszokni és a "DevOps" dolgai közül csak azokat szeretné megvalósítani, ami neki segít és teljes erőből keresztbe fekszik azoknak a dolgoknak, ami kompromisszumot igényelne a részéről.

https://iotguru.cloud

Na igen. ez ismerős :)

Olyasmikre gondolok főleg: Belép a szerverre dev, ops, ott szerkesztget konfigokat, esegleg gyorsan megpatkol dolgokat, logokat ott néz, ott van cserélve a cert akár, stb.

Ezeket primán kilehet váltani akarattal :D

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( Vamp | 2023. 04. 25., k – 20:20 )

A tema engem is erdekel! Ahol en dolgozom, egyaltalan nem kis ceg, (10.000 koruli letszamrol beszelunk, jelentos autoipari beszallito) nyilvan a dolgozok jo resze betanitott munkas, de (mint mindenhol) mindenhez szamitogepes rendszerek kellenek, (vallalatiranyitas, QM, management, munkaugy, HR, a termelesben kismillio aprosag... es akkor csak a magyar oldalrol beszeltem, az anyavallalat kb 10x-es IT hatterrel rendelkezik)

Ehhez kepest kontener/cloud/Kubernetes es tarsai a kanyarban sincsenek, ami van az zomeben Virtualizacio, VPS. Szinte minden MS termek, ami nem az valami "holdudvar" cucc, maximum MS kompatibilitassal. Pici Azure mar azert van, de kb csak "muszajbol".

En (peldaul az anyaceg felol) az igenyt sem nagyon latom az ilyen iranyu valtozasra. Nem hivei a kontenerezesnek/felhonek. Nem biznak benne, nagyon sztm nem is ismerik.

 

Szoval tenyleg erdekelne, hogy ilyen kozegben vagy egyaltalan ertelme pusholni a dolgot? Vagy ennek tenyleg csak a skalazhatosag (nalunk teljesen egyenletes a terheles, nyilvan) es/vagy hosting/brutal nagy meretnel van ertelme?

Szoval tenyleg erdekelne, hogy ilyen kozegben vagy egyaltalan ertelme pusholni a dolgot?

Ha nincs igény rá, akkor nem érdemes tolni, csak szopni fogsz. Beszélni érdemes róla, de a világot egyedül nem fogod megváltani.

Vagy ennek tenyleg csak a skalazhatosag (nalunk teljesen egyenletes a terheles, nyilvan) es/vagy hosting/brutal nagy meretnel van ertelme?

Igazából ennek akkor van értelme, ha a cégnél kialakul egy continuous delivery és DevOps kultúra, amit mindenki (egyformán) ért, a skálázhatóság és a high-availability csak bónuszként jön.

A rossz hírem az, hogy ilyen mamut cégeknél vagy nem vezetik be, vagy rosszul vezetik be: nem veszik át a kultúrát és gondolkodásmódot, hanem a saját korábbi működésükre szabják az egészet, aztán forgatják, mint medve a sünt, hogy miért is jó ez, mert a lényegi részeit nem értik vagy nem merik bevezetni.

https://iotguru.cloud

Én azt tanácsolom, hogy ne ölj bele felesleges energiát.

Egyrészről az anyavállalat IT-ja is tuti pörgött már a témán vagy folyamatban van. Másrészt egyedül nem fogod tudni megváltani a világot.

Minél nagyobb egy cég, annál több dolgot szeret házon belül megoldani IT-n belül. Persze bizonyos méret fölött rájönnek, hogy nem lehet.
Tedd fel a kérdést üzleti oldalról: Miért is lenne jó a cloud/K8S a cégnek? Nő tőle a termelékenység? Csökkennek a költségek? Javul a hatékonyság? Esetleg könnyebben lehet adóoptimalizálni? Tud a cég új piacokat szerezni? Ha ezekre nincs tiszta válasz, akkor veszett ügy a cloud. Szerintem.

Amit itt felsoroltal, azok kozul kb semmi sem igaz rank, marmint nem none a hatekonysagunk, ha nyomnank ezeket.... A fo ok ami miatt en (meg szerintem a kerdezo is) erdeklodik, hogy par eve mar tenyleg szo szerint a csapbol is ez a tema folyik... Hogy megvaltja a vilagot a cloud, a container meg a microservice (na es akkor a hiperkonvergenciarol, a szoftver definialt XY-rol meg nem is beszeltunk) 

Viszont neha (itt a hupon is) azt erzem, hogy ezen dolgok nagy reszet foleg a szoftverfejleszto cegek hasznaljak, egyeb (IT altal erintett) teruleten nem nagyon vannak jelen. Eddig azt hittem, azert mert foleg ezek a cegek innovalnak erosebben, de akkor lehet hogy inkabb azert mert letjogosultsaguk sincs igazan ezen a koron kivul?

A cloud egy hype. Sokan felülnek a vonatra. Nem mindenkinek éri meg.

A szoftverfejlesztőknek több okból megéri ez a vonal (cloud, CI/CD, sw defined IT, IaC stb.), mivel ők érdemben azonnal pénzre tudják váltani ezeket. Nem mindegy, hogy az IT viszi vagy hozza a pénzt.
Például egy gyorsabb release folyamat üzleti szempontból nézve eladhatóbbá teszi a terméket új ügyfeleknek ("Mi nem évente, hanem naponta adunk ki új verzió. Ha hibát jelentenek, akkor azt képesek vagyunk napon belül javítani"). Továbbá több ügyfelet is tud kiszolgálni így a szoftverfejlesztő cég.

Az se mindegy, hogy egy régóta létező cégről van szó, meglévő folyamatokkal, szokásokkal, kényszerekkel vagy a cég most indul (zöldmezős cég). Utóbbi jobban ki tudja használni a modern IT előnyeit.

Hasonló környezetben azt látom, hogy a használt szoftverek jó része nem alkalmas a konténerben való futtatásra.
Ha meg mégis dockerben fut valami, az leginkább egy VM-en belül egy mezei dockerben történik, azért hogy a havi patchelések ne tegyenek keresztbe az enterspájz szoftvernek.

A konténeres technológiát rádásul nem önmagában kell értelmezni, ahhoz kell még egy teljesen más megközelítést igénylő vállalati security is, ami szintén egy extra pénznyelő réteg. Illetve  a hagyományos üzemeltetésii folyamatokkal sem feltétlen fedhető le egy masszívan konténerező környezet.

A nagy cégeknek a már meglevő pár tucat (pár száz) szerveres hypervisor farmos környezetébe  beilleszteni egy konténeres infrát, ami teljesíti az elvárt megbízhatósági paramétereket csak akkor éri meg, ha van megfelelő mennyiségű rendszer ami alkalmas a konténeres üzemre, és ez olcsóbb, mintha a hagyományos VM környezetbe lennének berakva.

Ez ugyanolyan paradigmavaltas mint anno a bare-metal -> virtualizacio volt. Regen is ment a nyavajgas, hogy jajj hogy monitorozzuk, mi lesz a networkkel, a securityvel, zavarjak egymast, ilyesmik. Aztan eltelt jonehany ev es most mar tok termeszetes hogy VM-ekkel vagyunk korulvele. Szerintem ugyanez fog tortenni a kontenerizacioval. Lehet ellenkezni, de elobb-utobb termeszetes lesz a jelenletuk. Nyilvan okkal.

Egyetértek.

Annyit azért hozzátennék, hogy teljesen más helyzetben vagyunk az IT-ban, mint 1998-2004 között. Vissza lehet tekinteni, hogy fizikai vasakon mit is értettünk IT security alatt akkor. A komplexitás meg csak nőtt.

Ma is megvan a maga helye a bare-metal szervereknek. Használják nem is egy helyen. Ugyanígy megvan a maga helye a virtualizációnak, hibrid cloudnak, konténerizációnak, cloudnak. Csak idő kell, amíg kiforrja magát.
Nagyon veszélyes, ha valaki csak az egyikben tud gondolkodni és nem a célhoz választja meg az eszközt. Szerintem.

Paradigmaváltás, de teljesen más és nagyobb horderejű:

- virtualizáció elsősorban az üzemeltetésnek szól, konténerek&co a fejlesztőknek

- virtualizáció kvázi azonnal bevezethető: a szoftver réteg (idő és pénz) nem változik, konténerek&co esetén kvázi újra kell mindent csinálni - ez években mérhető

- virtualizációval az üzemeltetést egyszerűsíti, konténerek&co a fejlesztést segíti, üzemeltetést bonyolítja sok új technológiával

- virtualizációból kisebb és nagyobb is tud profitálni, konténerek&co inkább nagyobbaknak szól

- virtualizáció alapvetően házon belüli kérdés (üzemeltetés), szoftverfejlesztés nemcsak házon belül történik (termék/szolgáltatás)

Például van egy szoftverem: nem hogy azt nem látom, miért érné meg nulláról újraírni, de azt sem látom, ha ez megtörténne, akkor ki tudná használni. Vannak kisebb és nagyobb ügyfelek, amennyire rálátásom van, sehol nem tudnák befogadni, esetleg nagyobbak anyacéghez kellene fordulniuk, de ez innentől kezdve mind üzemeltetésben, mind adminisztrációban olyan teher, amit kizártnak tartok, hogy bevállalnának.

Emiatt úgy gondolom, hogy sokkal tovább fog tartani a hasonló mértékű elterjedése. Legfeljebb akkor, mire a világ teljesen átfordul felhőszolgáltatásokba, IaaS is kikopik. Ez nem 5-10 éves lépték.

A konténereket (microserviceket, business-contexteket) akkorára kell "szabni" hogy "pont jó legyen".
Nem érdemes a buzzwordökre hallgatni. 

Ha nem nagyon szarul van megírva a szoftver akkor gyakorlatilag nulla erőfeszítéssel konténerizálható és "nem lesz rosszabb" mint előtte volt.
Hogy mennyivel és mikor (és kinek) lesz jobb azt meg majd kitalálod.

Ez az az irány amikor a "legacy motyót" belapátolod egy az egyben és utólag állsz neki szabdalni kisebbre ahogy érdemesnek látszik.
Nagy microservice migrációs projekteknél egy egy jellemző irány.

Gábriel Ákos

virtualizációval az üzemeltetést egyszerűsíti, konténerek&co a fejlesztést segíti, üzemeltetést bonyolítja sok új technológiával 

Egyoldalú megállapítás. Virtualizációt ugyanúgy menedzselni kell, ugyanúgy fel kell húzni és karbantartani a virtualizációs megoldást, menedzselni erőforrásokat, stb. Ott menedzselheted a hostot és a virtuális gépeket. Aki pedig nem jártas a virtualizációban, annak ugyanúgy "sok új technológia" annak a szoftveres hátterét megismerni. 

virtualizációból kisebb és nagyobb is tud profitálni, konténerek&co inkább nagyobbaknak szól

Szerintem ez utóbbi tévedés. Konténerizáció ugyanúgy hasznos kicsiben is. Ismétlem magam: Nem kubernetesben kell gondolkodni konténerizáció alatt. Az fejlesztésnél és tesztelésnél is rohadt nagy előny, hogy reprodukálható környezeted van, utóbbi főleg ott jó ahol nincs pénz, idő, szakember külön környezeteket menedzselgetni. 

Például van egy szoftverem: nem hogy azt nem látom, miért érné meg nulláról újraírni

Tévhit, hogy újra kell írni. Kismillió szoftver van konténerizálva amik annó nem arra készültek, és futnak vígan. Jó eséllyel a te szoftvered is konténerizálható, esetleg apróbb igazítások vagy kompromisszumok mentén.

Fizikai szervereket is kell(ene/ett) menedzselni, legfeljebb kevésbé történt meg, mert kevésbé mászott az ember kezébe, virtuális gépek esetén megkerülni sem tudod. Nem állítom, hogy nem jár plusszal, csak azt állítom, hogy nem állt feje tetejére minden, lehet/lehetett a fizikai szervereket akár egyenként is költöztetni, tetszőleges tempóban.

Mondandómat fordítva közelíted meg: nem azt mondom, hogy nem lehet konténerbe tenni, hanem azt mondom, ha konténerbe teszem/átírom, nem megyek vele semmire, mert látókörömben nem tudják fogadni. Más szóval (egyelőre?) a konténeres környezetek sokkal ritkábbak.

Másrészt - értelmezésem szerint és a cím szerint is - ez a téma nem arról szól, hogy miként gyömöszöljük bele a meglévő monolitokat egy szatyorba, hanem a Kubernetesről. Még a "service mesh" is említésre került a kiírásban, többen is felvetették, hogy jó-jó, de náluk a kanyarban sincs. Szerintem pont azért nincs a kanyarban, mert sokkal átfogóbb, mint a virtualizáció, a hardveren kívül szinte minden más/új.

Most meg lehet. De felno majd egy olyan DevOps generacio, akik mar a kontenerizacioban szocializalodtak, ok majd csak kopni fognak olyan szoftver lattan, ami nem deployolhato K8s clusterba. Ha emiatt masik beszallitot valasztanak, akkor gyorsan atgondolod a fentit.

Nyilvan business sector fuggo a terjedese. Van ahol hallani se akarnak rola, de pl. a telco sectorban az 5G-s alkalmazasoknak mar cloud native-nek kell lenniuk. Azon beszallito labdaba se tud rugni, aki ezt nem tudja meglepni.

Persze a telco enterprise, a skálázás és a hibatűrés mindig is alapelvárás volt (kellett volna legyen).
K8S-el ez "jön". A licenszeken, vason, emberi erőforráson bőven többet fognak mint amit a  K8S komplexitása hozzáad.
Economies of scale, ilyen egyszerű. Az AWS-nek is pont ezért éri meg.
 

Gábriel Ákos

Meg köpni fognak akkor is, ha valami alacsonyabb szinten (network, storage, etc..) nem működik. Bár olyat is láttam, aki egy kis shell hibaüzenettől hátralépett. Aki meg ezekhez ért, az bottal se piszkálja a k8s-t. Lesznek itt szép kis egymásra mutogatások még.

Miért volna a devops dolga azzal az alacsonyabb réteggel foglalkozni? Azok a szakmák és rétegek amik eddig voltak ezután is lesznek, csak max a határok tolódtak el, és az eszközök változtak. 

Ezután is lesz szakember aki a hardvert, hálózatot építi, aki a node-okat telepíti, aki a kubernetes-t adja, adminisztrálja, és ettől tök független az, aki a service-eket, pod-okat definiálja, és a konténereket gyártja. 

Ne foglalkozzon vele, de azért annyit tudjon már megcsinálni, hogy indít egy shellt a konténerben, és abban legalább egy curllal megnézze, hogy mi a francért nem éri el azt, amiért épp sír, hogy nem megy. Persze remélhetőleg van valamilyen shell a konténerben, meg curl (vagy wget). Mert azért azt elfelejtik sokan, hogy nem csak yaml fájlokat kell írni, hanem néha debuggolni is.

Ebben egyetértünk, bár abban nem, hogy közvetlenül a futó konténerben kézzel kéne turkálni.

Nagyon művi és hiányos a fenti felvetés. Mi a hiba? Mi az ami miatt egyáltalán a fejlesztő vagy devopsnak be kéne másznia a konténerbe curl-t futtatni?

Ideális esetben van log amiből konkrétan látszik a probléma, nem tudom mi pluszt ad, ha te kézzel random címeket hívogatsz curl-lel.

Életem. :)

Kedvencem amikor "hálózati hiba" ez van a logban.

És kiderült hogy rossz az LDAP jelszó. :)

És egyébként valóban igaz, ha normálisan meg lenne csinálva a logolása az appnak akkor nem kéne megkérni az embert hogy curl-al, ldapsearch-al whateverrel hívja már meg az átkozott endpointot hogy "mitirki".

Számlázó rendszernél SQL hiba jelentkezett, a szoftver a naplójába annyit írt, amennyit az SQL szerver válaszolt, hogy a "művelet végrehajtása nem sikerült".

Mondom a fejlesztőnek, jó lenne többet tudni, mert attól, hogy nem sikerült, még nem 100%-is biztos, hogy az SQL szerver rossz (amit mi üzemeltetünk), hanem akár a program (amit ő írt) is akarhat olyant csináltatni, amit nem lehet...

Azt mondja, ő ez ügyben nem tud semmit tenni, mert kiíratja a naplóba a szerver válaszát, és részéről ennyi. A válasz meg annyi (mondja), hogy a művelet végrehajtása nem sikerült, ergo az SQL szerverrel van a baj, nem a programmal.

Mondom, ez oké, de azért segítene, ha azt is kiíratná a naplóba, hogy a program mi szeretett volna csinálni, ami nem sikerült... Mert a napló annyi volt, hogy "Program indulása", "SQL végrehajtása nem sikerült", "Program kilépett". Na ebből valóban nem könnyű hibát keresni...

Aztán naplóztattam kicsit az SQL műveleteket, és segítettem neki megtalálni az a SELECT-et, ami hibás volt és leölte a programját. De persze mindez úgy kezdődött, hogy az ügyfél veszekedett velem, hogy a program szuper, a fejlesztő megmondta, hogy mindenhol máshol jó, csak náluk nem, tehát az általunk üzemeltetett SQL szerver mindig rossz, és nem tudják a rendszert nyugisan használni...

Uh de ismerős sztori. Egyszer lehet jó fej az ember az ilyen fejlesztővel aztán már súlyos sörökbe kerül bármilyen infó.
A ratyi naplózás meg a minőségellenőrzés teljes hiányát mutatja. Nincs senior/lead ezek felett? Esetleg ezek a seniorok?

Gábriel Ákos

Én már kaptam azért is, hogy az általam, az üzemeltetés segítésére írt kis Python script-be minek az a sok naplózás meg azt még választani is lehet, mennyit naplózzon, tök felesleges. Ja, mondom amíg jól működik, addig felesleges, azért lehet kikapcsolni. Aztán mikor baja van, nem olyan rossz, hogy meg lehet nézni hol hal meg...

Más meg a több tízezer soros monolitba se tesz jóformán naplózást, mert minek, a kód tökéletes és a futtató rendszerek sem hibáznak soha, mert azokat is olyan tökéletes üzemeltetők viszik mint amilyen tökéletes programozó a szoftvert írta.

Ez tipikus selection bias. :)

Mondom a másik oldalát:

- furcsa hiba, szopunk fél napot, hogy lokalizáljuk, valószínűleg az okozza, hogy szmötyi került az izére, nosza, telefon üzemeltetésnek, hogy szmötyi van-e az izén.

- áh, nincs szmötyi az izén.

- köszi. szopunk két napot, debug log, egyebek, biztos, hogy szmötyi van az izén. telefon üzemeltetésnek.

- dehogy, nincs szmötyi az izén, innen látom.

- köszi. további két nap szopás, minden más hibát kizárunk, telefon üzemeltetésnek, hogy biztos, hogy szmötyi van az izén, ott van egy részletes debug log.

- várj, hm... hm... most jó?

- ó, megjavult. mit csináltál?

- én? semmit.

--

Kb. egy évtizedes tapasztalatom alapján azt mondanám, hogy kb. ugyanannyi balfasz van a fejlesztés és üzemeltetés területén... amíg nem jutsz el oda, hogy fel tudd ismerni a balfasz kollégát és bele tudd nyomni az orrát a saját szarjába és minden terület védi a saját emberei seggét, addig ott nem lesz DevOps szemlélet.

https://iotguru.cloud

Hát, én tényleg csak a saját oldalamat látom a letöbb esetben ügyben, a másikat nem (elég mélyen).

De elektronikai, hardveres, programozási ismereteimnek hála előrébb tudok lépni ilyen hibák kiderítésében annak ellenére, hogy üzemeltető vagyok.

Az teljesen igaz, hogy minden IT területen vannak alkalmatlanok szép számmal, és jellemzően egymásra mutogatnak. De azt akkor sem szoktam érteni, hogy egy sok-sok ember által sok év alatt kifejlesztett (tételezzük fel statisztikai alapon, hogy stabil) szerver szoftver miért valószínűbb minden fejlesztőnek, hogy rosszul működik, mint egy most, néhány ember által fejlesztett egyedi szoftver, ami kapcsolódik hozzá...

Mondjuk ez a sima felhasználóknál is megvan, mert ha valakinek nem megy el egy e-mail-je, akkor is tuti az e-mail szerver van elromolva, azt kell megnézni az üzemeltetőnek, csak ott lehet a hiba.

Ilyenkor célszerű a feleket összezárni egy szobába 2-3 napnyi hideg élelemmel.
Be kell vezetni cégen belül a részlegek közti számlázást. Az általad írt esetben az ops team fog tartozni a dev teamnek. Nem számviteli értelemben, hanem csak úgy elemzés szinten. Aztán gyorsan kiderül, hogy hol a tüske.

- én? semmit.

Na ilyenkor megkérdezném, hogy mi alapján eszközöl bármilyen változtatást is a rendszerben? Akár ops, akár dev. Ki engedélyezte? Hol van hozzá a normális change? Tudom, kis cégnél ilyenek nem jellemzőek. Sajnos.

Ilyenkor célszerű a feleket összezárni egy szobába 2-3 napnyi hideg élelemmel.

Gratulálunk, feltaláltad a DevOps szemlélet egyik aspektusát.

Be kell vezetni cégen belül a részlegek közti számlázást. Az általad írt esetben az ops team fog tartozni a dev teamnek. Nem számviteli értelemben, hanem csak úgy elemzés szinten. Aztán gyorsan kiderül, hogy hol a tüske.

Persze, növeljük a felesleges komplexitást, attól majd jobban haladnak az ügyek. :D

Na ilyenkor megkérdezném, hogy mi alapján eszközöl bármilyen változtatást is a rendszerben? Akár ops, akár dev. Ki engedélyezte? Hol van hozzá a normális change? Tudom, kis cégnél ilyenek nem jellemzőek. Sajnos.

Nagy cégnél se jellemző, hogy minden change le van dokumentálva. A legtöbb változás az 'áh, úgyse lesz hatása semmire' dobozba kerül és ez 95+ százalékban igaz. A maradék pár százalék miatt meg emberhetek mennek el a nyomozásra, hogy mitől baszódott el valami úgy, hogy senki nem változtatott semmit sehol.

https://iotguru.cloud

Gratulálunk, feltaláltad a DevOps szemlélet egyik aspektusát.

Ennyi erővel akkor én már 20 éve is devopsoztam. :D

Persze, növeljük a felesleges komplexitást, attól majd jobban haladnak az ügyek. :D

Ez nem növeli érdemben a komplexitást. Viszont rengeteg információt jelent a pénzügynek, vezetőségnek. Persze, ha szándék sincs rá, hogy kiderüljön, hogy ki/mi égeti a cég pénzét...

Ennyi erővel akkor én már 20 éve is devopsoztam. :D

Látod? Aztán mégse megy a DevOps gondolkodás.

Ez nem növeli érdemben a komplexitást. Viszont rengeteg információt jelent a pénzügynek, vezetőségnek. Persze, ha szándék sincs rá, hogy kiderüljön, hogy ki/mi égeti a cég pénzét...

Hogyne növelné a komplexitást, drágább lesz minden ettől, mert ott fog mindenki állni, adminisztrálják a semmit és dobálják egymásnak a feladatot, ami csak időt visz el és égeti a pénzt... ez az egyik dolog, ami például a DevOps szemlélethez képest igen messze áll. Ebből gondolom azt, hogy csak távolról gondolod úgy, hogy valaha is a közelében jártál DevOps jellegű dolgoknak.

https://iotguru.cloud

Megnézném a stack trace-t, amiben ott van a hibakód. Ha fel se épül a kapcsolat megnézném hogy jó-e a konfiguráció, az URL, hogy a szolgáltatás maga elérhető-e vagy sem, majd átadnám a hibát annak akinek a felelőssége biztosítani konfigurálni a kubernetes-ben futó alkalmazások hálózat hozzáférését.

Viszont pl nem az én dolgom elkészíteni a kubernetes konfigurációját az alkalmazásnak, hanem a devops-é. Szóval innentől az ő feladata. 

De az ő feladata is véget ér valahol, valószínűleg a vasat, a kubernetes hátterében futó OS-t már nem ő menedzseli. Tehát ha nincs valami policy vagy valami konfiguráció ami okot adna a hibára, akkor innentől megy a következő rétegnek a hiba.

Élő példa, ami számtalanszor előfordult: Az alkalmazás nem működik. A logokban nincs érdemi hibaüzenet, sőt, gyakran a hibáról semmilyen üzenet nincs.

Kinek kellene ezt a hibát megoldania? Hogyan?

A tipikus válaszok.
Ops team: Minden működik, nem lát érdemi hibát OS, hardver stb. szinten. Biztos a fejlesztők basztak el valamit megint! Debugolni kellene.
Alkalmazás üzemeltetés: Hibát reprodukálni tudják, de nem tudják, hogy mi lehet az oka. Mi a frászért nem lehet ezt normálisan üzemeltetni, a naplókban nincs semmi!
Network team: Minden eszköz rendben üzemel, nem látnak hibát. Már megint mit csesztek el a fejlesztők?
Storage team: Minden rendben működik, nem látnak hibát.
Dev team: A fejlesztői környezetben megfelelően működik, ők nem értik, hogy miért lenne hiba. A tanult üzemeltetők még egy ilyet se tudnak üzemeltetni!
Devops team: Biztos egy új deploy vagy konténer restart megoldja a dolgot.
Helpdesk team: Már a 10. ticketet nyitják a hibával kapcsolatban. Oldja meg már valaki, pleeeeease!

A konkrét eset mondjuk egy konténerben futó java processz esetében a processz megdöglését és automatikus újraindítását eredményezné.
Erről az event-ről simán tud akár a k8s akár a docker-compose logjára ráültetett monitoring, alkalmazáson belül semmit nem is kell csinálni.
Esni-kelni fog, igen. A debugolása ugyanolyan szopó mint amit a kollega leírt igen. 
De nem vagyunk vakon, tudunk róla, a monitoring jelzett. Ez a hatalmas különbség. 

Gábriel Ákos

Rosszul tartod, az a baj. 
A monitoringnak nem az a dolga hogy minden lehető és lehetetlen hibáról _pontosan_ megmondja hogy "mi van". Hanem (többek között) az, hogy megmondja, hogy az alkalmazás/szolgáltatás/példány/adatbázis/microservice/container/whatever egészséges vagy sem.
A "megdöglött és lövésünk se volt róla hogy megdöglött" szituáció az nem azt mondja nekem hogy "nem volt elég kifinomult a monitoring / belefutottunk egy váratlan eseménybe" hanem azt hogy egyáltalán semmilyen monitoring nem volt és bele is szartunk magasról. Asszem érezhető hogy a kettő között vannak fokozatok.

80/20 szabály alapján általában nem érdemes nagyon túlszofisztikálni a monitoringot sem, de néhány jól irányzott méréssel az idő 99.9%-a lefedhető. 

Gábriel Ákos

Mert ha magadba szívod a DevOps kultúrát, akkor már semmi olyan hiba nem fordulhat elő, ami után nyomozni kell. Ott a k8s magasságában persze nem fog látszani a flappelő switchport meg a bizonytalan UTP kábel, de ha ezeket kizárod a világodból, attól még léteznek.

Indulás / újraindulás: kifut a timeoutból (pl: 60 mp), ezért újraindítja magát a szoftver vagy a mgmt tool. Ez akár a végtelenségig mehet. Ilyenkor kell kézzel helyreállítani és a mélyére ásni a problémának. Ez a probléma általában olyan szokott lenni, ami addig sose fordult elő.

Úgy, hogy a gyakorlat a mai napig az, hogy a szoftver felépíti a kapcsolatot, és onnantól úgy tekinti, hogy az az örök időkig úgy lesz, ha csak nem szűnteti meg készakarva. A valóság meg nem mindig ez. Pláne nem ez a konténeres dinamikus világban.

Aztán ezt a szoftvert monitorozzák, hogy újra lehessen indítani, ha a kapcsolat (ideglenes) megszakadása miatt megállna, mert a fejlesztő nem hajlandó bele ellenőrzést és újracsatlakozást írni, javítsa meg a szakadozó vonalat az üzemeltetés. De a szoftver egyébként is lassú mint a bűn, így az égbe van emelve a monitoring-ban a timeout, ami felett hibásnak minősítené és próbálná újraindítani. De aztán eljön ez a pillanat, újraindítja, majd a szoftver továbbra sem csinál semmit, mert a rossz tervezés miatt a DB-ben be van beírva olyan státusz információ, ami már nem igaz, a szakadás miatt nem lett törölve, és megakasztja a további működést annak ellenére, hogy már újra él a kapcsolat...

Ez elég extrémnek hangzik, de én többször látok ilyen egymásra halmozott sz*rt, mint szeretnék.

Persze, de te arról beszélsz, hogy hogy lehet szarul használni valamit, én pedig arról, hogy az a valami jól használva hogy tudja nem létezővé alakítani a problémát. 

Lehet tévedek, de én úgy érzem a szál onnan indult, hogy a kubernetes hasznos-e vagy sem, megold-e problémákat vagy csak behoz újakat? 

Én nem gondolnám, hogy az, hogy hülyék használják jó érv ellene

Hát, van az elmélet, meg van a valóság. Igen, jól használva nagyszerű lenne. Mint annyi minden más. De sok helyen szarul használják ezt is, ahogy a legtöbb dolgot az egyszerűtől a bonyolultig. Így pedig inkább újabb probléma, mint megoldás. És azzal, hogy ekkora hype van körülötte, egy csomó olyan helyre is bekerül, ahová nem is kellene és nem is értenek hozzá.

Én nem érveltem sehol ellene, az meg pláne szerintem sem érv, hogy szüntessük meg, mert egyesek nem jól használják.

Nekem csak az nem tetszik, hogy ekkora hangsúlyt kap most az IT-ban ez a dolog (cloud native megoldások), holott nem a mindenható megoldás mindenre, hanem "csak" bizonyos feladatok oldhatók meg vele hatékonyabban - megfelelő hozzáértés esetén.

Mert ha magadba szívod a DevOps kultúrát, akkor már semmi olyan hiba nem fordulhat elő, ami után nyomozni kell.

De, előfordul, csak ilyen esetben a csapat a feladat megoldására fókuszál és nem arra, hogy az egymástól hermetikusan elszeparált területek miért nem tudják megoldani.

Ott a k8s magasságában persze nem fog látszani a flappelő switchport meg a bizonytalan UTP kábel, de ha ezeket kizárod a világodból, attól még léteznek.

Ezeknek látszania kellene metrikákban, hogy baj van. Ha nincs rá metrika, akkor 'hopp, egy feladat'. Másrészt a két kedvenc eszközöm közül az egyik a toxiproxy (https://github.com/Shopify/toxiproxy), amelyik pont ilyen hálózati hibákat tud szimulálni és ezt túl kell élnie a szolgáltatásnak. Egy szolgáltatást nem arra tervezünk, amikor minden rendben van, mert tökéletes rendszerekre könnyű építeni, a valóságban viszont soha nem lesznek tökéletes rendszerek, ezért a teszteknek is szimulálniuk kell a tökéletlen rendszert. Flappogjon az UTP, legyen hibás a kábel, legyen beteg a switch, legyen tele a storage, fogyjon el a memória, satöbbi. Vegyük észre és élje túl a rendszer.

https://iotguru.cloud

Azt képzeld el hogy anno Frankfurtban leégett az AWS datacenterének egy komplett épülete és a szolgáltatás "le se szarta", ment tovább a másik kettőről.
Nem egy UTP port flappelt, hanem az összes. Tudtunk róla, de nem kellett semmit csinálni. 

Őrület hol tart már a tudomány...

Gábriel Ákos

látszik, hogy nagyon szoftveres vagy

Hát mert talán a szoftverről volt szó a kommentben amire reagáltam :) Senki nem beszélt elmenő portokról, arról volt szó, hogy a szoftver a user felé látszik-e vagy sem, illetve azt látja-e a user hogy minden harmadik request teljesül, vagy azt látja, hogy folyamatosan üzemel / vs egyáltalán nem üzemel a szolgáltatás.

Ettől még rengeteg helyen előfordul az általam leírt helyzet. Kis cég, közepes és multi is. Elnevezésektől függetlenül.

Devops szemlélettel te hogyan kezelnéd a fenti helyzetet (hiba van az alkalmazásban, vannak róla ticketek, senki se érzi magáénak a problémát, súlyos információhiánnyal küzdenek az egyes csapatok, mindenki a saját várát védi)?

Egyébként ez szerintem nem csak a devops szemléleten múlik. Hanem az egyes csapatok akarva-akaratlanul keresztbe tesznek a másiknak. Gyakran ez az egész cég vagy a cég partnerei sínylik meg.

A DevOps a kifejezés eredeti értelmében egy filozófia (legjobb összefoglaló: https://aws.amazon.com/devops/what-is-devops/), vagyis nem ember, nem végzettség és nem munkakör. A munkakör például a platform engineer vagy a site reliability engineer, ami ehhez közel áll. Egy cégnél, ha azt mondják, hogy ő a "DevOps", az olyan, mintha azt mondanák, hogy a csapatban ő az "agilis" fejlesztő. Igen, elfajzott, mindenfélét jelent cégtől függően.

https://iotguru.cloud

Ettől még rengeteg helyen előfordul az általam leírt helyzet. Kis cég, közepes és multi is. Elnevezésektől függetlenül.

Hogyne. Mert tele van olyan emberekkel, akiknek nem a feladat megoldása az elsődleges céljuk.

Devops szemlélettel te hogyan kezelnéd a fenti helyzetet (hiba van az alkalmazásban, vannak róla ticketek, senki se érzi magáénak a problémát, súlyos információhiánnyal küzdenek az egyes csapatok, mindenki a saját várát védi)?

A DevOps szemlélet nem olyan, hogy megvesszük a boltban, kiszállítja a futár délután és onnantól kezdve van DevOps szemléletünk. Ahol van DevOps szemlélet, ott mindenki magáénak érzi a problémát, az információhiányt kérdésekkel enyhíti és nem védi a saját várát, mert ugyanabban a várban dolgoznak.

Egyébként ez szerintem nem csak a devops szemléleten múlik.

:D

Hanem az egyes csapatok akarva-akaratlanul keresztbe tesznek a másiknak.

A DevOps szemlélet az, hogy egy csapat van és nem teszünk keresztbe a másiknak.

https://iotguru.cloud

Kinek kellene ezt a hibát megoldania? Hogyan?

Arra tudok válaszolni kinek kell elkezdeni debugolni.

Részben devopsnak, ellenőrizni a pod/deployment/stb konfigurációt, részben a fejlesztőnek. 

Egyébként a vicc hogy a Kubernetes pont egy csomó hibalehetőséget kizár azzal hogy azonos környezetet ad localban és élesben is.

Szóval ezt jellemzően megúszod:

Dev team: A fejlesztői környezetben megfelelően működik, ők nem értik, hogy miért lenne hiba. A tanult üzemeltetők még egy ilyet se tudnak üzemeltetni!

Mert a worksforme jellegű dolgok jellemzően konfigurációkülönbségből adódnak.

Devops team: Biztos egy új deploy vagy konténer restart megoldja a dolgot.

Aminek a kiderítését - hogy a jó konfiguráció van a helyén - meg pont a devopstól várnám.

Igen ezek a kérdések megérnének egy meetup-ot egy sör mellett,  hogy hol hogyan kezelik ezt a dolgot. Pro-Contra stb.

Saját tapasztalat, ha nincs gazdája a hibának.

Tipikus multi cégnél "warroom" és minden csapatból egy-egy kolléga bent ül a callban és elkezdik keresni a hibát. Rettenetesen idő pazarló és sok ember idejét viszi feleslegsen. Konlúzió számomra, hogy a process hibás és javítani kéne ahol ez így megy.

Kisebb cégnél. Ops és Dev összeül vagy ahol van DevOps,  ott a DevOps deríti ki merre van a probléma és reportolja vissza a root cause-t a megfelelő helyre. A fenti példa esetén (API nem elérhető), aki keresi a hibát az nyit egy ticketet azoknak,  ahol  a hibát sejti (tűzfal, network, távoli service) ÉS egy másikat a fejlesztőknek, hogy lesznek szivesek logolni, ha egy szolgáltatást nem ér el az alkalmazás. A "something wne wrong" típusú üzenet nem lesz elég! Kellenek konkrét információk a logba, mint alkalmazás/szolgáltatás neve, konkrét hiba (HTTP hiba kód, kapcsolódási hiba stb. ) Sajnos ezt is meg kell fogalmazni a DEV felé, mert különben lesz egy exception a logban, amivel semmire se megy az ember legközelebb. Ezt kicsit erőszakosan kell tolni sokszor a Dev felé, mert hajlamosak elkényelmesedni és ha kód hiba van ő sem tudja egyből hol a hiba és keresi órákig, akár napokig, hogy hol a hiba! Tehát ezt be lehet mutatni, hogy ez neki is jó lesz hosszú távon.

Tehát meg kell tanulnia a Dev-nek a helyes hibakezelést, az Opsnak pedig erre szoktatni őket.

Persze, hogy paradigmaváltás, De egyelőre egy virtualizált Enterprise környezetben per pillanat nem egyértelmű a paradigma váltás hozadéka.
A bare-metal  --> VM váltásnak elsőre nyilvánvaló hozadékai voltak, olyannyira, hogy a virtualizálás igazából nagyvállalati környezetben előbb futott fel, mint máshol. A kubernetes világnak a hozadéka ennyire nem nyilvánvaló.

Egy fizikai-virtuális váltást  x86/64 vonalon az esetek jó részénél p2v migrációval gyorsan, nagy tömegben tudta az ember meglépni - konténernél baromira nincs így.

Egy nagyvállalati infrában több száz (vagy ezer) alkalmazás van, köztük pár annyira legacy, hogy még 5-10 évnél fiatalabb oprendszer release-en futtatni sem tudod.

Ahhoz, hogy egy k8-as cluster labdába rugjon, mögé kell rakni egy saját (geo) redundáns architektúrát, meg egy rakás erre szabott IT processzt. 8-10 alkalmazás esetén egy ilyen párhuzamos IT fenntartása baromira nem éri meg. (A VM világból nem látom hogy lehetne kubernetes világba migrálni mindent, gyorsan.)

Most ez enterprise konténerizáció leginkább ott tart, hogy a vmware clusterekben futó linuxokon lokális docker példányokban futkorásznak a dolgok.
Amíg nem lesz meg a kritikus tömeg a kubernetes környezetben futtatható alkalmazásokból, addig nem lesz paradigma váltás.

Most ez enterprise konténerizáció leginkább ott tart, hogy a vmware clusterekben futó linuxokon lokális docker példányokban futkorásznak a dolgok.

Cége válogatja, láttam olyan európai szintű energetikai céget, aminek több kurva nagy K8s cluster-ben futnak a dolgai. Nyilván nem mind, de az utóbbi 3-5 év zöldmezős és migrált cuccai igen.

https://iotguru.cloud

Én meg dolgozok olyan nemzetközi konszernnek, ahol az utóbbi 4 évben évente egyszer-kétszer megbeszélik, hogy felejtsük el a konténereket.

Múltkor egy legacy szart akartunk berakni egy dockerbe, hogy legalább a RedHat 5-öt kib*szhassuk alóla. Megvolt a proof of concept, a döntéshozó pedig közölte, hogy konténert akkor sem.

Érdekes módon ettől még akad 1-2 konténeres valami, de az mindíg akkor derül ki, amikor valami baja van. Ilyenkor megy a szokásos párbeszéd:

 - "dockert raktatok alá?"
- " Mi van?"
- "konténerben fut a cuccotok"
- "Mi nem tudjuk mi az, az alkalmazás szállító telepítette..."
- "....(b+)..."

Persze cége válogatja, de van egy tippem, hogy a legtöbb enterspájz üzem kb. itt tart.

( Vamp | 2023. 04. 25., k – 23:05 )

 Nem mindegy, hogy az IT viszi vagy hozza a pénzt.

 

Ez amugy megint egy erdekes kerdes. A szoftverfejlesztesben nyilvan hozza, ez adott. Nalunk, elsore azt mondana az ember, hogy viszi, hiszen az "erdemi munkat" a gyartosori osszeszerelo vegzi, kvazi o hozza a hasznot. Nade, ha az IT beall a foldbe, vagy lassu, megbizhatatlan, idejetmult, etc... akkor a termeles kb azonnal lereagalja...

Ezt úgy mondják, hogy van ahol az IT profit center, és van ahol cost center.

Egy informatikai szolgáltató cégnél profit center.  Kb bármi másnál az IT egy fejezet a költségvetésben.

Persze, hogy befolyásolja az IT a gyár eredményét, mert ha nem így lenne, akkor nem használnának IT-t, de alapjába véve a termelő cég nem az IT-t értékesíti, hanem a legyárott terméket.
Ergo az IT a gyártásnak alárendelt részleg.

Pl. Ha a gyár a a régi szervereket lecserélik hatékonyabb nagyobb teljesítményű szerverekre, akkor mondjuk spórol valamennyit a költségeken, de nem fog több terméket gyártani.

Ha egy hosting cég lecseréli a szervereit dupla teljesítményűre, akkor megkétszerezi a kibocsátási kapacitását.

"Pl. Ha a gyár a a régi szervereket lecserélik hatékonyabb nagyobb teljesítményű szerverekre, akkor mondjuk spórol valamennyit a költségeken, de nem fog több terméket gyártani."

Ez azért nem teljesen így van. Gyárnál maradva az IT hozzá tud járni a produktivitáshoz, elvileg erről szól az ipar4.0

De ugyanez igaz a vállalatirányításra is: megfelelő rendszerrel nő a szervezet átláthatósága, aminek köszönhetően jobban kiderül, hol úszik el a pénz.

Egyedül a számlázás termeli a pénzt

Ne a pénzmozgást nézd, hanem az értékteremtést. A számlázás ugyanúgy cost center a legtöbb helyen, mint az IT. Kivéve, ha te vagy a szamlazz.hu. :)

A számlázás már csak a beszedése a pénznek, nem ott termelődött meg a tulajdonosi érték. Csak azért állítunk ki számlát, mert ha nem tennénk, megbüntetne a NAV.

Számlázás, mint fogalom termeli a pénzt, megvalósításában nyilván az is költség, amit nyilván célszerű minél hatékonyabban csinálni. És nem a NAV miatt állítunk ki számlát, hanem azért, hogy pénzt kapjunk.

Az üzlet nem értékteremtésről, hanem pénzteremtésről szól, mögötte az van, miként tudod minél hatékonyabban mozgatni az erőforrásokat.

Mi nem cost center egy cégben, avagy mi van ingyen?

Az üzlet célja a pénz követelése valamilyen szolgáltatásért/termékért, a számla ennek a hivatalos megnyilvánulása. Ezért írtam, hogy számlázás, mint fogalom, mert a pénzkövetelés az utóbbi években hivatalosan számla formájában jelenik meg. A cserekereskedelem idején is azért gyártott az egyik csizmát, hogy a másiktól krumplit kaphasson, még ha ezt nem is vésték kőbe. Minden eszköz, idő, ami a csizma előállításához szükséges volt, az költség volt az előállító számára, önmaga is erőforrás volt a tudása révén (amíg csizmát készített, nem tudott krumplit termelni).

Az üzlettel nyilván érték is teremtődhet, de ez is elsősorban az üzletet szolgálja: jobb termék/szolgáltatás pláne jobb áron piacképesebb, jobb árat nagyobb hatékonysággal tudok elérni.

Az üzlet célja a pénz követelése valamilyen szolgáltatásért/termékért, a számla ennek a hivatalos megnyilvánulása. Ezért írtam, hogy számlázás, mint fogalom, mert a pénzkövetelés az utóbbi években hivatalosan számla formájában jelenik meg.

Ha nem lenne kötelező a számla, akkor hidd el, hogy a partnerek jelentős része nem igényelne számlát. Jön Occam borotvája és kiderül, hogy nem a számlázás hozza a pénz, a számlázás egy szükséges költség.

Az üzlettel nyilván érték is teremtődhet [...]

Nem teremtődhet, hanem kell, hogy legyen értékteremtés, hacsak nincsenek rákötelezve arra, hogy igénybe vegyék a szolgáltatásaimat, akkor azért jönnek, mert olyan értéket teremtek a részükre, ami nekik hasznos. A pénz és a számla másodlagos.

https://iotguru.cloud

Számla: ne legyél már ilyen korlátolt. A számla a pénz (=ellenérték, ami lehetne akár krumpli is) követelés egy formája. Nyilván minden esetben van költsége, jobb esetben csak néhány másodperc, amíg elhangzik a "mennyi?" és az "annyi".

Igen, teremtődik érték, hiszen azt adja el, de a cégeknek túlnyomóan nem az értékteremtés a célja, hanem a pénz, amit az általa előállított értékért kap. Baromi egyszerű okból kifolyólag: a megélhetéshez pénz kell, a csizmakészítőnek étel. De ha neked az értékteremtés a fontos, akkor megköszönök néhány óra ingyenes szaktanácsadást :-)

Számla: ne legyél már ilyen korlátolt. A számla a pénz (=ellenérték, ami lehetne akár krumpli is) követelés egy formája.

Nem, nem az.

Nyilván minden esetben van költsége, jobb esetben csak néhány másodperc, amíg elhangzik a "mennyi?" és az "annyi".

Ennél lényegesen több költsége van.

Igen, teremtődik érték, hiszen azt adja el, de a cégeknek túlnyomóan nem az értékteremtés a célja, hanem a pénz, amit az általa előállított értékért kap.

A vevőknek az értékteremtés a lényeg, az eladónak az a lényeg, hogy értéket teremtsen. Ezt lehet pénz nélkül is csinálni, csak nehezebb.

Baromi egyszerű okból kifolyólag: a megélhetéshez pénz kell, a csizmakészítőnek étel.

Nem pénz kell, hanem étel. A pénz csak egy szükséges rossz abban a folyamatban, hogy a szakács csizmát, a cipész meg ételt kaphasson. Nekik nem a pénz az érték, hanem az, amihez a pénzzel hozzájutnak.

De ha neked az értékteremtés a fontos, akkor megköszönök néhány óra ingyenes szaktanácsadást :-)

Szó nincs ingyenességről. Milyen értéket tudsz felmutatni, ami nekem hasznos?

https://iotguru.cloud

Ennél lényegesen több költsége van

Igen, pont erről van szó, ha globálisan nézem, akkor egy számlakiállításnak sok költsége van - feltételezem, hogy erre utalsz.

Amíg a számla nem kerül kiállításra (vagy szóban bemondásra, hogy "kész, most add a pénzt"), addig minden tevékenység szín tiszta költség. Éppen ezért csakis az a pillanat termel nyereséget, amikor megszületik a számla, azaz az ellenérték jogos követelése. (és még nyilván utána is van költség, mert a bevétel kezelése is költséggel jár)

az eladónak az a lényeg, hogy értéket teremtsen. Ezt lehet pénz nélkül is csinálni, csak nehezebb.

Az eladónak a végső célja a pénzteremtés, amiből ételt tud venni. Ahhoz, hogy pénzt tudjon keresni, vásárló számára értéket kell teremtenie. De ez az értékteremtés pusztán egy eszköz. Ha nem kapna pénzt, nem teremtené az értékét, mert éhen hal.

Az ember pályája elején még lelkes, motivált, majd egyre inkább a pénzteremtés motiválja (nyilván az elején is). Kinél hamarabb jön ez elő, kinél később, függetlenül attól, hogy alkalmazott vagy vállalkozó. Van, aki végig csak a pénz hajszolja és van, aki sok értéket teremet, de majdnem éhen hal.

Szó nincs ingyenességről. Milyen értéket tudsz felmutatni, ami nekem hasznos?

Nálad az érték a tudásod, a tapasztalatod, ez megteremtődött, ergó elérted a célodat, nem? Ha ingyen nem adod tovább, akkor mégis a pénz (vagy tetszőleges ellenérték) a végső cél.

Amíg a számla nem kerül kiállításra (vagy szóban bemondásra, hogy "kész, most add a pénzt"), addig minden tevékenység szín tiszta költség.

Nem, el is lehet cserélni bármire, simán vannak barter ügyletek, ahol kölcsönösen beszámítják az adott dolgok értékét. A barter ügylet számlája és szerződése csak a szükséges rossz, ha nem lenne kötelező a számla és a szerződés, akkor is ott maradna a barter ügylet. Nem a számlától lett értéke a barter ügyletnek.

Az eladónak a végső célja a pénzteremtés, amiből ételt tud venni.

Ha ételt akar venni, akkor az a végső célja. A pénz csak a szükséges rossz ebben a folyamatban.

Ahhoz, hogy pénzt tudjon keresni, vásárló számára értéket kell teremtenie. De ez az értékteremtés pusztán egy eszköz. Ha nem kapna pénzt, nem teremtené az értékét, mert éhen hal.

Fordítva ülsz a lovon. Nem a pénz a lényeg, az csak a szükséges rossz, egy olyan konstrukció, ami egyszerűbb, mint a barter, mert univerzális bartert tesz lehetővé. De végül a lánc két végén barter ügyletek köttetnek.

Nálad az érték a tudásod, a tapasztalatod, ez megteremtődött, ergó elérted a célodat, nem?

Nem, az én célom az, hogy élni tudjak, mivel nem tudok mindennel is foglalkozni, ezért ehhez barterügyleteket kötök: én adok szolgáltatást, cserébe hozzájutok olyan termékekhez és szolgáltatásokhoz, amelyekre szükségem van, ezeknek a barterügyleteknek az egyik köztes lépése a pénz.

Ha ingyen nem adod tovább, akkor mégis a pénz (vagy tetszőleges ellenérték) a végső cél.

Akkor lenne a pénz a végső célom, ha nem cserélném el szolgáltatásokra és termékekre. De elcserélem, ezért a végső célom az, hogy hozzájussak olyan termékekhez és szolgáltatásokhoz, amelyekre szükségem van.

https://iotguru.cloud

Barter: igen, én is hoztam cserekereskedelmi példát. Nyilván nem maga a pénz a lényeg, hanem az értékcsere. A termelés akkor valósul meg, mikor megkapod a cserét vagy az azt kötelezővé tévő akármit. Próbálj meg absztraktabban gondolkodni.

Fordítva ülsz a lovon. Nem a pénz a lényeg, az csak a szükséges rossz, egy olyan konstrukció, ami egyszerűbb, mint a barter, mert univerzális bartert tesz lehetővé. De végül a lánc két végén barter ügyletek köttetnek.

Nem, az én célom az, hogy élni tudjak, mivel nem tudok mindennel is foglalkozni, ezért ehhez barterügyleteket kötök: én adok szolgáltatást, cserébe hozzájutok olyan termékekhez és szolgáltatásokhoz, amelyekre szükségem van, ezeknek a barterügyleteknek az egyik köztes lépése a pénz.

Akkor lenne a pénz a végső célom, ha nem cserélném el szolgáltatásokra és termékekre. De elcserélem, ezért a végső célom az, hogy hozzájussak olyan termékekhez és szolgáltatásokhoz, amelyekre szükségem van.

Basszus, nyilván nem a pénz gyűjtögetése az alapvető cél, hanem hogy azt fel tudd használni. Vagy pénz helyett bármi, amit magad igényeinek hasznosítására tudsz fordítani. Azaz vállalkozási tevékenységednek mégsem az a célja, hogy össze gyűjtsd a tudást, tapasztalatot, hanem hasznosítsd igényeid kielégítéséhez, amihez a 2023-ban jellemzően pénz szükséges. Szerintem furcsán néznél rám, ha tanácsadásért néhány zsák krumplit vinnék, mondván úgyis el fog fogyni, legalább nem kell megvenned.

Barter: igen, én is hoztam cserekereskedelmi példát. Nyilván nem maga a pénz a lényeg, hanem az értékcsere.

Megy ez, látod.

A termelés akkor valósul meg, mikor megkapod a cserét vagy az azt kötelezővé tévő akármit. Próbálj meg absztraktabban gondolkodni.

:D

Basszus, nyilván nem a pénz gyűjtögetése az alapvető cél, hanem hogy azt fel tudd használni. Vagy pénz helyett bármi, amit magad igényeinek hasznosítására tudsz fordítani.

Kezded azt mondani, amit mi.

Szerintem furcsán néznél rám, ha tanácsadásért néhány zsák krumplit vinnék, mondván úgyis el fog fogyni, legalább nem kell megvenned.

Nyilván, de csak azért, mert van egy köztes barter eszköz - a pénz, amivel ez egyszerűbb az egész. De akár megmondhatnám, hogy adok négy óra tanácsot, ha hozod mindazt, ami listát adok. Nekem teljesen mindegy, nem ragaszkodom a pénzhez, de neked nehezebb lesz ezekkel jönni.

https://iotguru.cloud

Kezded azt mondani, amit mi.

Érdekes, hogy néhány hozzászólással ezelőtt még nem értetted a krumpli-csizmát.

Avagy az én nézőpontomból végre megértetted, mit mondok, hiszen mégsem adsz ingyen tanácsot (nem, mintha elvárnám), mert rájöttél, hogy van egy hasad.

Mindig elámulok a HUP-on, hogy egyesek mennyire hülyének nézik a másikat - én nyilván pénzt majszolok vacsorára és csak remélem, hogy nem kapok aprót, mert beletörne a fogam.

Érdekes, hogy néhány hozzászólással ezelőtt még nem értetted a krumpli-csizmát.

De, egészen pontosan értettem, pár hozzászólással korábban írtam is: "[...] (az ügyfelek) azért jönnek, mert olyan értéket teremtek a részükre, ami nekik hasznos. A pénz és a számla másodlagos."

Avagy az én nézőpontomból végre megértetted, mit mondok, hiszen mégsem adsz ingyen tanácsot (nem, mintha elvárnám), mert rájöttél, hogy van egy hasad.

Egyedül te beszéltél arról, hogy ingyen kellene tanácsot adnom, én nem: "A vevőknek az értékteremtés a lényeg, az eladónak az a lényeg, hogy értéket teremtsen. Ezt lehet pénz nélkül is csinálni, csak nehezebb."

Mindig elámulok a HUP-on, hogy egyesek mennyire hülyének nézik a másikat - én nyilván pénzt majszolok vacsorára és csak remélem, hogy nem kapok aprót, mert beletörne a fogam.

Baszki, te jöttél azzal az elejétől kezdve, hogy a pénz a fontos, én azt írtam végig, hogy a pénz csak egy köztes dolog, pénz nélkül is működik a rendszer, csak nehezebben. :D

https://iotguru.cloud

Igen, egy vállalkozás számára a pénz szerzése a fontos, nem pedig az, hogy értéket teremtsem (pl. tudás vagy akár műalkotás). Csak a csizmával és krumplival nem értetted meg, hogy nem a pénz (pl. 1,5 EUR), hanem hasznosítható értéke a fontos, okoskodni akartál.

De, egészen pontosan értettem, pár hozzászólással korábban írtam is: "[...] (az ügyfelek) azért jönnek, mert olyan értéket teremtek a részükre, ami nekik hasznos. A pénz és a számla másodlagos."

Nyilván azért jönnek, de ez a marketing, nem a vállalkozásod célja. Te nem azért teremted az értéket, hogy neki jó legyen, hanem hogy pénzt adjon érte (vagy krumplit vagy kacsát, tök mindegy).

Igen, egy vállalkozás számára a pénz szerzése a fontos, nem pedig az, hogy értéket teremtsem (pl. tudás vagy akár műalkotás).

Nem, ha kiveszed rendszerből a pénzt és maradsz a tiszta barternél, akkor is működik a vállalkozás: a pénz nem lényegi része egy vállalkozás működésének, csak egyszerűbbé teszi azt.

Csak a csizmával és krumplival nem értetted meg, hogy nem a pénz (pl. 1,5 EUR), hanem hasznosítható értéke a fontos, okoskodni akartál.

Továbbra se érted a pénz szerepét, csak okoskodsz... :)

Nyilván azért jönnek, de ez a marketing, nem a vállalkozásod célja.

De, a vállalkozásom célja az, hogy értéket teremtsek és ezért jöjjenek ügyfelek, akik olyan értéket hoznak, amire nekem szükségem van. Azért vállalkozok, mert nem tudok száz százalékban önfenntartó lenni és az ügyfeleim se, kölcsönösen rá vagyunk szorulva egymás szolgáltatásaira és termékeire. A pénz ebben opcionális köztes barter eszköz, lehetne akár zsák krumpli, mázsa búza, gramm arany vagy élő kacsa is az elszámolás alapja, vagy mindezek keveréke, akár a heti bevásárlólistám is, akkor is működne az üzlet. Csak nehezebben, a pénz mind a két fél részére működési költséget takarít meg, de az nem a cél.

Te nem azért teremted az értéket, hogy neki jó legyen, hanem hogy pénzt adjon érte (vagy krumplit vagy kacsát, tök mindegy).

De, azért teremtem az értéke, hogy az ügyfeleimnek jó legyen, különben nem hoznak pénzt, krumplit vagy kacsát, éppen mire van szükségem. Ha kölcsönösen értéket tudunk egymásnak teremteni, akkor működik az üzlet. Ezt pénz nélkül is lehet, nem a pénz az, ami a célunk, a pénz csak egyszerűbbé teszi, az egy technikai eszköz, aminek költsége és haszna van. Azért használjuk, mert több a haszna, mint a költsége. De nem célja a vállalkozásnak.

https://iotguru.cloud

Nem, ha kiveszed rendszerből a pénzt és maradsz a tiszta barternél, akkor is működik a vállalkozás: a pénz nem lényegi része egy vállalkozás működésének, csak egyszerűbbé teszi azt.

Szerinted miért hoztam fel a csizma-krumpli felállást még jó néhány hozzászólással ezelőtt? Te ragaszkodsz ahhoz, hogy én a pénzhez ragaszkodok.

De, azért teremtem az értéke, hogy az ügyfeleimnek jó legyen, különben nem hoznak pénzt, krumplit vagy kacsát, éppen mire van szükségem.

Igen, pont ezt állítom. Az érték előállítása eszköz, nem cél. Vagy köztes cél.

Ha kölcsönösen értéket tudunk egymásnak teremteni, akkor működik az üzlet.

Nem, engem nem érdekel, hogy ő teremt-e értéket. Legfeljebb annyiban, hogy az általa teremtett értékből ki tud-e engem fizetni, de erről tipikusan még az üzlet előtt megbizonyosodik az ember, nem utána.

Például tanácsot adsz, megkapod a krumplit/kacsát/disznót/pénzt, de az már téged nem fog érdekelni, hogy mire megyek vele. Nyilván jobban örülsz, ha hasznosul a tanácsadás (például mert akkor jobb eséllyel térek vissza vagy küldök mást is), de alapvetően mindegy.

Kb ugyanazt állítjuk, csak te akartál okoskodni, miszerint én tutira hülye vagyok, mert a pénzt nem fogom tudni megvacsorázni.

Szerinted miért hoztam fel a csizma-krumpli felállást még jó néhány hozzászólással ezelőtt?

Negatív példaként hoztad fel, miután én ragaszkodtam ahhoz, nem a számla és a pénz egy vállalkozás célja.

Te ragaszkodsz ahhoz, hogy én a pénzhez ragaszkodok.

Mert ahhoz ragaszkodtál, aztán megvilágosodtál.

Igen, pont ezt állítom. Az érték előállítása eszköz, nem cél. Vagy köztes cél.

Nem, nem köztes cél. Értékteremtés nélkül nincs üzlet. Minden más nélkül van üzlet.

Nem, engem nem érdekel, hogy ő teremt-e értéket. Legfeljebb annyiban, hogy az általa teremtett értékből ki tud-e engem fizetni, de erről tipikusan még az üzlet előtt megbizonyosodik az ember, nem utána.

Tehát nem érdekel, hogy teremt-e értéket, de mégis érdekel. Sőt, annyira érdekel, hogy előre tudni akarod, hogy tud-e neked értéket adni. Nem érzed néha úgy, hogy belegabalyodsz a hülyeségbe? :D

Például tanácsot adsz, megkapod a krumplit/kacsát/disznót/pénzt, de az már téged nem fog érdekelni, hogy mire megyek vele.

Ez pont a fordítottja. Nekem nem kell tudnom, hogy _neked_ értéket jelent-e a krumpli/kacsa/disznó/pénz. Nekem azt kell tudnom, hogy _számomra_ te értéket teremtesz-e azzal, amit szolgáltatsz vagy termelsz.

Kb ugyanazt állítjuk, csak te akartál okoskodni, miszerint én tutira hülye vagyok, mert a pénzt nem fogom tudni megvacsorázni.

Hát, innen indultunk: "Egyedül a számlázás termeli a pénzt, minden más csak költség."

https://iotguru.cloud

Mert ahhoz ragaszkodtál, aztán megvilágosodtál.

29-én 9:25-kor írtam írtam a csiszma-krumplit, az első hozzászólásodra válaszul, ha addig nem volt világos, ott világossá kellett volna, hogy váljon.

Nem, nem köztes cél. Értékteremtés nélkül nincs üzlet. Minden más nélkül van üzlet.

Nyilván nincs üzlet értékteremtés nélkül, ezt sehol nem is állítottam. Csak azzal semmire nem mész üzletileg, ha értéket állítasz elő és nem adod el. Lásd éhen haló művész esetét.

Ez pont a fordítottja. Nekem nem kell tudnom, hogy _neked_ értéket jelent-e a krumpli/kacsa/disznó/pénz. Nekem azt kell tudnom, hogy _számomra_ te értéket teremtesz-e azzal, amit szolgáltatsz vagy termelsz.

Az a gond, hogy folyamatosan forgatod a nézőpontot.

Nekem, mint vállalkozásnak olyan értéket kell előállítanom, amit pénzé/disznóvá/krumplivá tudok tenni (azaz el tudom cserélni olyanra, amit hasznosítani tudok). Azért állítom elő az értéket, hogy a számomra szükséges akármit megkapjam.

És akkor most odafordulunk, amit írsz: neked, mint vásárló vállalkozásnak igenis tudnod kell, hogy másnak mire van szüksége, ugyanis ha neked olyan értéked van, amire senkinek nincs szüksége (például tehén), akkor nem leszel fizető képes olyan értékért, amire neked szükséged van. De ez már elkanyarodás, nem a vállalkozás céljáról szól, hanem a vállalkozás kezeléséről, piacismeretről.

Nekem azt kell tudnom, hogy _számomra_ te értéket teremtesz-e azzal, amit szolgáltatsz vagy termelsz.

Ez pontosan így van. Hozzátéve, hogy meg tudod-e venni az általam teremtett értéket. Mert ha te csak tehenet tudsz érte adni (amire nekem nincs szükségem), akkor lehet, hogy nem kapod meg. De ez az én szempontból nem a vállalkozás célja, hanem stratégiája (milyen értéket állítsak/ne állítsak elő: például én hiába gyártok 1 személyes autókat, ha senki nem fogja megvenni, a vállalkozásom célja nem az autógyártás, hanem az azon történő nyereség realizálás).

Az a gond, hogy folyamatosan forgatod a nézőpontot.

Igen, én forgatom a nézőpontom, aki folyamatosan azt mondja, hogy a vállalkozás célja az értékteremtés, te pedig eljutottál oda attól, hogy a számla kiállítása, majd a pénz, majd a cserekereskedelem, majd a fene tudja mi, filozófikus és átvitt értelemben, de aztán a vállalkozás célja most már szerinted is az értékteremtés. Szerintem olvasd át az egészet újra, különös tekintettel azzal a mondatra, hogy "Egyedül a számlázás termeli a pénzt, minden más csak költség."

https://iotguru.cloud

Számlázás, mint fogalom termeli a pénzt

Nem. Ha nem lenne központosított számlázás, hanem a kereskedők rohangálnának számlatömbbel, akkor is lehetne termelni, és el lehetne pénzért adni a terméket, csak ez valószínűleg drágább lenne.

Ha a számlázás termelné a pénzt, akkor mikrovállalkozásoknak, ahol nincs számlázás, nem lenne bevétele.

Az üzlet nem értékteremtésről, hanem pénzteremtésről szól

De. Lásd tulajdonosi érték. Az értéket itt ne valami morális, etikai értelemben vedd - v.ö. vállalati érték, adósságérték, stb. Üzletet azért csinálunk, mert pozitív (tulajdonosi) értéket akarunk teremteni. Az, hogy egy túlfeszített D/E aránnyal, óriási adósságértékkel, és magas alternatívaköltséggel csinálok egy rakás bevételt, még nem jelent semmit.

Mi nem cost center egy cégben, avagy mi van ingyen?

A cost center definíciója nem az, hogy pénzbe kerül valami. :)

https://www.accountingtools.com/articles/the-difference-between-cost-ce…

Számla: te sem érted (vagy nem akarod érteni), hülyeségeken lovagolsz. Minden tevékenység, amit a cég csinál, pénzbe kerül, ergó a nyereséget csökkenti. Ezért az a pillanat termel egyedül bevételt, amíg megfogalmazódik a vásárló felé, hogy ő fizetni köteles a cégnek. Akár papíron, akár szóban, bárhogyan. És ez nyilván akkor termel, ha a fogadó fél ezt elismeri az előzőleg befektetett energia következményeként.

Érték: szerintem pont azt írod, amit én, csak én leegyszerűsítettem pénzre. Az esetek túlnyomó részében nem azért vállalkozik valaki (kockáztat), hogy például készítsen egy klassz csizmát bevétel nélkül, mert akkor éhen hal.

Cost center: ez teljesen világos, a probléma az, hogy nem feltétlenül kellene mindent cost centerként kezelni, ami ott van. Például az említett ipar 4.0 esetén a kapcsolódó informatikát hova sorolod? Hol húzod meg a határt az IT (cost center infrastruktúra) és termelési informatika (pl. gépsort vezérlő szoftver) között? Egy építésziroda esetén az ArchiCAD hova tartozik? Az azt futtató számítógép? A switch, amibe a számítógép kapcsolódik?

Véletlenül sem szeretném tudását megkérdőjelezni, az értelmesebbek közé tartozik itt a HUP-on, csak jelen esetben kicsit másról beszélünk. Ő technikailag/szervezetileg közelíti meg a számlázást, én filozófikusan próbáltam megközelíteni a kérdést: igen, az IT-t költségként szokták tipikusan beállítani, de annyira tud már nőni a jelentősége, hogy ez nem feltétlenül helyes irány és egyre kevésbé lesz az. Vagy legalább ketté kellene bontani az IT-t.

Ha most csinálja az msc diplomáját, akkor nem véletlenül ragad le túlságosan a szűken vett definícióknál. Pl. jelen esetben az adósság is pénz, csak negatív előjellel. Pénz=érték, csak ez jelen esetben pont nagyon félreérthető, azaz pénz = pénzben megfogalmazható érték.

Ő technikailag/szervezetileg közelíti meg a számlázást, én filozófikusan próbáltam megközelíteni a kérdést

Simán lehet.

Egyébként az IT-s példádra (beleértve az ipar4.0-t is) általában elég egyszerű a megoldás: külön cost/profit center a kettő. :) Meg nyilván akad bőven olyan, ahol nem egyértelmű, annyira nem szokták ezt szigorúan nézni.

az a pillanat termel egyedül bevételt, amíg megfogalmazódik a vásárló felé, hogy ő fizetni köteles a cégnek

Nálunk ez a pillanat a szerződéskötés, viszonylag ritkán fordul elő, hogy a vásárló a számla kiállításakor jön rá, hogy itt fizetni kell. Tény, hogy fordult már elő ilyen. Egyszer.

A "modern" kettős könyvelés nemrég múlt 500 éves, nézz bele, hogy ott hogyan modellezik a vállalkozásokat, egész jól meg lehet érteni ezt a témát a számvitelen keresztül. Az, hogy én legyártom a csizmát, az egy gazdasági esemény. (Igazából több, de most nem érdekes.) Az, hogy a vevő megveszi, az még egy. Az, hogy a vevő fizet, az egy harmadik. A háromnak még a sorrendje is mindegy. Lehet, előbb gyártunk, utána számla, utána fizet a vevő. De lehet, hogy a vevő fizet, csizmát gyártunk, és utána állítunk ki számlát. Mindegy.

Ha a vevő tartozik, már az is egy eszköz a cégben, pedig még nem fizetett. Lehet, hogy nem is fog! A tartozást például eladhatom, abból is lehet bevétel. Stb.

Az esetek túlnyomó részében nem azért vállalkozik valaki (kockáztat), hogy például készítsen egy klassz csizmát bevétel nélkül, mert akkor éhen hal.

Nyilván nem, csak fentebb nem véletlenül írtam, azt, hogy önmagában nem érdekes mennyit bevételt termelünk. Azt a trükköt mindenki ismeri, hogy ha az állampapír 16%-ot hoz, akkor hülyeség vállalkozást indítani 8% várható hozamért.

Na és 20% hozam mellett? 

Szerződéskötés szerintem nem jó példa, mert csak teljesítést követően várhatsz el pénzt. De nyilván szükséges a későbbi számlázáshoz. (függetlenül attól, hogy a szerződés írásban van, netán csak szóba, akár implicit köttetett.)

Ha a vevő tartozik, már az is egy eszköz a cégben, pedig még nem fizetett. Lehet, hogy nem is fog! A tartozást például eladhatom, abból is lehet bevétel. Stb.

Jogos, itt nehéz eldönteni, hogy hol húzzuk meg a határt vagy sem, egyébként a számlázás (fogalmilag) majdnem ugyanaz, mint a szerződés szerinti teljesítés, amit említesz.

Ha a vevő tartozik, az egy speciális eset, veszteség keletkezik. De jelen esetben ennek nincs jelentősége (nem könyvelést készítünk), a magam részéről onnan indultam, hogy egy cégen belül minden tevékenység költség/kiadás, amit célszerűen minimalizálni kell a nagyobb profit érdekében, nincs kivételezés. Hiába profit center a termelés, ott is van költség, amit kordában kell tartani, az IT hiába cost center, a profit center hatékonyságát tudja növelni.

Nyilván nem, csak fentebb nem véletlenül írtam, azt, hogy önmagában nem érdekes mennyit bevételt termelünk. Azt a trükköt mindenki ismeri, hogy ha az állampapír 16%-ot hoz, akkor hülyeség vállalkozást indítani 8% várható hozamért.

Na és 20% hozam mellett? 

Tegnap kérdeztem a chatgpt-t a fiam jövője kapcsán, milyen tevékenységek, munkák tudnak flow élményt nyújtani, az egyik:

4.    Entrepreneurial jobs: Jobs that involve entrepreneurship, such as starting a business or launching a startup, can also provide opportunities for flow experience. These jobs often require a high level of creativity, risk-taking, and decision-making, and can provide plenty of opportunities for learning and growth.

Azaz kérdés, hogy kinek mennyit ér meg a flow élmény.

Sőt: Előre fizetés? Előfizetés? Részteljesítés? Folyamatos teljesítés? Behajtás? Követeléskezelés? Még mindig ott tartunk, hogy egy technikai megvalósítás körül folyik a vita, hogy mikor és hogyan történik a pénz mozgása és nincs fókusz azon, hogy miért is történik a pénzmozgás...

https://iotguru.cloud

Mit akarsz ebből kihozni? Nem könyvelési rendszer felállítása a cél.

A téma onnan indult, hogy véleményem szerint az IT egyre kevésbé pusztán költség, mert aktívan hozzá tud járulni a termeléshez, ami az úgymond hasznot hozza. Erre egy példa az ipar4.0. Nem kell például hosting cégnek lenne ahhoz, hogy az informatika részt vegyen a termelésben, a határok mosódnak. Ez számunkra, mint informatikusoknak kedvező, hiszen több területen felértékelődik a munka értéke.

Ezenkívül attól, hogy valami hasznot hoz, ugyanúgy költség. Bármit is csinál egy cég, minden költség, mint "hagyományosan" az IT. Egy gyártósor is hiába termel, amíg nincs megállapodás szerint kiállított számla, addig nincs eredmény. A kézzel fogható eredmény nyilván a pénz (krumpli) befolyása, de az nem a cég tevékenységéből kifolyólag történik meg. Javaslom a Takuan Soho, A korlátaitól megszabadított elme című művét, azon belül is az időköz, melybe hajszál sem fér gondolatiságát.

A fizetés ideje teljesen mindegy, utólag is lehet probléma, mikor már ki van fizetve, mert például garanciális probléma miatt vissza kell fizetni az árát.

Mit akarsz ebből kihozni? Nem könyvelési rendszer felállítása a cél.

Még mindig az a kérdés, hogy te mit akarsz ebből kihozni...

A téma onnan indult, hogy véleményem szerint az IT egyre kevésbé pusztán költség, mert aktívan hozzá tud járulni a termeléshez, ami az úgymond hasznot hozza.

Technikailag a cég minden területe hozzájárul a haszonhoz, különben nem lenne rá szükség.

Egy gyártósor is hiába termel, amíg nincs megállapodás szerint kiállított számla, addig nincs eredmény.

Hogyne lenne eredmény, ott áll az eredmény a legyártott termékekben, ha cakk-und-pakk el kell adni a céget, akkor ugyanúgy értéket képvisel, növeli a cég értékét. Nem a kiállított számlától lesz eredménye a cégnek, az egy kötelező technikai dolog, mint a WC papír a budiban.

https://iotguru.cloud

Még mindig az a kérdés, hogy te mit akarsz ebből kihozni...

Volt egy állításom, Te kötsz bele állandóan mindenbe, játszván a szuper okosat. Én pedig b*fasz módon válaszolok.

Technikailag a cég minden területe hozzájárul a haszonhoz, különben nem lenne rá szükség.

Nyilván, csak szokott lenni a szükséges rossz, gondolom hallottál már róla.

Hogyne lenne eredmény, ott áll az eredmény a legyártott termékekben, ha cakk-und-pakk el kell adni a céget, akkor ugyanúgy értéket képvisel, növeli a cég értékét. Nem a kiállított számlától lesz eredménye a cégnek, az egy kötelező technikai dolog, mint a WC papír a budiban.

Amíg nincs eladva/hasznosítva, addig költség, mert előfordulhat, hogy soha senkinek nem lesz rá szüksége (legalábbis a kínálatot nem sikerül összehozni a kereslettel). Az a gond, hogy már megint a számla technikai vonatkozásán ragadtál le, de egyébként igen, a számlától lesz eredménye a cégnek, és most éppen végtelen ciklusba kerülünk (bár lehet, hogy eddig is ott voltunk).

Nyilván, csak szokott lenni a szükséges rossz, gondolom hallottál már róla.

Hogyne hallottam volna, a számlázás például egy ilyen szükséges rossz.

Amíg nincs eladva/hasznosítva, addig költség, mert előfordulhat, hogy soha senkinek nem lesz rá szüksége (legalábbis a kínálatot nem sikerül összehozni a kereslettel).

Nem költség, az már egy előállított érték.

Az a gond, hogy már megint a számla technikai vonatkozásán ragadtál le, de egyébként igen, a számlától lesz eredménye a cégnek, és most éppen végtelen ciklusba kerülünk (bár lehet, hogy eddig is ott voltunk).

Nem, egy cégnek lehet úgy is eredménye, hogy nem számláz, mert eredménynek számít például többek között az aktivált saját teljesítmények értéke is, mint például a félkész vagy készre legyártott és egyelőre el nem adott termékekkel megtöltött raktár tartalma. Ha pedig nem erre gondoltál, akkor ne keverd egy-egy szó hétköznapi és gazdasági jelentését, mert egy kurva nagy katyvasz lesz a mondatod.

https://iotguru.cloud

Gábor, Te alapvetően nagyon értelmes vagy szerintem, de rendkívül csökönyös és rugalmatlan. Ismétlem: nem könyvelésről beszélek. Hiába írtam számlát, próbálj már egy kicsit elvonatkoztatni, és a számla üzleti, nem pedig jogszabályi, könyvelés technikai jelentésére koncentrálni.

Az üzlet röviden cseréről szól: ki miért mit ad cserébe. Minden más csak körítés valamilyen célból, a számla azt jelképezi, hogy teljesült az üzlet eladói/szolgáltatói oldala, lehet fizetni (pénzzel, krumplival, disznóval, ...).

mint például a félkész vagy készre legyártott és egyelőre el nem adott termékekkel megtöltött raktár tartalma

Könyvelésileg sikeresen zárhatsz egy évet, pezsgőt is nyithatsz, de ennek a könyvelését elhasználhatod WC papírnak, ha leég a raktár, mielőtt eladtad volna, bevételed nem lesz belőle, végeredményben színtiszta költség volt. De ugyanez van, ha kiderül, hogy egy rakat selejtet készítettél: nem gyártástechnikailag, hanem mert senki nem veszi meg, ráadásul a megsemmisítés is (és előtte esetleg a tárolás is) pénzbe kerül.

mondjuk spórol valamennyit a költségeken, de nem fog több terméket gyártani.

akkor most profit vagy bevetel? regen volt mar, de ugy emlekszem, ha csokken a kiadas, ugyanakkora bevetel mellett novekszik a profit. (persze van roi is) :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( Mik v | 2023. 04. 26., sze – 08:40 )

"és ami nem a (futási) hatékényságot, erőforrás-gazdaságosságot segíti elő, hanem valami mást, ami számomra eddig nem derült ki. Igazából nem is látom át, mit segíthet elő valójában a Kubernetes és csatolmányai a multiknál és a felhőszolgáltatóknál kisebb cégek esetében."

Az alkalmazás fejlesztését és élesbe küldését jelentősen meg tudja gyorsítani. És nem azért mert annyira hatékony meg erőforrás kímélő, hanem mert valaki azt mondta hogy márpedig XY funkció kell.

"Tényleg hatékonyabb, gördülékenyebb és kevesebb munkával feljeszthetőek és üzemeltethetőek ezek a rendszerek? Takarékosabbak vagy jobbak ezek bármi téren, vagy csak mások?"

A fentiből következik, hogy nem feltétlenül azért van a hype a K8s körül mert kevesebb munkát kell beletolni. Én azt mondanám hogy eltolódtak vagy éppen összemosódtak a szerepek közti határok attól függően, hogy melyik IT szerepkört nézzük. gabrielakossal ellentétben én azt mondom, hogy kis-közepes méretben cloud only környezetben egy jó csapattal lehet gördülékenyebb a K8s környezet, de nem feltétlenül olcsóbb mint más.

Nagy céges környezetben viszont sok kérdés előjön amik ugyanazok vagy éppen mások mint nem Kubernetes estén. mesh, zero trust, monitoring, tracing, logging, access managment, csapatok közti egymásra mutogatás (NOC, SOC, DevOps, Enterprise Architecture, tesztelők)... Persze fel lehet jól építeni de az sok idő és energia. Rengeteg tool elérhető ami segíthet, de már a választás sem egyszerű. Azokat a cégeket nem is említve ahol az IT a szükséges rossz de mégis a modernizáció mellett döntenek.

És igen, iszonyú gyorsan elavult/nembiztonságos/nemtámogatott lesz minden IS. Ami azzal jár, hogy ha valamihez nem volt 8-10 hónapig hozzányúlva és megint babrálni kell vele akkor garantált a kudarc. Vagy épp maga a Kubernetes nem volt frissítve sokáig majd hirtelen a microservice alatt több verziót is ugrott a K8s akkor a deploy már nem fut le mert változott ez+az. Vagy éppen az egyik delopy tool verzió változott a központi template-ben és az új verzió bugos és a telepítést megcsinálja, de pár "apróság" kimaradt ami miatt az app fut, csak éppen nem csinálja amit kell... Két megtörtént eset a közelmúltból egy sima egyszerű K8s clusterrel.

Összefoglalva a kérdés szerintem inkább üzleti. Sem a cloud, sem a microservice sem a K8s nem feltétlenül lesz olcsóbb vagy jobban kezelhető, de az én tapasztalatom alapján a fejlesztést, tesztelést és végül a telepítést ténylegesen és hatékonyan meggyorsíthatja.

A fentebb emlegetett cloud menedzselt szolgáltatásokról mint a Fargate vagy a Lambda -ami ugyan nem microservice de talán meg lehet a témában említeni- már ne is beszéljünk...

mit segíthet elő valójában a Kubernetes és csatolmányai a multiknál és a felhőszolgáltatóknál kisebb cégek esetében."

 

Van otthon mondjuk 100-200  ( pl wifis népszerű shelly stb ) home kütyüd. Ezzel megy  redőny, a garázs a klotyólámpa. Nem engedheted meg a leállást  mert kinyír az asszony. Veszel 3 (esetleg 2) málnapct, teszel rá microk8s-t ami egy utasítás. Node -ba rakod őket , ami egy utasítás nodonként, bekapcsolgatsz add-onokat, ha kell, és van egy raspberrys HA rendszered. 

https://blog.claryel.hu

Perszepersze. Felrakod a homeassistantot meg alá a mysql-t shared storage-re vagy mi?

Kubernetes szép meg jó, de messze nem elég az "elejét" megcsinálni, a "hátulját" is meg kell. És az az igazi szopodáré.

Garantáltan több kiesésed lesz az upgrade-k során történt elb@szásokból mintha egyszerűen beraknád a fiókba a másikat és megoldod a rendes disaster recovery-t.

Gábriel Ákos

 Felrakod a homeassistantot meg alá a mysql-t shared storage-re vagy mi?

Ez csak egy példa, lehet hogy szopás, de igen, felrakom shared storage-ra: microk8s enable openebs . De ez csak egy példa volt,  nem egy tipikus példa. De ezt is lehet.

Bekapcsolsz egy három nodos klasztert GKE- n , nem teszel rá semmit, csak otthagyod , akkor is kapsz egy 100 dollárhoz közeli számlát  hónap végén. Nem versenytársa 

sok webes szolgáltatásnak, tárhelynek, vps-nek.  Látni szolgáltatókat, akik havi fix-ért próbálkoznak. Nyilván  itt nincs  országhatárokonn átnyúló redundáns hardwer load balancer.

https://blog.claryel.hu/wp-content/uploads/2023/03/openebs_filesystem.png

https://blog.claryel.hu

Nem engedheted meg a leállást  mert kinyír az asszony.

Szerintem hibás a tervezéstől kezdve az a rendszer, aminek a működtetéshez egy 7/24 központi rendszer kell. Ha lazán csatolt mesh van és minden egyes kis komponens akkor is tudja az alapfunkcióit, ha nincs körülötte semmi, akkor az egy helyes kivitelezés. Tehát ne kelljen azért egy három node-os cluster, hogy a WC-ben kapcsolható legyen a lámpa.

https://iotguru.cloud

( ibenny v | 2023. 04. 28., p – 10:00 )

Az update-edre reakció valahol: például magyarországi nagybankban használják, Openshift környezetben, és egyre inkább nyomják, költöztetik oda az eddig más környezetben létező alkalmazásokat. Szerencsére semennyi közöm nincs hozzá.

( trey | 2023. 04. 28., p – 10:04 )

Szerkesztve: 2023. 04. 28., p – 10:06

Ellenben egyetlen hsz.-ben nem olvastam arról, hogy ma Magyarországon ennek hol van olyan létjogosultsága, valós felhasználása,

🤣 🍿

Kíváncsian ülök itt én is. Aki csak ezt a topikot olvassa, azt hiszi, hogy ez ma kizárólag az IT.

trey @ gépház

( zrubi v | 2023. 04. 28., p – 10:09 )

Jól látom a helyzetet, vagy nem igazán értettem meg, amit írtok?

Szerintem jól látod a helyzetet.

 

Az itthoni piac kicsi, fizetőképes kereslet pedig gyakorlatilag nincs erre. - De lehet hogy valójában igény sincs.

Aki a gyaorlatban ilyennel foglalkozik az vagy egy nagy multinál/multinak teszi ezt, vagy 'csak' tanítja/tanulja ;)

 

De nyilván, aki az IT dolgozik, vagy tervezi hogy abban akar dolgozni, az nem csak (vagy inkább biztosan nem) a magyar KKV szektorban kívánja ezt tenni ;)

 

szerintem.

zrubi.hu

Az itthoni piac kicsi, fizetőképes kereslet pedig gyakorlatilag nincs erre. - De lehet hogy valójában igény sincs.

Akkor mire ez a sok ilyen irányú képzés? Ha az ehhez értő szakikra nincs valódi kereslet? Arra mennek a képzések, hogy a mostanában külföldre/külföldön dolgozni szándékozókat kiképezzék?

Én is azt gondolom, hogy ma itthon úgy vesznek fel cloud native szakit a nagy hype miatt, hogy "most ugyan nincs sok ilyen projektünk, de a jövőben tervezünk, addig itt van ez a VMware környezet és a Java alapon fejlesztő csapat, őket kellene támogatni, és ez alapján tudunk fizetni, nem a felhős technológiai tudás alapján"...

De nyilván, aki az IT dolgozik, vagy tervezi hogy abban akar dolgozni, az nem csak (vagy inkább biztosan nem) a magyar KKV szektorban kívánja ezt tenni ;)

Igen, elméletben. De valójában nem mehet mindenki külföldre (technikailag mehet, de kevésbé valószínáű, hogy mindenki akar+sikerül) dolgozni sok okból. Ergo maradnak itthon. És ha már maradtak, akkor pontosan mire jó a cloud native tudásuk? KKV nem használja, multi inkább nem mint igen... Tehát minden más tudás még mindig fontosabb, mint a cloud native technológiák, ha munkavállalásról van szó. Mert ahogy látom, nem csak Kubernetes DevOps hiány van itthon, amit be kell tölteni (és minden más IT terület meg telített megfelelő szakemberel)... 

Akkor mire ez a sok ilyen irányú képzés? Ha az ehhez értő szakikra nincs valódi kereslet?

Én az utóbbi fél évemből tudok minimum öt magyar céget, ahol azonnal felvennének K8s értő embert, ha nem kell kitanítani a szakmára.

Az egyik projekt, ahol vagyok, ott amúgy ez a K8s üzemeltetés ki van szervezve Indiába egy 7/24 IT SSC-be. Ha lenne rá magyar erőforrás, hasonló feltételekkel, akkor nem lenne kiszervezve. De nincs.

https://iotguru.cloud

lol, hát, akkor értem, miért nincs :D 

Oké, tudsz mondani olyan magyar céget, ahol vállalnak 7/24 K8s üzemeltetést és az nem azt jelenti, hogy ők is indiai céggel vannak szerződésben? Mert tudok magyar cégekről, de a levelek alján csak ott van Rajesh és Kumar.

https://iotguru.cloud

Nem az a baj, hogy a levelek alján Béla van, vagy Rajesh, hanem hogy az indiai horror-outsourcing cégekhez "hasonló feltételekkel" keres valaki itt munkavállalót. 

Mondjuk na, láttam már devops-os álláshirdetést bruttó 300k körül, szóval próbálkozás azért van, nem kérdés.

Nem a te személyednek szól, hanem az általános "tanácsadóknak".

Tanácsot adni mindenki tud. Sőt, akár 1-2 mondattal is lezárhat egy bonyolult problémát. Aztán amikor kiderül, hogy a megoldása nem működik, akkor pingvinezik vagy másra mutogat.
Rengeteg olyan tanácsadóval találkoztam - köztük nagyon nagy nevűekkel is, akik pár keresztkérdés után megbuktak nálam. Előítéletesség, tudom.

A konkrét kérdésedre válaszolva: Nem kell. De ha nem tudod üzemeltetni IS vagy korábban nem üzemeltettél ilyen rendszert, akkor a szememben egy lufit érnek a tanácsaid.

Nem a te személyednek szól, hanem az általános "tanácsadóknak".

Hát pedig nekem válaszoltál és az én hozzászólásomra. :D

Tanácsot adni mindenki tud.

Nem, tanácsot adni kevesen tudnak. Belepofázni tudnak sokan. A tanácsadás ott kezdődik, hogy először meghallgatod a cégnél azokat, akik a problémában érintettek és ezek után külső szakértőként mintákat adsz nekik, hogy merre érdemes haladni a probléma megoldása érdekében. A cégek felénél egyébként elég csak a műsorvezető-moderátor-pszichológust játszanom, és a bajoknak a jelentős részét azzal meg tudtam oldani, hogy kizártam vagy lehalkítottam a toxikus személyeket, akik állandóan beleszóltak, hogy miért nem lehet megcsinálni és miért nem fog működni, ha mégis megcsinálják. A többiek pedig ettől kezdve meg tudták csinálni. Ezen túl általában tudtam adni hasznos mintákat, amik mentén meg lehet szervezni a feladatot, mert én már láttam több ilyet, ők meg nem.

De ha nem tudod üzemeltetni IS vagy korábban nem üzemeltettél ilyen rendszert, akkor a szememben egy lufit érnek a tanácsaid.

Nyilván, te dolgod, hogy miről mit gondolsz.

https://iotguru.cloud

( vilmos.nagy | 2023. 04. 28., p – 10:17 )

mi használjuk, élesben, prodban - és nagyságrendekkel kényelmesebb, mint bármilyen korábbi technológia (az is igaz, hogy én dev irányból lettem az, aki az infrát pöcögteti a csapatban). korábban futott on-prem k8s-en is prod rendszer, hála égnek mára minden prod felhő (azure, aws, gcloud vegyesen. a hobbiprojektem oracle cloudban van).

nyilván a teljes stack cloud first, mire én idekerültem, megugrotta a csapat, hogy mindent migráltak k8s-re. a nagyságrend egy kis cluster: egy átlag helyen összesen átlagidőben ~50 vcpu, ~200 giga RAM. 

Amiben sokkal kényelmesebb nekem, és elsőre nem látszik (és akár 1-1 apró projektet is k8s-re vinnék), az a tooling: a helmmel csak az van kint a clusteren, amit szeretnél, és amit kiveszel, azt lepucolja. nem kell absent state-eket írogatni, mint ansible-ben, meg ottmaradó, legacy dolgokat kerülgetni a múltból.

Az, hogy konténerekben van minden, a fejlesztést segíti: nincs többet olyan, hogy egy-egy app fejlesztéséhez ~3 oldalas doksit kell beállítanod envvaroktól, verzióktól, anyámkínjától kezdve a cipőméretedig. Ugyanez igaz a runtime-ra is: ha konténer fut, minden van.

A többi (scaling, loadbalancing, healthcheck-ek, stb) már csak extra.

Ha nem titok, milyen jellegű a szoftver? Ügyviteli (ERP), vagy kereskedelem (webáruház) jellegű, vagy micsoda? Saját belső rendszer, vagy kereskedelmi termék?

Mennyire "régi" a rendszer, ami át lett ültetve és mennyire cserélődött le a csapat az átállás előtt/közben/után? Az architektúra változott jelentősen, vagy az annyira átgondolt volt, hogy jól át lehetett ültetni ilyen szemléletre?

A klasszikus üzemeltetés váltott (cserélődött) cloud DevOps-ra a fejlesztők meg átálltak amiben kellett, vagy hogy?

A nagy felhős szolgáltatóknál futtatás egyszerűbb és/vagy olcsóbb mint az on-prem volt azért kellett váltani? Vagy az on-prem beruházás, üzemeltetés okozott (szakember oldalon) gondot? Azt értem, hogy a fejlesztők adaptálódtak ügyesen.

Az lehet, hogy cloud native rendszereknél az 50 vCPU és 200 GB memória kicsinek számít, de itthoni viszonylatban szerintem nem számít kicsinek egy olyan rendszer, aminek ilyen erőforrás igénye van átlagosan.

Egyébként köszönöm, ez az első olyan hsz. amiben valaki azt írja, hogy konkrétan használnak ilyen rendszert.

Ha nem titok, milyen jellegű a szoftver? Ügyviteli (ERP), vagy kereskedelem (webáruház) jellegű, vagy micsoda? Saját belső rendszer, vagy kereskedelmi termék?

end-userek használják, mobilappok + webes frontend kérdez be (a frontendhez szükséges kód is innen kerül a CDN-re). Van néhány olyan szolgáltatás, amit a megrendelő alkalmazottai használnak, de ez a terhelés alacsony része. Az stackbe érkező adatok nagyrésze 3rd party integráció, így a megrendelő több más szoftveren keresztül bizergálja azt, amit a rajtun keresztül látnak a felhasználói.

Mennyire "régi" a rendszer, ami át lett ültetve és mennyire cserélődött le a csapat az átállás előtt/közben/után? Az architektúra változott jelentősen, vagy az annyira átgondolt volt, hogy jól át lehetett ültetni ilyen szemléletre?

~10+ éve kezdődött, a csapat core része maradt ugyanaz, organikus növekedéssel - de a funkciók is nőttek vele.

A klasszikus üzemeltetés váltott (cserélődött) cloud DevOps-ra a fejlesztők meg átálltak amiben kellett, vagy hogy?

Én még nem voltam itt az elején, de nekem az a megértésem, hogy a kezdetek kezdetén (~10+ éve) nem volt klasszikus üzemeltetői csapat, hanem egyből az infrastructure as code / korai devops szemléletben kezdték ezt üzemeltetni. Az on-prem -> k8s váltásnál sem voltam még itt, de ha jól tudom, az is organikus váltásként következett be, ahol 1-1 szogáltatást kezdtek a VM-es ansible-ös világból on-prem k8s-be költöztetni.

A nagy felhős szolgáltatóknál futtatás egyszerűbb és/vagy olcsóbb mint az on-prem volt azért kellett váltani? Vagy az on-prem beruházás, üzemeltetés okozott (szakember oldalon) gondot? Azt értem, hogy a fejlesztők adaptálódtak ügyesen.

A megrendelő motivációról nem tudok, az anyagiakat sem látom :)

Személyes tapasztalatom az, hogy jelenleg a fejlesztői környezetünk fut on-prem, self-managed k8s-ben (amihez hála égnek nekem semmi közöm), de folyton csak a szenvedés van vele - a storage szétesik néha alatta, a frissítése borzalom, stb. Ahogy hallottam, az on-prem k8s időkben a frissítés az ügyfélnél sem volt mindig zökkenőmentes.

Saját hobbiprojektemet az Oracle ingyen egy k8s-ében futtatom, ezerszer kényelmesebb, mint VM-ekre felhúzni valami k8s implentációt, és szenvedni vele.

(amiben biztosan jobb a cloud most, hogy korábban, az on-prem időkben a vége felé, amikor már nagyon kinőtte az on-prem infrát a minden is, akkor az extra terheléses időszakokban lettek low-prio, backend szolgáltatások leállítva azért, hogy a fő szolgáltatás kiszolgáljon mindenkit -> ez a cloudban nem fordult még elő, az autoscaling szépen megold mindent)

Az lehet, hogy cloud native rendszereknél az 50 vCPU és 200 GB memória kicsinek számít, de itthoni viszonylatban szerintem nem számít kicsinek egy olyan rendszer, aminek ilyen erőforrás igénye van átlagosan.

Most megszámoltam a saját kis hobbi- és egyéb projektjeimet: 32 vCPU, 92 GB memória, 1,6 TB storage. Szóval én egyedül nem számítok kicsinek? :D

https://iotguru.cloud

( Vamp | 2023. 04. 28., p – 10:23 )

Update1-re.

 

Ahogy en latom, a fejlesztok tenyleg toljak erosen ezt a temat, uzemeltetoi reszrol sztm nincs vele tul sok tapasztalat...

Abszolute kevés, sőt kifejezetten káros.

Ha a fejlesztő tolja, és erölteti, az IT üzem meg ellenáll, jobb esetben passzív, akkor abból lesz a legnagyobb káosz. Kezdve az itt-ott felbukkanó single VM docker telepítésektől az árnyék informatikáig (shadow IT).

Egy ilyen átmenet akkor vezényelhető le rendesen és értelmesen, ha az IT vezetéstől jön az igény, és az üzlet jóváhagyja. Ehhez meg az kell, hogy az IT vezetés számokkal bizonyítsa, hogy megéri a váltás. (A bizonyítás nagyjából úgy meg, hogy megmagyarázza, hogy, azért költ el most mondjuk 300 milliót, hogy 5 év alatt spóroljon 600-at.)
Ahhoz meg az kell, hogy az IT vezetés "képben" legyen a technológiáról, költség/előny szinten is.

En is pontosan igy latom igen. Pl nagyon sokszor latom azt, hogy a fejleszto hozna a kontenert, meg ajanlgatja a Kubernetes-t etc... de kozben egy olyan webappot ad, ami esszecialisan megiscsak php/sql/nginx/tomcat es tarsaibol all... ilyenkor kerdez vissza az uzemelteto/vevo, hogy OK de ezt mi osszerajuk egy VM-en is, szuperul bejaratott backup/failover/disaster/HA rendszerben, akkor miert is kukazzuk ezt az ujert?

szuperul bejaratott backup/failover/disaster/HA rendszerben

Az a baj, hogy nagy általánosságban nincs ilyenjük. Nincs is szuperül bejáratva, hanem "ezt így szoktuk" és ilyenkor jönnek olyan üzenetek (), hogy éjjel 22:00 és 05:00 között lófasz se lesz elérhető, pedig csak egy nyomorult weboldalt frissítenek.

A legtöbb probléma amúgy abból adódik, hogy a technikai élesítés és az üzleti élesítés nincs külön kezelve és minden élesítés éjjel történik, mert akkor okoz kevesebb bajt a leállás.

https://iotguru.cloud

A technikai vs üzleti élesítésnek köze nincs ahhoz, hogy milyen architektúrán fut az alkalmazásod.

Bare metal szerveren futtatott php+mysq "üzleti" alkalmazást is meg lehet úgy írni, hogy a technikai és üzleti élesítés elkülöníthető legyen.
És a legprofibban összarakott k8 clusterbe is deployolható olyan alkalmazás, ahol deploy után 5 perccel minden kliensen egyszerre élesedik minden új funkció.

És nem feltétlen azért kell éjszaka leállni mert nincs elkülönítve a technikai és üzleti élesítés. Vannak olyan technikai módosítások amihez mondjuk egy adatbázison nem szabad lekéréseknek futni, mert csak. Ekkor le kell állítani, hogy megcsinálhasd a technikai élesítést, amit mondjuk később követhet az üzleti élesítés amihez már nem kell majd leállás.

A technikai vs üzleti élesítésnek köze nincs ahhoz, hogy milyen architektúrán fut az alkalmazásod.

Hogy a lófaszba ne lenne.

Bare metal szerveren futtatott php+mysq "üzleti" alkalmazást is meg lehet úgy írni, hogy a technikai és üzleti élesítés elkülöníthető legyen.

Tehát tudsz egyszerre több üzleti verziót kezelni anélkül, hogy a kód lenne tele if-then-else blokkokkal?

És nem feltétlen azért kell éjszaka leállni mert nincs elkülönítve a technikai és üzleti élesítés.

De, a legtöbb helyen azért kell leállni éjjel, mert akkor megy ki a deployment és azzal egy időben kerül ki az üzleti feature.

Vannak olyan technikai módosítások amihez mondjuk egy adatbázison nem szabad lekéréseknek futni, mert csak. Ekkor le kell állítani, hogy megcsinálhasd a technikai élesítést, amit mondjuk később követhet az üzleti élesítés amihez már nem kell majd leállás.

Én egy kezemen meg tudtam számolni azokat az élesítéseket az utóbbi 20 évből, aminél azért kellett leállni, mert _csak_ technikai upgrade volt.

https://iotguru.cloud

"Tehát tudsz egyszerre több üzleti verziót kezelni anélkül, hogy a kód lenne tele if-then-else blokkokkal?'"

 

K8s ezt nyilván speciális célhardverrel oldja meg.... ja nem. Akkor ugyanúgy, szoftveresen.

attól hogy nem K8s még nem biztos, hogy monolitikus. A multi tiering már k8 előtt is létezett.

Külömböző frontend verziót szolgálhat ki más backend komponens...ez nem attól függ, hogy mi a futtató környrzet.

K8s ezt nyilván speciális célhardverrel oldja meg.... ja nem. Akkor ugyanúgy, szoftveresen.

Nem, nem kell hozzá célhardver, de nulla effort kell hozzá.

attól hogy nem K8s még nem biztos, hogy monolitikus. A multi tiering már k8 előtt is létezett.

Hogyne, nyilván. Csak elég nagy effort kell hozzá.

Külömböző frontend verziót szolgálhat ki más backend komponens...ez nem attól függ, hogy mi a futtató környrzet.

Nem, csak sokkal-sokkal-sokkal egyszerűbbé teszi. Egy rendes K8s cluster és CI/CD esetén egy feature branch azonnal és automatikusan kap egy feature környezetet, akár éles környezetben is. Ugyanez minden más esetben igen sok kézimunka, ezért nem is csinálják.

https://iotguru.cloud

Az a baj, hogy nagy általánosságban nincs ilyenjük. Nincs is szuperül bejáratva, hanem "ezt így szoktuk" és ilyenkor jönnek olyan üzenetek (), hogy éjjel 22:00 és 05:00 között lófasz se lesz elérhető, pedig csak egy nyomorult weboldalt frissítenek.

+1. Plusz ilyenkor jön az, hogy az üzemeltetés a saját bejáratott módja szerint szeretné ezt configolni, ami adott esetben teljesen más a fejlesztői módtól (pl.: spring boot beli publicstaticvoidmain, meg a nagy közös tomcat appserver), és egy használhatatlan, tesztelhetetlen szar az egész, mert élesben így szokták.

( zwei | 2023. 04. 28., p – 10:55 )

Az Update 1-re válaszolva:

Igen, nagyon sokan aki most kubernetes dolgokkal foglalkozik pusztán szakmai érdeklődésből teszi.

Viszont nálam mindig két fő részből állt a "szakma":  volt 1 amit nap szinten csináltam, és volt pár dolog amivel érdeklődésképp foglalkoztam, mert új/jó/érdekes volt.
És X évenként azt vettem észre, hogy amit addig érdeklődésből tanultam, az már a jelen, és tök jó, hogy már értek hozzá.

Szóval abszolut nem hülyeség ebbe a technológiába ölni a szabadidőt, mert ha jön egy szélesebb körű paradigma váltás, addigra már értesz hozzá, és nem akkor tanulod meg kényszerből.

( _Franko_ v | 2023. 04. 28., p – 11:13 )

Ellenben egyetlen hsz.-ben nem olvastam arról, hogy ma Magyarországon ennek hol van olyan létjogosultsága

De, többen is írták, én az utóbbi 2-3 évben egyre nagyobb arányban ezzel foglalkozom, idén kb. teljes időmben. Kis cégtől kezdve multi cégig, minden előfordult.

Jól látom a helyzetet, vagy nem igazán értettem meg, amit írtok?

Szerintem nem sikerült megértened... mondjuk volt bőven zaj is... :D

https://iotguru.cloud

Sztm a kerdezo arra nem kapott valaszt, hogy pontosan mire hasznaljak pl egy termeloi kornyezetben a Kubernetes-t ma Magyarorszagon. Addig mindenkinek vilagos, hogy fejleszto reszrol ok felpakoljak a K8S-t, abba fejlesztenek etc... De pl ma van annak realitasa, hogy a container image-t  ha te lekuldod egy xy multinak Magyarorszagon, akkor o azt siman tudja a sajat on-prem/hibrid cloudjaba integralni? Itt elso sorban azon cegekrol van szo, ahol nincs belso fejlesztes, hanem "hozott cuccbol" dolgoznak, de ettol fuggetlenul eros az IT "footstep"-juk, erosen gepesitettek, automatizaltak.

Sztm a kerdezo arra nem kapott valaszt, hogy pontosan mire hasznaljak pl egy termeloi kornyezetben a Kubernetes-t ma Magyarorszagon.

Define "termelői" környezet. Mint írtam, egy pletykalap sportrovata is K8s fut, hibrid felhőben.

De pl ma van annak realitasa, hogy a container image-t  ha te lekuldod egy xy multinak Magyarorszagon, akkor o azt siman tudja a sajat on-prem/hibrid cloudjaba integralni?

Igen, például egy EU szintű energiaszolgáltató multi esetén ez van, nemhogy simán tudja integrálni, hanem alapkövetelmény a beszállítóknak.

https://iotguru.cloud

Pl sajat peldam, Nemzetkozi autoipari beszallito multi 15+ telephellyel vilagszerte, on-prem futtat kb mindent, az alap VMware vSphere (1300-1400 VM) es Citrix (a desktopok miatt), szoftverek jo resze "erosen" MS kozeli. (ha nem MS akkor valami MS certificated)

A kérdés nem az, hogy mennyi az aránya, hanem az, hogy miért van ennyi képzés és tanfolyam.

Azért van ennyi képzés és tanfolyam, mert van rá igény és a piac felszívja azonnal azokat az embereket, akik értenek hozzá. Ezt nehéz azzal elütni, hogy "de hát nálunk nincs ilyen igény".

https://iotguru.cloud

Most is indul egy ingyenes, de lehet már elindult, de folyamatosan indulnak:

"Google 2023 Get Certified Program"

Egyébkénr a dolog megfogalmazható igy is: kell e nekem a webes szolgáltatásomhoz, weboldalamhoz, hogy minden kérést más pod, gép, VM  szolgáljon ki. Ettől nem lesz gyorsabb,  nincs annyi látogatom. Magas rendelkezésre állás meg jó, de nekem elég ami most van.

Középvállalatok windowsos vállalatirányítási rendszerei  jó pár évig futnak majd a win szerver 2033-on , meg windows 110-en .  Az ára miatt a kicsik, közepeseknek nem alternatíva, ez változhat. 

Kicsiknek: A canonical-nál  meg megcsinálták  a microk8s-et, amit nem csak tesztre  szánnak, zéró adminisztrácival hirdeti, ami barokkos túlzás, de az alapot tényleg gyorsan fel lehet rakni. 

https://blog.claryel.hu

( _Franko_ v | 2023. 04. 29., szo – 20:32 )

KSH most keres "szoftverfejlesztőt" - várjatok, megyek röhögni... na... megvolt - az alábbi feladatokra:

  • Automatizált termékelőállítást lehetővé tevő tájékoztatásir endszer kialakítása, üzemeltetése
  • CI/CD pipeline fejlesztése, üzemeltetése
  • Adattranszformációk
  • Backend alkalmazások fejlesztése, üzemeltetése
  • Kubernetes üzemeltetés

Azon túl, hogy kb. fogalmuk nincs, mire keresnek embert, a K8s betette oda is a lábát 

https://iotguru.cloud

( Raynes v | 2023. 04. 30., v – 00:55 )

Szerkesztve: 2023. 04. 30., v – 00:57

Semmilyen nagy titkok nincs benne. A konténerizáció most az egyik újabb buzzword, ahogy írtad te is. Majd lecseng pár év után. Most mindenki ettől várja a megváltást, ezt majmolják, hogy minden legyen konténerizálva. A natív rendszerek és a virtualizáció lejárt lemez, ki kellett valami újat találni. A magyar helyzet semmivel nem speciálisabb, M.o.-n is pont ugyanarra használják, amire akármelyik más országban.

Az overheadje elvileg kisebb, mint egy virtualizációnak, de a világot ez se váltja meg. Nekem is ki fog maradni szerintem. Majd kapok is a fejemre, hogy nem vagyok fejlesztő, meg ehhez se értek. Ez van. Annyi minden használatos ma már, hogy eleve lehetetlen mindenhez érteni, ezt főleg HR-esek képtelenek megérteni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( trey | 2023. 04. 30., v – 08:07 )

Nem volt elég flame itt, akkor hozok.

Ezt is a Google-nek köszönhetjük 🤣

trey @ gépház

Hozzáértés = fanboyism?

Kiderült már itt a nagy hozzáértésben, hogy milyen piaci részt szakít ez az IT-ból Magyarországon? Mert, hogy ez volt a kérdés 😂

Szakmailag meg itt tudnál hozzátenni valamit a témához:

https://hup.hu/treyblog/20230430/kubernetes_tema

;)

trey @ gépház

A fanboyism egyebkent igaz a szakmara.

Elismerem a letjogosultsagat a k8s-nek bizonyos esetekben (pl amire mi hasznaljuk/hasznalnank) de a tobbseg meg mindig a hype miatt es a CV-driven development miatt kardoskodik mellette es bukik is bele annak rendje es modja szerint.

En speciel nem rajongok erte. Megturom, kezelem, szakertem, de csak egy a repertoarbol.

Amit linkeltel blogpostot(?) tovabbra sem tukroz mely szakmaisagot a temaban csak az altalam itt kifogasolt belebofogest.

( ricpet | 2023. 04. 30., v – 11:27 )

A környezet egy nagy multi, egy olyan terméken dolgozunk itt Magyarországon, amit globálisan használnak a cégen belül. Kubernetesen hosztoljuk, és határozottan előnyösebbnek tartjuk, mint a korábbi VM alapú megoldást.  Persze azt is hozzá kell tenni, hogy a közvetlen VM alapú az on-premise volt elég béna management lehetőségekkel, a kubernetes meg most AWS-ben fut, ahol nyilván minden automatizálható. Először fejlesztői környezetek átköltöztetésével kezdtük, szmáunkra leginkább itt jöttek ki az előnyök, mert fejlesztői környezetből van több is, a lehetőség most már sokkal jobban adott, hogy könnyen létrehozzunk akár egy-egy feature branch-hez egy külön dev példányt a szoftverből. Továbbá a build esetén is elég komoly spórolást tudott hozni, hogy a kubernetes-ben a build pod-hoz akkor indul el egy nagy és drága VM, amikor van build job. És akkor hamar megvan a build, aztán a VM le is áll. És így már érezhetők a cloud-os környezet előnyei, hogy akkor tudsz vele spórolni, ha hullámzó terhelésed van.

hogy tudtok a dev rendszer ala tenni "eles" adatokat? tapasztalatom szerint egy bug miatt hibasan beirt db adat szokott mashol anomaliat okozni, ha "vegytiszta" adatokkal dolgozik a dev, akkor soha nem talalja  meg hogy melyik hibas rekord csinalja az anomaliat.

nyilvan egy idealis vilagban mindenre IS van unittest, de hat a vilagunk nem idealis...

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Bár ez nem igazán függ a kubernetes vs egyéb kérdéskörtől, de erre az a megoldás, hogy van segédprogram, ami a prod db egy másolatából kitörli a szenzitív adatokat, az adatméretet nagy mértékben lecsökkenti (lehetőleg úgy, hogy a rekordszám ne csökkenjen nagyon, tehát inkább a hosszú mezők tartalmár rövidíti le), és ezt lehet dev környezetben használni.

( igor | 2023. 04. 30., v – 13:40 )

Nem magyarorszagon hasznaljak, de itthon fejlesztunk eleg sok klinikai akalmazast, tobbseguk medical device besorolasu.

Van egy sajat PaaS megoldas Kube alapokon, az akalmazasok erre keszulnek. Van on-prem es cloud verzio is. On-prem van benne par Tesla kartya is ahol modell tanitas is resze a megallapodasnak pl egyetemi korhazakkal.

Ez utobbi megoldas kint van egy nagy magyar egyetemi korhaznal is, mert reszt vesznek a kutatasban.

( franklin | 2023. 05. 01., h – 05:47 )

Szerkesztve: 2023. 05. 01., h – 05:47

A kérdést egyébként több oldalról is meg lehet közelíteni - szerintem.

 

A DevOps ugye két szóból áll: "Dev" és "Ops". Emiatt szerintem biztosan lesznek akik több "Dev"-et végeznek (ergo Jenkins DSL, esetleg groovy, gitlab-ci / travis yaml-öket pakolnak össze, adott esetben python és c++ alapú debian-okat vagy épp nix derivation-ök buildezését automatizálják dependency alapú generálással (lásd poetry, pölö, ami ugye megtehetné aptitude-nak is python kódhoz), de biztosan lesznek "Ops"-os emberek is, akik nem feltétlenül kubernetessel (flavour most mindegy, microk8s, kind, "saját összerakás") bajlódnak, de ha már annyira az "IT vs. DevOps" kerül szóba (ami egyébként lassan kicsit nekem úgy tűnt mintha "mit adtak nekünk a Lómaiak" lándzsa-kovácsolás alakulna a kérdőjelből), senki sem említette pl. az Infra kódból kulcsfogalmat aminél például terraform-mal kb. 3100 provider közül lehet választani, hogy különösebben ne kelljen bonyolult kódot írni hogy AWS-be vagy vSphere-be akarna valaki ismételhető módon telepíteni - akár kubernetes-t - de bármilyen tűzfalat, legyen postfix, bármi, de nyilván a MS oldalon a choco barátoknak is lehet kedvezni így. Szóval a DevOps nem feltétlenül "csak kubernetes" ugye.

 

Szerintem a Magyarországon lévő cégeknek éppen hogy az IT-seknek kellene bemutatni, hogy most már az "Ops" részt "Dev"-ezni lehetne, amivel sokkal gyorsabban, megbízhatóbban kapnák ugyanazt (elnézést, nem ugyanazt, ez nem nix - lásd hash), hanem "ugyanolyan" konfigurációt, és minden változtatás, ahelyett hogy "Jóska a múlt héten mind a 13 gépen beállította a hosts file-t pedig tutira", git commit alapúvá változik. Még kevés gép esetén is.

 

Tehát az, hogy "nincs rá igény" elképzelhető hogy éppen az "Ops" csapat feladata kellene hogy legyen, hogy ezeket az új technológiákat (megfelelő eszköz a megfelelő helyen, nyilván minek Jenkins tanulni annak aki még mindig - mondjuk - egy 2011 SBS-t - szeretne telepíteni), hogy ők is "Dev" és "Ops"-á tudjanak lenni, később pedig ha még csak a telepítés idején generált SSH kulcsot használnak egy ideiglenes pod-ról futtatva, hogy még a telepítés idején se legyen egyszerű feltörni a folyamatot - még a "Sec" szót is közé tehetik.

 

Szerintem aki nem csak "Ops" hanem "Dev" is egy kicsit (arányok változhatnak), többek között nagyobb az esélye hogy megérti hogy mit jelent library-ket használni, később saját magáét megírni, így könnyebben válik akár szoftverfejlesztővé is.

 

Nyilván nem minden cég vezet be kubernetes-t, de ahol olyan alkalmazást használnak, ami akár több konténert tartalmazó pod-ot takar magában, ott az erőforrások automatikus kezelése miatt szerintem lényegesen kényelmesebb lehet.

( zolij | 2023. 05. 04., cs – 08:27 )

Szerkesztve: 2023. 05. 04., cs – 08:49

Bár mikro és kisvállalkozások valóban kevésbé használják a Kubernetest, de startupok és középvállalatok között azért már akad szép számmal, ami igen. 

Nagyobb cégek közül meg néhány példa:

- mindkét skandináv telkó

- legalább az egyik nagy mobiloperátor itthon

- kb. az összes nagyobb pénzintézet

- NISZ

 

De ezek csak saját példák, linkedinen biztos vagyok benne hogy többet találsz ha álláshirdetések között rászűrsz a kubernetes / openshift valamelyikére.

 

Hozzá kell tenni, hogy a Kubernetes nem csodaszer és simán elképzelhető, hogy egy monolit alkalmazásnál, főleg ha nagy stateful adathalmazzal dolgozik, lehet hogy ugyanúgy, vagy rosszabbul teljesít, mint egy hagyományosabb rendszer. 

Ez igaz, hozzátéve hogy nem mindig teremt pénzben mérhető értéket az a "szakmailag csábítóan hangzó" UI, az auth, ingress és backend különválasztása, pedig ez általában minden alkalmazásnál előfordul valamilyen módon.

 

Az álláskereséshez azért érdemes hozzátenni, hogy a gyakorlat fontos, aki épp csak elkezd(ene) ismerkedni a kubernetessel és nincs kézzelfogható példa előtte, elég nyomasztó mennyiségű infónak tűnhet megérteni, főként hogy ha még a virtualizáció sem ismert, vagy főként bevezetett fogalom. De szerintem is "feljövőben van hogy Magyarosan mondjam" (ja, vagy ez is csak "vágyvezérelt gondolkodás" :) ).

 

Aztán ugye a túl sok elvonatkoztatás miatt ha túl széles a szakadék, könnyen járhatunk úgy mint egy game dev sw konferencián elhangzott videóban elmondottak: https://www.youtube.com/watch?v=ZSRHeXYDLko - bár hosszúnak tűnhet, azért nem rossz a mondanivalója, szerintem.