Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
только что пришло приглашение от RightScale на Вебинар How to Think Multi-Cloud, актуальность темы на западном рынке довольно высокая
Протестировал сервис предложенный в статье. Конечно это интересно, но я как разработчик не готов перейти к созданию серьезного проекта с помощью этого. Плюсы, которые указаны в посткриптум отчасти являются плюсами CMS, они тоже ускоряют разработку и позиционируют себя как нечто гибкое и расширяемое. Рад буду если облачные сервисы для разработчиков будут развиваться, в этом что-то есть.
Если вы относительно Hivext, то многое зависит от того, какую конкретно задачу вы решаете… один из проектов моего знакомого, на который он тратит много денег на 80% покрывается функционалом платформы, т.е. если бы он делал на базе сервисов платформы, то сэкономил бы значительное кол-во времени и денег. Это реальный, не выдуманный пример из жизни. Когда он запускал проект, он не знал о нас. И такой пример в моем опыте не один…
CMS и библиотеки — да! отчасти решают те же задачи. Однако, сервисы с API более гибки со стороны разработки, при этом более мощны с функциональной точки зрения, улучшаясь разработчиками платформы автоматически улучают работу вашего приложения, + масштабируемость, + средства для диагностики, а также многое другое что не доступно по умолчанию и без дополнительных потерь своих сил при использовании CMS и библиотек.
Наша разработка только-только переходит на этап активного развития, мы нашли финансовую поддержку и вскоре будет реализован на должном уровне обширный список важных на наш взгляд фич и сервисов. К тому же, мы не ориентируемся на рынок СНГ, он подтормаживает, на западе уже давно это активно используется… у нас есть тау-задержки, ну сами знаете вообщем… Просто хочется поддерживать в тонусе и наше ИТ-сообщество. Лично я рад, что у нас появились такие проекты как Scalaxy и Clodo. Народ к ним тоже изначально скептически относился, а сейчас они все больше и больше преобретають доверие клиентов. Но все же, повторюсь, облачные хостинги на западе уже пройденный этап, новый тренд — API Cloud Services + Multi-Cloud
CMS и библиотеки — да! отчасти решают те же задачи. Однако, сервисы с API более гибки со стороны разработки, при этом более мощны с функциональной точки зрения, улучшаясь разработчиками платформы автоматически улучают работу вашего приложения, + масштабируемость, + средства для диагностики, а также многое другое что не доступно по умолчанию и без дополнительных потерь своих сил при использовании CMS и библиотек.
Наша разработка только-только переходит на этап активного развития, мы нашли финансовую поддержку и вскоре будет реализован на должном уровне обширный список важных на наш взгляд фич и сервисов. К тому же, мы не ориентируемся на рынок СНГ, он подтормаживает, на западе уже давно это активно используется… у нас есть тау-задержки, ну сами знаете вообщем… Просто хочется поддерживать в тонусе и наше ИТ-сообщество. Лично я рад, что у нас появились такие проекты как Scalaxy и Clodo. Народ к ним тоже изначально скептически относился, а сейчас они все больше и больше преобретають доверие клиентов. Но все же, повторюсь, облачные хостинги на западе уже пройденный этап, новый тренд — API Cloud Services + Multi-Cloud
но я как разработчик не готов перейти к созданию серьезного проекта с помощью этого.а когда будете готовы? что лично для вас будет являться тригер-поинтом для готовности перехода?
облачные исчисления экономит деньги только в случае плохих разработчиков. взять и тупо использовать облако не получится, всё же они достаточно медленные без подушек с кэшем.
экономит и в случае плохих и в случае хороших, в случае плохих экономит больше! ведь хорошему разработчику все равно надо делать дополнительный функционал, настраивать инфраструктуру, прочее…
В добавок, сервис кеширования как отдельный сервис заложен в наш роадмап с высоким приоритетом.
взять и тупо использовать облако не получится, всё же они достаточно медленные без подушек с кэшем.согласен на 100%! поэтому кеш есть! это важный элемент системы, сервис скриптинга применительно к шаблонам по умолчанию использует кеширование сгенерированного HTML. В следующей статье будет расширенный пример использования шаблонов и наглядный пример реализации реального сайта на шаблонах.
В добавок, сервис кеширования как отдельный сервис заложен в наш роадмап с высоким приоритетом.
но если у человека есть наработки, то интеграция их займёт примерно столько же времени как и интеграция облака, пускай даже больше, но эти затраты окупятся быстро потому что не нужно платить за трафик, а затем по мере роста переделывать, чтобы не разоряться на облаке.
я как не эксперт в хайлодах с трудом оцениваю разницу в цене и времени между развёртыванием своих маштабируемых наработок. но я точно знаю, что плохой программист умрёт на системе эффективного кэширования.
я как не эксперт в хайлодах с трудом оцениваю разницу в цене и времени между развёртыванием своих маштабируемых наработок. но я точно знаю, что плохой программист умрёт на системе эффективного кэширования.
согласен. если есть наработки, которые перекрывают бОльшую часть функционала платформы, и которые архитектурно спроектированы и реализованы с возможностью масштабирования без переделок, тогда естественно стоит использовать свои наработки.
Но все же возникают другие вопросы:
— код имеет свойство устаревать, необходима периодическая актуализация кода, обновление библиотек, рефакторинг
— функциональность проекта имеет свойство расширятся, поэтому потребуются создание новых базовых наработок
— использование наработок одного персонального программиста ставит под удар проект в случае выхода программиста из команды, требуется составление тех. документации
— интеграция со сторонними наработками внутри платформы или другими платформами будет на порядки проще, если это предусмотрено в платформе, по отношению использования своих наработок
— расширение общей сервисной шины — автоматически дает доступ вам к новым функциональным возможностям
— другие моменты…
вообщем, лично мое мнение: все, что не отличает мое приложение от других приложений — лучше отдать на сопровождение специалистам, которым нравится этим заниматься, а самому заняться созданием «изюма».
Но все же возникают другие вопросы:
— код имеет свойство устаревать, необходима периодическая актуализация кода, обновление библиотек, рефакторинг
— функциональность проекта имеет свойство расширятся, поэтому потребуются создание новых базовых наработок
— использование наработок одного персонального программиста ставит под удар проект в случае выхода программиста из команды, требуется составление тех. документации
— интеграция со сторонними наработками внутри платформы или другими платформами будет на порядки проще, если это предусмотрено в платформе, по отношению использования своих наработок
— расширение общей сервисной шины — автоматически дает доступ вам к новым функциональным возможностям
— другие моменты…
вообщем, лично мое мнение: все, что не отличает мое приложение от других приложений — лучше отдать на сопровождение специалистам, которым нравится этим заниматься, а самому заняться созданием «изюма».
У Вас в заголовке «развии PaaS».
разработка прямо в облаке, без деплоя — проблема деплоя решена — его вообще нет
компиляция происходит прямо на серверах платформы, изменения кода сразу же после сохранения скрипта отражаются на результатах работы
Вот это я бы расценивал как недостаток.
Выделенная фаза деплоя позволяет контролиовать изменения попадающие в продакшн и защищает от соблазна поправить побырому без тестирования.
компиляция происходит прямо на серверах платформы, изменения кода сразу же после сохранения скрипта отражаются на результатах работы
Вот это я бы расценивал как недостаток.
Выделенная фаза деплоя позволяет контролиовать изменения попадающие в продакшн и защищает от соблазна поправить побырому без тестирования.
да, вы правы, выкатывать продакшин на скорую руку — копать под себя яму. Вопрос деплоя сложных приложений в облаке приобретает другую форму: у вас будет три приложения dev, demo (test), production. Переход от одной стадии к другой — будет осуществятся простой сменой ролей (флагов, параметров) или простым клонированием. Как только ваш dev или demo будет готов к переходу в прадакшин, вы меняете его флаг — все запросы автоматом перенаправляются на нужное приложение. Этот механизм непосредственно в Hivext в стадии реализации и официально не выложен, имеет высокий приоритет в roadmap.
Под фразой — «нет деплоя», я имел ввиду не деплой в продакшин, а деплой новой версии при разработки. Ведь при каждых изменениях, к примеру в Java, зачастую приходится делать redeploy. Есть библиотеки, которые решают этот же вопрос, к примеру www.zeroturnaround.com/jrebel/. Именно этот момент имелся в виду.
Под фразой — «нет деплоя», я имел ввиду не деплой в продакшин, а деплой новой версии при разработки. Ведь при каждых изменениях, к примеру в Java, зачастую приходится делать redeploy. Есть библиотеки, которые решают этот же вопрос, к примеру www.zeroturnaround.com/jrebel/. Именно этот момент имелся в виду.
Странный обзор какой-то. Вы пишете о PaaS, игнорируя Windows Azure и Google Apps Engine — фактически основных игроков.
2/3 обзора — это общие понятия про технологии и экономию, которые применимы к Azure, GAE, Hivext и другим. Все три указаны в представителях платформ.
1/3 обзора — информация про нашу разработку, про то что делается в кузнях СНГ. Про Azure и GAE написано много других обзоров, про Hivext инфы очень, вот и восстанавливаем справедливость. Разве вам не интересно могут ли наши разработчики предложить достойную альтернативу западным продуктам? Причем хочу заметить никакого слизывания, Hivext развивается с 2008 года, когда GAE еще не был анонсирован.
1/3 обзора — информация про нашу разработку, про то что делается в кузнях СНГ. Про Azure и GAE написано много других обзоров, про Hivext инфы очень, вот и восстанавливаем справедливость. Разве вам не интересно могут ли наши разработчики предложить достойную альтернативу западным продуктам? Причем хочу заметить никакого слизывания, Hivext развивается с 2008 года, когда GAE еще не был анонсирован.
> Бытует мнение, что облачные платформы в недалеком будущем станут раем для приложений, и рано или поздно почти все приложения будут жить «на небесах».
Примерно то же говорили про ООП, компонентное ПО, потом SOA, «облака», SaaS, теперь PaaS. История повторяется. :)
> В основном, платформы разделяют на три группы, относительно уровня виртуализации:
> * Облачные хостинги
> * Облачные контейнеры
> * Облачные сервисы
Получается, что платформы классифицируются по признаку «виртуализации». «Хостинги» предоставляют ОС, «контейнеры» предоставляют ОС+вебсервер (сервер приложений) и иногда поддержку того или иного ЯП, «сервисы» предоставляют ОС+сервер приложений+ЯП+библиотеки и фреймворки.
> Самая расходная статья это зарплата сотрудников, а если конкретнее, это зарплата программистов и менеджеров.
Наверное, следует читать «в проектах, которые я видел, самая расходная статья была ...»?
У меня есть вопросы по поводу Hivext. Есть ли какой-нибудь REPL (read-eval print loop)? Можно ли разрабатывать и тестировать компоненты приложения независимо друг от друга (в полной изоляции)? Какую работу облегчают сервисы, конкретнее? Допустим, мне очень не нравится вручную разруливать зависимости ресурсов (скрипты, стили для веб-странички), или например, заниматься отловом ошибок, связанных с неправильным экранированием: хочется работать с синтаксическими деревьями, а не с текстом. :)
Также хотелось бы узнать о *недостатках* PaaS и API Облачных сервисов. Почему в статье об этом ни слова?
Примерно то же говорили про ООП, компонентное ПО, потом SOA, «облака», SaaS, теперь PaaS. История повторяется. :)
> В основном, платформы разделяют на три группы, относительно уровня виртуализации:
> * Облачные хостинги
> * Облачные контейнеры
> * Облачные сервисы
Получается, что платформы классифицируются по признаку «виртуализации». «Хостинги» предоставляют ОС, «контейнеры» предоставляют ОС+вебсервер (сервер приложений) и иногда поддержку того или иного ЯП, «сервисы» предоставляют ОС+сервер приложений+ЯП+библиотеки и фреймворки.
> Самая расходная статья это зарплата сотрудников, а если конкретнее, это зарплата программистов и менеджеров.
Наверное, следует читать «в проектах, которые я видел, самая расходная статья была ...»?
У меня есть вопросы по поводу Hivext. Есть ли какой-нибудь REPL (read-eval print loop)? Можно ли разрабатывать и тестировать компоненты приложения независимо друг от друга (в полной изоляции)? Какую работу облегчают сервисы, конкретнее? Допустим, мне очень не нравится вручную разруливать зависимости ресурсов (скрипты, стили для веб-странички), или например, заниматься отловом ошибок, связанных с неправильным экранированием: хочется работать с синтаксическими деревьями, а не с текстом. :)
Также хотелось бы узнать о *недостатках* PaaS и API Облачных сервисов. Почему в статье об этом ни слова?
> У меня есть вопросы по поводу Hivext. Есть ли какой-нибудь REPL (read-eval print loop)?
на данный момент есть Cloud IDE, можно считать что это аналог REPL
> Можно ли разрабатывать и тестировать компоненты приложения независимо друг от друга (в полной изоляции)?
можно разрабатывать приложения независимо друг от друга, а соединять их на уровне сервисов, будет практически одно и тоже. В таком варианте приложения будут выступать аналогом компонентов.
> Какую работу облегчают сервисы, конкретнее?
быстрое создание функционально-насыщенных приложений. К примеру, вам нужно иметь возможность загрузки и обработки фото при разработке Rich Web клиента с использованием JS. В обычном случае вам необходимо примерно следующее:
— на клиенте реализовать асинхронную загрузку файлов на сервер с отображением прогресса передачи
— на сервере реализовать обработку multipart потока данных
— продумать и реализовать структуру файлового хранилища с учетом возможного большого кол-ва фото
— реализовать отдачу на клиент фото по запросу
— реализовать обработку фото на сервере (ресайз, поворот, прочее)
— отладить и оптимизировать все это!
В случае с использованием сервисов — все что требуется это подключить на стороне клиента Hivext JavaScript SDK (маленькая библиотека — врапер API сервисов) и дальше дергать у объекта hivext.data.storage.Uploader методы upload | progress | abort. Тем самым будет задействован спец. сервис файловое хранилище и все вышеописанное вы получаете по умолчанию в готовом и отработанном виде. В ответ от метода upload вам приходит URL по которому можно скачать файл, просмотреть (добавив к URL суфикс /view), сделать ресайз (суфиксы /p100x100, /m100x100, /c100x100 — разные логические варианты), поворот (/r180,/r-90).
Интересно, в таком случае, какова Ваша оценка экономии времени разработки?
Подобным же образом вы получаете отработанную функциональность соответствующую тому или иному сервису — функции сервиса структур (c использованием ORM и возможностью изменение модели данных в Runtime режиме), сервиса прав доступа с гибридной моделью (дискреционная + ролевая), сервиса фоновых задач, сервиса авторизации и других сервисов, набор которых будет постоянно расти.
> Также хотелось бы узнать о *недостатках* PaaS и API Облачных сервисов. Почему в статье об этом ни слова?
ну не знаю… целью статьи донести к читателю где реально можно экономить больше. Самый большой недостаток, который сейчас существует — это зависимость от API и от облачного провайдера, упадет облако или изменится API — заглючит приложение, которое использует сервисы. Провайдеры облачных услуг это понимают и стараются максимально снизить риски.
P.S. вам ниже ответ написали по поводу ООП, видать промахнулись местом вставки комментария
на данный момент есть Cloud IDE, можно считать что это аналог REPL
> Можно ли разрабатывать и тестировать компоненты приложения независимо друг от друга (в полной изоляции)?
можно разрабатывать приложения независимо друг от друга, а соединять их на уровне сервисов, будет практически одно и тоже. В таком варианте приложения будут выступать аналогом компонентов.
> Какую работу облегчают сервисы, конкретнее?
быстрое создание функционально-насыщенных приложений. К примеру, вам нужно иметь возможность загрузки и обработки фото при разработке Rich Web клиента с использованием JS. В обычном случае вам необходимо примерно следующее:
— на клиенте реализовать асинхронную загрузку файлов на сервер с отображением прогресса передачи
— на сервере реализовать обработку multipart потока данных
— продумать и реализовать структуру файлового хранилища с учетом возможного большого кол-ва фото
— реализовать отдачу на клиент фото по запросу
— реализовать обработку фото на сервере (ресайз, поворот, прочее)
— отладить и оптимизировать все это!
В случае с использованием сервисов — все что требуется это подключить на стороне клиента Hivext JavaScript SDK (маленькая библиотека — врапер API сервисов) и дальше дергать у объекта hivext.data.storage.Uploader методы upload | progress | abort. Тем самым будет задействован спец. сервис файловое хранилище и все вышеописанное вы получаете по умолчанию в готовом и отработанном виде. В ответ от метода upload вам приходит URL по которому можно скачать файл, просмотреть (добавив к URL суфикс /view), сделать ресайз (суфиксы /p100x100, /m100x100, /c100x100 — разные логические варианты), поворот (/r180,/r-90).
Интересно, в таком случае, какова Ваша оценка экономии времени разработки?
Подобным же образом вы получаете отработанную функциональность соответствующую тому или иному сервису — функции сервиса структур (c использованием ORM и возможностью изменение модели данных в Runtime режиме), сервиса прав доступа с гибридной моделью (дискреционная + ролевая), сервиса фоновых задач, сервиса авторизации и других сервисов, набор которых будет постоянно расти.
> Также хотелось бы узнать о *недостатках* PaaS и API Облачных сервисов. Почему в статье об этом ни слова?
ну не знаю… целью статьи донести к читателю где реально можно экономить больше. Самый большой недостаток, который сейчас существует — это зависимость от API и от облачного провайдера, упадет облако или изменится API — заглючит приложение, которое использует сервисы. Провайдеры облачных услуг это понимают и стараются максимально снизить риски.
P.S. вам ниже ответ написали по поводу ООП, видать промахнулись местом вставки комментария
> на данный момент есть Cloud IDE, можно считать что это аналог REPL
Посмотрел — интересно, правда, REPL не нашел.
> К примеру, вам нужно иметь возможность загрузки и обработки фото при разработке Rich Web клиента с использованием JS.
Получается, что в этом случае есть уже что-то готовое, а интеграцию сервера и клиента уже решили. А если нет? Процесс разработки чем-нибудь различается?
Ваши API позволяют как-нибудь *снизить* количество возможных ошибок в коде пользователя? Для примера: допустим, понятно, что вызывать fopen() с пустым именем файла — это напрашиваться на неприятности. Hivext может с этим помочь, предоставив какие-нибудь средства для анализа/проверки?
> Интересно, в таком случае, какова Ваша оценка экономии времени разработки?
В данном случае существенная, но меня интересует самый худший вариант: когда ничего нет, ничего не подходит, нужно написать свое. (Ни в коем случае не хочу говорить, что только такие варианты имеют место быть.)
> ну не знаю… целью статьи донести к читателю где реально можно экономить больше.
Когда пишут, что все просто отлично, то у меня, например, возникает чувство, что где-то накалывают. :) Поэтому такой вопрос.
Посмотрел — интересно, правда, REPL не нашел.
> К примеру, вам нужно иметь возможность загрузки и обработки фото при разработке Rich Web клиента с использованием JS.
Получается, что в этом случае есть уже что-то готовое, а интеграцию сервера и клиента уже решили. А если нет? Процесс разработки чем-нибудь различается?
Ваши API позволяют как-нибудь *снизить* количество возможных ошибок в коде пользователя? Для примера: допустим, понятно, что вызывать fopen() с пустым именем файла — это напрашиваться на неприятности. Hivext может с этим помочь, предоставив какие-нибудь средства для анализа/проверки?
> Интересно, в таком случае, какова Ваша оценка экономии времени разработки?
В данном случае существенная, но меня интересует самый худший вариант: когда ничего нет, ничего не подходит, нужно написать свое. (Ни в коем случае не хочу говорить, что только такие варианты имеют место быть.)
> ну не знаю… целью статьи донести к читателю где реально можно экономить больше.
Когда пишут, что все просто отлично, то у меня, например, возникает чувство, что где-то накалывают. :) Поэтому такой вопрос.
а интеграцию сервера и клиента уже решили. А если нет? Процесс разработки чем-нибудь различается?что конкретно имеете ввиду, можно на примере?
Ваши API позволяют как-нибудь *снизить* количество возможных ошибок в коде пользователя? Для примера: допустим, понятно, что вызывать fopen() с пустым именем файла — это напрашиваться на неприятности. Hivext может с этим помочь, предоставив какие-нибудь средства для анализа/проверки?кол-во ошибок можно снизить за счет уменьшения кол-ва кода, что в свою очередь уменьшается использованием готовых блоков (сервисов). Отлов ошибок в коде на этапе компиляции зависит от реализации конкретного ЯП. Вообщем это задача создателей того или иного ЯП. Однако, мы предоставляем другие возможности при разработке — к примеру можно узнать сколько времени и сколько раз выполняется каждая строка скрипта. Для этого нужно только вызвать метод DebugTime в сервисе скриптинга (В ИДЕ пока не интегрировано). Так же будут другие плюшки по подобии профайлера с доступностью одного клика.
меня интересует самый худший вариант: когда ничего нет, ничего не подходит, нужно написать свое. (Ни в коем случае не хочу говорить, что только такие варианты имеют место быть.)такие варианты имеют место быть! это значит что вы создаете именно то, что отличает ваше приложение от других — это ваш цимус — ваша бизнес логика. В данном случае можно использовать синтаксис любимого ЯП (пока PHP, JS, Java) и писать код как обычно.
> Примерно то же говорили про ООП…
И что, это действительно круто все так же программировать функции, а не объекты?
И что, это действительно круто все так же программировать функции, а не объекты?
>> Примерно то же говорили про ООП…
> И что, это действительно круто все так же программировать функции, а не объекты?
Странный скачок в рассуждениях. Мое предложение было про то, что у ООП тоже есть проблемы, и не везде оно применимо. Ваше предложение — противопоставление функций и объектов, да еще и с «круто»/«не круто». В чем ваш пойнт?
> И что, это действительно круто все так же программировать функции, а не объекты?
Странный скачок в рассуждениях. Мое предложение было про то, что у ООП тоже есть проблемы, и не везде оно применимо. Ваше предложение — противопоставление функций и объектов, да еще и с «круто»/«не круто». В чем ваш пойнт?
У меня глупый вопрос, но он мне мешает жить последние три дня. Вопрос про Амазон EC2 такой: я правильно понимаю, что эта платформа позволяет свою разработку поверх всех уже зашитых в нее сервис АПИ — или нет? что дает (не дает) SDK? например, если нужно что-то сложное сконструировать подо что нету готового апи — например — таск — кусок одного дизайна в онлайне прикручивать (пользовательским интерфейсом) к другому куску дизайна или изображению — это возможно программными средствами?
EC2 — это облачный хостинг, это первая группа указанная в статье. Вам надо настраивать веб-сервер, БД, прочее…
Дока по теме вопроса
Описание набора сервисов
Общая информация про скриптинг
Базовые примеры, в реальности можно делать намного сложнее
если нужно что-то сложное сконструировать подо что нету готового апи — например — таск — кусок одного дизайна в онлайне прикручивать (пользовательским интерфейсом) к другому куску дизайна или изображению — это возможно программными средствами?вот! вот именно для этого Hivext и создан. Мы даем вам набор сервисов для решения типовых задач. Эти сервисы уже готовы и имеют клиентские СДК для разных ЯП, их очень удобно использовать через библиотеки (СДК) или напрямую через АПИ. Если вам чего-то не хватает, вы расширяете сервисы своей логикой используя сервис скриптинга, изнутри которого доступны опять же все сервисы платформы и сервисы других разработчиков.
Дока по теме вопроса
Описание набора сервисов
Общая информация про скриптинг
Базовые примеры, в реальности можно делать намного сложнее
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
API Облачных сервисов — следующий этап в развитии PaaS. Как экономить больше используя облачные платформы