Виртуальный облачный хостинг - посоветуйте, отговорите

https://hostian.ru конечно же !

ps облачнее амазона придумать что то сложно.

Дело не в провайдере.

А в конкретной услуге.

Полноценная VPS и у Гугля - это вовсе не облако, а всего лишь VPS.

А вот какой нибудь Google AppEngine - это 100% облако.

---------- Добавлено 23.10.2018 в 10:30 ----------

Довольно хорошо разжевано как раз именно для разработчика.

https://12factor.net/ru/

---------- Добавлено 23.10.2018 в 10:32 ----------

Вот когда подходят к полноценному облачному хостингу с обычными мерками - потом и удивляются:

"А че так дорого", "А где обещанная отказоустойчивость".

Диск - это всего лишь диск. Этого недостаточно.

"Упала нода, подняли другую, подключились к тому же диску"? Ага, а файловая система значит вас ждет после падения и чиниться сама?

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

А диски значит в эфире живут или железо в них настолько совершенно, что не падает?

Или софт на компьютерах, поддерживающих, скажем, тот же Ceph (файловая система, распределенная между несколькими компьютерами) настолько совершенен, что чинится сам?

Ну если так рассуждать, то все в этом мире это ассемблер - ибо все те же байтики.

Если ОС это облако, то браузер это Google AppEngine, вам не надо писать дрова, но на вас ряд ограничений, просто Google AppEngine это готовая надстройка для удобного использования, вам никто не мешает развернуть свой кубернетес. Облачный провайдер это как раз про организацию инфраструктуры, а не ограничения ПО.

Конкретная услуга "Облако для PHP" - это взяли облако, настроили под PHP и отдали клиенту.

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

А кто говорил что облако это дешево? Или кто говорил что облако это отказоустойчиво? Облако это из уровня HL и быстрой масштабируемости, удобства управления и развертывания. Когда можно запустить тысячи машин, объединить их в кластер Hadoop произвести нужные вычисления и потушить все машины и все это за минуты и в автоматическом режиме.

Всё тут происходящее - это потому что никто не договорился в самом начале о том что же такое это облако.

sgrumi топит за SOA; есть такой подход и у него есть свои плюсы и минусы; SOA хорошо существует в среде из большого количества контейнеров и позволяет (при выполнении ещё ряда доп требований) расширяться и сужаться под нагрузку (и _никто_ не сказал что делать со стейтфулами, все делают костыли из говна и палок, ага)

Aisamiery вообще говорит о хадупе. На searchengines? Серьёзно?

Большинство здесь использует софт из говна и палок, который не спасёт ничего. Какая SOA, о чем вы? Ссуровые монолитные парни на php4 (или близком по качеству уровне кода)

И сейчас вот ещё скажу - для подавляющего большинства проектов SOA и kubernetes-based облака вредны и дороги. Да и нахрен не нужны, если честно.

Потому что получится не очень красивая и очень дорогая в эксплуатации и поддержке игрушка.

Вообще, облако - это настолько обобщённый термин, что каждый его понимает по своему (и я уж не говорю о том, что имеют в виду продажники в каждом конкретном случае).

По хорошему, на этот термин вообще лучше не ориентироваться или, уж если ориентироваться, то лезть очень очень глубоко за подробностями, просто, чтобы не попасть впросак. Вот простой пример - вполне можно обозвать облачным хостингом такое сочетание:

1) Billmanager с поресурсной и почасовой оплатой (реализуем свойственный для облаков биллинг - Pay as you Go)

2) Кластер на iSPmanager с каким-нибудь СХД с балансировщиками нагрузки на HAproxy или хотя бы nginx + мониторинг доступности нод. Собственно, ISPsytem и смастерило же Cloud свой примерно таким же образом.

Вот ничем он для клиента не будет отличаться от навороченного амазона, гугля и т.п. и т.д. хотя там совсем могут применяться другие технические решения для бэкенда. Потому что:

а) У него личный кабинет с тарификацией по ресурсам и часам.

б) У него контрольная панель, где он выбирает нужные ресурсы и ставит лимиты, просматривает статистику.

в) У него высокая доступность его ресурса.

г) У него нет проблем с апгрейдом по процессорам, памяти, диску (так как данные на СХД и переносить на более мощный сервер остается только учетную запись владельца аккаунта, а это секунды занимает).

PS. Уточню, что это я об обычном, рядовом вебмастере. Это не про тех, кто из кубернетов, докеров и прочего подобного не вылазит.

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

SOA - это архитектура, не совсем понятно как оно относится к облаку и инфраструктуре, SOA можно строить и на обычных железных серверах, хоть в одной стойке, хоть в нескольких ДЦ, только это не будет облаком, все же это будет SOA

Это был пример, я не знаю какую задачу в рамках вордпреса кроме self-hosted может помочь решить облако. О более приближенный вариант, на каждую задачу парсера подымать в автомате по инстансу и при завершении убивать инстанс, если есть задача парсить 1000 сайтов, то можно поднять 1000 инстансов спарсить все за пару минут и убрать их. Экономия будет колоссальная, если задачу надо выполнять быстро.

Никто не говорил что это дешево =)) SOA действительно вредна, если она не нужна, то лучше даже не начинать, когда проекту понадобится, перейти из монолита на SOA намного проще чем наоборот.

