Kubernetes: aki erről lemarad, az kimarad

HUP

Egy technológia csak ritkán annyira meghatározó és felforgató, hogy nem csak egy szűk szegmensre, hanem kis túlzással szinte az összes IT-szakemberre nézve karrier-releváns. A 36. adásban a konténerek között dagonyáztunk.

Néztük nagyítóval, aztán sztratoszférából is, hívtunk K8s gurut, és széles időspektrumon átlátó rutinos rókát, de a konklúzió ugyanaz: Kubernetes volt, van, és velünk is marad. Aki erről lemarad, az kimarad - legyen akár fejlesztő, akár üzemeltető. Vendégeinkkel, Brautigam Gergellyel (Kubermatic) és Kollár Lacival (OTP Bank) megvizsgáltuk a tanulási görbéjét is, illetve természetesen szó esett arról is, mekkora a kereslet a K8s tudásra. Nem kicsi.

Az adásban elhangzott hivatkozások a Discord csatornánkon érhetők el, ahol még beszélgetni is tudsz velünk, és a többi hallgatóval. Adásainkat megtaláljátok a SoundCloudon, a Spotify-on, az Apple Podcasten, a YouTube csatornánkon, és immár a YouTube Music-on is.

( ricsip v | 2024. 06. 28., p – 12:35 )

Aki nem fejleszt, az hogyan kerülhet kapcsolatba kubernetes és tsai-val, ha nem is ops-os, főleg nem cloud-ban?

Ugyanakkor azt a részt pont megértem, ahol a techie srác arra panaszkodik h. saját szabadidejéből 3 évet beáldozott h. ezt a témát megtanulja. Aztán meg jön egy munkáltató, aki kényelmesen felnyalja azt az embert "ingyen" aki már megtanulta ezt a szakmát. Utána ők (cég) már nem akar ebbe invesztálni, továbbképezni, lényeges mértékben hozzájárulni a melós további  növekedéséhez.

Vs. az ember a munkáltatójától várja el h. támogassa olyan nagy rendszerekkel való tanulásban, amit a mérnök otthon saját szabadidejéből saját bankkártyájából már nem akarja/tudja finanszírozni.

nem néztem még meg a videot, nem tudom volt-e benne errol szo, de szerintem:

- mar sok olyan allas kiiras van, ahova k8s alapkovetelmeny

- k8s tudassal feltehetoleg az atlagnal jobban prosperalo (nyugati/kulfoldi) cegeknel dolgozhatsz, feltehetoen magasabb berert

- megy a siras-rivas hogy nehez a junioroknak elhelyezkedni, ez pont egy olyan tudas, amibol ki lehet emelkedni a tomegbol

IT cégnél technológiával dolgozva szoftvert nem állít elő és nem is tart életben, akkor az vagy tesztelő vagy designer. Az előbbinek kifejezetten jól jön a k8s tudás, az utóbbit pedig nem kell érdekelje. A többi valami üzlet közeli pozíció, ők ne legyenek irigyek, amúgy nem tilos beletanulni. Nálunk az egyik senior product igazgatónak otthon komolyabb k8s rpi klasztere van otthon játszós otthon automatizálásra, mint nekem.

Már többféle akár win desktop-ra tehető megoldás van, ahol lehet tanulni vagy épp nem összecseszni a környezetet amikor csak ki akarsz próbálni valamit. Én Rancher Desktop-ot használok erre. Már nem elérhetetlen űrtecnika drágán. Ha és Udemy-n 3500Ft-ért vettem Mumshad féle (az egyik legjobb tanfolyam amit valaha csináltam, és az nem volt kevés vagy spórolós) tanfolyamot amihez live környezet jár gyakorolni. Értékes tudás, ha érdekel is, ennyit érdemes bele fektetni.

Ezek egy része azért erősen kopik ki, a maradéknál meg... Jirát egyre nehezebben tudsz venni onpremre (tudsz még?), nyomják a cloudot. A DB költözik cloudba, ahol az indiai tudás lassan sajnos többet ér, mint bármilyen technológiai tudás.

