Új hozzászólás Aktív témák

• #3 Dißnäëß veterán bambano #1

  Új Válasz 2021-09-16 08:49:32 #3

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Dißnäëß

  veterán

  válasz bambano #1 üzenetére

  A többi ügyfelet ez nem érinti, egy bank ha a közel teljes stack-el felhôbe megy, az VPC lesz, azaz a megvett erôforrások dedikálva lesznek számára, párszáz procimag, pár tucat tera ram, storage dettó, egyszóval nem fog kockáztatni, hogy totál shared-ben legyen.

  Lesznek a teljes landscape-nek elemei, amik horizontálisan skálázódhatnak terhelés függvényében, és nem kell fizetnie érte, míg nem használja ôket, de jellemzôen ezek meg nem mission-critical cumók, tehát mondjuk nem az Oracle-t fogja oldalra kiskálázni, hanem a frontendjeit pl, vagy middleware, backend dolgokból ezt-azt (na nem a COBOL-ra gondolok), és a treshold mindenképpen úgy van beállítva, hogy van egy "piros vonal", ami alá nem tud menni az egész megoldás mérete (lefele), ergo az nonstop rendelkezésére áll, mint kapacitás, és dedikáltan neki szól.

  Ha van kis eszük, hibrid megoldásokkal élnek mindenhol szinte (kivéve kulcsfontosságú pontokat, pl. az Oracle cluster lábai), így nem igazán érheti ôket durva meglepi.

  A stressz teszt nem jog kérdése, hanem a felhôben megvett infrastruktúrát, amire becsült nekik xy beszállítójuk vagy tanácsadójuk, egyszerûen jól meghajtják púpra és megnézik, hogyan viselkedik.

  Szerzôdésüktôl függôen ezen rendszerek telepítése és üzemeltetése ritkán van magánál a felhôs cégnél (okkal, persze az fogja a kezüket), így vagy maguk rakják össze, vagy külsôst bíznak meg ezzel, akinek már van ebben iparági tapasztalata.

  A felhôszolgáltatónál ez az egész vállvonós, ô csak elad X erôforrást, jellemzôen dedikáltat (ilyen célra pláne), ott nem lesz gond, illetve ha a beszállító és/vagy IT javaslatára úgy döntenek, hogy legyen a landscape egy része spot instance-en mondjuk, mert rohadt olcsó, ott meg PET-elhetnek, vagy lesz kakaó, vagy nem.. de jogilag nem ütköznek semmibe.

  Ami történhet, hogy EGYÉB, spot instance-eket vevô ügyfelek beszophatják, mert lelövi az ô instance-eiket a host, amikor a dedikáltra megvett VM-eknek erôforrást kell allokálnia. Ez meg szintén vállvonós a felhôsnek, ugyanis a spot instance jogilag és technikailag így van megoldva, hogy csak ha van szabad hely, akkor fut adott host-on, de ha az púpra járatódik, lelövi azt a hypervisor és átmozgatja másikra. Ezt meg az ügyfél is tudja és tisztában van vele.

  Nem lesz gondja egyiknek sem a skálázódással. Meghajtják a rendszereket, sokkal inkább tervezésbôl adódó sebességlimit várható (kevés sávszél hálózaton, lassuló hibrid storage, kevés sávszél SAN-on, alulméretezett host-ok), emiatt meg szintén nem aggódik a felhôszolgáltató, mindenki amit kér, azt adja neki.

  Amúgy egyetértek, szántsák be mindet.. amikor egy ország teljes pénzügye, oktatása, elektromoshálózata, bármilyen egyéb infrastruktúrája költözik felhôbe az IT részlegével, az az ország onnantól egyetlen jenki gombnyomására lekapcsolható mindenrôl és kvázi meghalt. Nem kell drón, meg letámadni, meg semmi.

  A felhô kontroll, nettó függôség és rengeteg államközeli, állami szerepeket ellátó cég szempontjából szimplán nemzetbiztonsági kockázat.

  Legalábbis a publikus verziók és virtual private cloud-ok egyaránt, beleértve mondjuk egy onprem Outpost-ot is.

  A tényleges privát felhôk, melyek classic onprem módon vannak 1 vagy több geolokációra redundánsan letéve és AWS/Azure/GCP-t hírbôl sem ismernek, más tészta. A felhô technológiát és képességet is jelent, nem csak helyszínt, hogy "ott valahol", tehát egy zárt, jól védett privát felhô piszok jó cucc tud lenni, ugyanúgy élve az összes CI/CD, konténerizációs, SDDC stb. goodie-val, mint a publikus felhôk, sôt, nonkritikus részeket kitehetnek publikus felhôbe, pl. frontend réteg, vagy annak 3/4-e, hadd skálázódgasson ott, míg a privát felhô oldalon az infráját majdnem púpra lehet járatni (~70-80%), nincs parlagon hagyott hardver erôforrás (ami egyébként aranyáron van).

  Nincs gond a felhôvel MINDADDIG, míg úgy van design-olva a landscape, hogy nem függ a szolgáltatás egésze (tehát 1 vagy több kulcsfontosságú része) a publikus felhô szolgáltatótól. Bank, Paks, közlekedés, vasút, elektromos hálózat, vízgázvillany, NAV, hírközlés, stb.. esetén CSAK úgy lenne szabad csinálni a felhôzést, hogy vagy maguknak építenek ezek privátot, vagy létrehoz vki egy országon belüli felhôs céget és abba berámolja ôket (azért itt már lenne mérethatékonyság), na erre viszont se akarat (egyelôre), se kompetencia, pedig lenne értelme.

  Na meg nem kéne a CxO-knak a sales-esektôl feléjük áramló kenôpénzt elfogadni, de mivel ennek nem mindig tudnak ellenállni, megy dalolva mindenki a publikus felhôbe. Amíg mûxik, nincs gond vele, igazából maga a felhôs infra és az odavezetô utak rendelkezésre állása determinálja, a (geo)politikai vonzatáról meg hallgat mindenki mélyen, a helyi politikus vagy nem ismeri fel ennek veszélyeit, vagy belobbizta nála magát szintén valaki, hogy ugyanmár, nem lesz gond abból, ha ezentúl a teljes infrád felett mások rendelkeznek, mert náluk a "piros gomb", hiszen barátok vagyunk évtizedek óta..

  Legalább lenne egy európai felhôs cég.. de nem. GCP, AWS, Azure, amik a kontrollon felül még masszív lock-in-eket is jelentenek az egyre egyedibbé váló megoldásaikkal, melyek ma még "áhh semmiség, az Aurora egy Postgre, az Amazon Linux meg egy RedHat".. aztán 10 év múlva oda forkolódik el és nô úgy össze a felhôvel a saját cuccuk, hogy ha lejönnél róla és Aurora-ról kéne Opensource Postgre-re visszaállni, vért hugyozol vagy nettó lehetetlenség, a Linux esetében meg dettó, és mindez nem maga a kernel miatt, mert az közel ugyanaz mindnél kb, hanem a körítés, integrációk, automatizációk, ... Na ezeket, amik kényelmét megszokja az IT-s managga a felhôben, ha majd borul a bili és onprem kell felépíteni, se csapat, se skill, se semmi rá, ... ugyanúgy vérthugyozós.

  A legtöbb IT nagyvezérnek halvány lilája sincs arról, hogyan kell egy felhôt JÓL kihasználni (fôleg költségcsökkentés miatt ugye), hogy amikor esetleg ott kell hagyni, ne legyen az vért hugyozós.De legyünk ôszinték, tojnak erre is magasan. Bemennek felhôbe, nagy gázsi (bér + juttatások) felvesz + vastag boríték asztal alatt (felhôstôl), aztán ha gebasz van, max kirúgják, akkor meg úgy küldik el, hogy komoly távozási csomag és szarik bele mi lesz utána, megvan a balatoni kecó, az n+1-edik lakás, ház, vagyon, stb....

  Mi meg kis naivan elszakmázgatunk itt, hogy minek van értelme és minek nincs...

  Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

