Темы четырнадцатого выпуска: как убедить джавников и .NET-чиков перейти на функциональные языки, история создания веб-фреймворка N2O, проекты Erlang on Xen и Voxoz.com, а также Functional programming Meetup, который состоится в Москве 16-го августа 2014. Предыдущие выпуски: тринадцатый , двенадцатый , одиннадцатый , десятый .

Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/14/

Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/14/file/podfm_eaxcast__eaxcast_207.mp3

Шоу нотес:

• Блог Максима в Живом Журнале;
• Synrc research center;
• Проект voxoz.com и его исходники на GitHub;
• Встреча функциональщиков в Москве 16-го августа 2014;

Голоса выпуска: Максим @5HT Сохацкий, Валерий @sum3rman Мелешкин, Сергей @kpy3 Елин, Александр @afiskon Алексеев

Фоновая музыка: The Panets — Winter Beats (Big Power Mix)

А: Всем привет, это EaxCast, второй сезон седьмой выпуск. Я afiskon, со мной здесь в подкасте kpy3. Привет.

С: Привет.

А: Это sum3rman.

В: Привет.

А: И наш гость — Максим 5HT Сохатский.

М: Здравствуйте ребята.

А: Привет. Мы же обещали позвать Максима, ну, вот, мы и позвали. Максим, традиционный вопрос, который… Ну, ты ж слушал наши предыдущие выпуски?

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

А: Ну, вот, традиционный вопрос, мы его всем задаем. Объясни нам, пожалуйста, пирамидальную сортировку.

[смеются]

М: Это хорошая шутка.

А: Расскажи нам о себе.

М: Я долго занимался .NET — 10 лет работал в enterprise, мы скриптовали на самописных лиспах gui формы, автоматическое построение делали этих форм из самописного Hibernate. Его еще тогда не было в 2001 году, только начали ребята импортировать Hibernate из Java на .NET. В общем, и так я страдал очень долго, буквально, до недавнего времени. Еще успел поработать на Java несколько лет и, в целом, имею такой вот опыт в наблюдении за тем, чем занимаются люди в бодишопах . И последние 3 года я полностью переключился на Erlang . Я ушел в свободное плавание, мы сделали с моими друзьями компанию и выполняем различные заказы для наших клиентов и для этого используем исключительно Erlang. Мне есть, что рассказать про Erlang в том ключе, что я могу сравнить, как, допустим, люди работают в enterprise, используя мейнстримные утилиты, инструментарий и языки программирования, и как мы можем облегчить их жизнь. Мы таргетируем свои продукты для программистов, которые выходят из enterprise. Вот, и я думаю, что в таком ключе было бы неплохо провести всю нашу беседу.

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

М: Ничего такого супер уникального нет, все, в целом, есть похожие апликейшн стеки в Clojure, в fpcomplete на Haskell . Люди все пытаются сделать свою удобную платформу, каждый лиспер начинает писать свою платформу. Все с этим знакомы. Чтобы рассказывать про нашу платформу, нужно, так или иначе, проводить какие-то аналогии с другими существующими платформами. Обычно я это делаю с enterprise платформами и провожу такие аналогии для того, чтобы наши заказчики, которые enterprise ориентированы, мы для них предоставляем наши услуги. Но можно проводить аналогии и с другими платформами, я так чувствую, что на Erlang можно поставлять платформу, которая была бы, что называется, самого низкого уровня, начиная с процессора и заканчивая высокоуровневыми приложениями, Мы можем полностью предоставить full-stack Erlang applications от процессора, заканчивая какими-то поисковыми системами либо web-приложениями. В целом, это что-то напоминает, вот, как раньше были lisp-машины, Symbolics, Lisp Machine International. Мы хотим, чтобы Erlang в этом смысле реинкарнировал вот эту концепцию единой инфраструктуры.

С: А с какими платформами обычно приходится сравнивать?

М: Обычно я провожу параллели со Spring’ом. Я показываю на своих тренингах, людям которые работают в enterprise, как используя наш Erlang стек построить простые сервисы и приложения. Как они уже строят это все на .NET и на Java, за счет того, что у меня большой опыт в этом, я могу на их языке сказать им, как они могут заменить те или иные библиотеки, подходы в Erlang мире.

