Odstěhování služeb z claudu lze uštřit až 90% nákladů ?

[xsouku04]

Spousta vývojářů dnes provozuje svoje služby výhradně nebo téměř výhradně v claudu. Jde to mimo mne, "nutnost" používat claud a jeho údajné výhody moc nechápu.

Dnes jsem ale při procházení freebsd fóra narazil na projekt jailrun, který tvrdí, že umí s freebsd (nebo jeho virtualizací pod Linuxem nebo macOS) nahradit claudové služby přijatelným způsobem a ušetřit u toho až 90% nákladů. A často věci výrazně zjednodušit. A dosáhnout podobné spolehlivosti.

Ano, je třeba to brát trochu s rezervou, protože to není úplně nestranný názor a toho člověka to živí. Ale i tak.

Dotyčný tvrdí, že ty claudové služby jsou záměrně udělány tak, aby byly výhodný na úplný začátek, než člověka uvězní ve svém ekosystému. Který je pak obtížné opustit a proto je mnoho projektů odsouzeno platit násobky než by museli, kdyby v tomto ekosystému neuvízli.

Tento člověk nabízí přechod na freebsd na klíč. Tvrdí, že náklady se zaplatí obvykle už za dva nebo tři měsíce provozu. I kdyby to byl několikanásobně horší, jsou to stále obrovské peníze, které je možné ušetřit.

https://jail.run/commercial/cloud/

Mě se freebsd libí proto, že je tam možné dělat jednoduché věci jednoduše. Což je bohužel něco, co jde proti současným trendům. Obávám se, že podobný postup bude s umělou inteligencí. Firmy, které do ní nyní investují obrovské stovky miliard dolarů, se nás budou snažit uvrtat do jejich uměle překomplikovaných ekosystémů, aby zabránili tomu, že si to lidé dělají sami levněji často i na vlastním hardware. Když claudové služby začínaly, byly dost levné, že se to téměř nevyplácelo dělat. Nyní to už ale zdaleka není pravda a úspora běhu na vlastním hardware je často násobná. Obávám se, že způsob, jak donutit velkou část zákazníků využívat umělou inteligenci v claudu, bude v budoucnu podobný.
 
 
 

[alfi]

Tohle je dost individuální - cloud má největší smysl pro jednorázové-nárazové aktivity nebo navyšování výkonu. Taky pro rozsáhlé systémy, které potřebujou stovky až tisíce (opakovatelných) kontejnerů - kdyby to měl někdo klikat a udržovat ručně, bude to dražší. Stejně tak má pro spoustu firem smysl zaplatit klidně $1000-2000 za managed hardware, databáze, OS - protože jinak na to musí zaměstnat interního člověka, který bude stát podobně, budou mít problém najít šikovného, nebude mít zastupitelnost.. Ale ano, od určité velikosti, dlouhodobého a víceméně konstantního požadavku na výkon, může být levnější to rozjet na vlastním nebo pronajatém HW

S komplexitou dneska AI naopak velmi úspěšně pomůže - "rozjeď kontejner na XY podle image na ZZ, optimalizuj na náklady, každý měsíc vyhodnoť náklady a navrhni další optimalizaci" je násobně levnější než jiný interní člověk, který se o to stará ručně a musí se napřed učit syntaxe konfiguráků
 
 

[xsouku04]

Tohle je dost individuální - cloud má největší smysl pro jednorázové-nárazové aktivity nebo navyšování výkonu. Taky pro rozsáhlé systémy, které potřebujou stovky až tisíce (opakovatelných) kontejnerů - kdyby to měl někdo klikat a udržovat ručně, bude to dražší. Stejně tak má pro spoustu firem smysl zaplatit klidně $1000-2000 za managed hardware, databáze, OS - protože jinak na to musí zaměstnat interního člověka, který bude stát podobně, budou mít problém najít šikovného, nebude mít zastupitelnost.. Ale ano, od určité velikosti, dlouhodobého a víceméně konstantního požadavku na výkon, může být levnější to rozjet na vlastním nebo pronajatém HW

S komplexitou dneska AI naopak velmi úspěšně pomůže - "rozjeď kontejner na XY podle image na ZZ, optimalizuj na náklady, každý měsíc vyhodnoť náklady a navrhni další optimalizaci" je násobně levnější než jiný interní člověk, který se o to stará ručně a musí se napřed učit syntaxe konfiguráků
 
 



 

Samozřejmě, že pokud má někdo nárazovou zátěž, claud bude nejlepší. 
Předtím než zdražily paměti, bylo možné nový stroj pořídit už za 50 tisíc. Se 128 GB ECC pamětí. Spotřeba jen 30W bez zátěže. Teď je to kvůli zdražení pamětí a SSD disků horší. Problém trochu je v tom, že vhodné hotové servery je těžké si koupit, když se prodávají, tak mají nesmyslnou konfigucaci jako třeba jen 16 GB paměti. Musí si to člověk skládat sám. Ale to je právě asi důvod toho, že velká část lidí používá claudy.  Pak ten trh s hardware zakrňuje.

S komplexitou AL dnes opravdu pomáhá. Stále je ale podle mne dobré se zbytečné komplexitě vyhnout a mít věci co nejednoduší.

