Vlákno názorů k článku Jak jsme dostali náklady v Amazon Web Services pod kontrolu od anonym - koupit mac mini je sice fajn...ale kdo se...
-
koupit mac mini je sice fajn...ale kdo se o nej bude starat? az nam jednou odejde disk den pred releasem a my budem bez mac mini, co potom? ten support okolo toho je fakt nutnost. Kdyz uz kupovat vlastni hw, tak koupit jeden mac mini a druhy mit v zaloze a byt pripraven v sobotu vecer zajet do kanclu a zasahnout.
-
Lukáš Lánský (neregistrovaný)
Můžete plýtvat peníze na buildu, nebo můžete plýtvat peníze, které nevyděláte, protože pak nemáte koule skutečně pracovat. Z pohledu manažera s poškozenými pobídkami ("hlavně aby to vypadalo levně", "hlavně aby se to nerozbíjelo viditelně", "zisky, které se mohly stát, ale nestaly, nejsou vidět") je samozřejmě výhodnější cost-cuttovat.
-
kazdopadne to porovnani se SAP Hanou me pobavilo :-) taky neznam nenazranejsi software. Chvili jsem s nim musel pracovat a dodnes mam z toho nocni mury.
naklady jsou to velke, to je bez debat...ale tady bohuzel trosku postradam srovnani. Moc firem neni schopno priznat, kolik davaji za infrastruktury pro buildy. Par lidi na twitteru priznalo, ze u nich plati za buildy vice (v prepoctu na vyvojare), ale vic nevim. Ted mam pred sebou buildy pro ios a to taky neni zadna levna sranda...clovek by rekl, ze jednoducha mobilni appka nepotrebuje velke stroje pro buildy, ale ono ne :-)
-
ded.kenedy (neregistrovaný)
co s tim ma spolecneho in-memory databaze od SAPu, ktera je narocna na pamet, potrebuje certifikovany hardware, ma silene drahou licenci od SAPu, horko tezko se rozjizdi ve virtualce ?
Promin, ale nenazranejsi software me opravdu uz nenapadl, abychom tu meli predstavu, kolik vykonu je potreba na sestavovani vaseho software o par set tisicich radcich.
my stroje skalujem. Ve spicce nam na chvili bezi klidne i tech 25 stroju
Skalujte si jak je libo, je to vas problem a vase penize. Osobne by mi ale bylo lito plytvat takove mnozstvi prostredku (penez, vykonu a el. energie) na tak pomijivou vec jako jsou testovaci buildy. Testovat je potreba, ale pokud potrebujes na build a testy vykon takoveho clusteru, hledal bych usporu penez v tech testech, buildech a organizaci, protoze to je prapricina tech nakladu.
-
ded.kenedy (neregistrovaný)
To jsou z velke casti cliche, i kdyz je na nich trochu pravdy. Otazkou zustava, jestli se tim da obhajit potreba clusteru, na kterem by se slusnou rezervou bezel SAP HANA pro mensi vyrobni podnik. Pokud chteji optimalizovat tyto naklady, vetsi prilezitosti bych hledal opravdu jinde nez v cenach za jednotlive instance.
-
Lukasi, ja jsem otevren napadum z venci. Mimo jine proto taky piseme o nasich problemech nas blog https://medium.com/zonky-developers
My vime, ze to nemame dokonale. Hledame prostor pro vylepseni, ktery u nas nezpusobi zastaveni vyvoje novych featur na nekolik mesicu. Pokud budete chtit, rad se s vami sejdu a poslechnu si, jak to delate vy.
-
Lukáš Lánský (neregistrovaný)
Bugy jsou velmi, velmi drahé, protože zvyšují neochotu organizace vyvíjet -- cena příložitosti featur, které se nestanou, protože se lidi bojí, že další vývoj dané části je rizikový, je tím vyšší, čím víc firma vydělává peněz. To je zrovna ta špatná korelace, žejo.
Dávat peníze za to, aby automatizované integrační testy běžely na každé změně kódu, je velmi účelné. Odmítat psát snadno paralizovatelné integrační testy, protože běží dlouho a zatěžují tak testovací infrastrukturu, je pro firmy, co vydělávají peníze, chyba.
-
ded.kenedy (neregistrovaný)
Dnes nám ve špičce běží až 25 strojů typu m4.4×large pro Jenkins
V prekladu: To jsou stroje 16 CPU + 64 GB RAM. Takze krat 25, to je celkem 400 CPU a 1.6 TB RAM, jenom na buildovaci nastroje.
Pro uplnost by se sluselo dodat velikost kodu, teamu, apod. ale v kazdem pripade mi to prijde brutalne predimenzovane a videl bych prostor pro optimalizace uplne jinde nez jsou naklady na AWS.