А: Сорри, что я перебил. То есть, в N2O у тебя тоже аннотации, программирование на XML…

М: Я полностью заменяю эти вещи, у нас нет XML, у нас нет текстовых протоколов, мы стараемся исключить или минимизировать использование JSON. Если JSON есть, он там типизирован, мапится в Erlang record. Везде, где только можно, мы навязываем свои альтернативы, которые более минималистичны, и которые более управляемы с нашей точки зрения.

С: Скажи, а как начиналась твоя компания и вообще проект?

М: Компания достаточно древняя, в кавычках. Она была зарегистрирована в 2005 году, но она начала быть Erlang компанией буквально несколько лет назад, 3 года. И, вот, когда я начал работать на Erlang для выполнения конкретных проектов, я нашел то, что все библиотеки не в одном стиле сделаны. Вот так, чтобы кому-то показывать Erlang или библиотеки Erlang, и показывать, как строить приложения на Erlang, зачастую не хватает какого-то клея. Все использовали разные системы сборок, благо хоть какой-то rebar есть, что хоть какая-то видимость стандарта есть и можно было все это как-то облагородить. И я решил, что рано или поздно мне нужен будет буквально год, и я бы сделал что-то такое очень компактное, красивое, чтоб можно было быстро строить приложения для своих же заказчиков. По сути, я создал платформу, чтобы минимизировать расходы для наших заказчиков. И когда мы столкнулись с ограничениями и ошибками в Nitrogen, я себе поставил цель, что в 2013 году я посвящу весь год исключительно переписыванию Nitrogen, и сделаю самый компактный и быстрый веб фреймворк. Он, по сути, полностью Nitrogen совместимый, то, что называется Nitrogen 2.0.

С: Который всем известен, как N2O.

М: Да. И теперь так получилось, что людям он начал нравиться. Я очень рад, что его используют мои друзья и многие люди в России, в Украине и даже в Калифорнии. Это приятно. Приятно, что за год он набрал такую популярность, и я обещаю, что я буду его саппортить.

С: Скажи, а кроме N2O, какие еще проекты входят в твою платформу?

М: Первое, что спрашивают обычно люди, это про доступ к базам данных и поэтому мы постепенно открывали свои библиотеки коммерческие, и мы превратили все то, что мы делали для заказчиков в открытые библиотеки. И, вот, первая из них — это доступ к базам данных в наш KVS. Чем она отличается от всех остальных? Тем, что мы не используем текстовые протоколы. А SQL — это один из видов текстовых протоколов, текстовых языков, для которого постоянно нужно писать обертки, генераторы SQL. Я с этим очень много работал, когда писали мы свой Hibernate и свои ORM движки . Это все в высшей степени сложно, неоправданно, проблематично, плохо поддаются перформансу. Сложность неоправданна. Не оправдывают сложности те задачи, которые ставятся перед людьми, которые разрабатывают, грубо говоря, просмотрщики котов. Весь computer science который сейчас существует в мире направлен на то, чтобы хранить котов в интернете и листать их. Но для этого не нужен SQL, чтобы держать линейно подобный фид с комментариями древовидными даже. Для этого SQL не особо нужен. SQL нужен для вычисления какой-то аналитики, OLAP-кубов, вот для такого. Чтобы хранить просто картинки в интернете я не особо впечатлен развитием того же PostgreSQL . Эти инструменты я бы использовал в других целях.

С: Да, его, в общем-то, используют в других местах.

М: Да, поэтому мы просто взяли модель обычного key value storage и цепочки — двухсвязные списки. Мы храним двухсвязные списки, у каждой записи есть ссылка на следующую и предыдущую. Такая модель вырисовывается в этом KVS. Кроме того, мы используем полиморфные record-ы, это когда вы в Erlang объявляете record как макрос — первые наборы полей. Все record-ы, допустим, у них все первые n-полей — это одни и те же поля. Вы можете полиморфно ко всем record-ам, которые хранятся в базе данных, первые n-полей вы знаете, что там хранится список на следующие и предыдущие, топ фида, вы все это можете там вычислить, имя таблицы, служебные поля.

