Как стать автором
Обновить
7
Карма
0
Рейтинг

Пользователь

Jelastic Cloud PaaS — статистика использования баз данных MySQL, MariaDB, PostgreSQL и MongoDB

обязательно в следующем месяце выложим, только начали собирать статистику.

Java Cloud Hosting — autoscaling, easy deploy, environment management

все верно! раньше был 256, после тестирования поняли что лучше дробнее шаг делать, тогда маштабирование будет более мелкими шагами (платить меньше клиенту). Поэтому на данный момент клаудлет занимает 128 метров. Через неделю пресс-релиз обновления там и расскажем детальнее про изменения. Есть много интересных новостей.

[Перевод] VMware CloudFoundry: PaaS на Ruby

> Скейлинг делается через горизонтальное масштабирование, т.е. вы резервируется дополнительные инстанцы, и если текущих инстанцов не хватает (сильно загружены), поднимаются автоматом новые инстанцы. И получается кластер на томкатах.
проверяли? где можно почитать тесты или чего-то такое…

> Ну и они пока еще реализуют автоматическое масштабирование памяти на одном инстанце, в процессе это дело.
откуда инфа?

[Перевод] VMware CloudFoundry: PaaS на Ruby

about CloudFoundry scaling:«So, does it auto-scale?»… The answer is «no, but trivially so». goo.gl/oisQE

[Перевод] VMware CloudFoundry: PaaS на Ruby

А про скейлинг ничего не написанно…

True Java Elastic Cloud @ JavaOne — закрытый beta-test

Нет, мы строим на другой базе, нижний уровень виртуализации базируется на Parallels Containers.

True Java Elastic Cloud @ JavaOne — закрытый beta-test

Честно говоря периодически всплывает вопрос про ОпесСорс… В случае приватного клауда ОпенСорс неизбежен.

True Java Elastic Cloud @ JavaOne — закрытый beta-test

В принципе мы и так уже участвуем в национальных программах, которые не считаем попилом. А во вторых, на Амазоне мир не замыкается. Вот одна из наших задач помочь людям осознать это. Железо и подержка будут первоклассные, можете не сомневаться.

True Java Elastic Cloud @ JavaOne — закрытый beta-test

Алексей, спасибо, за нотки пессимизма, это тоже иногда полезно. На счет отличия — во многом мы будем схожы с указанными в статье конкурентами, на то они и конкуренты. Но есть и отличительные особенности. Наиболее глобальным является более высокая степень утилизации ресурсов, что в свою очередь дает более выгодные финансовые показатели. Насчет privat cloud — архитектура изначально планировалась с возможностью реализации private решений. Но будем ли мы сильно идти в эту сторону пока не известно, время покажет…
С удовольствием послушаю завтра коллег из vmforce.

True Java Elastic Cloud @ JavaOne — закрытый beta-test

Именно! Минимум извращений, максимум совместимости. Думаю мы встретимся. Если нет, пишите после конфы в личку — решим вопрос персонально.

True Java Elastic Cloud @ JavaOne — закрытый beta-test

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

True Java Elastic Cloud @ JavaOne — закрытый beta-test

Хорошо, без проблем. Отпишите в личку описание архитектуры вашего приложения, мы вам вышлем ключ доступа.

Вы можете подключать абсолютно любые Jar-ы, нет никаких ограничений! Память масштабируется вверх и вниз в реальном времени. Цены ниже конкурентов, но конкретно пока сказать не можем. Датацентры будут одни из лучших, на данный момент ведутся переговоры с «китами» хостинговых услуг в Европе и Америке. Комерческий релиз запланирован на авгут сего года.

True Java Elastic Cloud @ JavaOne — закрытый beta-test

С какими именно? Приведите конкретное название, дабы не было двоякого понимания…

True Java Elastic Cloud @ JavaOne — закрытый beta-test

Нас будет двое, мы будем «приставать» к некоторым посетителям с вопросами. Можем договориться о персональной встрече, если интересует — пишите в личку.

Кэширование в Google App Engine

а как на счет 1 вопроса :)?

Рейтрейсер на JavaScript

классно! можно прикрутить к серверному JS и потом запустить на компах с GPU

API Облачных сервисов — следующий этап в развитии PaaS. Как экономить больше используя облачные платформы

EC2 — это облачный хостинг, это первая группа указанная в статье. Вам надо настраивать веб-сервер, БД, прочее…
если нужно что-то сложное сконструировать подо что нету готового апи — например — таск — кусок одного дизайна в онлайне прикручивать (пользовательским интерфейсом) к другому куску дизайна или изображению — это возможно программными средствами?
вот! вот именно для этого Hivext и создан. Мы даем вам набор сервисов для решения типовых задач. Эти сервисы уже готовы и имеют клиентские СДК для разных ЯП, их очень удобно использовать через библиотеки (СДК) или напрямую через АПИ. Если вам чего-то не хватает, вы расширяете сервисы своей логикой используя сервис скриптинга, изнутри которого доступны опять же все сервисы платформы и сервисы других разработчиков.
Дока по теме вопроса
Описание набора сервисов
Общая информация про скриптинг
Базовые примеры, в реальности можно делать намного сложнее

Карточный дом

параллель: если в супермаркеты перестанут завозить еду — города вымрут, никто ведь на огороде ничего не сажает. Так что все современные люди в полнейшей физической зависимости от прогресса.

Выпущен релиз Google App Engine SDK 1.4.0

а есть если вообще где-то информация про архитектуру низкого уровня, каким образом приложения крутятся в контейнерах?

API Облачных сервисов — следующий этап в развитии PaaS. Как экономить больше используя облачные платформы

а интеграцию сервера и клиента уже решили. А если нет? Процесс разработки чем-нибудь различается?
что конкретно имеете ввиду, можно на примере?

Ваши API позволяют как-нибудь *снизить* количество возможных ошибок в коде пользователя? Для примера: допустим, понятно, что вызывать fopen() с пустым именем файла — это напрашиваться на неприятности. Hivext может с этим помочь, предоставив какие-нибудь средства для анализа/проверки?
кол-во ошибок можно снизить за счет уменьшения кол-ва кода, что в свою очередь уменьшается использованием готовых блоков (сервисов). Отлов ошибок в коде на этапе компиляции зависит от реализации конкретного ЯП. Вообщем это задача создателей того или иного ЯП. Однако, мы предоставляем другие возможности при разработке — к примеру можно узнать сколько времени и сколько раз выполняется каждая строка скрипта. Для этого нужно только вызвать метод DebugTime в сервисе скриптинга (В ИДЕ пока не интегрировано). Так же будут другие плюшки по подобии профайлера с доступностью одного клика.

меня интересует самый худший вариант: когда ничего нет, ничего не подходит, нужно написать свое. (Ни в коем случае не хочу говорить, что только такие варианты имеют место быть.)
такие варианты имеют место быть! это значит что вы создаете именно то, что отличает ваше приложение от других — это ваш цимус — ваша бизнес логика. В данном случае можно использовать синтаксис любимого ЯП (пока PHP, JS, Java) и писать код как обычно.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность