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