И когда вы работаете с какими-то record-ами, вы полиморфно с помощью элементов перелинковываете эти все цепочки. Это очень удобно для обычного веб приложения, оно очень компактное, все маленькое, та библиотека занимает 2000 строк. И там драйвера к Mnesia и к Riak выглядят тоже достаточно компактно. Кроме того, мы следим за тем, чтобы все наши приложения работали под Xen-ом без всяких проблем. Обычно, если выбирают N2O, мы советуем использовать KVS, потому что все выдержанно в этом стиле, она очень компактная, намного компактней, чем все остальные аналоги. Ели вы хотите использовать какую-то другую базу данных, вы, конечно же, можете ее использовать, никто вас не ограничивает. Вы можете использовать тот же BossDB, либо свои какие-то SQL генераторы. Есть в интернете довольно интересные SQL генераторы, которые я бы хотел включить в свой стек, просто руки не доходят, и нет задач, где бы я мог использовать SQL генерацию из erlang-record’а или DSL . Я думаю, что, если такие задачи появятся, я ими займусь и у меня уже есть кандидаты.

С: Скажи, а какая обычно реакция тех клиентов, которые сейчас пытаются уйти, например, с Java, со спринга, как ты говоришь, на Erlang, в первую очередь. У нас все знают про Java, платформа, все дела, там куча, миллионы человеко-часов, десятки всяких платформ и все такое прочее. И тут приходишь ты и говоришь «Ребята, вам это все не нужно, у нас есть Erlang, у нас есть замечательные библиотеки и, вот, все будет гораздо круче, быстрее, проще, масштабироваться из коробки. Мне нужно будет потратить пару десятков лямов на то, чтобы это завести».

М: Обычно оно так не происходит, я не хожу на конференции; точнее хожу, но ведь туда не ходят мои клиенты. Клиенты меня находят через друзей. Они не Erlang ищут, а вот каких-то людей, которым можно доверять. Вот они приходят ко мне и говорят, допустим, «Мы хотим себе сделать там какую-то часть банковской системы». В целом, эти люди, которые делают банки, они же понимают, что такое Erlang. Erlang же работает не только в телекоме, но и в некоторых банках, инвестбанках в том числе. И таким людям очень легко объяснить достоинства Erlang. Сложно объяснить, допустим, людям, которые пишут на Ruby, достоинства Erlang, потому что существует такой предрассудок, что круче Ruby ничего нет. И люди не могут поверить в то, что может быть что-то удобней, проще или круче ActiveRecord. Но мы с этим боремся, и я очень часто даю примеры, сравниваю, как делать сайты на Ruby, и у нас есть люди, которые имеют опыт с Ruby, которые коммитят в N2O. Мы как-то следим, чтобы он не потерялся в этом сумасшедшем мире дикого веба.

В: Ты говорил про KVS, я хочу начать свою любимую серию вопросов про consistency, которую я спрашиваю каждый раз когда слышу про распределенные базы данных. Смотри, есть, допустим, у нас есть на побережье США пользователь A и пользователь B. Пользователь B отвечает пользователю A на коммент, упоминая пользователя A. Пользователь C, сидя где-нибудь в заснеженной России, читает эту ленту комментариев и ему запись пользователя B оказывается видна раньше, чем запись пользователя A. И получается, что он видит какой-то ответ на ничего. KVS как-то с этим умеет бороться? Есть некоторое количество всяких изощрений и, в частности, поверх eventually consistent баз…

М: Нет, KVS не управляет консистентностью ни в каком виде. Для этого есть специальная библиотека. Моя работа достаточно простая и она подразумевает некоторую гигиену использования сервисов и их доступности. Мы, конечно же, не поддерживаем никакие CRDT структуры и тому подобное. Но, вот, я хочу рассказать, как мы обеспечиваем последовательную консистентность цепочек, которые существуют в системе. Допустим, у каждого залогиненного пользователя есть фиды, стены, на которые мы что-то пишем и комментим. Каждый пользователь в системе представлен в виде Erlang процесса. При бутстрепе всей системы, допустим у вас есть 10 миллионов пользователей, все они зонируются, шардируются и запускаются на всех серверах вот эти 10 миллионов Erlang процессов.