Dnes jsem např. strávil půl dne hledáním toho, jak automatizovaně konfigurovat síť uvnitř kontejnerů. (ip adresu, výchozí bránu + další routování). Umělá inteligence měla spousty nápadů, ale v podstatě si pořád vymýšlela. Šlo mi o to mít, ip adresu, bránu a routování uložené vždy na jednom místě v externích souborech, aby se s tím dalo automatizovaně pracovat jak zevnitř containeru tak zvenku. A např. při přestěhování kontnejneru s neveřejnou ip adresou tak automaticky změnila výchozí brána automaticky jen inclůdnutím jiné verze konfigu výchozí brány. No hrozný problém. Nakonec jsem vytvořil konfig níže, jako nejmenší zlo. V podstatě musím síť nahazovat ručně, protože všechny nástroje jsou sice překomplikované, ale se základním použitím je problém. Ve freeBSD je to prostě mnohem jednodušší, přesto jsou možnosti jak vše nakombinovat lepší, člověk dalo méně naráží na nějaká nesmyslná omezení. Ale bohužel jsou tam zase problémy, které plynou z toho, že to není mainstream.

Kód: Vybrat vše

# obsah /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0

iface eth0 inet manual
up ip addr add $(/etc/ovps_shared/ip.sh) dev eth0 || true
up ip route add default via $(/etc/ovps_shared/gw.sh)|| true
up /etc/ovps_shared/add_routes.sh

down ip addr del $(/etc/ovps_shared/ip.sh) dev eth0
down ip route del default via $(/etc/ovps_shared/gw.sh)

U VoIP bylo historický dobré se vyhýbat nějaké virtualizaci. A nyní narážím spíše na neprošlapané cestčiky, protože většina ostatních používá claudové služby.  A i když někteří používají vlastní hardware, pořád to staví na té standardní infrastruktuře pro claud. Což by přijde na spoustu použití jako zbytečně překomplikovaná cesta.
 
 

[alfi]

Dnes jsem např. strávil půl dne hledáním toho, jak konfigurovat síť. (ip adresu, výchozí bránu + další routování) uvnitř lxc kontaineru. Umělá inteligence měla spousty nápadů, ale v podstatě si pořád vymýšlela a vždy měla spousty nápadů, proč to co si vymyslela zrovna nejde. Šlo mi o to mít, ip adresu, bránu a routování uložené vždy na jednom místě v externích souborech, aby se s tím dalo automatizovaně pracovat. A např. při přestěhování kontnejneru s neveřejnou ip adresou tak automaticky změnila výchozí brána. No hrozný problém. Nakonec jsem vytvořil konfigu níže, jako nejmenší zlo. V podstatě musím síť nahazovat ručně, protože všechny nástroje jsou sice překomplikované, ale se základním použitím je problém. Ve freeBSD je to prostě mnohem jednodušší. Ale bohužel jsou tam zase problémy, které plynou z toho, že to není mainstream.
 

Síť pro lxc je nejlíp přímo v konfiguráku guesta, např.

Kód: Vybrat vše

lxc.net.0.ipv4.address = 10.20.30.23/24
lxc.net.0.ipv4.gateway = 10.20.30.1
lxc.net.0.ipv6.address = 2a03:3bee:ff:ff::23/64
lxc.net.0.ipv6.gateway = 2a03:3bee:ff:ff::1

nebo pak rozjet DHCP a řídit to tam. Ale ano, času se s tím dá strávit hodně
 
 
 

[xsouku04]

Jo tohle vím, že jde, ale to by pak nějaký skript musel měnit výchozí gateway vždy při přesunu containeru s neveřejnou ip adresou na jiný fyzický stroj. Protože ten fyzický stroj pak dělá NAT.

To by možná šlo řešit includem jiného soboru, který měl jen jeden řádek a definoval tu gateway. Snad lxc config nezakazuje includovat jednořádkové soubory jak to nesmyslně dělá soubor /etc/network/interfaces . Tam není možné, abych ip adresu includnul z jednoho souboru a gateway z jiného.
A pravděpodobně i systemd konfigurace sítě to také nesmyslně omezuje, co se dá na jaké místo includnout.

Krom toho, já potřebuji přidat více routovacích pravidel než jen výchozí brány.

Spousty pravidel ve stylu:

ip route add XX.XX.XX.XX/29  dev eth0

To by šlo řešit dost možná hookem, jestli tam také není nějaké nesmyslné špatně dokumentované omezení.

OK tak tohle je zjevně druhá podobně dobrá možnost než to moje řešení výše. Je to jako zákony, nesmyslně přesložitělé, ale přesto dost nedokonalé. 
 
No předělávat to nyní nebudu, neb mé řešení je zpětně kompatibilní s tím hrozně nepřehledným co jsem vymyslel dříve a které využívalo jakési nesmyslné dědičnosti souboru /etc/network/interfaces , funguje to, ale je to zbytečně nepřehledné, proto se toho zbavuji.

DHCP zbytečně vytváří jedno místo, které když se pokazí tak přestane fungovat všechno.
 
 
 
 
 

[dako]

Ještě je možnost veřejné IP NATovat na daný kontejner, ale to asi nebude to pravé. Kontejneru zůstane nativně vnitřní IP na kterou se provede forwarding z veřejné ip.
Nebo, jde ještě jít cestou různých tunelů, ve vniřních sítích třeba PPPoE, tak to treba dělají různí, i velcí, operátoři.

No a co se týká cloudu, tak je to opravdu otázka použití a rozsahu indrastruktury nebo služeb. Pokud člověk dopředu ví, že chce něco v malém nebo střednějším rozsahu, tak se to dá opravdu dobře vyřešit vlastním hardwarem. Já to vyřešil serverovou deskou od Supermicra nebo i něco od ASrocku, pokud má člověk / firma vlastní "housing"  tak to může být i server v rackovém provedení, když se pohlídá energetická náročnost.
Další z možností je pak ještě "server hosting", ale jak říkám, tohle je potřeba zvážit individuáně, těch možností je opravdu hodně.
A takový malý nebo i velký housing s FVE ... tam se dá i dost ušetřit na energiích.