Prodej módní značky DANNYS clothing
Stránka 2 z 2 PrvníPrvní 12
Zobrazují se odpovědi 31 až 35 z 35

V ČR existují přibližně tři domácí poskytovatelé cloudu

  1. Citace Původně odeslal Gav Zobrazit příspěvek
    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.


    Citace Původně odeslal Ondřeejj Zobrazit příspěvek
    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š? :)

    Citace Původně odeslal Gav Zobrazit příspěvek
    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.

    Citace Původně odeslal Registrace Zobrazit příspěvek
    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ý.

  2. Co se právě děje na Webtrhu?
  3. Citace Původně odeslal TomášX Zobrazit příspěvek
    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š? :)
    Máme kubernetes hosting u větší společnosti, která jej veřejně nabízí jako managed službu, ale nejsme spokojeni se servisem. Podpora sotva umí spravovat nginx/apache a ukázalo se kubernetesu ve skutečností nerozumí a učí se za běhu na nás na produkci.
    Výsledek je, že při každém upgrade kubernetes clusteru je výpadek aplikace i přes 60 minut a to máme 3 servery kvůli HA. Není potřeba čtyř devítková dostupnost za miliony, to už je mimo rozpočet.
    Ozvali se mi do PM společnosti, které tuto službu plánují brzo spustit, tak se snad časem vytřídí kvalitní poskytovatelé.

  4. Citace Původně odeslal Ondřeejj Zobrazit příspěvek
    Máme kubernetes hosting u větší společnosti, která jej veřejně nabízí jako managed službu, ale nejsme spokojeni se servisem. Podpora sotva umí spravovat nginx/apache a ukázalo se kubernetesu ve skutečností nerozumí a učí se za běhu na nás na produkci.
    Výsledek je, že při každém upgrade kubernetes clusteru je výpadek aplikace i přes 60 minut a to máme 3 servery kvůli HA. Není potřeba čtyř devítková dostupnost za miliony, to už je mimo rozpočet.
    Ozvali se mi do PM společnosti, které tuto službu plánují brzo spustit, tak se snad časem vytřídí kvalitní poskytovatelé.
    já se ptal jen proto, jestli bys nemohl použít jiné technologie a proč zrovna kubernetes, který je na provoz dost složitý. Nevypadá to, že bys měl tak velký počet serverů, aby se ti to vyplatilo.

  5. Citace Původně odeslal TomášX Zobrazit příspěvek
    já se ptal jen proto, jestli bys nemohl použít jiné technologie a proč zrovna kubernetes, který je na provoz dost složitý.
    Aplikace je architektura s desítky microservices. NodeJS a PHP. Kontejnery v dockeru. Je potřeba řešit service discovery. Kubernetes byl zvolen jako best in class open source technologie pro orchestraci kontejnerů. Pro vývovaře snadné ovládaní pro přidání služby a celý deployment aplikace. Na provoz kubernetes stačí jedna binárka a 5 kontejnerů, o které se stará poskytovatel managed kubernetes hostingu. Že to je i pro linux sysadminy dost složité provozovat se ukázalo za běhu.

  6. tenhle scénář vídám poslední dobou často. Dva klienti přešli místo kubernetes na Mesos, ale o moc si nepolepšili, u jiných zase teď implementujeme CoreOS. Kubernetes zažívá obrovskou rozvoj, má přes milion řádků kódu a spousty jich se mění každý půl rok (což je asi 8x více než má docker samotný), spousta pluginů a rozšíření nejsou dostatečně testována pro všechny případy, debugování na provozu je složité atd. Výsledek je drahý provoz, potřebuješ na to schopné lidi, kteří znají aspoň trochu go a sledují to, čtou manuály.

    Snad se ti ozve někdo, kdo s tím opravdu umí. Bez detailnějších informací ti asi víc neporadím. Snad jen, že tyhle služby pro microservices poskytují velké cloudy (tady ve vlákně několikrát zmíněny) celkem běžně a bezproblémově, kdybys obětovat vlastní HW a umístění v ČR, měl bys to s méně starostmi.

Stránka 2 z 2 PrvníPrvní 12
Hostujeme u Server powered by TELE3