Независимо от того, пользователь залогинен или нет, все операции записи цепочек в домене этого пользователя проходят через этот процесс. Все операции чтения естественным образом позволяют использоваться, откуда угодно. Но все операции записи должны пройти через этот процесс. Таким образом, все операции, допустим, запись в фид, обновление фида, удаление элемента из фида… нет прав у пользователя, оно выполняется в event loop этого процесса. Таким образом, если кто-то хочет написать кому-то что-то на стену, он посылает сообщение через pub/sub, а эти процессы подписаны на ключ этого пользователя. Вот когда вы посылаете в pub/sub публикацию какого-то сообщения для этого пользователя или группы пользователей, то эти сообщения попадают в эти процессы и эти процессы выстраивают запросы в Erlang очередь и совершают эти операции с фидом.

И кроме фида сообщений пользователь еще обладает другими какими-то цепочками — это его пейменты, его хистори какая-то, что угодно. И вот так мы это все менеджим. Эта библиотека называется feeds , она есть на нашем стеке synrc-apps . Немного написано пока про нее, но она используется и мы, таким образом, рекомендуем использовать это все. Там есть ряд вопросов, которые вы естественно захотели задать. Как мы обеспечиваем, если сервера падают с этими шардами, что происходит при этом. Это все, как бы, дальше можно рассказывать, объяснять и показывать.

В: Ну, вот, наверно было бы интересно послушать, но, действительно, пришел в голову вопрос про то, что будет, если автор приляжет? Но прежде чем говорить об этом, просто здесь хотя бы в целом известны подходы. А как у вас, вот ты говоришь, у вас есть pub/sub, у вас какие гарантии доставки на этом pub/sub?

М: Ну какие гарантии доставки? Это зависит от того, как вы конструируете приложение и что вы хотите туда записывать. Если это работа с какими-то финансовыми данными, то вы сами и проектируете эту часть. Если это для вас не критично, вы можете, допустим, пропустить какой-то коммент или когда вы делаете комментарий, в это время сервер упал. Ничего страшного не случится, если какой-то комментарий в супер онлайн потоке где-то удалится. Тут вы сами должны контролировать, наш framework не дает полного ответа на все вопросы. В полном смысле вы должны строить CRDT структуры данных и хранить все. Мы не решаем все проблемы за вас, мы просто показываем каким образом вы можете уйти от SQL и делать это все в другом виде. Но это не означает, что вы не должны читать книжки и понимать, как делать конкурентную систему и обеспечивать консистентность любых фидов.

В: Но это все-таки сильно большая нагрузка на мозг того несчастного человека, ушедшего из энтерпрайза, который привык к тому, что за него все делает база данных, а теперь ему говорят «Чувак, иди, читай матан».

М: Мы же таргетируем на web-разработку, мы хотим, чтобы PHP, люди на это правда, переходили из Java. И если вы думаете, что Java вам что-то там обеспечивает, гарантирует, если вы там Oracle поставили и блокирующие драйвера используете, то вы ошибаетесь. Ничего это не гарантирует, все будет точно так же не работать.

А: Валер, это же web, web scale, MongoDB , никаких транзакций, ты о чем? Какие-то CRDT, ну, что ты выдумываешь, в самом деле? У меня вот вопрос поинтересней, можно потом вернуться к твоим, Валер. Вопрос, кстати, не от меня, я не знаю, кто его тут добавил, тут есть ссылочка на какой-то voxoz.com, ты про него что-то знаешь и о чем вообще речь?