Nem azt vitatom, hogy ne lenne töménytelen k8s-nélküli meló, de a fentiek egy része kopik el. 

A "DB koltozik a cloudba" ugyan igaz, de ott sem mindegy, hogy 1000 DTU-t kell Azure SQL-hez foglalni, vagy 4000-et, es egy jo DBA eleg jol tudja billenteni a merleget a kisebb szam fele. Persze lehet ugy is adatbazist tervezni/uzemeltetni, hogy "code first EF Core go brr", csak akkor a vilag penzet otthagyod naluk.

A Jira is tud boven melot adni egy adminnak a cloudban is, elesben is volt alkalmam latni ezt, ugy 25 ezer user onpremrol cloudba migralasa soran.

( x-daemon | 2024. 06. 28., p – 13:54 )

mar akkor lxc-ztem, mikor a kubernetes meg halvany gondolat sem volt. aztan attertem xen hypervisorra. azota sem jelent meg az igeny a kubernetesre. akkor most lemaradok? :)

neked aztan fura humorod van...

Ha kontenerizalt (mikro)service-ekkel dolgozol, akkor igen, kb. must-have, foleg cloud kornyezetben (k8s on-prem eleg szivas tud lenni). Ha egyszer rakapsz, akkor nem is akarsz rola lejonni. Egyebkent mivel managelitek a kontenereket?

Ha megoldotok mindent virtualizacioval, akkor nem, mert a K8s nem arra valo.

Na igen. Nem beszélve aztán a Solaris 10-ben 2004-ben bemutatkozó Zones-ről.

Akkoriban páran "majdnem" elhitték hogy az x86 Solaris lesz a nagyon elterjedt Unix  like OS a jövőben....

Hogy is volt a sok tízezer Indiai programozó meséje akit majd felvesznek hogy megírja az összes hiányzó x86-os hardver drivert? :)

Hát, hogy voltak a HUP-on az akkori aktuális megmondók (hja, mindig voltak itt megmondók), akik azzal roadshow-ztak itt, hogy a Solaris mennyire előremutató, most (akkor) hogy megjelent x86-ra is, meg mert ZFS meg zones milyen nagy csuda tech., meg minden, hogy mindent is bele fog verni a földbe, a Linux elsorvad és a kutyának se kell majd, a Sun Microsystems meg a világ vezető UNIX vállalata lesz, csak ki kell várni, hogy a zéró HW támogatása (9 darab hálókártya pl.) szélesebb legyen, de nem kell aggódni, mert az indiai dev horda már gőzerővel dolgozik rajta. Hamarosan!

Na, ehhez képest:

  • Sun Microsystems már nem létezik (Oracle bendőjében)
  • A Solaris már rég meghalt, csak elfelejtették még kihúzni a lélegeztetőgépet
  • A ZFS elérhető Linuxhoz (itt Linux: kernel)
  • a zones-re kb. a kutya sem emlékszik
  • az indiai dev-ek meg nyilvánvalóan lófaszra se jutottak

Továbbiakban: https://hup.hu/Sun topik

A kacagásom kb. itt kezdődött: Jonathan Schwartz interjú - a Sun Linux stratégiája (2003)

.. hadd mondjam el igazán mi is a mi Linux stratégiánk. Nincs nekünk ilyen... Nem hiszünk abban, hogy a Linux szerepet játszana a szervereken... Ha vásárolni szeretne [Linuxot], akkor el fogunk adni magának, de mi úgy hisszük, hogy a Solaris jobb alternatíva, biztonságosabb, robusztusabb, jobb minőségű, és drámaian olcsóbb a vételi ára.

trey @ gépház

( dap | 2024. 06. 29., szo – 12:14 )

subs. nagy igazságok vannak ebben az epizódban.

disclaimer: felügyelek on-prem és managed k8s-t is

( ibenny v | 2024. 06. 29., szo – 16:58 )

Szerkesztve: 2024. 06. 29., szo – 16:59

A lényeg, hogy nem változik semmi, megint félig nem magyarul zajlott a beszélgetés, borzasztóan kellemetlen hallgatni, minimális odafigyeléssel lehetne például a kb. percenként 2x elhangzó "scaling"-et skálázódásnak nevezni (nem, nem érdekel, hogy így gyorsabban esik a szátokra), ahogy az "ekkora scale-ben"-t is a legnagyobb nyugalommal lehetne "ekkora léptékben"-nek nevezni. A többit inkább fel sem sorolom.

Ahogy azt is borzasztóan kellemetlen hallgatni, hogy minden résztvevő más módon ejti ki a Kubernetes nevét, vagy hívjátok közös megegyezéssel k8s-nek, vagy adás előtt állapodjatok meg valamiben, amihez mindenki tartja magát.

De ezek is csak pusztába kiáltott szavak, rengetegszer elhangzott már, hogy magyarul kéne beszélni, semmi eredménye, így viszont minden adás minimum szekunder szégyenérzetet okoz.

Mi nem ertjuk, hogy hogyan vezetted le a fentibol a kompetencia hianyt. Mikozben csak arrol van szo, hogy az IT-sok egy resze napi 8-10 orat kommunikal angolul, igy bizony hamarabb jon az ember szajara a "scale" szo a "leptek" helyett.

neked hogy all a nyelvismereted?

lassan harom nyelvet beszelek magas szinten, es bizony ossze-vissza keveri az ember. van, amit csak az egyiken tudok, es fogalmam sincs a masik ketton, hogy van, es vica versa. ha napi 8 oraban csak az egyik szot hasznalom (scale), es igy hasznalja a szakma (az IT nyelve az angol), akkor ez van.

tldr: hulyeseget irtal fent.

A Kubernetes kiejtese nemzetkozi problema, mindenki osszevissza ejti ki, ezen kar fennakadni. Nekem csak az volt fura, hogy vki mondott egy "ká-nyolc-ess"-et is, ami csak egy irasban alkalmazott rovidites, szerintem.

rengetegszer elhangzott már, hogy magyarul kéne beszélni

¯\_(ツ)_/¯

Ez egy ógörög szó, (hajó)kormányost jelent és a kiejtése: kübernétész

Az angoloknak ez ugyanúgy egy teljesen idegen szó, aztán (jobb híján) próbálják valahogy kiejteni. A klasszikus műveltségű ember mondjon csak kübernétészt. :-)  

(Egyébként maga  a görög szó ugyanaz a tő, mint ami a latin gubernator vagy az angol governor szavakban van, tehát rokon indoeurópai nyelvek rokon szavai.)

( azbest | 2024. 06. 29., szo – 18:46 )

Lehet én értem félre, de az alkalmazásfejlesztő deveknek miért kellene kubernetest ismernie? A beszélgetést hallgatva értetlenkedem. Az alkalmazásnak tudnia kell skálázódnia, de ez nem kubernetes függő.

Persze lehet félreértem és most devops fejlesztőről és üzemeltetőről van szó, nem kóderről.

Nem a kubernetest kell ismernie, hanem az egesz ecosystemet, ami korulveszi.

Egy developernek tisztaban kell lennie a cloud-native szempontokkal:

  • nem file-ba logolunk, hanem stdout/err-be
  • kerulni kell a filesystemre irast (mert lehet hogy readonly a /, meg egyebkentis egy Pod barmikor ujraindulhat, ergo elvesznek a file-ok)
  • az app lehetoleg envvarokbol vagy konfig file-bol (amit be lehet ConfigMapbol mountolni) szedje a konfigjat, ne vmi specialis nyakatekert modon
  • keszitsen endpointokat liveness/readiness probe-okhoz
  • keszitsen prometheushoz /metric endpointot
  • ha van tracing, akkor hasznaljon opentracing/-telemetry libet, hogy kuldjon span-okat a Jaegernek
  • hasznaljon kontenerizaciot, keszitsen Dockerfile-t
  • stb., stb.