• #9 Dißnäëß veterán anulu #5

  Új Válasz 2021-09-17 02:53:58 #9

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Dißnäëß

  veterán

  válasz anulu #5 üzenetére

  Mindketten MS-ről beszéltek, én AWS-ről, szerintem nem ismeri egyikőtök sem a cloud-ot olyan mélyen, hogy tudjátok, mit beszéltek, vagy azt nem tudjátok, hogy én mit beszélek vagy nem egyazon asztalnál pókerezünk éppen..

  Nyugodjatok meg, hogy "vannak még csodák".
  A SaaS meg dedikált így egy mondatban érzed... [...] .. de .. még ecseteled is..

  AWS-nél minden csak szerződés (és pénz) kérdése, mert náluk tudnak megfelelő kaliber fölött olyan egyedi SaaS szerződést adni, ami alatt az infra kőkomolyan odadedikálva Neked. De ismétlem, szó nincs SaaS-ról, mikor egy bank felhőbe megy, nem fogja a teljes irdatlan IT-ját SaaS-ként venni lol. A nagyja saját megoldás lesz PaaS szinten, amit pedig nem tud, vagy hozzávenne új feature-ként, pl. analitika, stb, az SaaS, de lehet az O365 is, meg bármi egyéb, ami eszébe jut, de a core kemény rendszerekkel nem fog szarozni, hogy csak úgy levesz egy "dobozos" SaaS megoldást majd egy OTP a polcról és örül, hogy lám, a hitel- meg folyószámla nyilvántartó rendszerei detökjóújak lettek, pont a saját szájíze szerint, aztán ember legyen a bolygón, aki a meglévő rendszereket hozzáintegrálja az újhoz egy átmeneti periódusra + többéves migrációra..

  Én szóba sem hoztam a SaaS-t, PaaS végig ... Illetve szatellit rendszerekben még lehet SaaS erre-arra, de a landscape nagyja PaaS, és ez lehet olyan dedikált cumó, ami alatt nincs más ügyfél, meg semmi himihumi, hülye lenne nem így kérni, a bank meg kaliber (hacsak nem valamelyik lepukkant sarki Coop jellegű takszöv).

  MS felhő egyébként össze sem hasonlítható az AWS-el, utóbbi lényegesen stabilabb.

  bambano: AWS DirectConnect 25ms Bp-Milánó, MINDIG, időjárástól függetlenül, jóreggelt, mondjuk ezt nem Kispista Kft. szokta az ügyfeles kislány és az AWS közé kihúzni, hanem ICT cégek, bankok, biztosítók, egyszóval, nagyágyúk. És igen, csinálnak dedikált vonalat, és az összes hálózati eszköz elbírja a teljes lánc mentén a forgalmat, hozhatom a kávét ? Mesélhetek még. Milyen kérdés ez, hogy mi hogy bírja-e a forgalmat ? Ezzel foglalkozni sem kell, mert a "hülye" felhőszolgáltató még ezt is skálázza úgy, hogy észre sem veszed, a háttérben (tekintettel arra, hogy minden triplán HA + agyonrommá biztosítva, meg többhónapos, többlépcsős előkészület, 1 éves csak a tervezés, meg ilyen apróságok, bőven van projekt roadmap mentén rákészülni a bővítésre, a köztes lépcsők, külső szolgáltatók, MPLS-t adók szintén, Te csak annyit mondasz, hogy kérsz mondjuk 40Gbitet A és B pont között, a többit intézik, hogy mire szerződés szerint ki kell épülnie a kapcsolatnak, amögött lesz kakaó is). Ami sávszélt Te megveszel egy DirectConnect-re, azt csurig terhelheted és cibálhatod, bírni fogja end-to-end minden, nyugodt lehetsz. Ez a lényege, erről szól, ha Te ezt nem tudod púpra használni, nem adják el Neked, mert nem veszed meg, na szóval érted.

  Említett hálózati eszközkiesés demonstrálására n+1 opció van, pláne egy felhőben, ki lehet magát a DirectConnect-et is lőni, meg a köztes kapcsolatokat is, vagy fogsz és default konfigot adsz egy tűzfalnak ( = minden lezár), vagy a loadbalancer egyik lábát lelövöd, vagy még n+1 módszer, ez így wtf, kihívás, vagy mi ? Jó kis teszt lehetett amit Te láttál remélem nem voltál benne, az nem HA meg DR, amikor összerakunk valamit, de nem teszteljük végig a lánc szinte minden sarokpontját. Ki kell alóla rúgni a szék mikor melyik lábát, mindezt nyilván tesztkörnyezeten, ami az élessel identikus (kapacitásban nem feltétlenül, de architektúrában teljesen), és mivel a konténer orchestrator (és még a VMWare is alatta) template-ekből dolgozik, ott nincs az, hogy az IT-s azt mondja, tesztrendszer = éles rendszer, aztán ami a teszten ment, élesen mégsem úgy viselkedik, mert kiderült, hogy ja, bocs, tényleg nem egyforma egészen a két környezet..., hanem itt IGEN, EGYFORMA a kettő, nincs user error egy automatizált deployment-ben (jó esetben ), ha meg a konfigok szarok, az már teszten kiderül..

  Az ilyen giga kaliberű projekteket általában külsősre bízza amúgy mindenki, aki teheti. Csak úgy egyedül ritkán vállalják be, a vendor meg nem lesz olyan hülye, hogy elkúrja az ilyeneket, hogy egy PREPROD mondjuk a PROD-tól jelentősen eltér, vagy bármi hasonló kreténség (ami inkonzisztenciát hoz a képletbe és kész a baj, amiről írtál), mert különben nagyon elverik őket.

  Betáp kérdés nemtéma, amikor egyetlen AWS region-ben több availability zone-ról beszélünk és kereszbe van 3 AZ egymásnak drótozva, de azért ne gondolja senki, hogy fricceknél az AWS által bérelt vagy üzemeltetett DC-kben betáp gondok vannak, ez egy csoffadt kis Victor Hugo-n magyarisztánban lehet, még divat, de szálljatok le a földre, itt nem fillérbaszó megoldásról beszélünk. Mikor anno T-Systems-ben külföldön voltam, egy "kisebb" DC-jében, az is önmagában (1 DC-ről beszélünk) 2 baszom épület volt, 2 külön áramszolgáltatótól betáp (fizikailag!) + az emeleti szint fűtött, kézmelegen tartott (!), mozdony méretű dízelmotorokkal megtámogatva, amiből volt emlékeim szerint épületenként 6 darab és ezekből 4 elég, hogy elvigye az adott szárnyat max kapacitás esetén is 1 hétig. És ez volt ööö ... 2009-2010 körül. Miiii a baj a táppal ? Ott szörnyülködtünk a szervizfolyosón az irdatlan motorok között mászkálva a "túravezetővel", hogy te jóóóó ééég, ez mekkora overkill, de sajnos vagy sem, indokolt, tekintettel arra, milyen durva kötbérek kötik őt ügyfelek ezrei által.

  Toljatok le pár durvább projektet többszázmilkó EUR nagyságrendben felhőben, utána beszélünk. Nem szeretném, ha bárki utánunk következő csak az amatőr tanulságot vonná le az egészből, hogy "hát ezt mindig mindenki így vagy úgy, de elbassza", csak mert kevesen láttak életükben TÉNYLEG jó, penge megoldást, megfelelő méretben.

  És akkor ez csak a technológia, hogy kereskedelmi szinten mik mennek, uh, külön A4-es oldalak, ha le kéne írni, a ki miért felel, milyen az együttműködés, licenszek, kedvezmények, ilyen-olyan deal-ek, holvagyunk itt már attól, hogy egy mezei user-nek, amit Ti is láttok ezekből a szolgáltatásokból, mi jár ? (Nagyon messze).

  @anulu: pénzforgalomra tojnak, lehet a világ összes vagyonát mozgató Warren Buffet cége is, a felhőszolgáltatókat az mozgatja, mennyit hagysz ott náluk, és van az a pénz - mint mindenhol a világban - amiért elkezd korpásodni a hajuk, letolják a gatyót, és egyedit adnak.

  Nem az ügyfél pénzforgalma számít, vagy tőzsdei mérete, vagy piaci kapitalizációja, stb.. náluk nem ez a kaliber meg VIP ügyfél, aki filléreket hagy ott, közben milliárdos cég, hanem aki sokat hagy ott, és attól még lehet egy "garázscég" is.. az a lényeg, hogy szarrágóskodik-e az IT részlege a felhőszolgáltatóval, vagy belátja saját igényei mentén, hogy itt zsebbe kell nyúlni, na akkor hajlandó moccanni a felhőszolgáltató is, és egyedi ajánlatok elérhetők, amik mentén - nyilván - egyedi megoldások születnek, meg mindenféle hibridek, el nem tudja földi halandó képzelni, aki nincs így ezekben benne, milyen csavart sztorik vannak.. (De amúgy szvsz ilyet az MS is tud, de velük nincs tapasztalatom, de nem hülyék, kell a biznic, ölik egymást az újabb üzletekért).

  Higyjétek el nekem, mert nem nyakig, fejbúbig benne vagyok egy elképesztően durva projektben: jó a felhő (!!). Az egyetlen gondom nekem vele, a "kinél van a gyeplő" kérdése, ez viszont rohadt nagy gond. Én kisember gondolok egyet és vagy szemet hunyok efelett, vagy nem, vagy letojom, vagy nem. A multik meg úgy gondolkodnak, hogy geopolitikától kezdve jogon át (hogy a legegyszerűbbet, GDPR-t mondjam), mindenféle megfelelőséget, stb. figyelembe vesznek és mérlegelnek, és ha a képletben az jön ki, hogy nem várható, hogy holnap az amerikai elnöknek elborul az agya és le akarna minket egy gombnyomással kapcsolni, akkor bizony bevonulnak a felhőbe akkor is, ha egy magamfajta mondjuk a haját tépi erre, mert hülye elveim vannak. Neeeem a gépek, meg a sávszélek, meg a latency-k meg ezek miatt, ezekre komolyan, van megoldás többnyire szinte mindig. Hanem tudjátok, a kiszolgáltatottság. A távolság még nem teszi nálam kiszolgáltatottá a történetet, fogok egy gluster-t, egy ceph-et, elosztott fájlrendszert, aminek 1-2 lábát Londonba, 1-2 lábát Malajziába, 1-2 lábát kishazánkban mondjuk nálam otthon a digi kapcsolatomon, 1000-es Digin ráér felcsorogni, amúgy meg jónapot.. aztán ha valamit lekapcsolnak, mert hirtelen nemkedvelt háborús zóna lettünk, vagy jön a MadMax, vagy tudomisén, akkor még mindig megvan mindenem a többiek által + önmagában az onprem-emen is a marék HDD-n.. csak mondtam valami nagyon hülye példát..

  Messzire mentünk. Ne ekézzétek a felhőt. Illetve nyugodtan, van pár disznóság bennük, törekednek a behúzottakat egyre inkább ott tartani (lock-in), én nem csipázom, de ha már muszáj, és megtehetitek, akkor érdemes átpillantanotok a sárgákhoz is..

  Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Új hozzászólás Aktív témák