М: Voxoz.com — это наша инициатива по деплою и хостингу наших приложений. Этот проект начался в прошлом году и есть рабочий прототип этого проекта, но он пока не очень активно развивается, потому что у нас очень много других направлений, которыми мы должны активно заниматься. Этот проект, если в двух словах, то это возможность запуска приложений, построенных на нашем стеке, в Docker контейнерах , либо на Xen серверах, там, на Citrix Xen сервере или на других. Он подразумевает под собой, как и update программного обеспечения в виде single-file-deployment. Сам voxoz стек открыт, он имеет github свой. И там есть сервера, которые, допустим, нарезают Docker контейнеры, обертки вокруг Docker-а, сервера которые управляют приложениями в пределах какого-то контейнера, ну, там всякие дополнительные утилиты eox_mount для mount файловой системы ксеновской, Erlang on Xen — и другие штуки.

А: Другими словами, вы делаете Amazon заточенный под Erlang и пытающийся на этом как-то играть?

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

Этот проект курирует и находится под влиянием Владимира Кирилова. @darkproger в twitter. Я думаю, что нам его тоже можно будет пригласить, у него есть много презентаций, публикаций в интернете на тему voxoz. Мы тесно сотрудничаем с Erlang on Xen, с Cloudozer на эту тему, и он лично знает ребят из Docker-а. Ну, пока показывать нечего особо. Есть там какие-то аккаунты на panel.voxoz.com. Он пока лежит, его можно поднять и показать, как вы можете себе просто создать машину, вы получаете ssh доступ на этот Docker. Некоторые примеры приложений сразу предоставлены, вот, допустим, gentle, skyline. Что посмотреть, как? Как выглядит приложение на N2O? Вы там создаете себе сразу box, в общем, там полностью готовый Erlang минимальный, по памяти там все очень скромно, и можно, допустим, подмоунтиться туда, просто заливать файлы.

А: Хорошо, а вот про Erlang on Xen, ты как-то следишь, ты знаешь в каком оно сейчас состоянии, и какие у них там планы на ближайшее будущее? Расскажи нам.

М: Я закончил заниматься своим web-программированием, этим турецким проектом социальной сети. Последнее время занимался активно, хотел посмотреть, что можно выжать из N2O в контексте использования с SVG клиентом. У нас был клиент, написанный на flash для турецкой социальной сети и мне это очень не нравилось, потому что, это просто ужасно, я хотел от этого избавиться и за месяц мы сделали очень достойный клиент, за который не стыдно на SVG. И там все, естественно, гоняется вместо JSON — BERT между клиентом и сервером, используется N2O в полную силу, весь роутинг между игровыми столами там происходит на N2O, в общем, там все красиво. Просто писать 2 месяца на JavaScript — это слишком для меня и я решил полностью закончить с этой темой и заняться чем-то более интересным.

Вот, сейчас мы развиваем одно из направлений Cloudozer-а — это ребята, которые написали Erlang machine. Я работаю сейчас с ними в одном офисе, я работаю над их проектом. Не знаю, можно ли раскрывать детали этого проекта, но вопрос был про Erlang on Xen, про Erlang on Xen я рассказывать могу. Значит, Cloudozer получил, вы знаете, что Erlang Solutions получил заказ на Openflow Switch. Они сделали для компании infoblox по-моему. Выполняло этот заказ польское подразделение Erlang solutions, которое находится в Польше. Эти ребятам там что-то сделали, но сделали недостаточно впечатляюще, поэтому Erlang solutions принял решение и передал этот Openflow Switch фирме Cloudozer. Фирма Cloudozer — это Виктор Советов — это известный эрлангист в Киеве, который подымал Erlang в Киеве. У него была здесь компания Massive Solutions, если вы знаете.

В: Massive Solutions знаю, правда, как-то печально.

М: Почему печально?

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

М: Там с Ломоносовым ситуация такая, что вроде там с Ломоносова миллион долларов не доплатили Виктору Советову, потому что проект был очень масштабный и работали все под нагрузку, в спешке. Это фактически вопрос стоит нал легальностью вообще наличие этого кода в Ломоносове. Понимаете?
В: Я сейчас, как бы, не легальные вопросы обсуждаю, а именно тот факт, что он был такого качества…

