Ebben az iparban olyan factory-k vannak, amiknek nincs kéményük, managerek, akik nem járnak meetingre és engine-k, amik nem vontatnak semmit. Nyilván kicsit lököttek is vagyunk. Ebbe fog most az alábbi is passzolni egy kicsit, elég absztrakt lesz és annyi időt szánok rá a magyarázatra, amíg a managerem fel nem ébred.
Az előző bejegyzésekben már említettem a 2000es évek IaaS architektúrájának egy tipikus elemét, a schedulert.
A különbség az oVirt, a Cloudstack és más IaaS platformok schedulere és a kerub plannere között az, hogy míg a schedulereket akkor hívja meg a rendszer, amikor be kell ütemezni egy új virtuális gépet, a planner minden eseményt megkap. Minden eseménynél értékeli, hogy az új helyzet minden expectationt (azaz SLA contract) kielégít-e. Például a virtuális gép, aminek futnia kell, az tényleg fut, és olyan környezetben és hardweren amit kért a felhasználó.
Minden event az tényleg minden eventet jelent, amikor a szerver jelenti az éppen aktuális terheltségét az egy event, amikor a VM módosult, az szintén egy event.
Amikor az expectation nem teljesül, akkor a planner lépéseket gyárt le lépés-factory-k segítségével. A factory egyetlen dolgot kap: a jelenlegi helyzetet, ami magába foglalja a VM-ek, virtuális merevlemezek satöbbi, valamint a fizikai eszközök statikus (nem változó), dinamikus (állapot) és konfigurációs adatait. Ez alapján egyetlen dolgot csinálnak: listát a lehetséges lépésekből. A factory-k teljes mértékben tesznek arra, hogy van-e valami értelme a műveletnek, csak legyártják a lépéseket és kész.
Minden legenerált lépés az aktuális állapotot transzformálja egy másik állapotra. A progmatos állapottér-model elkötelezett hívei azonnal vegyék le a kezüket a farkukról, fúj gusztustalan! Szóval például egy bizonyos fajta lépés az egyik hostról átpakolja a másik hostra az egyik VM-et (nevezzük migrációnak), egy másik egy hostot kapcsol ki, (nevezhetjük power managementnek, de bug is lehet)
A lépéseknek persze van költsége, különböző költségtípusok, például idő, számítási és IO igény, vagy akár a kockázat, hogy valami gixer üt be, az is egyfajta költség.
Ezen kívül a lépéseknek vannak erőforrás igényei is, például egy host osztott vagy kizárólagos használata, tárhely vagy számítási kapacítás, illetve a virtuális erőforrások, amit használnak. Ez a feladatok koordinálásához kell, pl hogy ne tervezzen keresztbe már folyamatban lévő ügyek végrehajtásával, ne kapcsoljuk ki azt a hostot amit egy másik terv éppen bekapcsolt valamilyen célból, ilyesmi.
Nyilván minden lépéshez kell egy végrehajtó kód is, mert a lépés önmagában olyan absztrakt hogy fingja nincs melyik lábbal induljon el, csak az állapotteret transzformálja. A végrehajtónak viszont van kapcsolata a konkrét anyagi világgal, ez többnyire egy ssh kapcsolat egy vagy több kiszolgálóhoz.
hmm mi hiányzik még... ja persze, hogy ez mitől kezdene működni... Az már egyszerű, csak egy kereső algoritmus. Egy depth-first backtrack-et csináltam rá, ezt nevezhetjük átmeneti megoldásnak, mert valószinűleg más keresés gyorsabb lenne, de ez is tűrhetően párhuzamosítható.
Ennek az eredménye az, hogy a kerub keres egy módot arra, hogy a kéréseknek megfelelően futtassa a virtuális gépeket, merevlemezeket, hálózatot, satöbbi. A többi IaaS megnézi, hogy van-e passzoló host és ha nincs akkor pl nem indul a vm, csókolom.
Az biztosan gyanús már az elejétől, hogy a planner elég rendesen busy-box, mert minnél több a VM és a host, annál több event érkezik és annál több expectation-t kell ellenőrizni. Másrészt az egyre több factory egyre több lépést generál az egyre több VM-re. Ezek sajnos problémák, bár van rá ötletem, a keresési probléma egyébként is exponenciálisan növekedik. Jelenleg egy pár szűkítés van érvényben a factory-kra a kielégítetlen elvárások típusa alapján, de sokat az érne, ha nem kellene minden elvárást mindig kiértékelni, ha a factory-k listája lazy módon értékelődne ki.
Meglátjuk meddig jutok el vele, de a cél egyébként nem matematikai értelemben vett optimális állapot hanem csak egy egész jó :)
2016. december 24., szombat
2016. december 4., vasárnap
final code-review-review
Vannak érvek a codereview mellett és ellene is. Kellett hozzá néhány év türelem, had gyűljenek az élmények. Ragyogó elméletek kontra szőrös valóság. Legyenek akkor elöbb a pro, mert az egyszerűbb, és sajnos sokkal rövidebb is.
Egyik régi munkaadómnál a külső beszállítók gyakorlatilag review nélkül, és a management nyomására nem elég ritkán tesztelés nélkül is élesbe állították a rendszereiket. Mindenki boldog volt, amíg el nem szállt. És akkor jött a körkérdés: "Ért itt valaki groovy-hoz?" mire a legtöbben: "Mihez?"
Élesben fut egy rendszer, azt se tudtuk hogy mit csinál és ki használja, de elhasalt és fel kell támasztani.
Ugyanitt önként és meghívásos alapon elkezdtünk egymás között egy code-review szerűséget. Tea vagy narancslé, két szék, egy képernyő, együtt átnéztük a szoftver egy részét. Az ötlet az volt, hogy a review-er egyúttal backup ember is lehet, ha az eredeti fejlesztő nem elérhető, mert mondjuk elütötte egy autó. Például ez meg is történt velem.
A review során a review-erek inkáb csak ötleteket adtak, nem kötelező jellegű utasításokat. Jópár nagyon jó és hasznos ötletet kaptam és ezeket a review-ket úgy tünt mindkét oldalon pozitívan értékeltük. Mindkét fél ott ült, mindenki csak erre figyelt, elég gyorsan ment. A pár-hetente pár óra aligha lassította a fejlesztést, ugyanakkor viszont arra nem volt jó hogy konkrét hibát találjon.
A szorosabb review process ötlete főleg, de nem kizárólag az open source projektek jellemzője. Mondjuk egy open source projekten tényleg át kell nézni az akárkiktől érkező patcheket, de ezzel sok probléma akadt:
Elösször is léteznie kellene egy alap kritérium listának, ami alapján elindul az ember, amolyan checklist. Ilyesmiket, mint kódformázással kapcsolatos szabályok. Ilyen többnyire nincs és helyette olyanokat szoktak mondani, mint "common sense", "well known traditions". Ez nem működik, ami az egyik kultúrában értelmes, az a másikban nem. Pl ami a spring-ben normális, az Java EE-ben nem az.
A helyzetet súlyosbítja, ha több reviewer is lehet, ugyanis többnyire ők sem értenek egymással, ami átmegy az egyiken fennakad a másiknál és fordítva.
Aztán a másik dolog ami a code review igéretei közűl megmaradt igéretnek az a párbeszéd. Egy webappon keresztül akarunk beszélgetni? Ne tessék viccelni, már a shared desktop + skype is elég szűkös néha, mert nincs hova rajzolni, lag-el a vonal, nem értjük elég jól egymást, esetleg a nálam már hajnalodik, a másik fél viszont még nem ebédelt.
Itt egy kicsit a kultúrális különbségek bejátszottak. Például sok izraelli munkatársam még mindig aktív katonai szolgáltaban állt, ők a command chain-hez voltak hozzászokva, az ő napi megszokásuk az volt, hogy a besztottak végrehajtják a parancsot. Abból lesz ám fasza dolog :)
Más kultúrákban is van így, például sok indiai is ha egyszer mondott valamit, akkor nagyon nehezen, vagy egyáltalán sehogy se tud kihátrálni. Persze ismerek kivételeket köztük is, de ez a rugalmatlanság amerikaiaknál és európaiaknál ritkábban fordul elő.
Harmadik beteljesítetlen igéret a kevesebb bug a kódban. A probléma talán onnan jön, hogy egy webappon keresztül nézegetik a reviewerek a kódot. Az hogy letöltsék és ki is próbálják, az opcionális, és mivel sok időt vesz igénybe, úgy látom többnyire nem is történik meg. Ezt a legtöbben be is vallották és azt mondták, a patch fejlesztőjének a felelőssége a tesztelés. Ebben nem értek egyet, teszt nélkül szerintem a review teljesen irreleváns.
Egy esetben pl 5 hónapig pöckölgettünk egymásnak patcheket, a végén a management nyomására lett vége a sztorinak. Bár egy délután alatt bőven le lehetett volna tesztelni a kódot, sajnos ez alatt az idő alatt én voltam az egyetlen aki kipróbálta.
A negyedik elmaradt igéret a tisztább kód. Bár a code review elvileg kivállóan betartatná a konvenciókat, a valóságban gyakran ez sem így történt. A már meglévő kód takarítása gyakorlatilag megvalósíthatatlanná vállt. Nem maradt rá idő. Amikor mégis beküldessz egy kis patchet, akkor a review gudelines hiánya miatti félreértések következnek: vedd még mást is hozzá illetve már így is túl sok, várj még a patch-csel illetve elavult és légyszi rebaseld.
Az ötödik probléma a review-val a határidő. Sajnos a reviewerek a gyakorlatban teljesen leszarták a határidőket. Ez már management hiba, de meg is tehették, mert rajtuk senki sem kérte számon. Gyakran hetekig vagy akár hónapokig is eltartott egy review, közben nem történik semmi. Ez két további problémát vet fel:
Mindenesetre a tavalyi év végére eldöntöttem, hogy olyan munkát akarok, ahol ezt veszélyt kiküszöböltük. Az elműlt egy évben ilyen helyen dolgoztam. Nyugodt volt a hangulat, bár pár alkalommal rendesen bele kellett húzni, végül mégis kényelmesen elértük a határidőket, az ügyfél boldog és nagyon jó fej velünk. Nekem ez bevállt és megtartom ezt az irányelvet: amíg találok olyan munkát ahol nincs potenciális probléma, addig olyat vállalok!
Code Review: Good Bye!
Pro - ami működött
Egyik régi munkaadómnál a külső beszállítók gyakorlatilag review nélkül, és a management nyomására nem elég ritkán tesztelés nélkül is élesbe állították a rendszereiket. Mindenki boldog volt, amíg el nem szállt. És akkor jött a körkérdés: "Ért itt valaki groovy-hoz?" mire a legtöbben: "Mihez?"
Élesben fut egy rendszer, azt se tudtuk hogy mit csinál és ki használja, de elhasalt és fel kell támasztani.
Ugyanitt önként és meghívásos alapon elkezdtünk egymás között egy code-review szerűséget. Tea vagy narancslé, két szék, egy képernyő, együtt átnéztük a szoftver egy részét. Az ötlet az volt, hogy a review-er egyúttal backup ember is lehet, ha az eredeti fejlesztő nem elérhető, mert mondjuk elütötte egy autó. Például ez meg is történt velem.
A review során a review-erek inkáb csak ötleteket adtak, nem kötelező jellegű utasításokat. Jópár nagyon jó és hasznos ötletet kaptam és ezeket a review-ket úgy tünt mindkét oldalon pozitívan értékeltük. Mindkét fél ott ült, mindenki csak erre figyelt, elég gyorsan ment. A pár-hetente pár óra aligha lassította a fejlesztést, ugyanakkor viszont arra nem volt jó hogy konkrét hibát találjon.
Kontra
A szorosabb review process ötlete főleg, de nem kizárólag az open source projektek jellemzője. Mondjuk egy open source projekten tényleg át kell nézni az akárkiktől érkező patcheket, de ezzel sok probléma akadt:
Elösször is léteznie kellene egy alap kritérium listának, ami alapján elindul az ember, amolyan checklist. Ilyesmiket, mint kódformázással kapcsolatos szabályok. Ilyen többnyire nincs és helyette olyanokat szoktak mondani, mint "common sense", "well known traditions". Ez nem működik, ami az egyik kultúrában értelmes, az a másikban nem. Pl ami a spring-ben normális, az Java EE-ben nem az.
A helyzetet súlyosbítja, ha több reviewer is lehet, ugyanis többnyire ők sem értenek egymással, ami átmegy az egyiken fennakad a másiknál és fordítva.
Aztán a másik dolog ami a code review igéretei közűl megmaradt igéretnek az a párbeszéd. Egy webappon keresztül akarunk beszélgetni? Ne tessék viccelni, már a shared desktop + skype is elég szűkös néha, mert nincs hova rajzolni, lag-el a vonal, nem értjük elég jól egymást, esetleg a nálam már hajnalodik, a másik fél viszont még nem ebédelt.
Itt egy kicsit a kultúrális különbségek bejátszottak. Például sok izraelli munkatársam még mindig aktív katonai szolgáltaban állt, ők a command chain-hez voltak hozzászokva, az ő napi megszokásuk az volt, hogy a besztottak végrehajtják a parancsot. Abból lesz ám fasza dolog :)
Más kultúrákban is van így, például sok indiai is ha egyszer mondott valamit, akkor nagyon nehezen, vagy egyáltalán sehogy se tud kihátrálni. Persze ismerek kivételeket köztük is, de ez a rugalmatlanság amerikaiaknál és európaiaknál ritkábban fordul elő.
Harmadik beteljesítetlen igéret a kevesebb bug a kódban. A probléma talán onnan jön, hogy egy webappon keresztül nézegetik a reviewerek a kódot. Az hogy letöltsék és ki is próbálják, az opcionális, és mivel sok időt vesz igénybe, úgy látom többnyire nem is történik meg. Ezt a legtöbben be is vallották és azt mondták, a patch fejlesztőjének a felelőssége a tesztelés. Ebben nem értek egyet, teszt nélkül szerintem a review teljesen irreleváns.
Egy esetben pl 5 hónapig pöckölgettünk egymásnak patcheket, a végén a management nyomására lett vége a sztorinak. Bár egy délután alatt bőven le lehetett volna tesztelni a kódot, sajnos ez alatt az idő alatt én voltam az egyetlen aki kipróbálta.
A negyedik elmaradt igéret a tisztább kód. Bár a code review elvileg kivállóan betartatná a konvenciókat, a valóságban gyakran ez sem így történt. A már meglévő kód takarítása gyakorlatilag megvalósíthatatlanná vállt. Nem maradt rá idő. Amikor mégis beküldessz egy kis patchet, akkor a review gudelines hiánya miatti félreértések következnek: vedd még mást is hozzá illetve már így is túl sok, várj még a patch-csel illetve elavult és légyszi rebaseld.
Az ötödik probléma a review-val a határidő. Sajnos a reviewerek a gyakorlatban teljesen leszarták a határidőket. Ez már management hiba, de meg is tehették, mert rajtuk senki sem kérte számon. Gyakran hetekig vagy akár hónapokig is eltartott egy review, közben nem történik semmi. Ez két további problémát vet fel:
- Nagyon gyakori task-switching. Ebben a gépek a nyerők, az embernek sok időbe tellik és a párhuzamos taszkok számával exponenciálisan nő a valószinűsége annak, hogy elcseszi. Csinálj egy dolgot, csináld addig, kész nem lesz!
- Ha nem tudok igéretet kapni a reviewerektől a határidőkre, akkor hogyan tudnék én igéretet adni határidőkre? Ez a legsúlyosabb probléma a code review-vel a hétköznapi életben.
Szóval...
A code review mögötti ötlet érthető, csak a gyakorlati megvalósítása elött van egy pár akadály, amit a projekt vezetők gyakran figyelmen kívül hagynak. Nem tartom elképzelhetetlennek azt, hogy működjön, csak valószinűtlennek. Túl könnyű szarba lépni, mint egy gyanútlan túristának a nyóckerben.Mindenesetre a tavalyi év végére eldöntöttem, hogy olyan munkát akarok, ahol ezt veszélyt kiküszöböltük. Az elműlt egy évben ilyen helyen dolgoztam. Nyugodt volt a hangulat, bár pár alkalommal rendesen bele kellett húzni, végül mégis kényelmesen elértük a határidőket, az ügyfél boldog és nagyon jó fej velünk. Nekem ez bevállt és megtartom ezt az irányelvet: amíg találok olyan munkát ahol nincs potenciális probléma, addig olyat vállalok!
Code Review: Good Bye!
2016. november 13., vasárnap
No kerub-agent
A legtöbb IaaS egy agent nevű szoftverre épít, ami minden host-on fut. Ez egyrészt egy olyan szoftver, ami a kommunikációt bonyolítja a controller és a host között, másrészt egy absztrakciós réteg is.
Az ovirt-ben ez egy VDSM nevű python script, ami XML-eket kap a kontrollertől és azt lefordítja másféle XML-be, konkrétan a libvirt XML formátumába, másrészt pedig néha operációs rendszer parancsokra, szóval kicsit többet csinál mint egy XSLT processzor :)
A cloudstack-nek egy java agentje van. Elsőre kicsit soknak tünhet akár fél gigát is beáldozni a host memóriájából egy ilyen, viszonylag erőforrásigényes processznek, de tipikusan a cloudstack felhasználók TB-ben mérik a host memóriát és fél giga nem kategória. A java-t inkáb azért nem tartom szuperfrankó választásnak agenthez, mert brutálisan béna az operációs rendszerekkel az integrációja, például a processz kezelés, meg persze mindenkinek vannak ellenérzései a JNI-vel szemben. JNI pedig van, persze hogy van...
Viszont itt nyilván előny, hogy a java fejlesztő, aki a kontrollert buherálja, az az agentet is simán buherálhatja minden további tanulmányok nélkül.
Mindkettő http protokolt használ: kapcsolódunk, kezetrázunk, bemutatkozunk, valami teljesen minimális dolgot közlök veled aztán elbúcsúzunk és fél másodperc múlva újrakezdjük. Az oVirt még emellett egy döbbenetes dolgot is csinál a tranzakciókkal, ami a MS-SQL-ből PostgreSQL-re való áttérés (és talán egy súlyos félreértés) eredménye.
Amikor azon gondolkodtam, hogy hogyan tudnék jó agentet a kerubhoz, elösször is inkáb azon gondolkodtam hogyan lehetne megúszni az egészet, mert nincs rá időm. Másodszor pedig szerettem volna megszabadulni a kommunikációs overhead-tól, pl xml parsing.
Végülis az, hogy nincs agent, azt nevezhetjük félrevezető marketing-baromságnak, mert valamilyen szoftvernek futnia kell, amivel kommunikálunk. Ennyi lett: OpenSSH, az OpenBSD klasszikus SSH szervere, ami fut linuxon, windowson (cygwin), mindenféle BSD-n és solarison, ráadásul többnyire része egy szerver alaptelepítésnek.
Az absztrakciós réteg... egy része ott van a kontrollerben, mert annak tudnia kell, hogy milyen operációs rendszerhez beszél, az absztrakciók nagy része viszont elment. Eleinte csináltam abstrakciót a hypervisor-elé, de később találtam jobb megoldást és mostanában lassan eltávolítom ezeket a kerub-ból.
Ez most hosszú lett, mert vasárnap van, legyen legközelebb például az, hogy mit csinál a planner és miért nem kellenek az absztrakciók.
Az ovirt-ben ez egy VDSM nevű python script, ami XML-eket kap a kontrollertől és azt lefordítja másféle XML-be, konkrétan a libvirt XML formátumába, másrészt pedig néha operációs rendszer parancsokra, szóval kicsit többet csinál mint egy XSLT processzor :)
A cloudstack-nek egy java agentje van. Elsőre kicsit soknak tünhet akár fél gigát is beáldozni a host memóriájából egy ilyen, viszonylag erőforrásigényes processznek, de tipikusan a cloudstack felhasználók TB-ben mérik a host memóriát és fél giga nem kategória. A java-t inkáb azért nem tartom szuperfrankó választásnak agenthez, mert brutálisan béna az operációs rendszerekkel az integrációja, például a processz kezelés, meg persze mindenkinek vannak ellenérzései a JNI-vel szemben. JNI pedig van, persze hogy van...
Viszont itt nyilván előny, hogy a java fejlesztő, aki a kontrollert buherálja, az az agentet is simán buherálhatja minden további tanulmányok nélkül.
Mindkettő http protokolt használ: kapcsolódunk, kezetrázunk, bemutatkozunk, valami teljesen minimális dolgot közlök veled aztán elbúcsúzunk és fél másodperc múlva újrakezdjük. Az oVirt még emellett egy döbbenetes dolgot is csinál a tranzakciókkal, ami a MS-SQL-ből PostgreSQL-re való áttérés (és talán egy súlyos félreértés) eredménye.
Amikor azon gondolkodtam, hogy hogyan tudnék jó agentet a kerubhoz, elösször is inkáb azon gondolkodtam hogyan lehetne megúszni az egészet, mert nincs rá időm. Másodszor pedig szerettem volna megszabadulni a kommunikációs overhead-tól, pl xml parsing.
Végülis az, hogy nincs agent, azt nevezhetjük félrevezető marketing-baromságnak, mert valamilyen szoftvernek futnia kell, amivel kommunikálunk. Ennyi lett: OpenSSH, az OpenBSD klasszikus SSH szervere, ami fut linuxon, windowson (cygwin), mindenféle BSD-n és solarison, ráadásul többnyire része egy szerver alaptelepítésnek.
Az absztrakciós réteg... egy része ott van a kontrollerben, mert annak tudnia kell, hogy milyen operációs rendszerhez beszél, az absztrakciók nagy része viszont elment. Eleinte csináltam abstrakciót a hypervisor-elé, de később találtam jobb megoldást és mostanában lassan eltávolítom ezeket a kerub-ból.
Ez most hosszú lett, mert vasárnap van, legyen legközelebb például az, hogy mit csinál a planner és miért nem kellenek az absztrakciók.
2016. november 9., szerda
kerub - az "expectation"
Az expectation (elvárás) az a dolog, ami a kerub nagy planner-egyenletének az egyik oldala. Elvárásokat határozhat meg az ember virtuális erőforrásokhoz (virtuális gép, virtuális merevlemez, hálózat) teljesítményükre, megbízhatóságukra, futási környezetükre vonatkozóan.
Pár ilyen elvárás:
Pár ilyen elvárás:
- Redundancia - egy merevlemezre megmondhatjuk hogy mennyi másolat kell hogy legyen belőle - esetleg egy vagy több hoston tarthatjuk-e a másolatokat.
- Kölcsönös kizárás (not-same-host) virtuális gépre és virtuális merevlemezekre lehet használni, például ha két tomcatunk között session replikációt játszunk, akkor igazán hülye dolog lenne a IaaS-tól ha ugyanazon a kiszolgálón hagyná futni őket. Ha a kiszolgáló elszáll, mindkettő tomcat bebukik. Hasonlóan pl scale-out adatbázisok (cassandra) merevlemezeinél.
- Host-tal kapcsolatos elvárások, pl ECC-memória, tápegységek száma, vagy akár a gyártó is (még van ember, aki hisz az IBM-ben pl, mindenki hülyének tartja de van pénze)
- Nyilván I/O teljesítmény, CPU teljesítmény és satöbbi elvárások
2016. november 7., hétfő
Műsorváltozás - kerub
Kicsit másként fogom használni ezt a blogot most egy ideig, mert nagyon kevés időm van rá, hogy ide írjak. Ez nem feltétlenül baj, mert nektek meg kevés időtök van rá, hogy elolvassátok, csak nem fogok rajta sokáig töprengeni, itt landol majd sokminden mint vasárnap hajnalban a diszkó elött a járdán.
Szóval mostanában ezen a kerub nevű dolgon dolgozok. A kerub egy IaaS prototípus. Arról, hogy IaaS alighanem mindenkinek az OpenStack jut eszébe. A legtöbb barátom OpenStack-en dolgozik vagy dolgozott, egy egész hadsereg lehet rajta. És mennyi ZS...
Nade kerub... Mi is lenne az alapötlet? Csak mert az egy jó kezdőlépés lenne ugye :)
A kerub-ot azért kezdtem el, mert ki akartam próbálni egy másmilyen megközelítést a virtuális gépek schedulerére. Bár a kernel scheduler abszolut tudományos dolog, sajnos a cloud rendszerek schedulerei enterprise agybajok.
A kerub schedulerétől elösször is azt akartam, hogy ne okozzon sok seggfájást, találja ki, hogyan tudja kielégiteni a felhasználók elvárásait.
Ja mert ez a tényleg fontos ötlet, a felhasználóknek elvárásaik vannak, mindig minden pillanatban azt nézi a kerub, hogy ezek az elvárások teljesülnek-e, illetve hogyan lehet kielégíteni őket. Nem kell servicenow ticketet nyitni, mint melóban, kerub tudja ha baj van és dolgozik is rajta.
Akkor legyen most gyorsan csak ennyi :)
Szóval mostanában ezen a kerub nevű dolgon dolgozok. A kerub egy IaaS prototípus. Arról, hogy IaaS alighanem mindenkinek az OpenStack jut eszébe. A legtöbb barátom OpenStack-en dolgozik vagy dolgozott, egy egész hadsereg lehet rajta. És mennyi ZS...
Nade kerub... Mi is lenne az alapötlet? Csak mert az egy jó kezdőlépés lenne ugye :)
A kerub-ot azért kezdtem el, mert ki akartam próbálni egy másmilyen megközelítést a virtuális gépek schedulerére. Bár a kernel scheduler abszolut tudományos dolog, sajnos a cloud rendszerek schedulerei enterprise agybajok.
A kerub schedulerétől elösször is azt akartam, hogy ne okozzon sok seggfájást, találja ki, hogyan tudja kielégiteni a felhasználók elvárásait.
Ja mert ez a tényleg fontos ötlet, a felhasználóknek elvárásaik vannak, mindig minden pillanatban azt nézi a kerub, hogy ezek az elvárások teljesülnek-e, illetve hogyan lehet kielégíteni őket. Nem kell servicenow ticketet nyitni, mint melóban, kerub tudja ha baj van és dolgozik is rajta.
Akkor legyen most gyorsan csak ennyi :)
2016. augusztus 22., hétfő
off: Az IT egy fekete lyuk
Ma sorba vettem, hogy mit csinálnak mostanában azok, akikkel huszonévesen térdig legyalogoltuk a lábunkat minden szombaton:
Kicsit olyan ez az ipar, mint London: szinte mindenki itt van. Vajon mit csinálnánk egy brexit esetén?
- Eszti N diplomával és X doktorival rendelkező bölcsész, úgy 6-7 éve IT supportos
- Dani posztdok biokémikus, most data scientist, Perl és Python mágus
- Szöcske fizikus phd, mostanában Java szoftverfejlesztő - érdekes választás
- Zalán szoftver-fejlesztő maradt
- Sanyi is maradt szoftver-fejlesztő
- Ákos rájött az egyetem végén, hogy valami gyanús és nem tudom pont most mit csinál, de nem szivatja magát absztrakciókkal
- Anikó szakirányú egyetemi előadások nélkül is rájött ugyanerre, ő pont most alszik...
- Nekem valami gyanús, de hát 11-12 éves korom óta szoftverfejlesztő akartam lenni. Mi legyek? Vadakat terelő juhász?:)
Kicsit olyan ez az ipar, mint London: szinte mindenki itt van. Vajon mit csinálnánk egy brexit esetén?
Feliratkozás:
Bejegyzések (Atom)