А вы зашлите бойца к нам в радио-т, мы с ним предметно все обсудим. Только не маркетингово специалиста, но технического. Обещаю сильно не ругать, только справедливо громить :)
Ох, сколько маркетингового шума. Может продукт и достойный, но меня доводы «как все плохо без него, но как хорошо с нами» не убедили. Я не понимаю, что такого сложного в развертывании TeamCity в облаке и на что там «Вы вынуждены будете тратить в месяц минимум 2 – 4 часа времени разработчика на обслуживание». Вообще там много такого… странного, например «В случае, когда вы сделаете 10 коммитов подряд, ваш open-source CI будет выполнять их последовательно» — это тоже, мягко говоря, неточно. Даже в бесплатном TC дают 3 агента которые будут запускать билды как пожелаете. Что касается выделения облачной мощности по необходимости, то и это прекрасно решается в TC и любом современном облаке. И цена вопроса не так, чтоб уж заоблачная. При вашем плане на 20 коммитов в день за $80 (на мой взгляд он совсем не «гигантский», но скорее «начальный») в виде более вменяемой альтернативы я бы поднял мелкий, но «разгоняемый» инстанс t2.medium, который обойдется в $37/м даже если его не тушить по ночам и не использовать reserved план. А на практике это будет ближе к $15/мес и коммить сколько влезет.
Конечно, когда не хватит бесплатного TC и за него придется платить, то там немалые $$$, но оно того стоит. Из вашего описания я не понял, что именно этот сервис умеет делать, а чего не умеет, но про TC все как раз понятно — он умеет много чего полезного. Ну и кроме того, нацеленность вашего продукта на рынок мелких/свежих компаний вполне позволяет его сравнить с бесплатной версией TC, который целится в ту же нишу.
конечно, задачи бывают разные. И если себе представить такую, при которой плотность использования 100% и все 24/7 — то тут хоть как-то можно притянуть логику сравнения цены своего сервера и арендованного и закрыть глзаа на все остальное. Но таких задач немного (мне не попадались), и даже весьма поулярные сервисы вроде Netflix и Instagram видимо выгоднее было (есть) держать в облаке. А уж для суровых вычислительных задач, когда нужна очень большая мощность на короткое время — тут врдое и спорить не о чем. И размер сервисов тут не так уж и важен. Да, некоторые большие энтерпрайзы строят свои собственные облака для того, чтоб упростить развертывание и увеличить плотнось использования, а некотрые не менее крупные — используют AWS и GCE.
Облачные сервера обычно не продают «штуками» т.е. это не аренда выделенного сервера, но аренда его части на какое-то время. При грамотно организованном процессе можно добится очень плотной загрузки арендовнной мощности именно на то время, что нужно. И есть крупные компании которые в этих облаках живут и все для них целесообразно. Это уж не говоря о том, что современное облако это не просто аренда вычислителных мощностей, но и целая куча прочих полезных сервисов.
Я вовсе не пример крупной компании, но у меня десятки «серверов» в облаках плюс целая куча всего, что в традиционном мире «своих мощностей» решается за отдельные деньги. Например разнесение серверов по нескольким континентам, хранилище с кучей девяток, распределители нагрузки, dns с географией и проверками, продвинутая система ограничения доступа и прав, несколько сетей с спецефическимми маршрутами, автоматические бэкапы всего на свете, автомтическое наращивание мощностей по необходимости и прочее и прочее. И для обслуживания всего этого хозяйства не надо штата бородатых адмнов.
Короче говоря, сравнивать цену покупки своего сервера с ценой за час * 720 * 365 в амазоне хорошо только если хочется доказать начальству «какие эти ваши облака отстой». Мой начальник тоже так считал, мол «мы можем купить свои сервера заплаитив один раз, будет дешевле». После того, как мы подняли полностью облачный проект в AWS за деньги меньше чем в своих датацентрах стоили 3 пустые стойки с интернетом, больше таких споров не возникает.
> Сам факт, что этот тоннель был проложен, в то время как железнодорожный тоннель строить не стали, говорит о многом – о том, что не так с современной Америкой.
Мне даже стало интерсно, а о чем именно это странное (мягко говоря) сравнение теплого с мягким говорит? О том, что у штата не оказалось достаточно денег чтоб не влезть в бесконечные проблемы, а у трейдеров деньги нашлись чтоб купить то, что им надо и это значит что? И как будет чтоб стало «как надо» с этой экоимикой? Забрать у трейдеров и железной рукой направить на железнодороные тоннели для народного блага? Воообще это популярный тут в последние годы тренд «мудрого перераспределения», и хотя с мудростью все пока невесело, но перераспределять это никак не мешает.
ну «должен» это вопрос того, чего вы страетесь достичь этим replica set. Например, если оба узла находяться в одном сегменте, то в принципе можно запустить арбитр на одном из узлов. Ну и в любо случае, для арбитра не нужен выделенный сервер, это легкий процесс.
3 ноды это минимум для того, чтоб отказоустойчивый replica set умел правильно определять лидера. Технически это может быть 2 настоящих узла и один легкий (арбитр).
позиция про помидоры называется словом конкуренция. Если помидоры в 4 раза дороже, то хочется узнать почему так, вдруг я действительно чего-то не понимаю. И если в ответ мне просто говорят — «потому что это самые помидорные помидоры» или «а у нас другие скоро запретят» то мое недоумение понятно. Очевидно, что они могут продавать по любой цене какой хотят, если есть покупатели, но в мире вокруг меня подобные продавцы хоть как-то пытаются пояснить, что именно в их сервисе/услуге элитного.
Ответ «там и покупайте» можно себе позволить только в том случае, если вам не очень интересен результат бизнеса и вся модель построена на факторах, далеких от экономики и конкуренции. Т.е. если всех клиентов нагнуть путем особой обязательной сертификации, запретов и прочего, то тогда можно и ценой не заморачиваться.
Я пытался понять, что в этом сервисе такого особого, что делает его таким удивительно дорогим. И пока никаких особенностей я не обнаружил и ответов не получил. Т.е. какие-то слова ответов я вижу, но они не складываются в технический и экономический смысл.
Каие-то у вас эфемерные плюсы. Вот вам SLA aws.amazon.com/ec2/sla/ а уж сколько девяток в S3 — это и не посчитать. Насколько я вижу, сегодня совсем трудно приходится облачным компаниям которые не могут конкурировать по цене с основными игрокам и по удобству с мелкими, но уютными. А у вас и дорого по цене, и бедновато по ассортименту и при этом не очень уютно, все на какие-то особые «Российские бизнесы» направленно.
Я не очень понял, что значит маркетинговая фраза «отвечать требованиям корпоративных клиентов», но EC2 инстанс, который видимо в вашем контексте вполне корпоративный, тоже будет сильно дешевле. Вообще за $39 в AWS можно купить t2.medium, с 4Г RAM и 2мя бурстабл ядрами и 20Г SSD.
1400 ($39) за одно ядро, 1г и 20HDD, и при этом 1М ограничение скорости? Ну тогда у вас там не простой, но золотой VPS, в 3.9 раза дороже чем в DO и при этом со смешным 1M.
Не знаю насколько плотно битбакетом пользуются те, кто хвалит изменения, но для рабочего варианта (т.е. приватные репозитории) это что-то ужасное. Нет то чтоб совсем кошмар, но форма уверенно побеждает смысл :( Какой светлой голове пришла мысль задвинуть в узкую правую колонку один из самых важных информационных потоков (там где изменения)? Мало того, что ее скукожили, так еще и обрезают комментарии к коммитам, ну чтоб аккуратно было. А то что смысл терятся — да какой смысл когда такая красота и все ахают. И с какого перпоя эта дикая идея занимать кусок экрана идиотским сообщением «ах, а у вас нет readme, как же так»? И кому в частных репозиториях надо все время видить эту огромную таблицу с бессмысленными для приватного репозитория числом фоловеров, форков и все прочего?
И это все при том, что у них уже с год сидят в очереди запросы на добавление элементарных групп, на поддержку Largefiles extension для hg и еще на массу полезного для работы. Но нет, они и сюда выкатывают шашечки, когде мне надо ехать. Вообще это у атласиана такой невеселый тренд наблюдается — сначала они функционально обезобразили SourceTree, а теперь «улучшили» и битбакет.
Здравый смысл и опыт работы с монгой подсказывают мне, что обьем памяти связан с размером данных+индекса. В моем тесте было памяти в 2 раза больше чем размер этого всего и удовлетворяло их «at least 1GB of main memory». Но любопытсва ради я проведу те же тесты в 4г и допишу, что получил
да у них там это через слово, практически. Все три пункта из www.tokutek.com/mongodb-performance/
И это вполне могло бы быть правдой и в том числе из-за меньшего обьема данных которые надо читать, из за организции их индекса и прочего. Хотя они мудро не приводят бенчамрков на чтение. На редите один чувак тоже спросил «а что так медленно доступ на чтение работает» и они не соглсились даже с тем, что может быть медленне на 10-20%. А тут в разы.
Кстати, выше по тексту я четко показал прирост в скорости записи. Не очень поимаю, почему бы вдруг если бы я это писал в реалтайм, то была бы ощутимая разница с тем, как я писал в тесте. Вообще «результат был бы в пользу последней и немаленький» в рассматриваемом случае это сферический конь в ваукуме. Не надо их писать быстрее чем они приходят и (в случае свечек) чаще чем раз в минуту. А то что надо писать, пишится с достаточной скоростью и в монгу. Ну и кроме того лок базы (у монги при записи) не факт, что хуже чем значительно большая нагрузка на cpu у току, с практической точки зрения.
4) Заходим в панель управления доменным именем domain.com и создаем поддомены, аналогичные названиям бакетов. В IN A записи прописываем Endpoint из настроек бакета.
Не уверен, что такое IN A на domain.com, но видимо это A record. В таком случае endpoint надо прописывать не в A но в CNAME.
Конечно, когда не хватит бесплатного TC и за него придется платить, то там немалые $$$, но оно того стоит. Из вашего описания я не понял, что именно этот сервис умеет делать, а чего не умеет, но про TC все как раз понятно — он умеет много чего полезного. Ну и кроме того, нацеленность вашего продукта на рынок мелких/свежих компаний вполне позволяет его сравнить с бесплатной версией TC, который целится в ту же нишу.
Я вовсе не пример крупной компании, но у меня десятки «серверов» в облаках плюс целая куча всего, что в традиционном мире «своих мощностей» решается за отдельные деньги. Например разнесение серверов по нескольким континентам, хранилище с кучей девяток, распределители нагрузки, dns с географией и проверками, продвинутая система ограничения доступа и прав, несколько сетей с спецефическимми маршрутами, автоматические бэкапы всего на свете, автомтическое наращивание мощностей по необходимости и прочее и прочее. И для обслуживания всего этого хозяйства не надо штата бородатых адмнов.
Короче говоря, сравнивать цену покупки своего сервера с ценой за час * 720 * 365 в амазоне хорошо только если хочется доказать начальству «какие эти ваши облака отстой». Мой начальник тоже так считал, мол «мы можем купить свои сервера заплаитив один раз, будет дешевле». После того, как мы подняли полностью облачный проект в AWS за деньги меньше чем в своих датацентрах стоили 3 пустые стойки с интернетом, больше таких споров не возникает.
Мне даже стало интерсно, а о чем именно это странное (мягко говоря) сравнение теплого с мягким говорит? О том, что у штата не оказалось достаточно денег чтоб не влезть в бесконечные проблемы, а у трейдеров деньги нашлись чтоб купить то, что им надо и это значит что? И как будет чтоб стало «как надо» с этой экоимикой? Забрать у трейдеров и железной рукой направить на железнодороные тоннели для народного блага? Воообще это популярный тут в последние годы тренд «мудрого перераспределения», и хотя с мудростью все пока невесело, но перераспределять это никак не мешает.
Я пытался понять, что в этом сервисе такого особого, что делает его таким удивительно дорогим. И пока никаких особенностей я не обнаружил и ответов не получил. Т.е. какие-то слова ответов я вижу, но они не складываются в технический и экономический смысл.
И это все при том, что у них уже с год сидят в очереди запросы на добавление элементарных групп, на поддержку Largefiles extension для hg и еще на массу полезного для работы. Но нет, они и сюда выкатывают шашечки, когде мне надо ехать. Вообще это у атласиана такой невеселый тренд наблюдается — сначала они функционально обезобразили SourceTree, а теперь «улучшили» и битбакет.
И это вполне могло бы быть правдой и в том числе из-за меньшего обьема данных которые надо читать, из за организции их индекса и прочего. Хотя они мудро не приводят бенчамрков на чтение. На редите один чувак тоже спросил «а что так медленно доступ на чтение работает» и они не соглсились даже с тем, что может быть медленне на 10-20%. А тут в разы.
Кстати, выше по тексту я четко показал прирост в скорости записи. Не очень поимаю, почему бы вдруг если бы я это писал в реалтайм, то была бы ощутимая разница с тем, как я писал в тесте. Вообще «результат был бы в пользу последней и немаленький» в рассматриваемом случае это сферический конь в ваукуме. Не надо их писать быстрее чем они приходят и (в случае свечек) чаще чем раз в минуту. А то что надо писать, пишится с достаточной скоростью и в монгу. Ну и кроме того лок базы (у монги при записи) не факт, что хуже чем значительно большая нагрузка на cpu у току, с практической точки зрения.
Не уверен, что такое IN A на domain.com, но видимо это A record. В таком случае endpoint надо прописывать не в A но в CNAME.