Отвечу тут, скрывать как бы нечего, надеюсь будет интересно другим тоже.

* По производительности стораджа. Собственно об этом статья на хабре, у нас есть 2 уровня дисковой производительности.

По умолчанию, все контейнеры, запущенные на облачной платформе, получают дисковую производительность первого уровня «Базовый Storage» - Tier I: disk.io - до 250 Mb/s; iops – до 200 o/s. Стоимость: 0,01 руб/час. Первые 10 Гб в каждом окружении бесплатно.

Более высокие показатели дисковой производительности можно получить, заказав услугу «Премиум Storage» для выбранных контейнеров - Tier II: disk.io - до 400 Mb/s; iops - до 20 000 o/s. Стоимость: 0,03 руб/час

Важные моменты:

- Оплата идет по факту использования места. Сколько реально Гб используете каждый час столько и списывается.

- Окружений может быть несколько. На каждый изначально дается первые 10 Гб места бесплатно базового стораджа

- Включать и выключать премиум сторадж можно на каждый контейнер (которых может быть несколько в рамках одного окружения)

- i/o лимиты даются на каждый контейнер. Если у нас кластер из 3 MySQL на премиум сторадже, то каждый контейнер получается до 20к iops.

Проблемы шумных соседей и в целом производительности сторадж решаются лимитами на каждый контейнер (то что я написал выше), а также увеличение количество чанк серверов (т.е. количество физических ssd/nvme). Чем их больше тем больше общая производительность.

Калькулятор на сайте дает индикацию и не предназначен для получения каких-то финальных цен, ибо их невозможно получить в таком виде по определению.

Именно поэтому мы предлагаем бесплатный триал на 2 недели, в течении которых можно спокойно поставитьи оценить реальные нагрузки и их стоимость. Для более сложных проектов мы готовы предоставлять расширенные пробные периоды вплоть до 90 дней.

CPU usage работает по CGroup лимитам и данным реального потребления CPU в контейнерах и соответствено от этого считается и потребление. Если у Вас не специфические проекты на CPU (типа майнинг или какие-то вычисления) то вряд ли Вы будете упираться в CPU в принципе. В любом случае, пока не протестируете реально - сказать мало чего можно.

И последнее, под разные задачи есть разные решения. Есть задачи, под которые будет лучше поставить распределенно кучку серверов с локальными nvme для создания кластеров на уровне приложения. Другими словами, частное облако, на выделенном оборудовании. Ну и наоборот, есть задачи где виртуального хостинга с головой.

Судя по дискуссии - есть. Облако - это инфраструктура. Но под "облаком" подразумевают очень разное. От самых первых попыток виртуализации до гиперконвергентных систем и оркестрации. Можно долго ломать копья, а потом выяснится, что сравнивали xen с кубером.

Очевидно. Там буква А на конце не для красоты)

SOA (сервисно-ориентированная архитектура) позволяет, при правильной реализации, упростить процесс горизонтального масштабирования систем. Горизонтальное масштабирование в длинных периодах делается железно, в коротких - облаками.

Ну и, ещё момент, когда у нас SOA с оркестрацией - можно легко утилизировать имеющееся железо путем переброски мощностей между сервисами, что улучшает TCO.

Именно поэтому так активно и растёт девопс (кроме того что это же круто и гугл так делает (тм) ) - можно лучше утилизировать гудящие железки в стойках и меньше падать.

Кстати, по опыту очень многих моих знакомых команд, на long-run SOA может очень больно выстрелить в ногу на 50+ сервисах. Очень. С космической стоимостью поддержки и развития.

Ещё можно быстро переезжать между хостерами и удобно бэкапиться.

Вопрос - а где эта точка? Я пока не слышал ни одного кейса, когда успешный продукт с SOA уходил в монолиты. Обратное происходит, но весьма неспешно и далеко не у всех.

И опять же: TCO - король. Если делать приложуху с SOA на входе в 1.5-2 раза дороже, но гипотетически через 4 года нас это будет ограничивать, то бог бы с ним. Давайте хоть заработаем для начала: "In the long run we are all dead"

Это зависит от реализации конкретных решений, маркетинг тут не причем.

В типовой стандартной ситуации все что требуется для работы приложения в облаке - это убедится что все сервисы стоят в autoboot. Чтобы в случае ситуации когда в облаке падает физическая нода и виртуальная машина/контейнер стартует на другой оборудовании, у него все стартануло как нужно.

Второе что нужно помнить - это приложения которые держат данные в памяти. Классический пример - базы данных. В этой ситуации есть вероятность что они не поднимутся после такого рестарта. Решается использованием SaaS готовых решений (как у амазон) или созданием собственных кластеров (например тот же Galera из 3 нод). Опять же отсылаю на запись конференции, там как раз об этом речь и идет. Или если из Москвы приходите в ноябре https://www.devopspro.ru/andrey-nesterenko/ где будет об этом же речь.

Это не проблема облака как такового, и этим нужно заниматься независимо от выбора способа хостинга.

А что с latency - медиана, 90p, 99p, стандартное отклонение? И как меряете иопсы: размер блока, глубина очереди?