М: В любом случае код Erlang on Xen открыт — это open source и все наши проекты в open source и вы можете комментировать качество всех наших продуктов открыто на GitHub-е, не стесняясь. Ломоносов — это все-таки закрытый проект и тут тяжело, что-то говорить об этом. Важно то, что после рефакторинга этого Openflow Switch, этот Openflow Switch теперь работает на Erlang on Xen. Т.е. Openflow Switch — это sdn приложение, которое использует протокол MPLS и все, что выше Ethernet-а. Это все управляется теперь Erlang-системой. Работает достаточно быстро, заказчики очень довольны и сейчас, насколько я знаю, Openflow Switch проходит все тесты, он является самым совместимым Openflow Switch-ом в мире. И это первый и очень успешный проект. Фактически этого проекта уже достаточно, чтобы Erlang on Xen технология жила и развивалась дальше. А мы работаем сейчас над следующим шагом в развитии инструментария для альтернативной, не ericsson платформы, ерланговской и это будет llvm компилятор. Из какого-то функционального языка он должен быть применим к sdn свитчам, т.е. это узкое телекоммуникационное направление.

В: А ты для кого говоришь, они sdn делали свитч? Для Infoblox?

М: Да.

С: Но это будет, насколько я понимаю, не тот llvm компилятор, который некоторое время назад, ну, в прошлом году, так активно обсуждался и по нему даже выступления были.

В: Само собой, тот компилятор для BEAM, точнее, я так понимаю, это было продолжение HiPE.

М: Нет, это, как бы, не Erlang вообще. Просто мы столкнулись с тем, что даже в виде Erlang on Xen виртуальная машина Erlang-а — это достаточно серьезная штука. Ей нужно 25 Мб памяти, ей нужно 3 Мб диска, сам image занимает — виртуальная машина со всеми приложениями там, допустим, 8 Мб, какой-то web-сайт средненький, web-магазин будет занимать где-то 10 Мб. Ну, и памяти нужно минимум для старта 20-30. Это все нас не устраивает, мы хотим сделать что-то более компактное, чтобы можно было генерировать llvm код прямо, в котором бы, были расставлены yield’ы в коде, при подсчете llvm’ом инструкций сами сразу автоматически. Чтобы при заходе в каждую функцию была проверка не заэксидился ли подсчет этих llvm инструкций, чтобы переключались стеки хорошо, там же есть гранулярность стеков. В общем, много технических проблем нужно решить, чтобы про это рассказывать. Ну, я надеюсь, что этот проект закончится успешно, потому что уже что-то есть и все говорит о том, что этот проект может стать очень хорошим и успешным. И я вот пытаюсь сейчас контрибьютить в этот проект.

В: Но, вот ты говоришь 3 Мб минимального пространства на диске, да?

М: Да.

В: И 30 Мб памяти?

М: Это стандартные параметры виртуальной машины Erlang-а со всеми этими структурами, с таблицами атомов, со всем. Оно приблизительно одинаковое. Точно такое же приблизительно и BEAM, т.е. точно также занимает, единственная разница в том, что Ling — виртуальная машина — Максим Харченко — автор Ling-а. Он сделал сумасшедшую оптимизацию и по поводу запуска виртуальной машины. Т.е. виртуальная машина стартует за 50 миллисекунд под чистым Xen hypervisor. И это открывает целый спектр новых вариантов использования технологий cloud вычислений и создания этих виртуальных инстансов. Там на сайте описаны все эти варианты использования, как это все меняет. Еще когда у вас идет http запрос и вы прямо в процессе роутинга этого http запроса вы можете поднять виртуальную машину и она успеет его обработать незаметно для пользователя. Представьте себе, что ничего нет, есть где-то система, которая отслеживает запросы и, вот, когда она видит, что запрос направлен на какую-то страницу, какого-то пользователя, она сразу для него поднимает виртуальную машину и этой виртуальной машиной обрабатывает запрос и умирает. Таким образом, можно экономить значительно вычисления на вычислительных мощностях в cloud’е. Эти варианты использования этой технологии Erlang on Xen пока остаются незадействованными.

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

