Shared Hosting vs Облака
Давайте сравним shared hosting и облачную систему хранения данных.
Для начала — вспомним одну любопытную и достаточно основополагающую историю из общего курса экономики. В 70-х годах прошлого века, один предприимчивый человек, будущий лауреат Нобелевской премии, Джордж Акерлоф описал новаторскую модель экономики. Он назвал ее — «Рынок лимонов», заранее давая понять, о чем она будет. Итак, что он сделал? Он рассмотрел рынок подержанных автомобилей. Как и сейчас, 40 лет назад на этом рынке продавались не только те автомобили, хозяева которых лелеяли и заботились о своих машинах, но и те, которые были в достаточно плохом состоянии. Именно последние и получили название «лимонов». Вся модель упиралась в один важный факт — покупатель никогда до конца не знает, покупает ли он «лимон» или хороший добротный автомобиль.
Логично, что на самом деле эта проблема решается достаточно просто — нужно было всего лишь указать ВСЕ волнующее параметры потенциальной покупки — не только пробег, но, скажем, и моторесурс. Чем меньше параметров потенциально покупки мы задаем, тем больше есть вероятность того, что она нас не удовлетворит.
Это же правило очень хорошо работает и, например, с shared хостингами. Много памяти в пакете? Получите в довесок медленные SATA диски. SSD хостинг? В довесок процессор на Atom. И прочие неприятные комбинации.
Если мы не указываем конкретных параметров отбора по необходимым нам критериям — то, согласно «закону лимонов» мы получаем неликвид по критериям, которые мы забыли.
Чем же нам это грозит в случае облачных сервисов?
Параметры, которые нам действительно должны быть важны — это тактовая частота процессора, скорость шины, тип памяти, объем и ECC. Но что мы видим в описаниях? Объём места (без iops), количество ядер (каких ядер?), объём ОЗУ… Выходит, что мы видим лишь «маркетинговые» параметры, которые, на самом деле, никакой погоды не делают. А это значит, что большинство попыток сравнить облачные сервисы в лоб (например, по прайсу) — обречены на провал или махинацию. Вот она — победа маркетинга в IT! Мы перестали смотреть в суть облака, а лишь меряем маркетинговые величины.
Поэтому, начиная выбирать по принципу — мне побольше ОЗУ и подешевле, мы попадем в заранее расставленную ловушку. Но зачем облаку скрывать своё реальное железо?
Давайте разберем это на примере провайдера. Скажем, я региональный провайдер, имеющий 1гб выделенный канал. Я продаю его двадцати пользователям — как гигабитный (или 40а, как повезёт). Если все они одновременно не включат торрент, способный забить весь канал, то никто и не заметит, что гигабит давно коммунальный, а не его личный.
То же самое делает и shared hosting — продавая место и память. На самом же деле, далеко не все сайты постоянно кто-то смотрит — и, в итоге, они могут один сервер продать шесть/семь раз.
Примерно так же работает и «облако». Переход к У.Е. позволяет нам потерять из виду реально потребляемые ресурсы и начать измерять мир «в попугаях». Эта же система позволяет продать нам один сервер несколько раз. И из-за этого мы получаем ещё одну неизвестную переменную в работе с облаком. Мы не знаем сколько на самом деле у облака ресурсов, как они загружены на данный момент. Мы даже не знаем, сколько реальных ресурсов потребляем сами.
Отчасти понимая проигрышность такой системы, большинство облачных сервисов пытается привязать к себе дополнительными услугами. К примеру, пользуясь облаком Amazon, вы моментально станете пользователем их балансировщика и т.д. Выделенные сервера — одинаковые у всех поставщиков. От этого — невысокая маржа и большая конкуренция. Но облака же пока — у всех персональные.
В то же время, CloudZZ — облако, ориентированное на качество работы 1С. Благодаря постоянному мониторингу и оригинальным технологиям, позволяющим хранить данные компактнее, CloudZZ является не только быстрой 1С-ориентированной системой, но и самой надежной для наших пользователей. Например, в случае отказа одного из хранилищ данных, облако возьмет копию из резервного хранилища. Это произойдет без задержки — и даже без отключения пользователей. После восстанавления работы отказавшего хранилища, данные так же автоматически будут заменены на актуальные. Весь процесс проходит без вмешательства людей. Эта система позволяет не только поддерживать 100% целостность данных и непрерывную работоспособность, но и возможность «откатывать» изменения данных, на несколько часов, дней, недель. А еще можно выключить доступ ко всей базе данных одним нажатием кнопки на телефоне, так… — на всякий случай ;)
