Az AT&T beperelte a Broadcom-ot a VMware-rel kötött támogatás kiterjesztés szerződése felrúgása miatt

Virtualizáció

Az amerikai telekommunikációs óriás, az AT&T azt állítja, hogy a Broadcom megszegte azt a kiterjesztett támogatási megállapodást, amelyet a VMware-rel kötött, és figyelmeztetett, hogy ennek következményei jelentős leállások lehetnek az ügyféltámogatási műveletekben – sőt, még az Egyesült Államok elnöki hivatalában is.

Egy, a múlt héten a New York állami Legfelsőbb Bíróságon benyújtott panasz [PDF] szerint az AT&T állandó licenccel rendelkezik a VMware szoftverére, és fizetett a támogatási szolgáltatásokért egy olyan szerződés alapján, amely szeptember 8-án jár le. A panasz szerint az AT&T-nek lehetősége van a támogatási megállapodás két évre történő meghosszabbítására, feltéve, hogy ezt a lehetőséget az aktuális szerződés lejárta előtt aktiválja.

Az AT&T beadványában azt állítja, hogy éltek ezzel a lehetőséggel, de a Broadcom „megtagadja a szerződés betartását.”

Részletek itt.

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

( trey | 2024. 09. 05., cs – 11:06 )

Egy újabb egykori VMware ügyfél, aki nincs megelégedve a Broadcom-mal.

Csak annyi a különbség, hogy az AT&T nem garázscég, az USA elnöki hivatala meg nem játék (főleg nem választások előtt), még a Broadcom-nak sem.

🍿

trey @ gépház

( sanyex | 2024. 09. 05., cs – 11:57 )

" ~8,600 servers that host AT&T's ~75,000 VMs "

Lesz mit migrálni .

Mindkettő elég jól működik enterprise környezetben (1k+ számú fizikai szerver). Bár a Hyper-V a Microsoft többi terméke miatt picit többet tud. Össze lehet drótozni további MS termékekkel is. De ez egyben vendor lockot is jelent bizonyos esetekben.

Vmware-nél is nem maga az ESX a probléma. Hanem a hozzá kapcsolódó további Vmware termékek és szolgáltatások. IT drog. Nehéz róla lejönni.

Amíg ott tartunk, hogy a kedves megrendelők / architectek / kollégák stb. képtelen minimálisan előre gondolkodni, addig nincs miről beszélni. Egyszerűen felültek a Vmware vonatra. Most meg próbálják minden lustaságukat a Vmware-re / Broadcomra kenni.

Például egy Powershell jól fog működni Windowson. De szkriptnyelv és nem a Linux nagy barátja.
Viszont egy Bash az még egy kávéfőzőn is fut kis túlzással.
Tehát ha írnom kellene valami szkriptet, akkor inkább írnám Bashben, mint PS-ben - ha nincs akadálya és nem Windows only megoldásra van szükség.

Kapzsiságról: a lufit fújni kell. :D

Ebben a volumenben bármi játszik, extrém esetben akár egy open source fork de legalább kontribúció is, saját csapattal. 

A menedzsmenttől függ, attól hogy mennyire értik a technológiát, mennyire értik hogy át lettek baszva és mennyire vállalják fel hogy megoldják rendesen.
És persze attól, hogy mennyire jönnek a lobbisták megkenni őket. Jönni fognak, nagyon.

Gábriel Ákos

Nem a VM-ek számával lesz itt baj, hanem azzal, hogy valószínűleg API szinten is borzasztóan szorosan rá vannak integrálódva.

AT&T-vel konkrétan nem volt dolgom (najó, valami pilot projekt szinten igen), de más telco szolgáltatókkal igen. A teljes automatizáció, tooling keményen kötődik a VI API-khoz. Nemcsak vCenter hanem vCloud Director, vROPS, NSX, is elég gyakran használatban van telco-s cégeknél. Erről lemigrálni kb egy 0-ról teljesen új üzemeltetési folyamatrendszer felépítésével is jár. Rengeteg egyedi megoldásuk, bevásárolt szoftverük is szorosan kötődik a VMware-hez.

Másik oldalról, sok telco szolgáltató, aki Openstackezére adta a fejét, VIO-t választott (vmware-alapú openstack). API szinten ők kevésbé erősen kötődnek a vmware-hez, de a VM-ek, image-ek szintjén igen.

Régóta vágyok én, az androidok mezonkincsére már!

A számokkal csak a feladat nagyságára próbáltam utalni. Amúgy igazad van, ez csak a projekt egy része. Méghozzá nem  a legnagyobb része.

A felmerülő költségekről meg ne is beszéljünk. Ezért nem is hiszek a rövid távú szakításban, szerintem meg fognak majd egyezni.