М: Нет, это в наших приложениях, которые мы строим. Наше сотрудничество с Cloudozer заключается, в том числе, и в том чтобы попытаться построить прототипы вот таких вот новых приложений для Erlang on Xen. У вас есть, допустим, какой-то сайт — facebook like application, у вас есть там фид, ну вы же можете сервить этот фид, вам не нужен вообще Erlang для этого. Вы можете просто отрендерить сайт в статике и просто статику сервить с Nginx там, да? Зачем нам вообще какой-то Erlang? Erlang нужен только тогда, когда приходит какой-то чувак на сайт, залогинился уже и хочет дописать какой-то комментарий. Вот когда он хочет запостить комментарий куда-то, вот тогда нужно поднять виртуальную машину Erlang для него, записать этот комментарий в базу данных, перерендерить сайт и умереть, потому что он, в принципе, уже больше не нужен. Мы запрос обработали, умерли, и все, у вас уже новая статическая страница, вы дальше сервите статику. Т.е. это, как статик сайт генераторы, что-то среднее и вот эти вот штуки, которые поднимаются, которые генерируют эту штуку, они просто временно поднимаются, отрабатывают и умирают. Вот такие вот варианты использования нам были бы интересны, мы может, если будет время, будем делать вот такие прототипы новых таких веб-приложений.

В: Но это уже не N2O тогда.

М: Почему? Это все можно сделать на N2O.

В: Ну, именно на Nitrogen это очень не похоже, потому что в Nitrogen именно есть такое, что оно все живое и везде можно послать сообщение. Ну, я говорю о том, как я это видел, понимаю, трогал. И оно сразу реагирует.

М: Тут оно тоже будет реагировать, просто, сам этот инстанс будет поднимать какой-то контролирующий орган, который следит за запросом. Если это какой-то http запрос, то…

В: Извини, что перебиваю, смотри, вот, есть, допустим, юзер Вася, который сейчас залогинен на сайте, для него уже поднят актор, он с ним работает.

М: Вот, смотрите, вот вместо актора считайте, что это виртуальная машина должна подняться для каждого юзера.

В: Допустим, что поднята его виртуальная машина и внезапно он хочет провзаимодействовать с пользователем Дэвидом, который сейчас не залогинен. А запрос http идет в ту виртуальную машину, которая сейчас для пользователя Васи.

М: Если пользователь Вася хочет Дэвиду что-то написать, то поднимается две виртуальные машины — Вася и Дэвид. Они взаимодействуют и из пользовательской машины Вася, из ее домена, пересылается туда сообщение, возможно, даже напрямую и потом после этого они умирают. Или некоторое время остаются еще там.

В: Ну, смотри, сразу возникает проблема. У тебя есть две машины, одна из которых поднята, а вторая не поднята вообще еще. У тебя должна поднять вторая машина, зарегиться в каком-то discovery service, должна пройти сообщенька, должно все записаться в базу данных, перерендериться сайт и отдаться пользователю. Ведь эта идея очень сильно увеличивает latency.

М: Это увеличивает latency, если она сразу должна умереть. Тут дело не в том, что вы увеличиваете latency на операции запуска виртуальной машины и ее смерти. Дело в том, что когда, допустим, пики будут происходить, то вы можете их гранулярность изменения текущей capacity для обеспечения вашей текущей нагрузки на cloud. Мы можете не машинами, не инстансами приложения его, т.е. не Linux компьютерами, а вы можете добавлять это все, гранулировать вот такими вот снепшотами по 20 Мб, нарезками. Понимаете? Вы можете, буквально, доступ каждого пользователя создавать, он не обязательно должен сразу умирать, чтобы таким образом демонстрировать плохие показатели latency при обслуживании запроса. Машина может держаться некоторое время, но если какая-то там эвристика показывает, что тенденция такая, что эта машина не назначалась никому, вы можете ее смело засуспендить.

В: Ну, вот ты снова говоришь о эвристика и получается, что тут две проблемы. Во-первых, если мы будем брать и деплоить Erlang on Xen на тот же самый Amazon, который, я так понимаю, сейчас основной таргет для…

