https://www.theregister.com/2024/01/10/broadcom_ends_vmware_partner_program/?td=rt-3a
Én nem vagyok érintet, de kiváncsi lennék ki mire menekül, már ha menekül?
- 3271 megtekintés
Hozzászólások
Egyrészt nem eszik olyan forrón a kását. Várjuk meg, hogy mit is akar a Broadcom ténylegesen. Láttunk már példát Vmware-nél is, hogy bejelentenek valami oltári nagy butaságot, aztán visszakoznak. Lehet, hogy csak 1-2 év múlva, de visszakoznak.
Másrészről fontos kérdés, hogy mihez van szakember. Hiába tér át a cég mondjuk Hyper-V-re, ha az átállás költségei + HR költségek túl magasak.
Továbbá 2024-t írunk.
- Egyrészt ott a cloud. Lehet migrálni vagy privát cloudot építeni - ha a lehetőségek adottak.
- Nutanix, mint hyper converged infrastructure.
- Multi vendor stratégia alkalmazása. Hybrid cloud, hybrid infrastructure, vendor independent.
- Áttérés konténerekre, ahol lehetséges és megéri. Docker, K8S, OpenShift. Akár bare metal alapokon. És akkor hoppá a Vmware-nek - igaz, nekik ott a Tanzu.
- A hozzászóláshoz be kell jelentkezni
Épp ezt akartam írni én is. Ez majd csak áprilistól lép életbe, addig lehet még visszakozás, tárgyalásások. Lehet nem eszik azt tényleg olyan forrón.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Persze, csak egy cégnél nem szeretik a bizonytalanságot, és ez azért egy rohadt nagy risk. A magam részéről egy ilyen bejelentés meglebegtetése után VMWare közelébe nem mennék.
- A hozzászóláshoz be kell jelentkezni
Az "egyszerű" partnerek kukázása február 1-én megtörténik, a Cloud Provider partnerek kaptak haladékot április 30-ig.
Illetve február 1-től már csak Subscription alapú vSphere licenc lesz, a Perpetual megszűnik.
Ha jól tudom, a magyar VMware teamet már szélnek is eresztették. A Broadcom direct support alá vonta a global top 5000 VMware ügyfelet. Ezek partnerei, akikkel eredetileg szerződtek pl. támogatásra, biztosan repesnek az örömtől.
- A hozzászóláshoz be kell jelentkezni
Docker, K8S, OpenShift.
A szőr is feláll a hátamon, főleg az utóbbi kettőtől...
- A hozzászóláshoz be kell jelentkezni
Pont K8S-OpenShift ilág felé gyalogolunk.
Kifejtenéd miért áll fel tőle a szőr a hátadon?
// Hocus Pocus, grab the focus
winSetFocus(...)
http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation
- A hozzászóláshoz be kell jelentkezni
Ezt mondják mindig mindenre, aztán hirtelen mind elfelejtődik. LXC-nél találkoztam ezzel először...
Pénzügyi szektorban dolgozom, nálunk az atomstabilitás és nem a rajság az első. Van nálunk pár devopsnak hívott rajkodó brigád, akik 2 éve kínlódnak már k8s-sel, most éppen RKE2-vel. Egyszerűen nekünk nem hoz semmi olyan pluszt, amiért érdemes lenne fél infrát kidobni, fél évet beleölni minimum, hogy alap-közép szinten megértsem, plusz még önkéntes bétateszter is legyek...
- A hozzászóláshoz be kell jelentkezni
Mi cégünk 5-6 éve tolja és már teljesen lecserélődött mindenki a kis kubernetes csapatkában volt amikor ezt megálmodták, ettől függetlenül a telepítést működik és mindenki inkább ezzel dolgozik mint a virtualizált vagy baremetal szarokkal.
Én a helyedben elkezdeném tanulni azt a kubernetes dolgot, soha nem lehet tudni mikor lesz rá szükség.
- A hozzászóláshoz be kell jelentkezni
Nem tudom mire használni, a meglévő dolgaimat 1:1 nem tudom átrakni, plusz erőforrás igénye hatalmas. Leírások, értelmes leírások alig vannak, plusz a nagy kuberneteseink is csak egyre jobban köpködik.
A legnagyobb versenytársunk a szektorban 3 éve dobta az egészet, rájöttek, hogy nem éri meg jelen állapotában nekik.
Én megvárom míg vagy kimászik ebből a béta státuszból vagy kimegy a divatból.
- A hozzászóláshoz be kell jelentkezni
Csak nem az Amazon Prime Videoval versenyzel? :)
- A hozzászóláshoz be kell jelentkezni
Nope, pénzügyi szektorban kicsit másképpen megy. :)
- A hozzászóláshoz be kell jelentkezni
Ha nincs olyan megkötés hogy kell konfiguráció management meg CVE report akkor perszehogy fölösleges.
- A hozzászóláshoz be kell jelentkezni
Van rá más eszköz. Kettő is.
- A hozzászóláshoz be kell jelentkezni
Ki ne találjuk már, hogy konfig management meg cve kezelést nem lehet k8s nélkül csinálni....
- A hozzászóláshoz be kell jelentkezni
Nem értem hogy jött ide a k8s amikor eleve Satellite volt az ami le lett cserélve náluk.
Az érdekelt ott mi a helyzet, azt tudom hogy annyi megoldás van mint égen a csillag.
- A hozzászóláshoz be kell jelentkezni
Hát, én a szálban található kommenteket úgy értelmeztem, hogy:
- a [te] k8s jó
- [Kronosz] nekem úgy tűnik, számomra nem hasznos
- [te] hát, ha nem kell config mgmt meg cve report, akkor persze hogy nem kell
Nekem ebből úgy tűnik, hogy szerinted a k8s ezekhez kell. Lehet, hogy nem ezt akartad mondani :)
- A hozzászóláshoz be kell jelentkezni
Megpróbálom kifejteni.
Kérdésem a Satellite-ről szólt, mivel azt kapta Kronosz munkahelye minden szirszarral. Érdekelt miután kidobták, mi lett helyette.
Általában véve minden technológiai megoldásnak megvan a helye: virtuális gép, ennek configja bash vagy ansible, chef, puppet, vagy app mozgatása konténerbe. Azt hogy konténerezni miért jó nem kell kifejtenem.
Banki környezetben kifejezetten érdekes lehet a k8s, lévén hogy egyszerű auditálni és az infrastruktúra méretéből. Úgy vélem megéri a komplexitása miatt belefektetett idő és energia. Tudok pár bankról és biztosítóról ahol alkalmazzák.
Ettől függetlenül nem használható mindenhol.
Láttam olyan projektet ahol EC2 telepítő és konfig bash-ban volt megoldva és a kolléga nem volt hajlandó ezen változtatni, addig jó is volt, amig egészségügyi okokból át nem kellett vegye valaki más a feladatot és a bugokat és fejlesztéseket beletolni a több tízezer soros bash scriptbe. Ment a levesbe az egész miután hárman egymás után felmondtak miután megörökölték a projektet, csak az a kár hogy ennek be kellett következnie. A telepítés méretéről annyit, hogy EU régióban jelentős EC2 számot foglalunk le és vicces, de a spot instance árát tudjuk befolyásolni a gépeink számával.
Dolgozom AWS szolgáltatásokkal is, minden serverless és nincs konténerekkel bíbelődés. Van más probléma, kezdve azzal hogy ha mindenki más rajtad kívül utálja a felhőt mert az rossz. Sorolhatnám, nem lényeges.
Amikor azt írtam a k8s-t nem hagynám figyelmen kívül mert hasznos lehet, arra gondoltam hogy nem is feltétlenül a mostani, de talán a következő munkahelyeden ez lehet az irányvonal van. Nem limitálom/limitálhatom az alkalmazhatóságomat.
Igyekszem nyitott lenni és olyan irányba haladni ahol az üzemeltetéssel nagyon keveset kell foglalkozni. A megoldás lehet bármi ami naprakész és olyan technológiai amire van kereslet a munkaerőpiacon, lehetőleg jól megfizetve.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy sok mindent nem árulhatok, hogy mi hogy és miért úgy néz ki nálunk, amiért. De megpróbálom úgy leírni, hogy valamennyire érthető is legyen és ne sértsem a munkahelyem érdekeit.
Tehát, mi a pénzügyi szektor nem banki részénél vagyunk. Olyan adatokkal is kell dolgoznunk, amit örökidőkvégezetéig' IS meg kell tartanunk. Amikor idő jön hozzánk valaki, akkor az első pár hónapban természettől függően hogyismondjam' csodálkozik, hogy miért van nálunk 2x vlan meg 1x DMZ-s vlan, miért kell mindenre tűzfalszabályt igényelni és miért nem valami kommersz vagy elterjedt vállalatirányítási sw-t használnak. De ahogy megérti a miérteket, már amennyiben hajlandó, akkor rájön arra, hogy ez a legjobb megoldás és döntő többsége felügyelet általi követelmény vagy éppen egy fejlődési út van előtte, ami nehezen vagy sehogy sem váltható ki. Éppen most nehezítették meg btw az Ansible használatát is, de mivel én szokás szerint megint két tűz közé kerültem, elég hamar rájöttem a megoldásra, csak a fentebb említett agyonbonyolítások miatt segítség nélkül nem tudom implemetálni a dolgot...
Tehát adott egy barna mezős környezet, ahol különböző alkalmazások vannak, melyeknek van kötöttsége, melyeket mindig figyelembe kell vennünk, de a legnagyobb kötöttség maga az üzlet.
Miután a Satellite-ot kidobtuk, a központi managelést Ansible-lel oldjuk meg, illetve dsh-val CWS-ről. Mindenről change, igény, etc. kell, plusz minden tevékenység logolva van.
Security szempontból már a Satellite megjelenésekor voltak jó drága és egyébként jól is működő management eszközök, melyeket nem írnék le inkább, maradjunk csak annyiban, hogy folyamatosan legalább két eszközzel vannak szkennelve a win és linux, de még a maradék pár AIX gépek is. Most már kezdünk egészen jól kinézni, de feladat mindig van, mint pl. most Centos7 -> Oracle Linux8 átállás. Amint elkészül egy gép, már integrálom Ansible alá, de előbb a role gyűjteményeket ki kell gyomlálnom, mert annyi felesleges szeméttel van tele, hogy a rívás kerülget, mikor meglátom. Szerencsére van saját célra készített role gyűjteményem, majd a kettőt összefésülöm, mert azért a bonyolítások között azért akadnak olyan dolgok, amik még hasznosak is lehetnek.
Tehát a Satellite kidobása a teljesen felesleges túlbonyolítása mellett azért is kellett, mert hivatalosan Oracle Linux-ot nem lehet vele managelni. Még mindig tudom, rá lehet gányolni a subscription-manager-t, tudja OL repókat is szinkronizálni, de mivel gányolni kell és nem supportált a dolog, ezért inkább dobtuk, mert ha bajt okoz, akkor nagyot és nem lesz akkor kedvünk/időnk/idegrendszerünk ott keresgélni.
És akkor a k8s-ről. Úgy szoktam csinálni eddig, hogy itthon nekem van egy mini munkahelyi környezetem. Nem, nem teljes koppintás, tehát nem vettem (még) ide több tízmilliós cuccokat, hanem az engem érintő dolgok vannak meg arányosan kicsinyítve. Tehát nem vmware-em van, hanem proxmoxom (itt gondolkodok cserén, de még nem vitt rá a lélek), nem 350 linuxom van és 250 Windows-om, hanem ~40-50 linuxom és 3 Windows-om. Nem két site-os működésem van, hanem egy szerverszobám, stb. Céges adatok nincsenek, nem is kellenek, hanem minden alap infra szolgáltatásnak meg van a megfelelője kicsiben (8db win2019 AD -> 1db win2016 AD, Exchange2019 -> Zimbra, NFS fájszerver -> Samba4, IBM 7200 storage -> D-Link NAS, stb.)
Ez arra jó, hogyha valamelyik helyi rajcsávó kitalálja, hogy most aztán be kell hozzánk vezetni az XYZ-t, mert azzal aztán megváltjuk a világot, akkor én itt kicsiben kitudom próbálni, amennyiben nekem a napi munkámat érinti. Ez volt a Satellite-tal is, de a dockert, még annak idején a tomcat-et is így próbálgattam. Hogy miért csinálom, annak sok oka van, a legfőbb ok a tűzfalazás meg a többi bürokrácia (de pl. bent céges környezetben nincs direkt elérése egyik virtuális gépnek sem a proxykat leszámítva), itt nincs 600 vlan, sokkal gyorsabban nekitudok állni a tesztelésnek.
Így lett k8s-em is, pontosabban RKE2-m, mert azzal megy itt a kínlódás a szomszédban. Csak nem 16 gépes környezet, hanem 6. Van mindig egy nagyon alap beugró szintű feladatom minden ilyen csuda szoftvernek, amit prodban senki nem használ, de amennyiben ha én összetudom rakni lehetőleg gányolás nélkül, akkor érdemes vele foglalkoznom. Amennyiben bukik a dolog 4-6 havonta újra megpróbálom és amikor egyszer jó lesz, tehát a valós béta állapotból kijön, akkor foglalkozok vele komolyabban. Dockernél és k8s-nél egy sima mysql-wordpress páros az ilyen próbafeladat. Ezen szegényem már 3x elhasalt, míg dockernél ez azért másodjára összejött. Mysql már a podokat se akarta felhozni, még az ősszel próbálkoztam vele, így a pontos hibaüzenetre nem emlékszem, hogy mi baja volt, de lassan újra megpróbálom, hátha már sikerült egyszerűsíteni.
Satellite-nál és előtte Foreman-nál pedig egy 4-5 gépes lamp szerver környezetnek a minden szintű managelése volt. Foreman 3 frissítési kanyar után egyszerűen mindenféle puppet hibákat dobott, már nem emlékszem rá, mi volt, jó sokáig kellett rúgdalnom, mire elindult újra, Satellite-tal ilyen gond nem volt, csak az volt a bajom, hogy annak a Satellite teszt környezetnek (1 Satellite, 1 Capsule, 3-4 kliens) akkora volt az erőforrás igénye, hogy tényleg értelmes sebességgel menjen minden, mint az összes többi gépemnek, beleértve a Windows Servert is. De hát igazából erőforrás volt a cégnél, nekem meg itthonra nem kellett, de legalább megtanultam az alap kezelését, volt, hogy össze is döntöttem, mégsem az élest nyírtam ki)
Mindent így tanultam meg, kivéve AIX-ot, mert azt nehéz lett volna. Kollégáim is tudják csapaton belül, hogyha van valami új, akkor én napokig küzdök vele, legyen az bármi, elmondják, hogy mi az és mire kell majd nekünk, akkor találok egy tök egyszerű próbafeladatot, amit ha nem vesz be különösebb problémák nélkül, akkor megfelelő bizonyítási procedúra után eldobatjuk (pihentetjük). Volt olyan is, amit elsőre betudtunk hozni, számtalan ilyen volt az Aide-től a Gitlabig, azok rendesen mennek is. Viszont a divattermékeket megfelelő tesztelésnek vetjük alá, mielőtt belemennénk az erdőbe.
Tudom hülye módszer, mindig megkapom, de mivel mindenki hülyének néz és biztos az is vagyok, de nekem ez vált be. Segítséget pedig vagy 10 éve szinte csak alig kapok, ilyen nagy kivétel volt tavaly az Ansible vagy Előtte Satellite oktatás.
- A hozzászóláshoz be kell jelentkezni
Biztosan igazad van (nem írtál olyat, amivel nagy vonalakban nem értenék egyet, max olyat, miről nagyon csak tippelgetni tudnék), de egyre jobban össze vagyok zavarodva. :) Még csak kérdésed sincs ebben a szálban, csak kijelentéseid :)
Mindegy, nem érdekes :)
- A hozzászóláshoz be kell jelentkezni
Az egy teljesen másik layer, nem 1:1 csere. Proxmox VE például 1:1 csere.
- A hozzászóláshoz be kell jelentkezni
Igen, az. És mint fentebb írtam semmilyen pluszt nem ad nekem, csak nyűgöt.
Ilyen volt 2 éve a Satellite, tavaly meg Ansible...
Satellite bevezetésekor már mondtam, hogy nekünk nem kell semmire, ágyúval verébre, az általam kitalált és azóta is használt reposync + 2-3 shell script kényelmesen és milliószor hatékonyabban működik, mint ez az erőforrászabáló szar. Erre idejött nekem egy rajKft, megcsinálták a Satellite infrát csilliárdokért, vlan-onként egy-egy Capsule szerverrel, amitől azt hittem, hogy a hajam kihullik, CV hegyekkel totálisan átláthatatlanul. Drága kollégáim meg mikor jött az átvétel sikítva menekültek és én, a vidéki marha maradtam ott egyedül, hogy megtanuljam. Kaptam licenszt, hogy itthonra a saját infrámon feltelepítsek nulláról egy 3-4 gépes Satellite környezetet, kaptam egy egy hetes (amúgy nagyon hatékony és jó) oktatást és felépítettem kicsiben és használhatóban azt, amire a cég csilliárdokat kifizetett. Majd mivel én voltam az egyetlen, aki tudta azt a hulladékot használni, de párhuzamosan a saját reposzervereim is megmaradtak, így könnyű dolgom volt, hogy prezentáljam a vezetőségnek, hogy mi is a valóság. Tavaly ősszel decomoltam az egészet, bevallom nyitottam egy pezsgőt utána. 2 nap alatt leköltöztem a gépről jó öreg dsh-nak köszönhetően. Le sem merem írni mennyi erőforrást szabadítottam fel.
Aztán jött a másik kedvencem az Ansible. Ágyúval verébre van ezzel is nálunk, amit Ansible-el csinálnak én másképpen ~4x gyorsabban (lemértem) és milliószor hatékonyabban megcsinálom. Géptelepítés az egyik ilyen veréb, amit annyira sikerült megbonyolítani, hogy összesen ketten vagyunk kb. a cégnél, aki tudja használni, a kitalálója meg én... (na jó, meg még egy maréknyi ember, de én vagyok az egyetlen, aki a vmware modultól mondjuk az aide config update-ig mindent tudni akar.)
Mivel holt hülye voltam Ansible-hez, de tudtam, hogy egy agyonbonyolított szar, ezért 6-8 hónapig tartott nekem megtanulni. Én is megírtam teljesen nulláról géptelepítést, csak mivel nekem itthon nem vmware infrám van, hanem Proxmox, így arra csináltam meg. (Direkt úgy csináltam meg, hogy a Proxmox modul jól elkülönüljön, hogyha egyszer felbírom fogni a vmware modul működését, akkor azzal is működjön minden más.) Körülbelül az eredeti agyonbonyolított kódhalmaznak a 30%-ból sikerült úgy összehoznom a role-okat, hogy egy role gyűjteménnyel képes vagyok gépet nulláról (templateből) feltelepíteni, konfigurálni, frissíteni és még a template-eket is tudom frissíteni. Ezzel párhuzamosan ugyanezeket a feladatokat megírtam shell scriptben is hasonló elvek alapján, mint Ansible-nél (változókkal, templatekkel, gép profilokkal) és még mindig gyorsabb, átláthatóbb és stabilabb, mint az Ansible. Mikor pedig megakadtam a tanulásban, főleg az elején, akkor mindig pont annyi segítséget kaptam, hogy tovább tudjak haladni. Ebben korrektek voltak mindig is a kollégák. A Proxmox modult azóta is annyira szeretem, hogy Taigetoszról lökném le a fejlesztőjét... A cégnél pedig amíg lehet az általam megírt scriptből telepítem a gépeket, mivel az alap gépek tök egységesek, nevet és hálózatot leszámítva, így egy-egy géptelepítés 2,5-4 percig tart. Ansible-el ez 15-20 perc... Ugyanez nálam itthon 12-15 perc, milliószor gyengébb hardveren. Az is tény, hogy itthon Ansible-el telepítek gépeket, mert nem akarom elfelejteni a nagy nehezen felszedett tudást, illetve mindig találok valami feladatot, amit esetleg később használhatok, ha divatban marad még.*
*3 hónapja kitaláltam, hogy mivel a cégnél 3 havonta fixen frissítünk minden Ádámtól Béláig, így mi lenne, ha Ansible-el csinálnám itthon. Mivel agyonbonyolítás nincs nálam, így gyorsan sikerült egy olyan plusz role-t írni, amivel szabályosan egy playbook futtatásával végig megy a frissítendő környezeten (test, preprod, prod) és szabályosan AD-t leszámítva mindent lefrissít és újraindít. Tényleg nagyon kényelmes volt az, hogy legutóbb mikor volt update, akkor amíg a Lidl-ben bevásároltam, itthon minden lefrissült és hazaérve csak ellenőriznem kellett CSW-ről, hogy mindegyik gép azonos szinten van-e. De ezt megtudom csinálni shell scriptből is hasonló módszerrel, fele annyi időben és huszadannyi erőforrásból. Ez lesz az idei egyik első IT projekt :)
- A hozzászóláshoz be kell jelentkezni
egyreszt reg hallottam ennyi picsogast. masreszt a satelliteot nem vedem, sikerult elkerulnom mindig, de az ansiblet szerintem vagy teljesen felreerted, vagy csak NIH szindromaban szenvedsz.
De ezt megtudom csinálni shell scriptből is hasonló módszerrel, fele annyi időben és huszadannyi erőforrásból. Ez lesz az idei egyik első IT projekt :)
nem, nem tudod. amint jon a valtozas, irhatod at a cuccaidat. es most nem arrol beszelek hogy 1x le kell futtatni, hanem ha mondjuk orankent le akarom futtatni idempotensen a beallitasokat, akkor azt lescriptelni eleg szopoag. mondom, foleg ha valtoza van.
az ansible eroforrasigenye meg aztan lofasz sem.
- A hozzászóláshoz be kell jelentkezni
Lol, látom magadra ismertél akkor. Nem csak elkényelmesedett vagy ezek szerint. :)
Nem ismertem félre én legalábbis, hanem a drága kollégáim, akik után kellene dolgozni. Próbálta más is megértetni vele, hogy nem a világ körforgását kell lemodellezni, de nem vették a lapot.
Pont hogy Ansible-nél volt az, hogy jött egy változás, aztán lehet újra írni az egészet. Volt erre is legalább 2 eset, erről én tudok. Az én scriptjeim úgy vannak megcsinálva, hogy ne kelljen mindent újra megcsinálni, ha változás van, akkor könnyen megtalálható legyen, hisz ez az én érdekem főleg.
Delphiben jártam úgy, hogy teljes újrakártya, mikor a BDE-t kivezették, na az volt az igazi szopóág.
- A hozzászóláshoz be kell jelentkezni
Nekem van egy több, mint 5 éves projektem Ansible-ben, nagyon nem kell újraírogatni. Bár mostanában szaporodnak a deprecated dolgok, de mindig bízom benne, hogy nem szednek ki belőle dolgokat just for fun.
- A hozzászóláshoz be kell jelentkezni
Pedig készülhetsz rá.. Ez a másik bajom, a sok deprecated szarság. Leginkább azért kell mindent újraírni.
- A hozzászóláshoz be kell jelentkezni
Sokszor az új szintaxis nem tudja azt, amit a régi, így kénytelenek meghagyni.
Pl. loop:
-
We added
loopin Ansible 2.5. It is not yet a full replacement forwith_<lookup>, but we recommend it for most use cases. -
We have not deprecated the use of
with_<lookup>- that syntax will still be valid for the foreseeable future.
Egyébként ez nem csak Ansible probléma, hogy a fejlesztők saját szórakoztatásukra olyan dolgokat változatnak, ami a termékhez semmit nem ad hozzá, viszont kibaszik azokkal, akik már valamit csináltak belőle. Ha C-ben megírsz valamit, az 20 év múlva is használható (ha csak a libek nem kopnak ki alóla teljesen), ha meg valami új felkapott dologban csinálsz valamit, már fél év múlva "legacy" meg "deprecated" dolgokkal kell szembesülnöd.
- A hozzászóláshoz be kell jelentkezni
Az alap probléma ismerős (és borzasztó) hogy tulajdonképpen egyre többet és többet kell azzal foglalkozni hogy "életben tartsunk" egyszer működőre megírt dolgokat. Én nemrégen kezdtem el (nagyjából 6 év után megint) az ansible-t. Most semaphore-al és a hozzá tartozó git-es flow-val.
Egyelőre tetszik de persze nem tudom hogy mondjuk egy év múlva (az akkori ansible-el és modulokkal) minden ugyanúgy fog-e menni mint most.
A kubernetes világban is ezt látom, folyamatosan kell mindent basztatni hogy benne maradjunk a "supported radius"-ban.
- A hozzászóláshoz be kell jelentkezni
en nem vagyok elkenyelmesedve, sajnos :), pedig jo lenne. nem is lenne mibe belekenyelmesedni, naponta olyan dolgokat csinalok, amiket vagy meg senki, vagy annyira uj techet hasznalok, hogy szinte 0 vele a tapasztalat, tehat elegge felrement. ettol fuggetlenul a picsogast, na, azt nem birom.
tuzzel-vassal nem szeretem a k8st, de fejlesztoi szempontbol olyan mint egy falat kenyer, lehet elni nelkule, csak nem erdemes :) az uzemeltetes mas kerdest, de nehogymar forditva uljunk a lovon kerem, nem az uzemeltetesert van a ceg, hanem forditva, ugye.
az ansible valtozasai sok releaseig olyanok hogy szolnak h deprecated lesz, aztan 1x az lesz (honapok, evek utan). nem gondolom hogy ez meglepetes lenne barkinek.
- A hozzászóláshoz be kell jelentkezni
Hát ti rajcsávók ültök fordítva a lovon, mert nagyon raj fejlesztők vagytok, de az üzemeltetéshez meg marhára nem értetek, ami szerintem nagy szégyen.
További jó picsogást. :)
- A hozzászóláshoz be kell jelentkezni
igen, csak ez lehet, miutan 24/7-es global cuccot uzemeltettem az elmult 7 evben :D
ha ilyen jo arannyal lottozol, akkor azt ajanlom, ne vegyel lottot ;)
- A hozzászóláshoz be kell jelentkezni
Egy cégnél dolgoztunk, csak szólok. Az arcod akkor is volt, hogy a Sametime is alig bírta el. ;)
- A hozzászóláshoz be kell jelentkezni
meg vagy negyedmillio emberrel egy cegnel dolgozunk, akkor mind a negyedmillio ugyanazt csinalja? :D ne rohogtess
az szerintem nem arc kerdese, hogy az ansible vagy a bash script a fenntarthatobb ut uzleti szempontbol, a trivialis mokakat leszamitva (es latod, megelolegeztem, hogy nem trivialis dolgokat csinaltok, mert jofej vagyok!). a capsulerol nem mondok velemenyt, fent is irtam ;)
- A hozzászóláshoz be kell jelentkezni
Pfu b+, látom neked is bejött a squadosítás :DDDDDDD
Capsule. :DDDDDDD
- A hozzászóláshoz be kell jelentkezni
Na de uraim (vagy ahogy ma jol esik)!
Ahelyett, hogy itt jol legyilkoljatok egymast, irhatnatok egy konyvet is a temaban. Az ICT ipar egyik rakfenejebe sikerult beletenyerelni. Sokaknak nem vilagos ez az ellentet.
Persze ott a devops eredeti otlete. Es mennyire jobb lett tole a vilag :)
- A hozzászóláshoz be kell jelentkezni
lehet a devopst is jol csinalni, csak altalaban vagy uzemeltetesbol, vagy fejlesztesbol alulkepzettek a delikvensek :)
a konyvek hatranya meg hogy X ido utan elevul a tartalom bben az iparban (anno Marco Cantu: Mastering Delphi 5 konyvebol tanultam, 99-es, lasd, mennyire relevans ma:D)
- A hozzászóláshoz be kell jelentkezni
Na, ebben látod egyetértünk.
- A hozzászóláshoz be kell jelentkezni
Mert nem a kontenerekrol kell irni. Az a loteri kutyat nem erdekli majd par ev mulva. Illetve talan az uzemeltetes fog sirni, hogy miert ter at a devel kontenerrol egy ujabb agyremre.
Az alap tema a fejlesztes es uzemeltetes szembenallasa, technologiak adptaciojanak idobeli eltolodasa stb.
- A hozzászóláshoz be kell jelentkezni
A phoenix project-nél jobb művet még nem olvastam a témában.
- A hozzászóláshoz be kell jelentkezni
Sok mindenben igazad van, egyet is értek veled. Én is csináltam automatizációt bash scriptekkel, amikor az Ansible épphogy gyerekcipőben járt csak.
Viszont nézd üzleti oldalról, a cég oldaláról: Te kiesel a munkából. Elmész a cégtől, netalán elhalálozol. Ha a scripteket csak te érted, te tudsz vele dolgozni, akkor az egy óriási risk a cégnek. A cégnek olyan IT megoldásokra van szükségük, hogy ha kell, akkor az utcáról felvett emberke is hozzá tudjon szagolni viszonylag gyorsan.
Egy Ansible-re, Satellite-ra bármikor talál a cég embert (ha megfizeti). De custom scriptekkel és a benne lévő aknákkal senki se akar foglalkozni. Meg egy cégnek mindig szüksége van supportra. Ez tisztán a felelősség áthárítása ("Várunk a supportra, dolgoznak a problémán").
A másik, hogy ha egy feladatot csak 1-2 ember tud elvégezni a cégnél, akkor a cég kockázatkereső üzemmódban működik. Mit jelent ez? Szabályosan keresik azt a pillanatot, amikor bedől az egész kártyavár. Persze lehet így is élni, üzletet vinni....
- A hozzászóláshoz be kell jelentkezni
a fejlesztok mindig azt hiszik hogy az o kodjuk hibatlan, es jobb cuccot tudnak irni mint masik X fizetett mernok/fejleszto. istenem, hany php "engine"-t lattam, ami mind ugyanazt tudta, de a gazdaja ragaszkodott hozza! :-/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Ez mindig így lesz... Az én kódjaimnál inkább az átláthatóságra próbálok rámenni, hisz mindig én vagyok a leghülyébb mindenhol, így egyszerűbben kilehet dobni, amit csináltam.
- A hozzászóláshoz be kell jelentkezni
Úgy van minden megírva, hogy átlátható és egyszerű legyen, hisz 15 éve ezt verik bele a fejembe.
Soha nem talált a cég embert sem Satellite-ra, sem Ansible-re. Csak olyat, aki mikor ideérkezett és egyből mindent újra akart csinálni mert természetesen amit az elődje kitalált az szar. Aztán mikor belekezdett, rájött mindenre, hogy az előd mit miért csinált úgy ahogy, aztán a vége az lett, hogy ugyanazt írta meg, csak bonyolultabban. A probléma tehát nem maga a technológia elsősorban, hanem a bonyolítás. A meglévő lehetőségek sincsenek kihasználva rendesen.
- A hozzászóláshoz be kell jelentkezni
Ez a trend sajnos általánosan megfigyelhető IT-ban: "Amit az előző kolléga csinált, az minden szar! Írjuk újra az egészet nulláról! Ez tuti jó lesz!"
Aki egyből fikázza az elődöket, ő elég gyorsan leírja magát nálam.
Örülnék neki személyesen is, ha a kedves kollégák leszoknának az elődök munkájának a fikázásáról. A dolgok általában okkal történnek. Először meg kell érteni a folyamatokat, a miérteket, utána lehet javaslatot tenni a reformokra. Szerintem.
Ha esetleg valaki elmagyarázná, hogy miért jó lehúzni a másik munkáját, annak örülnék. Főleg pszichológiai oldalról.
A meglévő lehetőségek sincsenek kihasználva rendesen.
+1. Megveszik drágán a hw-t, sw-t, de csak a funkciók 20-30 %-t használják. Ez igaz KKV-től multiig sok helyre, sajnos.
- A hozzászóláshoz be kell jelentkezni
ez reszben igaz is. de sokszor nem szar (inkabb hibas a megfelelo szo) az elozo kollega munkaja, hanem elavult: az akkori technikaval/designel, az akkori verziokkal csinalta meg a cuccot. azota meg a vilag haladt tovabb, fejlodtek a programok.
Nalunk ilyen volt a puppet: a v2-v3 korul kezdtuk egesz sok mindent beleautomatizaltunk. aztan jott a frissites az 5-osre, ott teljesen mas elvek szerint kellett hasznalni, ujra is irtuk az "egeszet" (nyilvan sok mindent felhasznaltuk a regibol). mert mar tudta azokat a dolgokat, amit a v2-ben meg korbe kellett takolni. igy tulkepp mondtam hogy a friss puppetben a regi v2-es "kod" az szar!
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Örülök, hogy nem csak én látom ezt így.
Nálunk párszor előfordult, hogy tényleg szar volt, amit az elődöm csinált, de ő mondta is, hogy tud róla. És nagyon jól esett neki mikor megmutattam, hogy szerintem mit kellene még beletenni, mindenféle köpködés nélkül. Az elvvel nem volt gond, csak rendbe kellett rázni a scriptet. Volt olyan is, amit inkább újraírtam, volt amit meg inkább én írtam meg, mert voltak olyan kollégák, akik egy step-by-step howtot sem tudtak követni hibázás nélkül. Aztán a harmadik eset után inkább azt mondtam, hogy jó, majd megcsinálom én, csak gitből le kell szedni és megfelelő paraméterekkel le kell futtatni és az tuti jó lesz.
- A hozzászóláshoz be kell jelentkezni
a NIH az egesz iparban altalanos, de a mozgatorugojaval sokszor egyetert az ember: annyira fos munkat adott ki az elozo ember/csapat, hogy vagy nem nyulsz hozza (ha ez elfogadhato - nekem van olyan LDAP scriptem amihez nem nyultunk 8 eve, mert mukodik, de mar reg nincs itt nem hogy aki irta, hanem az se, akinek az megmutatta, hogy mukodik, ujrairni pedig minek?), vagy ujra kell irni.
- A hozzászóláshoz be kell jelentkezni
> A cégnek olyan IT megoldásokra van szükségük, hogy ha kell, akkor az utcáról felvett emberke is hozzá tudjon szagolni viszonylag gyorsan.
Egyébként pont ellenkező irányba mennek. 3rd party, beszállítós custom cuccok toldozása, a többségnél csak corporate bullshit hogy standardek legyenek. Már az operátor világban sem működik, hogy két hét alatt betanítható majmot óhajtunk olcsóért.
> De custom scriptekkel és a benne lévő aknákkal senki se akar foglalkozni.
Sokszor egy playbook se jobb. Sajnos.
> A másik, hogy ha egy feladatot csak 1-2 ember tud elvégezni a cégnél, akkor a cég kockázatkereső üzemmódban működik.
Egyetértek, a rocksztárok kockázatot jelentenek. Mégis őket imádják.
echo crash > /dev/kmem
- A hozzászóláshoz be kell jelentkezni
Sokszor egy playbook se jobb. Sajnos.
+1.
Egyetértek, a rocksztárok kockázatot jelentenek. Mégis őket imádják.
+1.
Már az operátor világban sem működik, hogy két hét alatt betanítható majmot óhajtunk olcsóért.
Ettől még sok cég így gondolkodott / gondolkodik. Aztán jön a rácsodálkozás, hogy 2 fürt banánért nem találnak majmot.
3rd party, beszállítós custom cuccok toldozása, a többségnél csak corporate bullshit hogy standardek legyenek.
Amikor kedves kolléga heti X órát cseszett el a levelezőrendszer tutujgatásával, ami nem a cég core businesse, közvetlen profitot se termel, akkor mit mondjak? Hiába mondták / mondtuk a kedves kollégának, hogy át kéne térni Exchangere / MS365-re (amire amúgy is volt licencünk), ő ragaszkodott a saját homokozójához. Ha lett volna egy tökös CFO a cégnél (nem volt), akkor elég gyorsan lemehetett volna az átállás.
Ja, hogy esetleg kiderült volna, hogy ez a kedves kolléga csak ehhez ért.... Ciki.
El kell dönteni, hogy mi a fontos. Ami több profitot hoz, abba kell beletenni több energiát. Sajnos ehhez még Magyarországon sok cég nem elég érett.
- A hozzászóláshoz be kell jelentkezni
A vége úgyis mindig az, hogy mennyi az annyi, ha a nagy kockázat és egy esetleges komoly probléma kevesebbet visz el összességében, mint a kis kockázat, akkor simán rámennek az elsőre.
- A hozzászóláshoz be kell jelentkezni
Satellite szerverekkel volt dolgom. Cégnél ahol használtuk a gépszám és a mindenféle audit-kompatibilitás és infra komplexitás miatt indokolta a nagyon komoly beruházást. Rendesen össze is lett pattintva, két belső mérnökünk csinálta.
Annak idején úgy használtok a gépeinket mintha konténerek lennének, legyalultuk az OS-t és ment a következő patchelt verzió Cobblerrel. Később amikor jött a Docker népszerűsége meg a Kubernetes, nem volt nagy fejtörés látni miért is jobb váltani.
Amikor Ansible-t kellett használnom, szerettem. Tény, mostanában kezd elk*rvulni a projekt és már nem olyan a minőség, az auto-generált dokumentáció kivette a projekt lelkét és már nem biztos hogy működik ami oda le van írva (gondolom python docstringből kerül automatikusan a doksiba).
Az LXC modul kifejezetten szar állapotban volt 3-4 hónapja.
Ettől függetlenül cégben használjuk, csináltam komolyabb meg kevésbé komoly feladatokat vele. Most megint lesz egy kisebb feladat amit majd rábízok.
- A hozzászóláshoz be kell jelentkezni
Nálunk van egy CWS által vezérelt környezet, 95 %-ban Oracle Linux. Redhat+Oracle miatt találták ki, de mocskos mód szétszedték. A legfőbb baj az volt, hogy idejött egy cég, hogy megcsinálja nekünk, mi semmit nem értettünk hozzá, a cég meg pélóméregetédnek használta. Látod, ez még ezt is tudja! Aztán mégsem tudta... Pénzügyi szektor, nem fejlesztői. Itt az NMB megkövetel olyat is, ami miatt sok csiribiri nem működik. Meg igazából nem is volt rá szükségünk. Jah és OL8-at nem képes a Satellite kezelni (tudom tud, csak hekkelni kell, de mi nem akarunk hekkelni), így mehetett isten hírével.
Ansible használata majdnem ilyen, mint a Satellite volt. Csak itt belsős kolléga adja az irányt, aki marha intelligens tényleg, de emiatt hajlamos a túlbonyolításra. Erre nem akarok példát írni, de a lényeg, hogy mikor bele kell nyúlni valamelyik role-ba, saját magának is annyit kell gondolkodnia, hogy mi hol van, mint nekem, aki akkor látta először. Van egy beszállítónk, akinek szintén van egy adatbázis hakkoló role gyűjteménye, de az meg annyira szar, hogy azt meg azért kell újraírni nulláról.. Nagy az elkurvulás, semmit nem nyertünk...
- A hozzászóláshoz be kell jelentkezni
Akkor neked csak 1 Ansible task kellene:
- command: /usr/local/bin/regi_script
így az Ansible átállás pipa, eddig fejlesztés megmarad :D
- A hozzászóláshoz be kell jelentkezni
Ne is mondd. Ez volt az első gondolatom nekem is, de aztán eszembe jutott egy 15 éves terrorcselekményem Ubuntuval, hogy wine-on keresztl futtattam Winamp-ot. Olyan érzés volt a mesteremnek, mint amikor egy olasznak ketchuppal leöntöd a pizzáját. :D
Szóval inkább úgy tartom elegánsnak, ha megcsinálom inkább Ansible-lel. :D
- A hozzászóláshoz be kell jelentkezni
" mint amikor egy olasznak ketchuppal leöntöd a pizzáját" - de előtte megszórod ananásszal :-D
- A hozzászóláshoz be kell jelentkezni
Pont most olvastam a témában egy cikket: https://www.server-parts.eu/post/vmware_new_licensing_model
Persze ilyenkor az összes alternatív szolgáltató próbál hasznot húzni a szituációból.
Jakab Zoltán
- A hozzászóláshoz be kell jelentkezni
Minden termék, minden cég életében eljön az időpont amikor elfogy belőle a szufla. Megáll az innováció, megáll a növekedés, a cég átlép a "cash cow" életszakaszba. A tulajdonosok (és a menedzsment) kiszedi belőle az összes pénzt amit lehet aztán vagy eladják vagy kuka a legvégén.
Láttunk már jópár ilyet, a kevésbé amatőr partnerek már rég képben vannak alternatívákkal és húzzák át az ügyfeleiket amoda.
És nyilván van egy csomó kutyaütő (indiai) partner aki csak lehúzta a vmware-t is (mind szakmailag mind pénzzel) na ezek mind mennek a levesbe, nem is kár értük.
- A hozzászóláshoz be kell jelentkezni
Azt nem értem, hogy akik megvették az állandó licence-eket, őket hogyan kényszerítik át a fizetősre? Nyilván mondhatják, hogy azokra mostantól nincs support (pontosabban a support szerződés lejárta után), de mást mit tudnak csinálni?
- A hozzászóláshoz be kell jelentkezni
A nincs support azért elég keményen hangzik, ha a CVE-ket is nézzük. Márpedig egy komoly cég nem engedheti meg, hogy CVE-k tömkelegei hemzsegjenek az IT infrastruktúráján. Normális esetben.
Jó, persze, tudom, hogy egy update/patch/upgrade az gyakran hetekig/hónapokig tartó folyamat.
- A hozzászóláshoz be kell jelentkezni
igen, nagy cég nem engedheti meg magának, hogy support szerződés nélkül üzemeltessen. Csak itt a cikkekben roppant közeli dátumok vannak (február, április), a support szerződések meg jellemzően minimum egy évesek, van, hogy több. Addig kényelmesen lehet használni, és közben kiírni egy RFP-t, melynek egyik meghívottja persze lehet a Broadcom, és akkor lehet kérdezni, hogy mennyit tesz rá a 90%-os discountra :)
- A hozzászóláshoz be kell jelentkezni
a nagy cegek persze veszenk supportot, mert akkor a manager hatradolhet: ki van pipalva a "mitcsinaljukhabajvan?" sor.
a kis cegek meg futtatjak tovabb a regi cuccot, es szarnak a frissitesre :(
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Akik allandot vettek azok vettek hozza support and subscriptiont, utobbi kb ugyanaz, mint a leendo elofizeteses...
- A hozzászóláshoz be kell jelentkezni
Engem viszonteladóként érint, a levelet is megkaptam.
VMware Partner Programs Termination Notice
For more than two years, VMware has outlined its plan to transition from a perpetual to a subscription-based business model. This is consistent with the overall market trend toward cloud operating models and was reinforced with the launch and evolution of VMware’s Partner Connect Program.
[...]
Ma jött egy újabb levél.
Open Perpetual Quotes Issued Prior to December 11, 2023 Must be Booked by February 2, 2024
We are excited to launch the evolved Broadcom Advantage Partner Program in February 2024—offering deeper upfront discounts, improved partner profitability and more![...]
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
En pedig varom a CSP meghivot...
- A hozzászóláshoz be kell jelentkezni
Nekem megjött tegnap a meghívó:
Your Organization's Invitation to Join the Broadcom Advantage Partner Program
You are invited to join and experience the evolution of partnership with our award-winning Broadcom Advantage Partner Program launching February 5, 2024.
The Broadcom Advantage Partner Program is an invitation-only, evergreen program that encompasses four tiers covering all routes to market for maximum growth potential. We have aligned your current (legacy) VMware Partner Connect Program level to the appropriate level in the Broadcom Advantage Partner Program.
Exciting news awaits! Next week, your organization will receive more information for your Reseller level within the Broadcom Advantage Partner Program. As the Primary/Key Contact for your organization, you play a vital role in our partnership. Here are the requirements to unlock the full benefits of the new Program.
- Review the Program Terms & Conditions
- Accept the Program Invitation
- Complete the Partner Diligence Questionnaire (if applicable)
Once you have completed your Broadcom Advantage Partner Program membership requirements, your organization will experience the following:
- Seemlessly align to your designated level within the evolved Broadcom Advantage Partner Program.
- Gain access to sell through an authorized VMware by Broadcom Distributor.
- Unlock the ability to resell all products in the VMware by Broadcom February Channel Pricebook (in the country of your organization's headquarters).
Stay Tuned—More Broadcom Advantage Partner Program Information is on the Horizon
- Watch for invitations and details for other routes-to-market and partner transaction programs, such as Cloud Services Provider, Hyperscaler, Global Systems Integrator, and OEM.
- Keep the VMware by Broadcom Essential Partner Information page bookmarked for frequent updates.
- Join us for the February 8 | Broadcom Advantage Partner Program: Evolved vmLIVE where VMware by Broadcom Resellers will gain valuable insights into the landscape of the evolved Program.
If you have any questions, don't hesitate to reach out to your VMware by Broadcom representative or either of our Partner Support teams (Broadcom Advantage Partner or VMware Partner Connect).
Your VMware partnership is invaluable to us, and we appreciate your patience as we strive to provide you with the best possible partner program.
Get ready for an inspiring journey ahead!
—Broadcom Partner Program Office
trey @ gépház
- A hozzászóláshoz be kell jelentkezni