Kde ja to jen kua ... nojo .. urcite tady a na praskly lupe taky ... voni prece ti profici v tech velkych korporacich zcela jiste umej zajistit spolehlivost provozu daleko lip, nez nejakej matla v nejaky firme ... zejo?
Aneb, sverte provoz svy firmy cmoudu, usetrite a spolehlivost je garantovana ....
Do cluodu vetsinou nemigrujes kvuli spolehlivosti (i kdyz i t obvykle byva vyssi nez on-site infra spravovana nejakym matlou). Ale spis kvuli snadne skalovatelnosti a i kydz platis casto nasobne vice nez za on premise setup, tak nemusis resit jeslti zitra potrebujes 4x tolik serveru nez dnes.
Zaroven i v tom cloudu bezi tve aplikace, tvym noumou spravovane/navrzene systemy, takze prostor pro nej vse kazit tu samozrejme je ;)
Navic myslis, ze kazdy nouma by zvladl spravovat infra pro sluzbu rozsahu Webexu? :)
Lol, to zname pak v realu jak je to s tou snadnou skalovatelnosti ;).
Udelat aplikaci stateless stejne skoro nikdo neumi (i kdyz samozrejme tvrdi ze ano), db je tam pak jedna (cluster; master-standby ;)), to stejne NAS nebo reverzni proxy (v lepsim setupu se stand-by), sessiony se rvou do databaze
A mame super HA, skalovatelny cloud a vsichni jsou happy :).
Nerikam, ze je spatne to tak delat. Ale *jak* to skaluje? Mate to realne zmerene? Kdy z toho bude bottleneck? Session jsou jeden priklad, borci co nutne potrebuji cloud pak do te jedne db zapisuji uvnitr for loopu (a jeste schovane pres ORM), atd. A po par optimalizacich se ukaze, ze by to v jedne instanci zvladlo vic nez ted cely cluster.
Dal se muzeme bavit treba o tom jak se resi resetovani kontejneru ve spojeni s dlouhotrvajicimi websockets spojenimi a reversni proxy.
Zazil jsem i pripady ve stylu "ale ta reverzni proxy ve virtualu je pomalejsi nez aplikace primo na zeleze" ... eh, tak tu aplikaci zpomal, at muzem ukazat jak je to super :).
Zajimalo by me kolik obhajcu "cloud skaluje super" maji v ruce realna cisla z benchmarku jejich aplikaci. Samozrejme temer nikdo, je to postavene na ideii, ze ted uz s tim nebude problem (ktery nebyl ani ted, a kdyz prijde radove vetsi traffic tak se to stejne zacne sypat).
Reverse proxy - to se dá škálovat. Cloudem. ;) Třeba Cloudflare ...
Nebo si to lze udělat sám. Škálování reverse proxy lze např. řešit větším počtem proxy serverů a na rozklad mezi ně využít DNS round robin balancing. Vysokou dostupnost proxy serverů lze řešit více způsoby (dynamickým přidáváním/odebíráním DNS záznamů, proxy cluster, ...). Takže no problem.
Slo mi o konkretni pripad "cloud je super" demagogie, kde bylo uzke hrdlo uzsi nez kdyby byla vlastni appka na zeleze. Jestli si tohle z toho nepochopil tak ...
Vetsina tehle jsme super in a s dobou fellow-kids cloudu to ma uplne stejne a jede pres jednu reverzni proxy. Jeden priklad z mnoha. Tohle uz se delalo vic nez dekadu proxy z haproxy a keepalived akorat se tomu nerikalo cloud ;). No dnes je tam misto haproxy nginx a pouzivaji se kontejnery (kdyz je linux zacal 13 let po freebsd podporovat).
Ty tomu vůbec nerozumíš. Když do toho cloudu nedokopeš lidi silou, zkus ještě větší sílu.
Exchange Server 2019 system requirements:
Memory:
• Mailbox: 128GB minimum
• Edge Transport: 64GB minimum
Hele uz sem si vzpomel ... presne tyhle blaboly byly u "jak moneta prechazi do cmoudu", protoze prece ta uzasna korporace (amazon) ma prece daleko lepsi ITky a proto jim to zcela urcite bude fungovat ....
Ad exch - jen vic a houst, stejne to vetsina firem pouziva jako hloupej mailserver, hlavne ze maj ten exchange.
BTW: Pro tu prdel, skus si do exchange pridat security grupu a pridat ji prava z toho polenefunkcniho adminwebu ... nebo si zkus vyresit, jak bude mit jeden useer dva (nebo vic) mailboxu bez toho abys mel v domene 2(a vic) uctu ...
Apropos, vis co je na tom jeste vetsi rit?
Note that Exchange 2019 has large memory support (up to 256 GB).
Takze minimalne to chce 128GB, ale umi to ohromny mnoztvi ... az 256GB ... ;D
Nebo ....
Screen resolution 1024 x 768 pixels (XGA) or higher
To jako fant? Exchange se nedaj provozovat bez monitoru? hmm ...
Těch 128GB už jed dávno vysvětleno. Je to minimální množství od kdy se využije nový .NET garbage collector.
Exchange 2019 lze samozřejmě provozovat i s minimem RAM - třeba 8GB.
Těch 128GB v požadavcích se dá pravděpodobně vysvětlil změnou cílové skupiny - Exchange je nyní k dispozici jen v rámci volume programu. Takže pokud jde velká firma a mátě tisíce a tisíce schránek, hodně ram potřebujete a je naopak matoucí uvádět 8-16GB.
Nicméně takhle je to matoucí asi pro všechny.