М: Так это именно для Amazon-а вообще штука, потому что просто над Amazon-ом вы можете деплоить любую штуку, которая выпускается на Xen-е. Это не то. Тут именно нужно создавать свою инфраструктуру для обеспечения вот этих вот механизмов автоспавнингавиртуальных машин, там есть специальный сервис в Erlang on Xen, который называется gator, который шлюзует вот эти запросы и перенаправляет с помощью вот этих ксеновских утилит XL провизионинг создает вам dom там, понимаете, ксеновский. Это нужно все самому писать, мы не можем. Допустим, захоститься на Amazon-е или Rackspace, вы тогда не получите бенефита вот этого.

В: Ну, да, я просто хотел тебе сказать, да. Т.е. это нужно именно полностью инфраструктуру строить с нуля получается.

М: Поэтому, как бы, стоит вопрос о voxoz-е, как о каком-то инфраструктурном решении для Erlang on Xen, потому что сам EoX — это просто ксеновское приложение. Если вы его будете так использовать, то вы не на полную мощность его будете использовать. Он же оптимизирован для быстрого запуска, он делает быстрый запуск. Чтобы его задействовать, нужны соответствующие инфраструктурные элементы и соответствующая архитектура баз, и рендеринга этих сайтов. Это все должно быть в целом цельным механизмом. Это не обычный механизм, но вот аналогии, на которые можно опираться — это вот, допустим, статическая генерация сайтов, оживание/умирание виртуальных машин для каждого пользователя. Кроме того, тем есть еще security use-case’ы, т.е. мы можем создавать виртуальные машины, которые живут только в памяти. Ключ primary key находится только в памяти, вы не можете его никак извлечь, потому что он для юзера запущен. Инстанс виртуальной машины ерланговской — там находится его ключ, это как кошелек его. Он абсолютно защищен. Это тоже один из вариантов use-case. Все варианты use-case, которые возможны, которые мы хоть как-то пытались анализировать, они есть на сайте Erlang on Xen, там их можно прочитать. Очень много, конечно, у всех возникает вопросов «А как мы будем делать то?», «А как мы будем делать это?», но это все решаемые вопросы. Главное, что некоторые люди понимают, раз есть вот такой вот шаг вперед, что мы можем запускать виртуальные машины за 50 миллисекунд, по-любому из этого можно извлечь пользу и нужно просто понять, как это сделать.

А: Я извиняюсь, что я вторгаюсь в ваш интересный разговор, дело в том, что у нас заканчивается первая часть выпуска и перед второй мне хочется сделать маленькое объявление, просто, чтобы оно попало именно в первую часть, потому что они с разницей в неделю выходят. Есть такая компания, называется Evron, наверно я читаю неправильно. Это команда, которая организует серии конференций, называется Rails club Moscow. Но не бойтесь, речь пойдет не о Ruby. Дело в том, что эта команда решила также попробовать организовать встречи о функциональном программировании. Называется это дело functional programming moscow teach meetup. В качестве demo встречи пройдет это мероприятие 16 августа, по-моему, это суббота. Уже подтвердили свое участи Максим Лапшин, всем известный, не нуждающийся в представлении, Николай Рыжиков. Меня туда зовут рассказать про Haskell, но я пока не знаю, с одной стороны хочется, конечно, рассказать, с другой стороны влом, там что-то делать надо, слайды готовить.

С: Расскажи, расскажи Саш. Кто ж кроме тебя?

А: Ну, да, да. Может быть, я там буду 16 августа. Ссылка будет в show notes, не пропустите. И, видимо, заканчивается наша первая часть, будет вторая. Как обычно она выйдет через недельку для вас, а для нас она наступит через минут пять, мы сделаем небольшой перерыв. Сереж, я так понял, ты нас решил покинуть и вместо тебя придет Ваня Глушков ?

С: Да, все так.

А: Ну, тогда пока.

С: Пока.

А: А нашим слушателям я хочу сказать большое спасибо за прослушивание и надеюсь, эта часть выпуска вам понравилась. Подписывайтесь, лайкайте, комментируйте и до следующей второй части. Всем пока.

Дополнение: EaxCast S02E08 — окончание интервью с Максимом Сохацким о проекте Erlang on Xen, девочках и теории категории