Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Антон Коренюшкин (Akshell): PaaS для исполнения JavaScrip на сервере

Выступление Антона Коренюшкина (Akshell) на Неконференции *aaS предпринимателей 2011.

Рассказ о PaaS для исполнения JavaScript на сервере: стандарты, технологии, платформы.

Презентация

Видео

Стенограмма

Скачать .pdf

Я начну, вообще, с платформ. Почему все говорят о платформах? Почему все делают платформы в последе время? Отвечу в следующем ключе. представьте себе, что, чтобы доехать сюда на автомобиле, вам для начала нужно собрать вот эти детали. Во-первых, не многие бы с этим справились. Во-вторых, это занимает время. А, в-третьих, это пришлось бы делать каждому. И в некотором смысле web-разработка устроена, действительно, отчасти так. То есть, существует множество инструментов, множество программного обеспечения для того, чтобы создать web-приложения. Но программистам, разработчикам приходится как бы заново все это разворачивать на своих серверах, настраивать, администрировать и так далее. А вообще, если доходит дело до масштабирования, то тут, вообще, все срезу становится сложно. Поэтому в последнее время предлагается множество Platform as a Service (PaaS).

Основные преимущества подобных вещей. В качестве характерных примеров можно привести Google App Engine, Oracle, предназначенные для любых web-приложений вообще. Или платформа Force.com, предназначенная для бизнес-приложений. Преимущества платформ очевидные. Это, во-первых, простота использования по сравнению с тем, чтобы разворачивать все это на своем сервере. автоматическая масштабируемость. Мало кто себе, на самом деле, представляет, что это такое. То есть, ваше приложение описывает бизнес-логику, а когда вы свое бизнес-приложение переносите на сервера, об этом заботится платформа, что значительно упрощает жизнь. Естественно, значительно меньше забот по администрированию приложения. Обычно, клиент не представляет всех необходимых для работы с базой данных инструментов, и не знает о гораздо большем количестве вещей. Это зависит, собственно, от специфики платформы. Если это Google App Engine, то это у нас, в основном, база данных, причем, весьма специфическая. Если это Force.com, то это множество инструментов для бизнеса, для создания приложения именно автоматизирующего бизнес-процессы. Ну, и обычно, кроме всего этого, платформа предоставляет какую-то свою богатую среду, в которой можно собирать приложения из кирпичиков. То есть, это набор библиотек, набор сервисов на платформе и так далее.

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

Также преимуществом, или недостатком, является то, что JavaScript — это такая чистая доска, в отличие от Python или Ruby, которые идут вместе с buyju inclued. JavaScript — это только язык, почти без библиотек, поэтому он является таким базовым. То есть, это такая открытая платформа, на которой можно добавлять какой-то свой функционал, свои библиотеки, специфичные для платформы. Это с какой-то стороны является недостатком, потому что, если вы начинаете создавать какое-то приложение на Python, вы можете делать что угодно, запускать процесс, ну, много чего можно делать на Python. В JavaScript стандартом нельзя делать практически ничего. То есть, можно делать только то, что вам предоставит платформа, а дальше уже задавать стандарты.

Немаловажным преимуществом, как оказалось, является то, что традиционное клиентское программирование на JavaScript play-элементо-ориентированное. То есть, взаимодействие с пользователем происходит не так, что вы что-то делаете и идете, действие какое-то происходит, а вы реагируете на события, которые происходят, за счет взаимодействия с пользователем. То есть, происходит какое-то событие, у вас в программе развивается какой-то пункт play и обрабатывает событие. Потом программа выходит в меню, потом происходит следующее событие, и так далее. И сейчас появляется много новых приложений, которые рассчитаны именно на синхронную модель взаимодействия. Наиболее классический пример, это IRC сервер. Если вы хотите сделать IRC сервер, например, для брендмаузера, вам нужно не только ориентироваться на то, что клиенты будут использовать этот сервер синхронно, но и наоборот, сервер передает данные и тоже синхронно, потому что это происходит тогда, когда другие пользователи что-то делают. Соответственно, такая синхронная модель взаимодействия очень плохо реализуется традиционными моделями программирования, когда у нас под каждый запрос выделяется отдельный стрэт. Потому что стрэтов становится очень много, каждый стрэт развивает свои листы, как минимум, на мегабайт, поэтому это не работает. То есть, не просто плохо работает, а не работает модель такого взаимодействия. И сейчас для каждого приложения Rich Interfaces они все чаще и чаще используют такую модель, поэтому то, что JavaScript заточен под синхронность — это очень хорошо. И, собственно, много платформ для такого серверного JavaScript нам известны.

