Так никаких холиваров, я знаю что многие (точнее некоторые) стартапы используют эту связку, и да, Visual Studio — действительно одна из лучших IDE. У нас более миллиона уникальных посетителей в день, async фичи MVC4 используются для работу SOA Api, в частности. Все дело в масштабе, и когда он большой — очень легко принять страх перед багами mono за какую-то реальную проблему, поэтому никто не рискует. Да и как мы все уже поняли, что то что было когда-то стартапом в идеале должно быть переписано раз 5 до близкого к «более чем хорошему» коду, а это значит что придется изобретать велосипед почти каждый раз (создавать что-то лучшее чем было до этого). Короче говоря говнокод который делал деньги будет выкинут, а новый продукт/ проект будет переписан на Scala/Akka и, надеюсь будет делать еще больше денег в неблокирующем режиме :)
У нас смешанная архитектура, и я печалюсь когда смотрю в сторону контейнеров LXC и Docker, а также тонну модулей puppet/chef/ansible которые написаны только под Linux и скрипя сердцем продолжаю знакомить Windows с миром opensource (что-то вроде этого и этого). Для DevOps как я — Windows это не выбор, это данное «свыше». Но в тех проектах где есть выбор я не посмотрю в сторону Windows, потому что экосистема совсем не та…
Бред это. Я работаю в .net компании, и как мы не печалимся о том что мы .net — перейти на mono никак не можем, a все потому что compatibility. Я не спорю, список выглядит намного лучше чем год назад, но скажите, какой смысл идти по пути «совместимости» если Вам нужно зарабатывать деньги, или у Вас есть время на отлов багов Mono? Сейчас, когда мир Unix развивается гораздо быстрее чем мир Windows, ИМХО вообще нет смысла касаться технологий от MS — всегда будете отставать в «развитии». И это только потому, что основа всего — проприетарная, в отличие от Java, где каждый компонент открыт (не считая закрытых реализаций Oracle).
По поводу статьи — спасибо, приятно почитать, но интересна причина выбора именно .net? Почему тот же python, node или даже Java? К примеру Вы смогли бы хостить Ваше чудо на raspberry pi или dd/openwrt.
Я работаю с Mongo уже года 3 и вот что решил для себя: MongoDB не так хороша в действительно BigData средах. «Простота» горизонтальной масштабируемости несколько преувеличена. Возьмем тот же Elasticsearch, где для добавления новой железки в кластер Вам нужно просто указать имя кластера на новой железке. Что предлагает нам Mongo? Давайте посчитаем, скажем, кластер из 20 физических серверов: Минимум 3 Конфиг ноды, Минимум 10 арбитров на другом железе/vm. При этом, если живем в реальных условиях скорее всего придется поднимать конфиги на том же кластере, а если еще хотим побороть глобальный лок (а мы хотим), то придется делить RAID на несколько томов, что повлечет за собой несколько инстансов mongod на одной машине, что в свою очередь означает строгую последовательность портов дата нод, в которую добавляем конфиг ноды и арбитры для дата шардов на другом железе. В итоге все это выливается в сложную систему, для обслуживания которой каждый раз вчитываемся в документацию чтобы ненароком не добавить реплику в неверный шард =)
У меня лично нет проблем с чтением документации, это сухое сравнение фактического пути достижения по сути одной цели.
Это поведение по умолчанию. slaveOk=true делает возможным чтение со слейва. Но это далеко не всегда принесет пользу — скорее всего будет race condition при проверке вашем приложении. (создать запись -> запись создана?): Запись не будет еще реплицирована к этому моменту.
А вот это замечательное дополнение! :) И я, кстати, ничего не увидел про ограничение на родственников, только то что если получатель знает что отправители могут как-то иметь отношение к друг-другу, тогда сумма считается совместно.
virusman прав, именно вычетается.
Также по закону США если у Вас сумма на зарубежных счетах превышает $10 000 в любое время то Вы обязаны информировать IRS о всех зарубежных счетах.
Еще на заметку, по законам США ближайшие родственники могут Вам переслать до $14 000 в год без налога, то есть если у гипотетической семьи здравствуют все 4 родителя то это $56 000 в год.
Интересный факт, что даже если гражданин США не является резидентом страны (к примеру живет в России) он все равно обязан платить прогрессивный налог на доход (10-40%).
Возьмите хотя бы климат, метеочувствительные люди сразу отмечают разницу в самочувствии, а все потому что погода почти не меняется и давление атмосферное не скачет (но с таким же успехом можно рассматривать ту же широту в Европе). К этому можно добавить удобный срок возврата товара по любой причине (30 дней), в большинстве добрых и отзывчивых людей которые довольны своей жизнью и могут безвозмездно помочь Вам, огромное количество IT компаний, пляж тихого океана, кому-то понравятся послабления в некоторых законах и дружественные полицейские. Интернациональность и толерантность. Множество реальных факторов. Конечно, Калифорния — это не весь мир, и достаточно мест с пускай не всеми, но схожими характеристиками. Но все же, согласитесь, общее сочетание преимуществ ведь неплохое? :)
Спасибо за статью, интересно почитать. Но вот с жильем вы неравноправно сравнили, возмите более объективные цены на недвижимость и фотографию того же места зимой и сразу станет ясно что к чему (снег, холод против солнца и тепла, Мериленд / Калифорния). Расскажу небольшую историю. Мне как-то предлагали работу в RackSpace (один из лидеров хостинга в штатах), у которого штаб-квартира в техасе. Кстати, интересный факт — они выкупили заброшенный завод и сделали это достаточно здорово . В то время я работал в небольшом стартапе (около 50 человек), поддерживал всю инфрастуктуру и касался очень многих технологий, чему был очень рад. Мне предложили хорошую зарплату по меркам техаса (Сан Антонио), но по меркам Los Angeles она была грустновато-низкая. Я отказал им по следующим причинам 1. Низкая зарплата — даже принимая во внимание факт что жилье и стоимость потребительской корзины в Сан Антонио намного ниже, 2. Плохой климат — в техасе жарко и влажно летом и холодно зимой, к сожалению техас не сравнится с Калифорнией. 3. Корпоративная среда, пришлось бы стать винтиком в системе RackSpace, а это серьезно сузит кругозор, чего я делать совсем не хочу. В итоге я остался в своем стартапе в Санта Монике и ничуть не жалею, сейчас часть крупной компании с офисом в Маунтин Вью (через дорогу от гугловского)… Пару раз бывал в Сан-Франциско, и, честно сказать, мне LA больше нравится. А вот такое предложение Вам: переводитесь в офис в Irvine или Venice, тут с жильем проще! А лучше переводитесь к нам, и будет Вам баланс и счастье! (серьезно) :)
Еще один минус кирпича — он сейсмонеустойчив. Заметьте многие здания начала 20 строились из кирпича, а после множества сильных землетрясений дома стали строить сейсмоустойчивые — бетон, гипсокартон и дерево.
Мы используем MongoDB во многих местах, в том числе кластером в 18 нод, и все бы ничего, быстро работает, true NoSQL, и Бог бы с глобальным локом — обходим ограничение несколькими RAID массивами… Меня удивляет сам факт того, что во времена автоматического шардинга и распределения реплик в том же Elastic Search мне приходится каждый раз читать свою же документацию о том, какие ноды что делают при необходимости обслуживания (читай — добавления нод). Приходится вчитываться в нее полностью, вспоминать зачем на одной машине на разных портах висит 3 mongod, а на другой это 6 mongod (в первом случае это 3 data ноды, во-втором это может быть комбинация дата нод, арбитров и конфиг серверов). Не поймите меня не правильно, проблем с чтением документации у меня нет, но есть частичные притязания к идеализму в архитектуре, а также относительно большой опыт работы с другими системами, в том числе Elastic Search, где для горизонтального масштабирования кластера мне всего лишь нужно у новой ноды указать имя кластера. Кстати, наши ребята Alex и Jeff были на Mongo World в качестве участников и рассказывали про кластер с текстовыми файлами (всего 8 нод в шарде/реплике) который заменил систему c веб сервером который раздавал те же файлы но с файловой системы, но они не упомянули о том кластере в 18 нод, который мы со свистом отправляем на пенсию. Стало невероятно сложно отслеживать баги, особенно бесит когда конфиг нода умирает, но никому ничего не говорит, даже процесс и демон висит как ничего не бывало :) В итоге одна из шардов у нас разбухла до 99% на диске, в то время как соседние были ~30%. Раз пять за 3 месяца перезапускал балансировщик, ресинхронизировал реплики, через некоторые время опять та же история. В итоге мы фиксим баги в архитектуре, а точнее с нуля пересоздаем всю систему, но уже в этот раз Монга там только как одна из систем хранения (+Elastic Search +Cassanda), а реал тайм обеспечивается Kaffka pub/sub. В общем что хочу сказать, Монго — это хорошо, но здесь магии нет и на поддержку более-менее сложной архитектуры придется потратиться. Надеюсь что нововведения решат эту проблему и магия Mongo снова будет с нами!
Спасибо за статью.
Хорошей практикой является ставить mongos прокси на клиентские машины (Web, App сервер). Таким образом Вы уменьшаете количество хопов на 1 для Вашего клиента. Также я бы рекомендовал использовать порты отличные от стандартных 27017 для шардов, т.к. ненароком какой-нибудь невнимательный разработчик сможет к ним случайно подключиться и убить всю балансировку. Лучше смените их на 27020 и 27021 для каждого шарда и в дополнение поставьте по mongos на каждый из них, чтобы не задавали лишние вопросы (на случай если клиентская машина не имеет mongos).
В дополнение могу сказать что очень рекомендую использовать системы управления конфигурациями для кластеров, экономит время на правку init скриптов, а часто и на конфигурацию самого кластера. Например puppet.
На мой взгляд ITIL эффективен когда Вы не планируете частых сильных сдвигов в инфраструктуре: т.е. Вы определились с процессом, определились с технологиями и все что делаете — наращиваете мощности. Если Вы хотите оставаться гибким и строить динамичную компанию — ITIL это лишнее препятствие. ITIL, как и почти любой «оптимизированный» процесс или система процессов устроен против природы человека. Если речь об IT (именно админство, DevOps) идет как о ключевой части бизнеса (IT аутсорс, к примеру) — это идеальное решение для интерфейса с клиентом. Если же это IT отдел небольшой компании в 50 — 100 человек, в котором 10 админов и пара руководителей — то ИМХО это перебор. Работал в двух диаметрально-противоположных компаниях, и я убежден что сила в Agile, а не в процессах. Как сравниваю? По фактическим достижениям и прибыли :) Да, падает, да паника, но за это время в Agile проходит десять итераций, а в процессной модели одна. И оказывается что мы построили идеальный процесс, а он оказался не нужен. Почему? Потому что продукт который мы делали — дерьмо. Следующая интерация? Да, начнем с описания процесса и отслеживания каждого изменения! :) Я за Agile! Ну или хотя бы за микс, если это необходимо.
Спасибо за пост, было интересно почитать. Работаю в Intuit (8 в Top 100 лучших компаний), под 10 000 сотрудников. Подписываюсь под каждым словом. Но что мне нравится у нас, что здесь очень сильно поощряют инновации. Очень легко выбить время и инструменты для какого-то нового, совершенно безумного проекта, который поможет решить ту или иную проблему.
Сильно соглашусь про умение убеждать — это прямой путь к достижению цели в таких корпорациях (ну, в дополнение к прямым скиллам и таланту, конечно). Бенефиты не сравнятся, к примеру я был удивлен что нам дают $800 в год на фитнес, и это учитывая что в большинстве офисов есть бесплатные спорт-залы с душевыми, шампунем и чистыми полотенцами. Из минусов — процессы и регламенты жутко нудная штука, но, похоже с этим сильно борются — внутри компании создаются «мини-стартапы», которые идут по несколько другому, более быстрому пути. И самое прекрасное что никто не навязывает ни стек ни хостинг платформу: Обсуждаешь бюджет в плане цифр, бизнес кейс и все: вперед на следующий месяц или два! И все это с корпоративными инструментами, включая MBP Retina, телефоны, айпады и прочее. Соглашусь что это очень сильно расслабляет, но именно здесь всегда есть возможность озвучить и «протолкнуть» свою идею, особенно если это прямое влияние на бизнес. В моем случае с этим немного сложнее, потому что работа DevOps редко влияет напрямую, а в большинстве ситуаций — вообще не влияет. В Front End и Back End не трогаю ничего кроме конфиг файлов, и все это, естественно СТРОГО в рамках моей группы или даже проекта. Вот такие две стороны. Еще раз спасибо за пост!
Автор, есть ли шанс увидет Вас на гитхабе? У меня есть подобный скрипт на php с поддержкой разных трекеров, хотелось бы приобщиться к python и поконтрибьютить :)
Делаем похожее с opsview и pushover. Pushover умеет выбирать звуки для уведомления, но не умеет отправлять изображения, как pushbullet. В остальном — api очень схожи.
Из плюсов — у Pushover есть приложение для iOS,
Из минусов — приложение «немного» платное.
У нас похожая ситуация, ориентировочно то же количество нод. Хотим переехать на ElasticSearch — есть сила lucene, и не нужно поддерживать собственное решение, которое выходит достаточно затратно по ресурсам. Предварительные бенчмарки показывают схожую или превосходящую производительность системы. И да, наше решение на C#, что сразу вовлекает большие деньги на Enterprise Windows с возможностью использования достаточного объема памяти, в то время как Elastic Search создан для *nix.
У нас смешанная архитектура, и я печалюсь когда смотрю в сторону контейнеров LXC и Docker, а также тонну модулей puppet/chef/ansible которые написаны только под Linux и скрипя сердцем продолжаю знакомить Windows с миром opensource (что-то вроде этого и этого). Для DevOps как я — Windows это не выбор, это данное «свыше». Но в тех проектах где есть выбор я не посмотрю в сторону Windows, потому что экосистема совсем не та…
По поводу статьи — спасибо, приятно почитать, но интересна причина выбора именно .net? Почему тот же python, node или даже Java? К примеру Вы смогли бы хостить Ваше чудо на raspberry pi или dd/openwrt.
У меня лично нет проблем с чтением документации, это сухое сравнение фактического пути достижения по сути одной цели.
Также по закону США если у Вас сумма на зарубежных счетах превышает $10 000 в любое время то Вы обязаны информировать IRS о всех зарубежных счетах.
Еще на заметку, по законам США ближайшие родственники могут Вам переслать до $14 000 в год без налога, то есть если у гипотетической семьи здравствуют все 4 родителя то это $56 000 в год.
Интересный факт, что даже если гражданин США не является резидентом страны (к примеру живет в России) он все равно обязан платить прогрессивный налог на доход (10-40%).
Хорошей практикой является ставить mongos прокси на клиентские машины (Web, App сервер). Таким образом Вы уменьшаете количество хопов на 1 для Вашего клиента. Также я бы рекомендовал использовать порты отличные от стандартных 27017 для шардов, т.к. ненароком какой-нибудь невнимательный разработчик сможет к ним случайно подключиться и убить всю балансировку. Лучше смените их на 27020 и 27021 для каждого шарда и в дополнение поставьте по mongos на каждый из них, чтобы не задавали лишние вопросы (на случай если клиентская машина не имеет mongos).
В дополнение могу сказать что очень рекомендую использовать системы управления конфигурациями для кластеров, экономит время на правку init скриптов, а часто и на конфигурацию самого кластера. Например puppet.
Сильно соглашусь про умение убеждать — это прямой путь к достижению цели в таких корпорациях (ну, в дополнение к прямым скиллам и таланту, конечно). Бенефиты не сравнятся, к примеру я был удивлен что нам дают $800 в год на фитнес, и это учитывая что в большинстве офисов есть бесплатные спорт-залы с душевыми, шампунем и чистыми полотенцами. Из минусов — процессы и регламенты жутко нудная штука, но, похоже с этим сильно борются — внутри компании создаются «мини-стартапы», которые идут по несколько другому, более быстрому пути. И самое прекрасное что никто не навязывает ни стек ни хостинг платформу: Обсуждаешь бюджет в плане цифр, бизнес кейс и все: вперед на следующий месяц или два! И все это с корпоративными инструментами, включая MBP Retina, телефоны, айпады и прочее. Соглашусь что это очень сильно расслабляет, но именно здесь всегда есть возможность озвучить и «протолкнуть» свою идею, особенно если это прямое влияние на бизнес. В моем случае с этим немного сложнее, потому что работа DevOps редко влияет напрямую, а в большинстве ситуаций — вообще не влияет. В Front End и Back End не трогаю ничего кроме конфиг файлов, и все это, естественно СТРОГО в рамках моей группы или даже проекта. Вот такие две стороны. Еще раз спасибо за пост!
Таким образом весь текст становится unicode, если не укажете что он b'текст'
Из плюсов — у Pushover есть приложение для iOS,
Из минусов — приложение «немного» платное.