Ha kelloen devopsos gondolkodassal bir a fejleszto, akkor csinal meg:

  • helm chartot
  • alert rule-okat
  • grafana dashboardokat
  • CI-hoz teszteket

Ha a fentiek hianyoznak, akkor az alkalmazas benan uzemeltetheto k8s kozegben.

Plusz

  • legyen képes egynél több aktív példány futni anélkül, hogy inkonzisztenciát okoznának (nem röhög, van ahol ez tényleg probléma)
  • Ne várjon 100% rendelkezésre állást egyetlen pod szempontjából
  • Egy pod újraindulása ne ejtsen ki tranzakciót 
  • Legyen képes horizontálisan nagyjából lineárisan skálázódni. Nem, a 32GB memóriával és 16 vCPU-val kért konténer mint induló méret nem tűnik olyannak (bár láttam már olyat, hogy igen, de minimum red flag)
  • Non-root user nevében tudjon futni 

Az ilyen környezetek nagyon fejlesztő szemmel készülnek, cserében nagyon sok dolog hárul a fejlesztőre ahhoz, hogy ideálisan működjön, így nem opció, hogy a fejlesztőnek fogalma sincs, hol fog futni a cucca.

Plusz:

Microservice szemlelet:

  • ne akarjon mindent is egy app megcsinalni (e.g. ne monolitikus legyen), az architekturat ehhez kell igazitani
  • kulonbozo app-ok kulonbozo eletciklussal futnak: van amihez gyakran hozzanyulunk, van amihez honapokig nem
  • az app csak a business logikaval foglalkozzon, ne akarjon olyan dolgokkal foglalkozni, amit mas retegben szoktunk megoldani (pl. HTTPS terminalas, rate limiting)
  • jol definialt API-kon keresztul kommunikaljanak a microservice-ek (swagger es tarsai)
  • minel inkabb stateless legyen az app, ha ez nem megoldhato, akkor szukseg van Redis-re, vagy SQL/noSQL adatbazisra/docstore-ra, nyilvan ezekhez is erteni kell akkor

Egyeb:

  • Lehessen konnyen rollbackelni
  • N-1 es N verzios podok tudjanak egyutt futni (rolling update miatt, plusz ez kell a rollbackhez is)
  • Egyseges logolas (JSON vs. plain text), log verbosity allithato legyen
  • Feature flagekkel lehessen vezerelni
  • Jol tesztelheto legyen (nem unit tesztekre gondolok, hanem kesobb CI soran)
  • Gyakori perf. teszteles
  • ha van kulso observability (Datadog es tarsai), akkor azt is bele kell fejleszteni ertelmesen (nem csak a logot belehanyni oszt jovan)
  • A fejleszto lasson ra es erdekelje, hogy mi tortenik a commit utan:
    • CI/CD pipeline-ok
    • hogyan lehet logot nezni
    • hogyan lehet trace-eket nezni
    • alertek legyenek visszacsatolva
    • mennyi cloud resource-t fogyaszt az app (-> FinOps)
    • stb.
  • WAF-hoz szabalyok irasa
  • CDN
  • IaC szemlelet

Ha ezek mind rendben vannak, akkor johetnek az olyan fincsi dolgok mint:

  • Service-mesh
  • A/B teszteles a felhasznalokkal

Az ilyen környezetek nagyon fejlesztő szemmel készülnek, cserében nagyon sok dolog hárul a fejlesztőre ahhoz, hogy ideálisan működjön, így nem opció, hogy a fejlesztőnek fogalma sincs, hol fog futni a cucca.

Ez a devops paradigma lenyege, hogy a fejlesztes es az uzemeltetes egy csapatban osszpontosul. Nincs mutogatas a masikra.

Forditsuk meg a dolgot:

Ha a babzsakfejlesztonek nem kell foglalkoznia:

  • a logolas, tracing minosegevel
  • tesztelhetoseggel, automatikus tesztelessel (CI)
  • deploymenttel (CD)
  • config es secret managementtel
  • securityval (SecOps)
  • performanciaval, skalazhatosaggal, annak koltsegeivel (FinOps)
  • az adatbazisokkal (DBA)
  • monitoringozhatosaggal, monitoringozassal, on-call
  • firewall rule-okkal, WAF, ...
  • CDN-nel