Ну, и последним обстоятельством, которое делает JavaScript отличным для применения как надсерверной части именно как платформа as a Service. Это фактически потому, что на сегодня он является самым быстрым и самим динамичным из языков благодаря тому, что фирмы Google и Apple вкладывают большие деньги в развитие интерпретаторов JavaScript. Google Wave не просто интерпретирует Java язык, а он изначально компилирует его в 2-3-6 строчный код, который поддерживает процессор, и потом уже исполняет. Соответственно, все это происходит быстро и для динамического языка это максимум. С ним могут специально соревноваться разве что специальные языки, которые уже писались очень давно.

Сегодня есть стандарт, единственный и неповторимый, называется HMGS, написан на сайте hmgs.org. Это инициатива их же. Уже несколько лет она пытается стандартизировать такие вещи, которые не нужны на клиенте, но очень нужны на сервере. Выглядит все это как модульные пакеты, которые на JavaScript, даже, нет возможности стандартным образом конфуглить. И эти стандарт-модули, стали действительно общими. Все серверные платформы одинаково поддерживают этот стандарт-модуль. Все остальные стандарты, перечисленные на экране, это далеко не все. Их много. Они не настолько распространены. И, на самом деле, есть большая проблема, потому что для каждого из вышеописанных стандартов есть несколько вариантов. С тем же HMGS нет такого человека, который бы сказал, что, вот, я выбираю именно это. Все децентрализовано. Есть такое мнение, довольно распространенное среди поклонников, что HMGS, это фактически группа людей, которая занимается общим флудом на абстрактные далекие от жизни темы и результаты их действий соответствующие. То есть, получаются спецификации не реализованные к тому же, еще и с разними вариантами спецификаций. В общем, качество этого стандарта, скажем, не высоко.

Теперь немного о движках, которые существуют для JavaScript. Самые новые — это Google V8 и Applescript Code, которые были созданы, соответственно, для браузеров Chrome и Safari. Они, безусловно, среди перечисленных являются самыми быстрыми, и периодически друг с другом соревнуются, кто из них самый быстрый. Когда Applе выдает очередной script, то они говорят, что у них самый быстрый. Когда Google его постепенно обгоняет, то Applе выпускает новый script, и так далее. В общем, для сообщества эту ситуацию я считаю полезной, потому что все становится быстрее и быстрее. Самый старый движок — это Mozilla SpiderMonkey. Он гораздо медленнее, чем первые два. Просто, намного медленней. Он используется в браузере Firefox. Единственное у него достоинство перед движками Google и Applе заключается в том, что он поддерживает новые стандарты JavaScript, в котором они позаимствовали много хороших вещей из Python, но программировать стало значительно приятнее. Но неизвество, во-первых, станет ли этот стандарт настолько широко использующимся. Во-вторых, если мы говорим, чтобы на клиенте и сервере программировалось одинаково, то ясно, что на сервере мы сможем использовать SpiderMonkey, какие-то новые скрипты для работы с данными, а на клиенте — никак. Потому что никто не гарантирует, что клиент этот будет в Firefox. Соответственно, преимущества SpiderMonkey в этом плане невелики. И еще нужно добавить то, что в плане что-то поставить на него, я оценивал как его использовать как движок для нашей платформы, он обладает таким old school ps интерфейсом, когда там функции занимают по 20 параметров, что в этом разобраться очень сложно.

И последний движок — это Mozilla 5.0 Alpha. Он отличается от всех предыдущих тем, что работает на платформе dium. И это большое преимущество, потому что для Java создано очень много библиотек и все их можно использовать из wap. Ну, ясно, что по скорости он очень отстает от Google V8 и Applescript Code, но зато можно использовать JavaScript библиотеки. Возможно, если создавать что-то для бизнеса, какие-то платформы или бизнес-приложения, то есть некоторый смысл использовать Alpha, потому что для интеграции уже создали очень много кодов.

