Мини-интервью: Виктор Гамов

Среди интервью с JPoint 2017 разговор с Виктором Гамовым — самый короткий, но и в этом случае тоже интересно сравнить «тогда» и «сейчас». На момент интервью Виктор был широко известен как сотрудник Hazelcast, топил за in-memory computing, всё это находило отражение в его докладах — и мы как раз задали ему пару вопросов об этом. А теперь, год спустя, он приезжает на JPoint 2018 уже как представитель «грефневой» Kafka, и в новом докладе совместно с Барухом Садогурским будет использовать Apache Kafka для «поиска русских хакеров».

Руслан: С нами Виктор Гамов, сооснователь подкаста «Разбор полётов», человек и Hazelcast. Ты на этой неделе уже дважды выступил на Java- конференциях, JBreak и JPoint, и с первой уже получил фидбек. Расскажи, каковы твои чувства в связи с ними?

Виктор: Я как правильный маркетолог должен принять фидбек и на его основе как-то изменить, улучшить свой доклад. Мне в фидбеке говорили, что были непонятные места в теме или подаче темы, поэтому мне пришлось показать прямо со сцены, что я думаю о фидбеках!

На самом деле всё это полезно. Мы читаем всё, что вы пишете. И нет такого «я сейчас прочитаю негативный фидбек и обижусь», ну здравствуйте, я большой дядя. Благодаря отзывам, когда в следующий раз будешь готовить доклад, будешь знать, что заходит, что не заходит — а это важная информация. Отправляйте её спикерам, это для них важно.

Лучше получить много негативных фидбеков, чем вообще никаких. При их отсутствии ощущаешь «Вообще, что ли, никого не зацепило?» Когда нет реакции, получается, что ты просто потратил своё время и людей. Поэтому фидбеки — это очень хорошо.

Руслан: Ты работаешь в Hazelcast и рассказываешь про него. Когда ты готовишь доклад, ты хочешь показать, как Hazelcast крут в решении каких то задач, или о том, что есть какой то комплекс задач, который решается с помощью Hazelcast? Не знаю, понятным ли получился вопрос.

Виктор: Понял вопрос. Моя идея заключается, во-первых, в том, чтобы рассказать, какие есть проблемы. Зачастую перед тем, как придумать какое-то решение, нам нужно понять проблему. Может быть, овчинка не стоит выделки.

Во-вторых, когда я говорю о каких-то технологиях, то опираюсь на наш опыт в реализации конкретных проектов. Те вещи, о которых я рассказываю, я видел у живых людей в работе.

И если я при этом использую технологию Hazelcast — ну да, я просто работаю с этой технологией и не вижу ничего зазорного в том, чтобы рассказать, как опенсорсный проект может решить проблемы в сфере scalability, распараллеливания вычислений, шардирования разноса данных по разным машинам, создания большого хранилища данных, и так далее.

Зачастую, когда делаешь абстрактный доклад о каких-то теоретических основах, это одно, а когда ты делаешь доклад как решение, люди видят практический опыт. Один из поводов для критики докладов заключается в том, что «ты работаешь в Hazelcast и не расскажешь всё по чесноку». Это неправда. Я всегда говорю честные вещи: если я вижу, что моё решение не подходит сценарию, о котором люди спрашивают, то говорю, что не надо использовать его, вы получите больше проблем, можно решить другими способами. То есть у меня нет проблемы посоветовать что-то другое.

Ещё часто спрашивают, почему я про GridGain ничего не рассказываю, а что я расскажу? Ну, есть GridGain.

Евгений: Есть GridGain, есть Hazelcast, а есть in-memory computing в целом. Про него можно услышать, что если сейчас это нишевое решение, то со временем оно будет становиться всё более мейнстримовым и дефолтным — что можешь сказать?

Виктор: Выглядит всё достаточно хорошо. Cистемы, которые сейчас известны и гремят среди разработчиков, те же Redis, memcached — это системы, которые используют память из основного хранилища. Да, понятно что юзкейсы там могут быть ограничены каким-то кэшированием, потому что потерять кэшированные данные не страшно. А когда ты используешь in-memory operational store, когда у тебя данные в памяти как база данных, то тут ты начинаешь задумываться, чтобы не потерять продуктовые данные.

Но всё идёт в правильном направлении, развиваются сетевые технологии, которые позволяют быстрее обрабатывать. Потому что в системе распределённых вычислений сеть, которая является устойчивой — это ключевой аспект. И построение систем, которые умеют работать на полную катушку, используя возможности памяти, а если надо что-то сохранить на диск, то сохранить на что-то быстрое, на какую-то флеш-память, например. В in-memory мы получаем доступ к данным оперативно и унифицировано по скорости, потому что нам нет этого доступа, когда «иголка должна по блину пробежать». И с экономической точки зрения все технологии, в том числе память, дешевеют.

Десять лет назад я потратил всю стипендию на флешку объёмом один гигабайт, чтобы подарить своей будущей жене на 8 марта. Сейчас один гигабайт — это даже не смешно, даже в облаке столько не дают, потому что это мало. Технологии шагнули дальше.

По-моему, у Артура Кларка была фраза (примечание jug.ru: на самом деле у Уильяма Гибсона!), что будущее уже наступило, но оно неравномерно распределено. И вот мы занимаемся тем, что равномерно его распределяем.