Bár azt nem tudom, hogy az AT&T-nél van-e egyéb párhuzamosan működő rendszer, mert az még bekavarhat az egyenletbe. ( Elsőre nem gondolnám, hogy csak egy lábon állnak. )

Világos. Az At&t-ről pont nem tudok nyilatkozni, de a hozzá fogható méretű telco szolgáltatók között voltak, akik az ETSI NFV vonalra elkezdtek felülni évekkel ezelőtt. Az elméletileg vendorfüggetlen szabvány (a gyakorlat meg... hosszú történet), és az NFVI (azaz a VI) réteget leggyakrabban valamilyen, kissé customizált Openstack disztró adja. Mi mondjuk speciel támogattunk vCloud Directort is NFVI szerepkörben. És az Openstack alatt is lehet vCenter (ez a VMware saját openstack-je, a VIO - fogalmam sincs a Broadcom szándékozik-e továbbvinni ezt a vonalat), de a leggyakoribb a hagyományos KVM-alapú virtualizáció. Xen vagy Hyper-V alapú Openstack ugyan létezik, de nem találkoztunk egyetlen ügyféllel sem, akinél egyáltalán felmerült volna.

Az igazán nagy (At&t súlycsoportú) telco operátorok voltak akik tényleg ki is akarták játszani az ETSI NFV vendorfüggetlenségét és szándékosan mixed-vendor rendszert építettek maguknak. Gyakorlatilag kikényszerítették, hogy össze legyenek tesztelve más vendoroktól származó komponensek, meglegyen a deployment template minden platformra stb. Kisebb ügyfelek simán elvoltak úgy, hogy egy vendortól vettek mindent.

Szóval akik már jópár éve ezt tolják, ott legalábbis van esély rá, hogy tudnak alternatív platformra váltani.

Bezavarhat még az is, hogy az ETSI NFV-re többnyire az újabb hálózati komponensek (4G VoLTE, 5G) készültek el. A legacy dolgokra igazán senki nem költött. Bár a 2G, 3G dolgok nagy része virtualizálva sem volt.

Régóta vágyok én, az androidok mezonkincsére már!

A cikk tartalmanak ellenorzese nem az ujsagiro legfontosabb feladata? Vagy mar ez is olyan mint a beta-teszteles Microsoftnal, majd az ugyfel megcsinalja?

Mivel itt se újság, se újságíró, se újságírás nincs, csak pointer-ek érdekes témákra, amelyek beszélgetést indítanak, ezért valóban, a végleges fact-check olvasó feladata. A HUP-on mindig is így volt, ezért is tartalmazott minden HUP cikk (nem hír) linket a forrásra már az első naptól kezdve. Jelzem, ez 2001 környékén kuriózum volt, az oldalak nem nagyon adtak akkoriban még forrásmegjelölést.

trey @ gépház

( freeoli v | 2024. 09. 06., p – 11:25 )

A mi anyavállaltunk 1 év haladékot tudott kibirkózni, de volt olyan telephely ami már migrált.

( Raynes v | 2024. 09. 07., szo – 18:41 )

Az nem érdekel, ha nyomokban AI gyártotta, az elegendő indok, hogy meg se nézzem a cikket, így érdemben a tartalmát sem fogok kommentelni, pedig lehet érdekes lenne. Majd az AI megkommenteli helyettem, ha olyan fainos.

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

Az mennyire gáz, hogy azt is tudom, hogy azelőtt GSX Server-nek hívták. :) Amikor még az "ESX Server" - így egyben kiírva, i-nélkül - volt a másik termék, amiben a VMFS-en nem tudtál subdirectory-kat létrehozni, ezért ömlesztve volt az összes VM minden file-ja. Öröm volt, mikor az ESX3.0-ra upgrade után kézzel kellett szétszortírozni.

Régóta vágyok én, az androidok mezonkincsére már!

Nem azt a részét, de mivel AI-val gyártott téma, azokat kerülöm. Konkrétan pedig ez a támgatása téma érdekes lett volna megvitatni, és kész is lennék rá, ha nem AI-s infókra épülne az egész.

Amúgy megnyugtatlak, hogy nem VMware-ezek már nagyon régóta, nekem tökéletesen elegendő a qemu-KVM, nem ebből a szempontból kommentelném. Sőt, a FOSS megoldások között sem szeretek mindent, pl. a Virtualbox-ot is régóta hanyagolom, szokásos Oracle minőség, főleg stabilitás terén, meg lehet hozzá minden alkalommal feleslegesen kernelmodult pörgettyűzni, ha az ember kernelt frissített.

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

Egyébként vannak dolgok, amiket tényleg nem ismerek. Pl. azt is most tudtam meg egy videóból, hogy a Virtualbox hiába FOSS, az Extension Pack az zárt kódú, és csak magánhasználatra ingyenes, kereskedelmi használatra már licencet kell hozzá venni. Hihetetlen.

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