EaxCast (afiskon&sum3rman) - S02E08 - продолжение интервью с Максимом Сохацким | Текст песни и Перевод на русский

• Тексты песен
• EaxCast (afiskon&sum3rman)
• S02E08 - продолжение интервью с Максимом Сохацким

http://eax.me/eaxcast-s02e08/
EaxCast S02E08 — окончание интервью с Максимом Сохацким об Erlang on Xen, девочках и теории категорий
27 августа 2014
Темы выпуска: сколько форкнуть Xen’ов, Erlang-девочки и теория категорий, системы типов и сиподобная лапша, а также ответы на вопросы слушателей. Предыдущие выпуски: четырнадцатый, тринадцатый, двенадцатый, одиннадцатый.
Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/15/
Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/15/file/podfm_eaxcast__eaxcast_208.mp3
Шоу нотес:
Список книг от Максима
Статья и слайды про TLA+ в Amazon;
Голоса выпуска: Максим @5HT Сохацкий, Валерий @sum3rman Мелешкин, Иван @gliush Глушков, Александр @afiskon Алексеев
Фоновая музыка: The Panets — Winter Beats (Big Power Mix)

А: Всем привет, вы слушаете EaxCast, второй сезон, восьмой выпуск. Это продолжение интервью с Максимом Сохацким. Сережа Елин нас покинул, ему на смену пришел Ваня gluish Глушков, я правильно произнес?
И: Нет, gliush.
А: Глиуш. Надо будет заботать. Мы продолжаем, и я так понял, Валера продолжает свою серию хитрых вопросов.
В: Ну, в общем, я собственно, что хотел спросить? Максим закончил на том, что Erlang on Xen – в принципе, этот контейнер можно запускать на практически каждого пользователя, это быстро и довольно экономно. И у меня возник такой вопрос, а чем это принципиально лучше запуска lxc контейнера?
А: У меня другой вопрос, я сразу встряну. Чем это принципиально лучше создания процесса ерлангового?
М: Самый экономный вариант – это создание ерланг-процесса, но, если речь идет о какой-то сущности, которую мы можем остановить и потом полностью запустить и сосредоточить какие-то вычисления от имени какого-то конкретного юзера в виде виртуальной машины, то мы можем легко при неактивности этого пользователя держать эти вычисления засуспенженными. Что касается lxc контейнера, то очевидно, что слишком много слоев и стеков в линуксе для обеспечения… Ну допустим, мы разрабатываем какое-то приложение поисковое и нам нужно где-то хранить индексы. Что мы делаем? Мы в Key-Value storage’е создаем какие-то таблицы, какие-то записи и делаем B-Tree хранилища для того, чтобы хранить наши индексы в нашей поисковой системе. А что такое Key-Value storagе? А Key-Value storagе – это тоже какая-то штука, которая хранит в B-Tree все индексы внутри какого-то файла на файловой системе.
А что такое файловая система? Файловая система – это тоже какое-то B-Tree хранилище, которое хранит индексы этих файловых дескрипторов. Понимаете? Получается у нас на ровном месте три уровня B-Tree, три уровня баз данных, три уровня файловых систем, и непонятно почему это все вообще так произошло. Очевидно, что какая-то была допущена ошибка при конструировании промышленных систем в 60-х годах с появлением UNIX-а. И мы хотим эту ошибку исправить. Очевидно, что имея чистый Xen контейнер, мы можем построить минимально необходимое обеспечение хранения данных. Почему не lxc. LXC – это очень удобная штука для прототипирования деплоя, для деплоя legacy unix приложений. Это очень удобно, используя docker задеплоить что-то, куда-то в виде одного файла, запаковать это вместе с файловой системой. В docker’е, как вы знаете, оно версионируется, в отличие от чистого lxc контейнера. Т.е. там есть версионированная файловая система – очень удобная штука. Я советую, кто еще не использовал докер, обязательно посмотрите, эта штука очень перспективная. В будущем предполагается написание плагинов различных. В том числе Вова Кирилов работает с docker-командой над тем, чтобы использовать docker-интерфейс для создания xen образов.
А: Я знаю, кто из нас сейчас без проблем сочинит какой-нибудь вопрос по докеру.
М: Давайте.
А: Да, Вань?
И: Вообще, я хотел вернуться немного назад. В docker мы очень весело перешли, я готов про него потом поспрашивать.
В: Дело в то, что. Да, да.
И: Давай я вопрос задам, потом ты все это вместе резюмируешь. Получается, что Xen – это, в принципе, чуть похуже, чем Erlang процессы? Они будут запускаться чуть помедленней и Erlang машина сама по себе, если она уже работает, она быстрей создаст процесс и быстрей обработает входящий запрос.
М: Конечно.
И: А какой смысл тогда генирить? Не легче иметь одну большую машину, которая будет хорошо работать с кучей ядер и легко обрабатывать все входящие запросы?
М: Гранулярность масштабирования, т.е. для того, чтобы в том месте, где нужно срезать пики, у вас получится. Вот, когда происходит всплеск нагрузки, вы можете очень точно нарезать мощность через каждые 20 Мб и каждые 50 мс. А в случае с каким-то незапланированным пиком, вам делать какие-то запросы, чтобы выделить мне машину либо мне диапазон машин – 10 машин. Я вижу, что у меня сервис растет, нагрузка растет, пожалуйста, подготовьте мне 10 машин и разворачивайте полностью эти 10 машин. Т.е. там поднимается Linux, поднимаются все сервисы, все это коннектится в кластер. Это все много, это не 50 мс. Мы сокращаем гранулярность масштабирования кластеров до минимума.
И: И это очень полезно для облачных сервисов вида то, что мы в Amazon-е имеем или в Google облаке. Т.е. фактически мы пришли к тому, что облачные структуры нам уничтожают все преимущества Erlang потому, что мы фактически уходим от больших машин, мы переходим к м

EaxCast (afiskon&sum3rman) еще тексты

Перевод Translate.vc