> У меня есть вопросы по поводу 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. вам ниже ответ написали по поводу ООП, видать промахнулись местом вставки комментария
2/3 обзора — это общие понятия про технологии и экономию, которые применимы к Azure, GAE, Hivext и другим. Все три указаны в представителях платформ.
1/3 обзора — информация про нашу разработку, про то что делается в кузнях СНГ. Про Azure и GAE написано много других обзоров, про Hivext инфы очень, вот и восстанавливаем справедливость. Разве вам не интересно могут ли наши разработчики предложить достойную альтернативу западным продуктам? Причем хочу заметить никакого слизывания, Hivext развивается с 2008 года, когда GAE еще не был анонсирован.
да, вы правы, выкатывать продакшин на скорую руку — копать под себя яму. Вопрос деплоя сложных приложений в облаке приобретает другую форму: у вас будет три приложения dev, demo (test), production. Переход от одной стадии к другой — будет осуществятся простой сменой ролей (флагов, параметров) или простым клонированием. Как только ваш dev или demo будет готов к переходу в прадакшин, вы меняете его флаг — все запросы автоматом перенаправляются на нужное приложение. Этот механизм непосредственно в Hivext в стадии реализации и официально не выложен, имеет высокий приоритет в roadmap.
Под фразой — «нет деплоя», я имел ввиду не деплой в продакшин, а деплой новой версии при разработки. Ведь при каждых изменениях, к примеру в Java, зачастую приходится делать redeploy. Есть библиотеки, которые решают этот же вопрос, к примеру www.zeroturnaround.com/jrebel/. Именно этот момент имелся в виду.
согласен. если есть наработки, которые перекрывают бОльшую часть функционала платформы, и которые архитектурно спроектированы и реализованы с возможностью масштабирования без переделок, тогда естественно стоит использовать свои наработки.
Но все же возникают другие вопросы:
— код имеет свойство устаревать, необходима периодическая актуализация кода, обновление библиотек, рефакторинг
— функциональность проекта имеет свойство расширятся, поэтому потребуются создание новых базовых наработок
— использование наработок одного персонального программиста ставит под удар проект в случае выхода программиста из команды, требуется составление тех. документации
— интеграция со сторонними наработками внутри платформы или другими платформами будет на порядки проще, если это предусмотрено в платформе, по отношению использования своих наработок
— расширение общей сервисной шины — автоматически дает доступ вам к новым функциональным возможностям
— другие моменты…
вообщем, лично мое мнение: все, что не отличает мое приложение от других приложений — лучше отдать на сопровождение специалистам, которым нравится этим заниматься, а самому заняться созданием «изюма».
экономит и в случае плохих и в случае хороших, в случае плохих экономит больше! ведь хорошему разработчику все равно надо делать дополнительный функционал, настраивать инфраструктуру, прочее…
взять и тупо использовать облако не получится, всё же они достаточно медленные без подушек с кэшем.
согласен на 100%! поэтому кеш есть! это важный элемент системы, сервис скриптинга применительно к шаблонам по умолчанию использует кеширование сгенерированного HTML. В следующей статье будет расширенный пример использования шаблонов и наглядный пример реализации реального сайта на шаблонах.
В добавок, сервис кеширования как отдельный сервис заложен в наш роадмап с высоким приоритетом.
Если вы относительно Hivext, то многое зависит от того, какую конкретно задачу вы решаете… один из проектов моего знакомого, на который он тратит много денег на 80% покрывается функционалом платформы, т.е. если бы он делал на базе сервисов платформы, то сэкономил бы значительное кол-во времени и денег. Это реальный, не выдуманный пример из жизни. Когда он запускал проект, он не знал о нас. И такой пример в моем опыте не один…
CMS и библиотеки — да! отчасти решают те же задачи. Однако, сервисы с API более гибки со стороны разработки, при этом более мощны с функциональной точки зрения, улучшаясь разработчиками платформы автоматически улучают работу вашего приложения, + масштабируемость, + средства для диагностики, а также многое другое что не доступно по умолчанию и без дополнительных потерь своих сил при использовании CMS и библиотек.
Наша разработка только-только переходит на этап активного развития, мы нашли финансовую поддержку и вскоре будет реализован на должном уровне обширный список важных на наш взгляд фич и сервисов. К тому же, мы не ориентируемся на рынок СНГ, он подтормаживает, на западе уже давно это активно используется… у нас есть тау-задержки, ну сами знаете вообщем… Просто хочется поддерживать в тонусе и наше ИТ-сообщество. Лично я рад, что у нас появились такие проекты как Scalaxy и Clodo. Народ к ним тоже изначально скептически относился, а сейчас они все больше и больше преобретають доверие клиентов. Но все же, повторюсь, облачные хостинги на западе уже пройденный этап, новый тренд — API Cloud Services + Multi-Cloud
но я как разработчик не готов перейти к созданию серьезного проекта с помощью этого.
а когда будете готовы? что лично для вас будет являться тригер-поинтом для готовности перехода?
skip-external-locking —… когда несколько серверов работают с одними и теми же файлами данных, т.е. имеют одинаковую datadir, что на практике не используется
почему не используется? и для чего вообще предназначено было с практической точки зрения? для поднятия двух инстансов БД на разных физических компах, которые работают с одними и теми же данными? если да, то о существовании подобного решения спрашивал у одного моего знакомого специалиста, он не знал о такой возможности
> Разработчик получает очень высокоуровневые методы, что упрощают разработку
это круто, сервисное программирование в подобном виде радует скоростью и простотой разработки, даже при наличии некоторых ограничений в большинстве случаев базовых функций хватает с головой
проще говоря:
потому что избавляет вас думать вообще про уровень инфраструктуры
потому что ресурсы на ваше приложение реально выдаются только по необходимости, а при простое вообще выгружается приложение из памяти
“On-demand self service” — принцип доступности любого объема услуг.
“Ubiquitous network access” — принцип сетевой доступности.
“Metered use” — принцип оплаты по факту.
“Elasticity” — принцип гибкости закупки.
“Resource pooling” — принцип независимости от «железа».
уважаемый, во время приготовления пищи важно знать для чего служит каждый «нож» и важно уметь пользоваться этими ножами.
Nginx не может быть лекарством от всех болезней.
Апач может справляться с большими нагрузками, кроме нас его использует VMWare, он входит в состав VMware vFabric Cloud Application Platform, а именно Enterprise Ready Apache Web Server. На данный момент решение на базе Апач нас полностью удовлетворяет.
> тестеры уже выявили проблемы у tomcat'а.
если вы про ограничение памяти при запуске, то это не проблемы, а архитектура. если вы про падение, тогда явно есть проблемы, в нормальном режиме работы tomcat не падает.
желаю вам скорейшего выздоровления.
и вообще эта опция динамического выделения памяти востребована кем-то?
на данный момент есть 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. вам ниже ответ написали по поводу ООП, видать промахнулись местом вставки комментария
1/3 обзора — информация про нашу разработку, про то что делается в кузнях СНГ. Про Azure и GAE написано много других обзоров, про Hivext инфы очень, вот и восстанавливаем справедливость. Разве вам не интересно могут ли наши разработчики предложить достойную альтернативу западным продуктам? Причем хочу заметить никакого слизывания, Hivext развивается с 2008 года, когда GAE еще не был анонсирован.
Под фразой — «нет деплоя», я имел ввиду не деплой в продакшин, а деплой новой версии при разработки. Ведь при каждых изменениях, к примеру в Java, зачастую приходится делать redeploy. Есть библиотеки, которые решают этот же вопрос, к примеру www.zeroturnaround.com/jrebel/. Именно этот момент имелся в виду.
Но все же возникают другие вопросы:
— код имеет свойство устаревать, необходима периодическая актуализация кода, обновление библиотек, рефакторинг
— функциональность проекта имеет свойство расширятся, поэтому потребуются создание новых базовых наработок
— использование наработок одного персонального программиста ставит под удар проект в случае выхода программиста из команды, требуется составление тех. документации
— интеграция со сторонними наработками внутри платформы или другими платформами будет на порядки проще, если это предусмотрено в платформе, по отношению использования своих наработок
— расширение общей сервисной шины — автоматически дает доступ вам к новым функциональным возможностям
— другие моменты…
вообщем, лично мое мнение: все, что не отличает мое приложение от других приложений — лучше отдать на сопровождение специалистам, которым нравится этим заниматься, а самому заняться созданием «изюма».
согласен на 100%! поэтому кеш есть! это важный элемент системы, сервис скриптинга применительно к шаблонам по умолчанию использует кеширование сгенерированного HTML. В следующей статье будет расширенный пример использования шаблонов и наглядный пример реализации реального сайта на шаблонах.
В добавок, сервис кеширования как отдельный сервис заложен в наш роадмап с высоким приоритетом.
CMS и библиотеки — да! отчасти решают те же задачи. Однако, сервисы с API более гибки со стороны разработки, при этом более мощны с функциональной точки зрения, улучшаясь разработчиками платформы автоматически улучают работу вашего приложения, + масштабируемость, + средства для диагностики, а также многое другое что не доступно по умолчанию и без дополнительных потерь своих сил при использовании CMS и библиотек.
Наша разработка только-только переходит на этап активного развития, мы нашли финансовую поддержку и вскоре будет реализован на должном уровне обширный список важных на наш взгляд фич и сервисов. К тому же, мы не ориентируемся на рынок СНГ, он подтормаживает, на западе уже давно это активно используется… у нас есть тау-задержки, ну сами знаете вообщем… Просто хочется поддерживать в тонусе и наше ИТ-сообщество. Лично я рад, что у нас появились такие проекты как Scalaxy и Clodo. Народ к ним тоже изначально скептически относился, а сейчас они все больше и больше преобретають доверие клиентов. Но все же, повторюсь, облачные хостинги на западе уже пройденный этап, новый тренд — API Cloud Services + Multi-Cloud
а когда будете готовы? что лично для вас будет являться тригер-поинтом для готовности перехода?
почему не используется? и для чего вообще предназначено было с практической точки зрения? для поднятия двух инстансов БД на разных физических компах, которые работают с одними и теми же данными? если да, то о существовании подобного решения спрашивал у одного моего знакомого специалиста, он не знал о такой возможности
это круто, сервисное программирование в подобном виде радует скоростью и простотой разработки, даже при наличии некоторых ограничений в большинстве случаев базовых функций хватает с головой
потому что избавляет вас думать вообще про уровень инфраструктуры
потому что ресурсы на ваше приложение реально выдаются только по необходимости, а при простое вообще выгружается приложение из памяти
“On-demand self service” — принцип доступности любого объема услуг.
“Ubiquitous network access” — принцип сетевой доступности.
“Metered use” — принцип оплаты по факту.
“Elasticity” — принцип гибкости закупки.
“Resource pooling” — принцип независимости от «железа».
Примеры
Туториалы
скоро будет больше
Nginx не может быть лекарством от всех болезней.
Апач может справляться с большими нагрузками, кроме нас его использует VMWare, он входит в состав VMware vFabric Cloud Application Platform, а именно Enterprise Ready Apache Web Server. На данный момент решение на базе Апач нас полностью удовлетворяет.
Hivext как раз таки в частности и предназначен для быстрого прототипирования и проверки идей
если вы про ограничение памяти при запуске, то это не проблемы, а архитектура. если вы про падение, тогда явно есть проблемы, в нормальном режиме работы tomcat не падает.
желаю вам скорейшего выздоровления.
и вообще эта опция динамического выделения памяти востребована кем-то?