Akkor szukseged van egy min. 10-15 fos "tradicionalis" IT-ra, akinek minden reggel vegig kell mennie az on-prem datacenteren, hogy minden LED zolden vilagit-e (mert ugye el lett koltve rengeteg penz szerverekre, VMware/Oracle licencekre, SAN storage-ra). Az Ops es Dev mutogat egymasra, hogy miert egy nagy szar az egesz.

Tenyleg jobb ez?

Szerintem jobb amikor s feleősségi körök tiszták. Mutogatás egy irányban szokott lenni, mert elég ritka, hogy az infra rosszul működik, ha működik.

Ha nem működik, akkor egyértelmű, hogy ki a felelős. Nincs mit mutogatni, látszik.

Tapasztalat az, hogy 100-ból 1-szer (vagy se) az infrával van probléma.

trey @ gépház

Csak par pelda a regmultbol (ahol kulon volt Dev (raadasul kulsos ceg), Ops (kulon linuxos, windowsos, storage-os, DBA, halozatos), QA):

  • lassu az app -> IT tegyen ala jobb/erosebb/tobb vasat
  • IT nem akart megint egy raklap HW-t es licencet venni -> mutogatas Dev fele -> Dev-nek ugye a business kategorias laptopjan jol futott anno
  • Dev-nel jol futott, Prodban mar nem (XYZ lib hianyzik es tarsai)
  • az app telihannya a logot ertelmetlen logokkal, Ops nem tud mast csinalni, mint sok TB-os storage-ot tenni a log management ala, mert policy van ra, hogy X honapig meg kell orizni
  • hiaba szoltak a Devnek, hogy szarul logol, mar keso, mert a release ki lett adva (waterfall ugye)
  • egyebkent meg senki nem tudja, hogy miert lassu, nyilvan az app nem profile-ozhato ertelmesen, venni kell rahedli penzert javahoz APM-et, ami mar csak a kovetkezo release-be kerulhet bele, mert instrumentalni kell hozza a kodot; par honap alatt elfelejtodik a szivas, descope-oljak a release-bol, pedig Ops megvette mar a cuccot
  • Dev leszarja, hogy a DB query lassu, vegyen IT jobb vasat
  • DBA nem ismeri az app business logikajat, ha ki is ismeri a nyugjeit, nem tudja atvarialni a schemat, max ratesz 1-2 indexet. Egyebkent meg minden update utan kezdodott elorol az egesz.
  • VMware-hez venni kell vROpsot, mert a vCenter alap cpu+mem grafikonjai keves
  • minden egyes update kinkeserves volt, nyilvan teljes leallassal ment, ezert (hosszu)hetvegen ejszaka kellett csinalni MINDENKINEK (ugyertem teljes QAstol)
  • nyilvan azert volt ritkan az update, mert kinlodas volt minden alkalom
  • minden update utan vadaszni kellett, hogy mi miert nem megy (firewall nyitogatasok): Ops mutogat Dev-re, hogy szar; Dev mutogat a 100+ oldalas user guide 50. oldalara, hogy o emlitette, hogy kell, igaz elirta a szamot :)
  • microsegmentationhoz kellene NSX -> rahedli penz
  • ha kiderul egy vulnerability az egyik VM-ben, akkor vissza Dev-hez hogy szituacio van, akkor szajhuzva kell kiadniuk off-cycle release-t, extra update szivas mindenkinel, random bugok megint
  • minden halozatos valtoztatasra (uj VLAN, stb.) heteket kellett varni a mas csapatokra, mire felvettek a ticketet

Es akkor igy szepen felhizalodik egy majd' 100 fos IT department, mert minden terulet megmagyarazza, hogy miert kell annyi alkalmazott arra amire. A HW + licence + datacenter koltsegekrol nem is beszelve.

