Napsal Gav;1539765
0) Nejdriv bych mel mit vubec definovanou Cloud Strategy, dlouhodobe cile v navaznosti na strategii organizace, znat vsechny regulatorni pozadavky, ktere se na me vztahuji (a maji impact v pripade pouziti Cloud zdroju) a mit nastavenou obecnou governance prostredi. Pak by bylo taky fajn znat detailni TCO jednotlivych business cases (cena VM v Cloudu neni finalni cena a stejne tak neni finalni cena cena fyzickeho serveru v on-prem). Cloud first nebo Cloud never neni strategie. Strategie je o tom kdy / s cim / jak / proc / za kolik do Cloudu jit a je to vedome, racionalni a podlozene rozhodnuti. No a taky na to potrebuju lidi, kteri tomu rozumi, maji kompetence, mandat a drive menit zabehnute veci (to nejde). Muzeme to honosne nazyvat Cloud Center of Excelence.
1) Tohle je samozrejme individualni pro kazdeho zakaznika a jeho Risk Analyze, Business Impact Analyze, Regulatornich pozadavcich a spouste dalsi (primarne business rozhodnuti). Vychazim ze zakladni obecne premisy: 2 AZs (dve datacentra) = dve fault domains = resim Business Continuity scenar. Dva Regiony = resim Disaster Recovery. Mozna ne vsechny aplikace musi resit BC/DR respektive mohou mit nastaveny ruzne metriky (treba RTO / RPO pro DR scenar). Jestli ma od sebe byt region 10KM nebo 1000KM definuje business a risk analyza.
2) Myslim PaaS. On se fakt chce dnes nekdo starat o servery, pokud to neni jeho primarni business (nebo neni hracicka)? Neni lepsi vzit lidi, kteri se mi staraji o infra a transformovat je na lidi, kteri podporuji muj primarni business? Pod PaaS si predstavuju minimalne veci jako Database as a Service, Backup as a Service, DR as a Service, veci kolem networkingu a VPN, CDN , DNS ci Kubernetes.
3) Chybi mi cokoliv nad ramec zakladnich IaaS sluzeb a malych krucku v PaaS (cest nekterym vyjimkam, kteri ale zase resi jen nejakou cast PaaS - treba DevOps)
4) API ma smysl vzdy a vsude. Integrace, integrace, integrace...
5) Samozrejme ze si kazdy musi vyvynout / navrhnout kazdy sam, ale chci nastroj. Treba zminovany CloudFormation od AWS, ARM sablony v Azure nebo dokonce obecne nastroje jako Teraform. Chci si treba "oliznout" svoji infrastrukturu (nebo jeji cast) a udelat z ni Blueprint, az budu znova nasazovat identickou aplikaci.
6) Serverless != Kubernetes. Nechci se starat o Kubernetes a podklad. Dokonce ani nechci managed variantu takove sluzby. Nechci resit deployement kontejneru. Chci nahrat svoji aplikaci a kdyz ji pres nejaky definovany endpoint zavolam, tak chci aby neco udelala. Chci se soustredit na vyvoj a nic jineho. AWS Lambda treba.
7) Mas nejaky konkretni use-case kdy mi nestaci nativni bezpecnostni nastroje AWS / Azure? (troufam si rict, ze pri spravnem nasazeni nekterych z techto nastroju 95% zakazniku ziska mnohem vyssi uroven zabezpeceni nez maji ted).
Pokud narazis na ten incident s EBS Snapshots viz link, tak kde nic neni ani smrt nebere. AWS nice nezpackal, to jen nekompetentni lidi. "If you choose, you can make your unencrypted snapshots available publicly to all AWS users."
Pokud si nastavim snapshot na "public" (identicka situace s S3 bucketama kterejch je plnej internet), tak tam ti proste nic nepomuze. Respektive pomuze - kdyz uz jsem tele, tak si jednoduse nastavim baseline v AWS Config, ktera mi rozsviti muj dashboard a ukaze, kde je to blbe nastavene. A nebo to taky celou remedietion operaci automatizuju asi tak na 3 radky.
Disclaimer - netusim, jak se to nastaveni "Public" u tech snapshots objevilo, ale vhledem k rozsahu (± 1000 affected in all regions) tak to spise ukazuje na debilitu / neznalost nez systemovou chybu.
8) Chci auditni nastroje, chci vedet, jak mam realne nastavenou infrastruktury a jestli jsem compliant se vlastni baseline (opravdu pouzivam tagy pro billing? Fakt mam vsude svoje CMK pro encryption nebo nekde nejaky pitomec nechal vychozi provider klice?). Chci vedet, kolik me stoji provoz Dev/Stage/Prod prostredi aplikace XYZ a kolik stoji provoz vsech aplikaci oddeleni ABC. Chci vedet kdy, kdo a co zmenil na serveru 12345
díky za obsáhlou odpověď, teď ty tvoje zkratkovité body dávají smysl a vidím jak jsi to myslel.
ad 1) no právě, řikat, že minimum je 2+2 je za mě nesmysl, je to ryze individuální záležitost
ad 2) ano, chce, třeba ti, kteří potřebují specifický HW (ne vše se dá pronajmout), stejně tak ti, kteří potřebují zajistit fyzickou bezpečnost infr. (např. certifikační autority) nebo ti, kteří potřebují poskytovat spolehlivé služby v různých lokalitách (i s dnešní rozšířeností globálních cloudů existuje řada slepích míst). V českých podmínkách to je zejména z důvodu historické návaznosti, není snadné udělat transformaci a přejít do cloudu. Krásný příklad je Moneta, u které se náklady na IT zvedly a částečná transformace trvala několik let
ad 3) miluji api a automatizaci, ale 100% api za mě dnes nemá nikdo koho znám...
ad 6) to ale pořád nemění nic na tom, že serverless je jen způsob zpoplatnění a nikoliv samotná technologie, která tady je již pěknou řádku let.
ad 7) těch use casů je celá velká řada, vůbec třeba AWS má velké nedostatky k sledování přístupu k datům jednotlivých uživatelů, často to chtěná funkce u klientů, stejně tak možnosti šifrování dat separátními klíči pro každou doménu dat jsou v řadě jejich služeb omezené nebo nefunkční. Souhlas s tím, že většinu projektů to pozvedne proti současnosti, ale také chce upozornit, že sposty home made přechodů do cloudů otevřou spousty nových cest
ad EBS Snapshots) údajně se řeší, že v některých formulářích byla "public" jako výchozí hodnota. Ano, chyba primárně admina, ale za mě je obrovský problém, že té chybě nelze snadno zabránit, nemohu jít jednoduše vynutit a pak tečou data, s chybami podobné úrovně je nutné počítat a mít kontrolní mechanismy, víceúrovňovou ochranu a nikoliv nechat jednu konfigurační chybu způsob tak obrovský problém.
ad 8) já také :). V kolika reálných nasazeních cloudu jsi to takhle viděl udělané? Opakovaně se setkávám s tím, že to někdo "vytočí" a tím to končí. Dělat si vlastní subscription v Azure pro každý projekt, abych to měl nějak vynucené je opruz vzhledem k těžké komunikaci s Azure supportem. Vynucování šifrování je opět velká bolístka, nepoužit ho je strašně jednoduché s neskutečnými vedlejšími náklady. Vede jen k jedné věci, k admin a api má přístup minimum lidí a dělají se vlastní aplikaci na správu cloudů, které tohle vše řeší. Za mě to jsou zbytečné náklady bez kterých zatím moc cest nevede.
Každopádně díky za odpovědi, jsou přínosné a věřím, že řada čtenářů aspoň částečně pochopí, že cloud je proces, který musí zvládnout.
Napsal Ondřeejj;1540014
Prosím o radu, jestli někdo nemá zmapované jaké české společnosti poskytuji managed Kubernetes as a service provozované na dedikovaných serverech, vlastních nebo zákazníkových (nesmí jít o sdílený public cloud).
A to takové, že tomu relativně dost rozumí, upgrade na vyšší verzi kubernetes zvládnou téměř bez výpadku (pří clusteru o 3 serverech) a nabídnou k tomu SLA?
Nevím o tom, Kubernetes mají zatím všichni velký problém zvládnout a neviděl jsem v ČR cluster, který by byl na dobré technické úrovni. To co poskytují velké cloudy jako containery vlastně ani kuberentes není, jen se to chová podobně. Ti co mají kubernetes privátně, to nějak zvládají (běží na tom u nás alespoň jedna banka s 24/7 provozem čtyř devítkovým sla). Náklady jsou na to ale vysoké, bez HW počítej v milionech za rok, proč to chceš? :)
Napsal Gav;1540087
Magické zaklínadlo bezpečnost. Mám na to jednu prezentaci, že je to nesmysl :-)
Každopádně existují situace (především specificke regulatorni požadavky), kdy to opravdu nejde.
Za mě je to strach z neznáma, neznalost na manažerské úrovni, strach dělat zásadní rozhodnutí. Pokud jde o ČR, je opravdu minimum věcí, které banka musí mít fyzicky doma, ale drtivou většinu může dát do cloudu. ČNB není proti a povolení dává, s legislativou to není v rozporu (musí to zůstat pouze v EU). Legislativní problém to je třeba pro certifikační autority, v současné době jsou některá nejasná ustanovení pro zdravotnická zařízení, velcí ISP opět musí mít zatím řadu věcí doma.
Řadu klientů, pro které pracuji ale brzdí kapacita linek a zajišťovat si privátní optiky je zatím i pro ně nad rámec rozpočtu. To je ale jen otázka času.
Napsal Registrace;1540088
Bezpečnost není zrovna validní argument.
Praxe docela jasně ukazuje, že bezpečnostní problémy mají spíše vlastní řešení, než služby typu AWS, Google Cloud, nebo Azure.
Řekl bych, že bezpečnost stejně visí na lidech, jak privátní věci, tak i cloud jsou na tom srovnatelně, u cloudu naopak je lepší možnost monitoringu a auditu. Opakovaně se setkávám s únikem HW (zejména disků) mimo zabezpečené prostředí a to se prostě blbě kontroluje, řětězec dodavatelů a techniků je příliš velký a příliš neřízený.
19. 8. 2019 09:48:12
Prodej
Více