Но, Java постепенно отходит на второй план. Ну, это мы еще увидим. Есть такое мнение, что в каждой парадигме программирования сначала возникает много языков, а в конце остается только один. Например, процедурных языков когда-то было очень много, сейчас остался только один Си. И существует предположение, что может быть когда-нибудь среди динамических языков тоже останется только один. А так как от браузеров мы никуда не денемся, то вероятно это будет JavaScript. Ну, это мы посмотрим.

Какие существуют платформы на эту тему? Платформы не в том смысле как as a Service, а просто, платформы, которые вы можете взять и у себя на компьютере запустить. Самая популярная, конечно, это HMGS, про которую я уже говорил. Главное его отличие от традиционных платформ, он — асинхронен. Тут как раз было использовано то преимущество JavaScript, что у него нет стандартной библиотеки, и создатели нода создали эту стандартную библиотеку, в которой, просто, невозможно сделать блокирующий вызов вообще никак. А все вызовы, которые могут быть блокироваться, они делаются с помощью передачи comeback, и таким образом вам возможно обрабатывать множество запросов не разделяясь на потоки. Соответственно, HMGS идеальна для создания web-серверов, какого-то асинхронного приложения и так далее.

Но ее большой недостаток в том, что бизнес-логи прописаны таким способом, что это, просто, невозможно. Код превращается в «спагетти» из comeback-ов и это абсолютно нечитаемо. То есть, то что возможно сделать в 2 строчки на традиционной парадигме, в HMGS превращается в 20 строк, причем, сложностью в 8 уровней. Но есть попытки, одну из них мы сейчас предпринимаем, думаем над ней. Я разговаривал с создателем нода на Keyskont, и с помощью кейта есть возможность создать легковесные процессы. У него есть понятие так называемого контекста, и с помощью этих контекстов можно создать несколько стэков исполнения, и каждый стэк, они друг от друга зависимы, то есть у них какая-то одна общая глобальная нэуспэйс, но при этом стэки у каждого процесса будут разные, и создавать новые такие стэки достаточно дешево. И за счет этого можно сделать как бы многозадачность, как бы стрэты. Это будет реализовано следующим образом. В единственном главном строителе выполняется асинхронный код, а в дополнительных исполняется синхронный код, там нет блокирующего вызлва и мы как бы возвращаемся в главный, и в главном осуществляем руками переключение между дополнительными стрэтами, таким образом, создаем новый код, и программируется бизнес-логика.

Но, есть там некоторые проблемы, опять же. Проблемы, в частности, с нотом и проблемы вот с этой моделью. Weeton был создан для браузера, не для сервера. И это накладывает определенное ограничение. Главное ограничение, это то, что он медленно запускается, медленно создает потоки, поэтому использовать с контекстами, как я говорил, в принципе, может быть можно, если контексты создавать быстро. И второе ограничение. Например, он вообще не поддерживает стрэк от операционной системы, но он в единственном стреке работает, и когда у него включается гамбридж коллешион, а включается она у него неизвестно когда, все замораживается. То есть, если вы пишете приложение на ноде и вы не позаботитесь о том, чтобы оно работало во многих процессах, то периодически оно будет замораживаться.

Вторая платформа — это индекджес, не менее популярная, но существующая, если не ошибаюсь, уже 15 лет. Отличается она тем, что базируется на Mozilla Raine. Это большое отличие. На общей этой платформе вы можете создавать какие-то интегрированные Java-приложения. Кстати говоря, у них, наверно, в первых числах июня будет конференция, и мы организуем там секцию JavaScript, так что я, пользуясь случаем, всех туда приглашаю.

Следующая инициатива — это Naurwal. Это, даже уже не платформа, а некая инициатива создать поверх платформы общий API. Сейчас она есть, но широко не используется.

Последняя — это наша любимая платформа Akshion. Она как раз создана для разработки бизнес приложений. Она с синхронными API. Это часть только нашей платформы. Кроме того на ней возможны разработки браузерные. Можно зайти на ее сайт. Одним кликом возможны разработки. Возможно написать код и одним кликом сохранить результаты в инфраструктуре.

Вот наши разработки, написанные с помощью Cappuccino. Тоже, кстати, очень хороший продукт для клиентского JavaScript. Я вам всем его рекомендую. С помощью его можно с легкостью создавать приложения браузерные, которые по своему функционалу ни чем не будут отличаться от десктопных, они будут, действительно, rich Internet application (RIA). И, главное, что все это создается, базируясь на фреймворк Earl PК. То есть, у низ все API взяты оттуда, из PК. Поэтому им очень легко пользоваться. там очень продвинутая модель, то есть, вы описываете только бизнес-логику, но это отдельная тема для разговора.