Igen, es erre az egyik megoldas, hogy nem Dev es tradicionalis IT (HW, OS, storage, network, DB, stb.) szerint szeleteljuk az organizaciot, hanem applikacionkent. Egy team egy vagy tobb applikacioert felel end-to-end: irjak a kodot, foglalkoznak az adatbazissal, deploymentjevel, tesztelesevel, monitoringozasaval es akar a prodban uzemeltetesevel is. Ha gond van az app-pal, akkor nem kerdes, hogy melyik csapat foglalkozzon vele. Csak a csapaton belul kell leverekedniuk.

Ehhez az uj felallashoz szukseges a cloud-native app fejlesztes + public cloud (managed service-ek mint k8s, db, storage).

Ahogy en latom: X developer melle kb. ugyanannyi tradicionalis IT staff szukseges, meg ugye egy valag HW+SW+licence. Mig egy modern app fejleszteshez picit tobb (legyen 1.3X), kompetensebb (=tobb berert dolgozo) devopsos szemleletu developer kell + par cloud admin (mondjuk 3) es ennyi. A public cloud koltsege 1-2-3 alkalmazott berebol kijon, nyilvan erosen fugg a business jellegetol. Nem kellenek dedikalt halozatosok, storage-osok, DBA-k, linux+windows adminok, ilyesmik. Nem csak a TCO jelentosen kevesebb, hanem a ceg alkalmazottai a core businessel tudnak foglalkozni, es nem azzal vannak sportoltatva az IT-sok, hogy jajj VMware arat emelt es migralni kell.

Én ezt értem, azt is, hogy ennek van helye az IT-ban, de úgy előadni, hogy ez megkerülhetetlen ...

Eleve, ahol nem fejlesztenek semmiféle app-ot, hanem off the shelf szoftvereket üzemeltetnek, semmi ilyesmire nincs szükség. És az IT jó részén ilyeneket üzemeltetnek.

trey @ gépház

Szerintem az nyilvanvalo, hogy a video azon szoftverfejlesztokrol szol, akik szeles piacra fejlesztenek vmit. Nem a kormanyszervo embedded SW fejlesztorol es Windows domain adminisztratorrol van szo.

Az sajnalatos, hogy Magyarorszagon gyenge a startup kultura, igy a hazai IT szakemberek tobbsege nagy multinal vagy NER-es (van penz lovera) cegeknel dolgoznak, ahol nagy az IT department, es a sajat kis silojukban nem ertik, hogy mire jo a kubernetes ecosystem. Ez van.

Az utolsó bekezdésed bullshit, lázálom, bocs. Nem mindig ilyen szép a világ, mint ahogy leírod. Végig kell számolni, hogy mikor melyik megoldás éri meg. A legnagyobb baj, hogy a cégek, ügyfelek képtelen / lusták végigszámolni és majd rendszeresen újraszámolni a TCO-t.
Rövid távú stratégia != hosszú távú stratégia.

A cloud nem csodaszer. Csak egy lehetséges megoldás pár IT és üzleti feladatra.

Nem mindig ilyen szép a világ

Lehet. De megis latszik az a trend (lehet hogy nem Magyarorszagon, hanem nyugaton, bar idehaza OTP is raallt mar mint latjuk a videobol), hogy uj app fejleszteseket mar cloud-native-kent csinaljak a fenti okok miatt.

Ha szoftver fejlesztokent ezt nem koveted le, akkor elobb-utobb hatranyba kerulsz azokkal, akik viszont megteszik.

Persze. A public cloud arra jo, hogy mielobb elerjuk az MVP-t, piacra kerulest, majd tartani a gyors fejlesztest. Nem kell arra varni, hogy az on-prem cucc elkeszuljon hetek, honapok alatt.

Kesobb pedig lehet mindenfele hybrid konstrukciokkal probalkozni, attol fuggoen, hogy minek milyen dinamikus skalazodasi igenye van. On-prem k8s se ordogtol valo, bar ketsegtelen, hogy sokkal macerasabb mint a managed EKS/AKS/GKE.

