Комментарии 35
Источник:
Бизнес-завтрак Одноклассников, февраль 2017
Святая простота. Кто-то что-то взял… где-то попробовал, оно зачем-то до сих пор работает. Где-то… Короче, хорошее хранилище.
Если внимательно прочитать текст, то видно, что речь шла о конкретно версии 1.2. а так — хранилище неплохое, широко используются версии 0.6 и 2.0 ( сильно перепиленные для того чтобы работало хорошо ), общее число порядка 1000 нод ( в разных кластерах ).
Кассандра же работает по masterless quorum — то есть за «регион» в простейшем случае отвечают не менее 3 нод. При этом запись считается успешной, если большинство нод подтвердит запись. Соответственно, выход из строя одной ноды никак не влияет на работоспособность системы — может и принимать запись и читать. А при использовании спекулятивного ретрая — и на скорость работы системы не влияет.
Поэтому лучше сделать тест для своей задачи с реальными данными и сравнить самому как они быстро работают на важных для задачи кейсах.
> обязаны ждать консенсуса по каждой операции.
latency и производительности _чего_. И расскажите подробнее, что за консенсус происходит при чтении данных, учитывая что в HBase всегда один мастер для региона.
— Сейчас в индустрии понятие «архитектор» означает некоего человека с огромной головой, который всё всегда знает наперёд, естественно, давно отошедшего от дел и уже не марающего руки кодом. Его задача — раздавать указания тем, кто ещё не дорос до архитектора, максимум — рисовать квадратики, соединять их стрелочками. Как строительный архитектор, который рисует, но ничего сам не делает.
Мне запомнились слова тур гида на острове Крит:
Все считают архитекторов белыми воротничками в глянцевом офисе. На нашем острове пыльный архитектор в грязных сапогах носится по стройке, проверяет состав глины, качество блоков, контролирует всё. Потому что если дом по его проекту разрушится от землетрясения (землетрясения там часто бывают), когда соседские всё ещё останутся стоять — он больше заказов не получит. Карьере конец.
Еще есть неплохое рассуждение об архитекторах в книге Сэма Ньюмена «Создание микросервисов». Фрагмент:
Нужно признать, что после того как большинство создаваемых нами продуктов попадают к потребителям, мы вынуждены реагировать на все замечания последних и подстраивать продукты под них, поэтому нашу продукцию нельзя признать незыблемым творением искусства. Следовательно, архитекторам нужно избавиться от мысли о создании совершенного конечного продукта, а вместо этого сфокусироваться на содействии созданию программной структуры, в которой могут появляться подходящие системы, способные расти по мере более глубокого осмысления стоящих перед нами задач.
Так что это может быть мнение разработчика с хорошим опытом, чувством здравого смысла, ценящего ROI и разницу между профессиональным и чисто карьерным ростом.
Мне приходилось работать в команде с архитекторами, которые адекватно понимали свою роль и обязанности, активно принимая участие в разработке — трудно было переоценить их вклад в общий результат. К сожалению был и противоположный опыт, хорошо описанный в этом видео.
То есть выяснилось, что объём работы совершенно колоссальный. И если четыре года назад, когда Андрей начинал рассказывать про one-nio, зацепиться за это и начать делать из этого OpenSource, наверное, имело бы смысл, то сейчас подобных решений на рынке появилось довольно много и, пожалуй, этот момент уже упущен.
Например каких решений?
Эти много кто это обычно closed-world фреймворки, поэтому что раньше, что сейчас это несколько ортогонально к тому off-heap который дает one-nio. Я думал про сетевой стек и сериализацию. То есть какие-нибудь netty и protobuf/jackson. Ну, пожалуй они не стояли на месте 4 года, да.
Ром, ты же хорошо этот рынок знаешь. Как думаешь, имеет смысл сейчас им заниматься в плане маркетинга и опенорса или поезд уже уехал?
Глобальный open-source это рынок брендов. С Гуглом, Фейсбуком, Эпплом и Нетфликсом тягаться бесполезно.
Для русской аудитории, мне кажется, более чем есть смысл сделать доклад, где рассказать с техническими деталями, чем, допустим, HTTP-сервер из one-nio хорош и как его применить. Или какой-то другой компонент разобрать.
Какой-то странный когнитивный диссонанс возник по ходу рассказа. С одной стороны m0nstermind говорит, что они очень внимательно относятся к распределению знаний между людьми для исключения фактора трамвая, а с другой — выясняется, что тот-же one-nio нормально знает только apangin и для толкового документирования этой библиотеки нужно очень серёзно отвлекать автора. И тут же вопрос:"А зачем нам тратиться на оформления OpenSourse проекта?"
Не знаю как на счёт конкретно OpenSourse, но в целом подобного рода работа даже просто на уровне компании как раз и гарантирует качественное распределение знаний между сотрудниками. Т.к. если сторонний человек таки написал, например, документацию к проекту и у автора библиотеки не возникло к итоговому варианту претензий, то это значит что человек уже разобрался в проекте достаточно хорошо. Да автора отвлекать придётся. Но как ещё знания-то передавать?
А если ещё и по коду прилизать что-то корректно смог, то по поводу трамвая уже можно не так сильно париться :-)
А вот уже от OpenSourse можно получить бонус в другом плане: при поиске специалистов для найма. Если человек воспользовался библиотекой такого уровня в своём проекте и сделал это корректно, то он уже может являться хорошим кандидатом для привлечения в компанию. Возможно выхлоп от такого подхода будет ничуть не хуже, чем от организации конференций ;-)
P.S. Всё это чисто мои умозаключения. Возможно ложные.
P.P.S. Надеюсь не очень путано изложил свои мысли.
Но основная проблема в том, что OpenSource проект нужно продавать и рекламировать, а хорошие евангелисты (те которые доки делают, примеры и ездят по конфам ) так же редки как хорошие программисты, которые понимают в one-nio. А чтобы сразу и то и другое — то это вообще редкий фрукт. Поэтому, либо из хорошего программиста делать маркетолога/евангелиста, либо из маркетолога — программиста. Оба пути как вы понимаете имеют свои минусы ;-) В это имеет смысл вкладываться, если у вас бизнес вокруг этого построен — как у Spring, Cassandra, etc.
Как это влияет ( и влияет ли ) на найм, эффективнее ли это конференций — мне сложно судить. На ум приходит только пример с Disruptor — один их нишевых hpc проектов, чем-то похожий на one-nio, только значительно сильнее распиаренный. Готовы ли вы взять тех, кто его использует на работу делать высокочастотный трейдинг?
Возможно кто-то, у кого был и тот и другой опыт и может сравнить оба подхода и напишет свое мнение? Думаю всем было бы интересно.
Так что нет смысла слишком «опекать» one-nio — достаточно его упомянуть в блоге, в интервью или на конфе и все кому интересно скачают, прочитают, возможно (не) оценят и возможно (не) используют.
А пиар пошел дизраптору во вред… Сравните исходники первой версии и третьей…
Какой-то странный когнитивный диссонанс возник по ходу рассказа. С одной стороны m0nstermind говорит, что они очень внимательно относятся к распределению знаний между людьми для исключения фактора трамвая, а с другой — выясняется, что тот-же one-nio нормально знает только apangin и для толкового документирования этой библиотеки нужно очень серёзно отвлекать автора. И тут же вопрос:«А зачем нам тратиться на оформления OpenSourse проекта?»
Как всегда, глубже всех код понимает его автор. И one-nio — не исключение. Коллеги тоже понимают, но наверное не настолько супер-супер детально. Это совешенно нормальная ситуация для любого кода.
Не знаю как на счёт конкретно OpenSourse, но в целом подобного рода работа даже просто на уровне компании как раз и гарантирует качественное распределение знаний между сотрудниками. Т.к. если сторонний человек таки написал, например, документацию к проекту и у автора библиотеки не возникло к итоговому варианту претензий, то это значит что человек уже разобрался в проекте достаточно хорошо. Да автора отвлекать придётся. Но как ещё знания-то передавать?
Снова все правильно пишете. В долгосрочной перспективе компания заинтересована в том, чтобы код важной библиотеки знало как можно больше людей. Поэтому, в том числе, используется принцип, что человек не просит Андрея пофиксить библиотеку, а предлагает патч. И уже дальше с Андреем обсуждает, как этот патч сделать, чего этот патч стоит с точки зрения совместимости, перфоманса и т.п. Таким образом, знания шарятся внутри компании.
А вот уже от OpenSourse можно получить бонус в другом плане: при поиске специалистов для найма. Если человек воспользовался библиотекой такого уровня в своём проекте и сделал это корректно, то он уже может являться хорошим кандидатом для привлечения в компанию. Возможно выхлоп от такого подхода будет ничуть не хуже, чем от организации конференций ;-)
И снова классный вопрос. Ответ будет такой: тут экономику довольно сложно считать, потому что речь идет о довольно нишевом инструменте, и вопрос я бы ставил так: не будет ли вся эта деятельность по опенсорсу оверкиллом? Возможно, проше нанять толкового компетентного специалиста, который не знает конкретного фреймворка, но будет (за счет собственных компетенций) в состоянии разобраться с ним. Учитывая, что фреймворков становится все больше и больше, мне этот подход нынче видится более правильным — искать умного и способного разобраться вместо того, чтобы искать того, кто уже и сразу умеет то, что нужно. Потому, что подход с умным — более универсальный, чем подход со знающим конкретный тул. Он банально позволяет не зависить от тула.
«Сложную архитектуру очень просто сделать» — интервью с Олегом Анастасьевым из Одноклассников