Кстати, я еще забыл сказать, что для нода существуют, они растут как грибы, сервисы, которые хостит нод. Интерфейс там простой, без всякой сервис-разработки. Просто пишете код и делаете туда. Собственно говоря, и весь интерфейс. Кроме этого существует еще множество Platform as a Service для нода. На самом деле, они появляются пачками, но создать базовую какую-то платформу, это дело отдельное. Создать что-то действительно масштабируемое и надежное, это, конечно, посложнее.

Вот, собственно, все, что я хотел рассказать.

Кто-нибудь имеет делать сервер JavaScript? Вообще, никто? Неудивительно, что вопросов нет. На самом деле, это большой тренд в последнее время. На конференции, которая проходила около месяца назад, собралось около тысячи человек, и большая часть конференции была посвящена именно серверному, а не клиентскому, JavaScript.

Из зала: Играет роль производительность платформы?

Главное, это производительность программиста, потому что JavaScript — это динамический язык, и ограничений почти что нет.

Из зала: А если параллельно делать движок на Java, приложение еще на чем-то помимо JavaScript?

Параллельно, в смысле, по трендам параллельно?

Из зала: Ну, да. Ну, может, для отдельных машин.

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

Представьте, что вы пишите IRC сервер. Это для нода классический пример. В серверной части IRC сервера что происходит? А происходят там длинные нити реестра. Ваш браузер делает запрос на сервер, а сервер не дает ответа, а как бы придерживает это соединение, то есть для этого создается отдельный стрэк. Зашло 200 человек на ваш IRC сервер, вам придется держать 200 стрэков. Ясно, что это, просто, не масштабируется, это неприемлемо, тем более, все эти стрэки просто висят. В то время, как в ноде вам достаточно одного потока, одного процесса, который будет обрабатываться асинхронно. Пришло сообщение от какого-то пользователя, вы по всем канальчикам разослали ответы, но ответы происходят асинхронно. То есть, вы не висите ни на чем, нет блокирующих вызовов. В этом главное отличие нода. И, учитывая, какие-то браузерные дополнения и приложения, обновления в браузере, это идеальная платформа для бизнес-логики. Поэтому, как я уже говорил, мы пытаемся взять лучшее из обоих миров и наладить вот эти бизнес-процессы.

Если коротко, основные отличия нода от Java при традиционном программировании. То есть, он очень хорош для какой-нибудь специфической задачи, но для бизнес-логики он плох. Но я надеюсь, что нам удастся создать на базе новых процессоров что-то, что будет хорошо для бизнес-вещей. Вот, вы все никогда не имели дела с серверным JavaScript, какие вы технологии профессионально используете?

Из зала: Java.

А Python кто-нибудь использует? Нет? Только Java?

Из зала: А Key Code для движка используется?

Последние сообщения появлялись о том, что на Facebook его собираются использовать. Но, это очень давняя история. Ту же асинхронность не Райян придумал. Если помните, был такой сервис Funkle, он и сейчас используется. Для него еще создали серверный Python, который делает фактически тоже самое. Так как Python не так удобен, чтобы на нем не сделать блокирующий вызов, это нужно очень постараться, нужно использовать только твистовские API. Соответственно, были разработаны другие платформы. Но ни одна из них не приобрела такой известности как нод. Собственно лента новостей на Facebook с помощью твиста реализована. За счет этого вы на ней можете получать данные по апдейту, то есть не ждать каждый раз, а зайти на него и сразу смотреть ленту новостей. Собственно, для этих вещей и предназначено нетиповое программирование.

Ну, а большие игроки… Ну, про Facebook я сказал, что у них есть свои плагеты. Поверьте, это большой рынок и сейчас мы можем наблюдать, как он развивается, и сейчас в это вкладываются большие деньги. То есть, скорее всего, не то что через 2 года все вдруг перейдут на JavaScript, но то, что он дает огромную нишу, это — факт. На сервере, я имею ввиду, благодаря своей природе.

Из зала: А для Соло используется JavaScript, сервиса, я имею ввиду?

Почему бы и нет. В смысле, для предоставления API?

Из зала: Да.

