Vlákno názorů k článku Jak se staví CDN: bezpečnost, monitoring a tipy z praxe od anonym - Dobrý den, S chutí jsem přečetl vaší sérii článků...

Dobrý den,

S chutí jsem přečetl vaší sérii článků o CDN. Po přečtení posledního dílu mám několik otázek.

Ze článků to působí tak, že stavba vlastního CDN je především věc zdrojově velmi náročná, jak časově v rámci nutných znalostí lidí (pokročilé znalosti z IT infrastruktury, administrace, networkingu, zkušenosti z praxe, aktuální vývoj trhu), tak čas samotný pro realizaci a hlavně(!) čas, který je nutné věnovat provozování 24/7/365 této služby.
Umět skloubit správně nastavení (což je prakticky minové pole, které se v čase vyvíjí), držet krok s dobou, update / security management jednotlivých komponent - to nepochybně vyžaduje čas týmu zkušených lidí. Dále je zde nutná vytvoření a udržba poměrně rozsáhlé dokumentace, vytvoření modelu zastupitelnosti a ostatních postupů nutných pro provoz. Nutnost dedikováného teamu je samozřejmostí.

V prvním článku této série jste vyčíslil jako možnou alternativu u dedikovaných CDN za 20-30 tisíc měsíčně, případně větší providery, kteři začínají na 100 tisících.

Vám se opravdu finančně vyplatí vyvinout, naprogramovat, otestovat, integrovat do produkce, spravovat a podporovat takový projekt v situaci kdy vámi popsaná alternativa stojí 25 tisíc korun měsíčně (vámi uvedená střední hodnota)? Příjde mi stěží uvěřitelné, že vše výše se dá zvládnout pod 25 tisíc měsíčně.

Jaká je přesně přidaná hodnota spravovat takový projekt ve firmě oproti zvolení služby poskytovatele, který má ne tým, ale celou společnost dedikovanou pro tento účel?

Z pohledu majitele menší it firmy, náklad 25-100 tisíc (tedy v podstatě měsíční náklad na jednoho administrátora, a jeden administrátor výše jmenované určitě nezvládne) za outsourcování CDN na profesionální firmu mi přijde jako více než dobrá nabídka.

Takto se mi to jeví jak "hobby" projekt zaměstnanců firmy, ale najímat lidi na správu takového projektu bych ani ve snu nechtěl.

Tohle je CND specialne pro weby s celosvetovou dostupnosti pro zakaznika, ktery chce byt vsude dostupny a rychle. Nejedna se uplne bezneho "as a service" poskytovatele a asi se to vyplati.

Děkuji za tento zajímavý a pochopitelný dotaz. Určitě se na to ptá více lidí. Já popíšu náš pohled, naší situaci a motivaci.

Cílem těchto článků bylo dát návod k tomu, jak si CDN sestavit a upozornit i na to, na co všechno je potřeba při její implementaci myslet. Když jsem to začínal psát, říkal jsem si, že chci pomoct 3 skupinám - ušetřím čas těm, kteří by podobné řešení začali stavět, pak že odradím a pomůžu se lépe rozhodnout těm, kteří by se do toho chtěli pouštět a přitom je pro ně lepší pronajmout komerční řešení a na závěr, že v tom najdou nějaké zajímavé myšlenky a inspirace správci webových serverů.

V našem případě toto řešení dávalo technologický i ekonomický smysl - měli jsme pro to reálnou potřebu i interní kapacity, potřebné know-how (i když jsme v něčem museli jít do ještě větší hloubky, ale to je jenom plus i kvůli vývoji a provozu jiných projektů), máme automatizační nástroje a s tím související interní procesy a z části i servery a již běžící spolupráce s některými ISP.

Kvůli provozu našich projektů stejně pečujeme o více než 100 serverů ve 3 datacentrech v ČR, takže spravovat, aktualizovat, monitorovat a zálohovat pár dalších ve světě, pro nás není téměř žádná režie navíc.

Mimochodem, tím, že jsme se rozhodli dělat PoPy svým způsobem "nestavové" (neřídí to žádný centrální a dynamický mozek), ale každý server je samostatná jednotka s pár interními procesy na pozadí, prakticky nedochází k žádným provozním problémům, které by vyžadovali něčí čas. V podstatě stačí jednou za pár týdnů věnovat 1-2 hodiny otestování a nasazení bezpečnostních aktualizací, ale s tím nám pomáhá Ansible. Každé ráno věnujeme několik minut prohlédnutí vygenerovaného reportu se stovkami grafů a občas je potřeba prověřit nějaké anomálie. Jednou za pár dní či týdnu je potřeba prověřit hlášení z monitoringu. Jednou za pár měsíců je potřeba nějaké komunikace s ISP, např. v případě problému s nějakým serverem či konektivitou, ale jinak za tím nejsou žádné šílené náklady. Samozřejmě do toho teče i nějaký další čas, ten už je ale čistě dobrovolný, kdy někdo ze svého osobního zájmu o danou oblast a problematiku analyzuje data a chce to posouvat dál a dál. Ta core funkčnost CDN by ale přežila i bez toho.

A co se týče vynaloženého času na další rozvoj CDN a jejich funkcionalit - tím, že téměř všechny naše projekty jak vyvíjíme tak provozujeme se vším všudy a je to náš denní chleba, tak potřebné sledování vývoje technologií, best-practices, postupů, nástrojů, ochran, prohlížečů... i následné implementace do projektů či serverů ... to je interní proces, který běží nepřetržitě bez ohledu na to, zda bychom vlastní CDN měli, nebo ne. Chceme a potřebujeme svému řemeslu rozumět. Máme na tom osobní zájem a je to součástí toho, co nás živí a baví. Pak už záleží na tom, na co se kdo specializuje, kde vnímá, že to jeho řemeslo začíná a končí a jak vnímá capex/opex náklady vs. hodnotu nabytých znalostí, co může být dobrá investice do budoucna.

Někdy se oplatí zariskovat, i když to na první pohled nedává smysl. Vždy je z toho nějaké poznání a ponaučení. Existují firmy a lidi, kteří dokáží provozovat stejný projekt úspěšně ve 3-4 lidech na pár serverech a jsou firmy, kde musí svůj stejný projekt při životě držet oddělení 20 lidí na stovkách serverů a pořád jsou čímsi zaměstnaní a náklady jsou extrémní. Když se dělají dobrá rozhodnutí, kvalitní research, hlídá se míra overengineeringu a definují ty správné a nepřestřelené funkčnosti, leccos se dá stejně kvalitně vyvinout a provozovat za o řád nižší náklady, než je něčí zkušenost či odhad. Učíme se a hledáme cesty celý život... ;-)

Pak prichazeji na radu mzdove naklady, mira prescasu, rychlost reseni v dobe nizkeho stavu zamestnancu v navaznosti na SLA atd...

Ten pravidelny research něco stojí, případně řešení provoznich problémů do toho. A IaaC to nezachrání.

At kalkuluji jak kalkuluji ja to při platu kvalitního člověka/specialisty v ČR nejsem schopen dát.
Možná mi uchází nějaký detail jako menší firma kde šéf sedi vedle v kanclu a rozhoduje okamžitě. Prakticky real-time scheduler:-)
Leda že by lidé měli přímý podíl na zisku firmy, byli spoluvlastníky a odměňování by probíhalo ještě jinak.
To může dávat ekonomicky smysl a perspektivu.