On-prem k8s se ordogtol valo, bar ketsegtelen, hogy sokkal macerasabb mint a managed EKS/AKS/GKE.

Ezzel igy ebben a formaban azert tudnek vitatkozni. Onprem nagyobb az Ops BAU koltseg, a managed viszont egy fekete doboz, hallottam mar ott is akkora szivasrol, hogy szerintem boven kinullazott minden potencialis megtakaritast onpremhez kepest.

Onprem szivas tud lenni a kulonfele cert-ek rotalasa, etcd nyavajai (kulonfele infra outage-bol osszevakarni), bootstrap miatt static podok, k8s upgrade-ek soran deprekalt dolgok csereje (docker->containerd ugye), node OS csere (centosrol el), iptables->nftables, meg hasonloak. Ezek mind elkerulheto managed k8s eseten, mert a tamogatott OS image-ben mar masok megoldottak elottunk. Raadasul onprem k8s tobbnyire VM-ekben fut, tehat az alatta futo cluster uzemeltetese is a csapatra harul, a fenti eszmefuttatasom meg pont arrol szol, hogy ezektol szeretnenk megszabadulni.

Terraform segitsegevel egy ember lazan elvisz 5-10 managed k8s-t, mig onpremhez kell legalabb 5 fo, mert folyton masszirozni kell vmi miatt.

Nekem meg szerencsere nem volt nagy EKS borulasom, ugyhogy a merleg egyertelmuen a managed fele billen.

Ez kb működik egy startap pár fős porjektjével.

Nagyban viszont nem lehet 100 főt vagy 1000 főt egy csapatba tenni.

A szálon felsorolt igények nagyrészt korrektek, de általánosságban igaz, hogy jól specifikált be és kimenet és igénylista kell. 

Nem mindenhez értő midenki kell, hanem minden területhez olyanok, akik értenek ahhoz. A köztük való kommunikációhoz viszont szerintem is kellenek olyan emberek, akik a csapatok közti kapcsolattartásnál értik, mint mond a másik csapat.

Nagyban viszont nem lehet 100 főt vagy 1000 főt egy csapatba tenni.

Ezert kell a monolit alkalmazast microservice-ekre bontani. Ha sikerul, akkor a csapatok is ugy aprozodnak.

de általánosságban igaz, hogy jól specifikált be és kimenet és igénylista kell. 

Vannak dolgok, amit nem lehet meguszni. Egy monolitot hogy fejleszt 1000 ember specifikacio nelkul?

Nem mindenhez értő midenki kell, hanem minden területhez olyanok, akik értenek ahhoz.

Nem mindenkinek kell mindenhez erteni, hiszen az kb. lehetetlen, hanem az a cel, hogy minden csapatban (agile team) legyen mindenfele affinitasu ember:

  • nyilvan jo koder az adott nyelven: frontendes, backendes (ugye ebbol alakult ki a full-stack fejleszto)
  • legyen olyan ember aki jobban vagja a cloud szolgaltatasokat
  • legyen aki jol erti a DB-t
  • legyen aki szeret tesztelni (ha ilyen nincs, akkor QA-bol lehet egy embert allokalni)
  • devopsos a pipeline-okhoz
  • stb.

Es akkor a csapaton belul megbeszelik (napi standup) ki miben tud segiteni. Agile frameworkokben ki is van szamolva, hogy 7 fos csapatok az idealisak.

A köztük való kommunikációhoz viszont szerintem is kellenek olyan emberek, akik a csapatok közti kapcsolattartásnál értik, mint mond a másik csapat.

Erre van a PO, ha agile van. Egyebkent meg a lead-ek, seniorok megoldjak.

"minel inkabb stateless legyen az app, ha ez nem megoldhato, akkor szukseg van Redis-re, vagy SQL/noSQL adatbazisra/docstore-ra, nyilvan ezekhez is erteni kell akkor"

ez a xen alatt futo fix mennyisegu virtualis gepnel is igy van, az adatokat es session adatokat sql szerveren taroljuk, ideiglenes adatokat redis clusterben.

neked aztan fura humorod van...