Делать на нем шаблоны htme неудобно, то есть, это именно бизнес-логика, это неудобно, он для этого не предназначен. Именно создавать копирейты на нем хорошо, потому что вы можете создавать асинхронные вещи, помните, я говорил? Именно для этого он предназначен больше всего. Современные web-приложения… Не то, чтобы это единственный способ, но многие так делают. В офисе вы когда получаете на страницу от сервера изначальный какой-то код клиентский, и все остальные обновления вы через API делаете. И, соответственно, все обновляется в самом клиенте. А сервер, он не получает такой кучности соединений.

Ну, вот, наш пример приведу разработки. Это абсолютно одностраничное приложение. То есть, вы один раз получили тестодемейд, который, естественно, закешировался, и все остальное вы на этих кнопках открытия меню и так далее. Это происходит уже через серверный API. То есть, это, фактически, сервисная единая.

Для того, чтобы создавать интернет-магазины, наверно, это не самое лучшее решение. Вот, как я и говорю, бизнес-логика не дружит с асинхронностью, потому что бизнес-логика описывает, что вы хотите. Хочу — это, хочу — это, хочу — это. А не «сделай мне это, а потом вызови мне того-то». И нужен еще один comeback, чтобы вернуться и сделать это. Но я уверен, что нам удастся взять лучшее из обоих миров и создать платформу, которая была бы универсальна.

Из зала: Вот, сервер GS предназначен для передачи массированных данных, а не для каких-то социальных страниц бизнес-приложений?

Нет, GS может передавать клиентам различные данные, статические файлы, и это не вопрос. Я, на самом деле, не совсем до конца понял вопрос. Бизнес-логика отличается от таких вещей как репликенты IRC сервера, что вам нужно описывать семантику. У IRC сервера нет семантики никакой. Просто, он данные передает, ну, чуть-чуть обрабатывает, и для таких вещей, не для web-приложений, а для web-сервисов, нод GS — идеальное решение. А то, что мы пытаемся сделать, это сделать так, чтобы с помощью него можно было и бизнес-логику писать. Потому что, на самом деле, понятно, что на динамическом языке бизнес-логику описывать не быстрее, чем на нединамическом. И ясно, что JavaScript дает много специальных возможностей, что он может использоваться как для серверов, так и для клиентов. Поэтому, вероятно, за JavaScript мы последуем и будем с ним работать.

Есть стартап NauES, он как раз создает вещи, которые синхронизируют, делают видимость одной среды, на том же Google Space и так далее. Понятно, что одного сервера будет недостаточно. Тем более, что при такой модели в этом сервере будет использоваться одновременно много процессов. И нужно с помощью обмена легковесными сообщениями поддерживать именно активные среды, но это сейчас пока только создается.

В клиентской части JavaScript с новым стандартом поддерживает web берджик, в котором что-то вроде нового сервиса. А тренд такой есть, потому что с помощью этого можно научить программиста делать эти вещи. Собственно, такой трен есть как на клиенте, так и на сервере. Chrome и Safari уже поддерживают многие web-сервисы.

По поводу клиента могу еще сказать. Появляются такие языки как Cappuccino и SQL (Structured Query Language), которые именно заточены на то, в отличие от JavaScript, на фреймворк, где вы можете создавать именно rich application и использовать полноценную бизнес-модель, синхронизироваться через модели не с Cappuccinо, например, чтобы создать серверную разработку мне ни разу не пришлось писать какие-то процессы. То есть, все это преобразуется специальным фреймворк, а вы описываете только соответствующий контроль, располагаете их, описываете каким образом они должны взаимодействовать. то есть, все происходит так же как в десктопных серверных разработках.

Из зала: То есть, все это вручную описывается в JavaScript?

В Cappuccinо еще есть что-то вроде интерфейс-бьютера, там где вы можете мышкой таскать что-то в интерфейс, код писать. Это не мета-язык, не DSL. Он сохраняет некие файлы, которые невозможно руками писать. Есть, проще говоря, инструмент графический для создания интерфейсов. Но, если вам нужно создать что-то нестандартное, то все равно приходится вводить руками. На самом деле, это не настолько актуально для JavaScript. Там очень широко используется XML и она добавляет гибкости языка. В JavaScript не настолько требуется DSL.

Так что я всем рекомендую использовать и писать на JavaScript. До вас этот тренд тоже дойдет, вы не первые.

Комментарии (0)