Комментарии 57
Проблемы с авторизацией. В логах не пишутся (по понятным причинам) имена пользователей и пароли, а то, что видит по ссылке человек с правильной кукой может разительно отличаться от содержимого для анонима.
Да, там вообще масса тонкостей выплывает. В логах ещё и полные GET-запросы не всегда пишутся. Конкретно с авторизацией, к примеру, можно решить, проставив виртуальному сайту «автоматически залогиненного юзера» и сравнив получающиеся числа с «анонимными посещениями».
юзеру? Одному? А ничего, что у пользователя а get выполняется за 0.01с, а у пользоваетя b за 0.9с?
Стоп-стоп-стоп, у меня нет реального сайта с такими закидонами и реального облачного хостинга под руками. Я не могу спорить о конкретных числах на абстрактных примерах на основе несуществующего опыта.
Мой текст — это идея о виртуальной проверке реального сайта реальным логом, которая даст бОльшую точность, чем «абстрактный вордпресс с тысячью абстрактных юзеров» из кейсов. Даст не бесплатно, а в обмен на усложнение процедуры (в том числе и за счёт вот таких тонкостей, с которыми должен будет справляться клиент-вебмастер, а не хостер). Даст не абсолютную точность, но всё-таки повыше, как мне кажется.
Мой текст — это идея о виртуальной проверке реального сайта реальным логом, которая даст бОльшую точность, чем «абстрактный вордпресс с тысячью абстрактных юзеров» из кейсов. Даст не бесплатно, а в обмен на усложнение процедуры (в том числе и за счёт вот таких тонкостей, с которыми должен будет справляться клиент-вебмастер, а не хостер). Даст не абсолютную точность, но всё-таки повыше, как мне кажется.
Подобную задачу можно решить поставив прокси напримаер от tsung, правда он ориентирован на прикручивание к конкретному браузеру, но направление движения думаю понятно.
После этого воспроизвести все POST, GET, HEAD и другие типы запросов, а также все заголовки включая куки, если присутствуют в полном соответствии.
После этого воспроизвести все POST, GET, HEAD и другие типы запросов, а также все заголовки включая куки, если присутствуют в полном соответствии.
1. «Новички», берите VPS и не страдайте «облаками»;
2. Шансов на то, что Ваша идея перевернет мир — очень мало, и если такое случится — Ваши пользователи будут спокойно терпеть простои, пока Вы будете улучшать архитектуру (такое происходило с twitter, с flickr и еще с морем других сервисов);
3. Есть совершенно реальные пути улучшения архитектуры от простой до супер-навороченной и они не начинаются с облаков, iops и т.п.: 1 vps -> 1 сервер -> 3 сервера (приложение, база данных, статика) -> увеличение количества серверов баз банных через репликацию, увеличение числа серверов приложений и какой-нибудь nginx перед ними… но реально говоря, даже 3 сервера (сервер приложения, сервер с базой данных, сервер статики) Вам дадут ТАКОЙ мощный запас мощности, что надолго хватит — десятки миллионов запросов в день — на настолько уж нереально на трех современных серверах, за которые Вы будете платить фиксированную сумму без учета всяких IOPS и прочего (только траффик, но он более чем предсказуем на такой посещаемости);
4. «сайт на вордпрессе с 10к хостов в день генерирует вот такой профиль загрузки»
Сайты в облаках (а только они и берут за CPU, IOPS и т.п.) — они для тех, кто УЖЕ точно знает сколько у него будет IOPS, и прочего.
4а. «вот такой профиль загрузки» один хреново написанный плагин для вашего вордпресса и профиль будет СОВСЕМ другой; а может Вы посередине какой-нибудь страницы захотите записать файл размером в 50 мегабайт куда-нибудь — вот Вам и совсем другой профиль. Может у Вас картинка будет одна на 10кб, а может Вы тему используете с PNGшками размером под несколько мегов — совсем другой профиль загрузки будет.
5 (и самое важное) «Преждевременная оптимизация — корень всего зла» Д. Кнут Использование облаков на этапе когда Вы не знаете сколько Ваш сайт вообще требует ресурсов и НУЖНЫ ли ему «облака» — это самая настоящая преждевременная оптимизация.
2. Шансов на то, что Ваша идея перевернет мир — очень мало, и если такое случится — Ваши пользователи будут спокойно терпеть простои, пока Вы будете улучшать архитектуру (такое происходило с twitter, с flickr и еще с морем других сервисов);
3. Есть совершенно реальные пути улучшения архитектуры от простой до супер-навороченной и они не начинаются с облаков, iops и т.п.: 1 vps -> 1 сервер -> 3 сервера (приложение, база данных, статика) -> увеличение количества серверов баз банных через репликацию, увеличение числа серверов приложений и какой-нибудь nginx перед ними… но реально говоря, даже 3 сервера (сервер приложения, сервер с базой данных, сервер статики) Вам дадут ТАКОЙ мощный запас мощности, что надолго хватит — десятки миллионов запросов в день — на настолько уж нереально на трех современных серверах, за которые Вы будете платить фиксированную сумму без учета всяких IOPS и прочего (только траффик, но он более чем предсказуем на такой посещаемости);
4. «сайт на вордпрессе с 10к хостов в день генерирует вот такой профиль загрузки»
Сайты в облаках (а только они и берут за CPU, IOPS и т.п.) — они для тех, кто УЖЕ точно знает сколько у него будет IOPS, и прочего.
4а. «вот такой профиль загрузки» один хреново написанный плагин для вашего вордпресса и профиль будет СОВСЕМ другой; а может Вы посередине какой-нибудь страницы захотите записать файл размером в 50 мегабайт куда-нибудь — вот Вам и совсем другой профиль. Может у Вас картинка будет одна на 10кб, а может Вы тему используете с PNGшками размером под несколько мегов — совсем другой профиль загрузки будет.
5 (и самое важное) «Преждевременная оптимизация — корень всего зла» Д. Кнут Использование облаков на этапе когда Вы не знаете сколько Ваш сайт вообще требует ресурсов и НУЖНЫ ли ему «облака» — это самая настоящая преждевременная оптимизация.
Кстати, вот с четвёртым пунктом я негласно и спорю. Возможно, есть такое сочетание цены и труда, когда даже личный хомяк уместно залить в облако. Оно маргинально, согласен, типа недавно пробежавшего варианта «почти CGI на базе дропбокса» и «хостинг картинок в аттачах гмыла», но кто знает?
Не понимаю я смысла держать хомяк (или даже вордпресс с 10к посещениями) в облаках. Взяли VPS за 5-10-20$ и расслабились — не такие это огромные деньги и все предсказуемо.
(поскольку этот вопрос всегда задают — то за 5$ это firstvds, дешево и сердито)
(поскольку этот вопрос всегда задают — то за 5$ это firstvds, дешево и сердито)
Эти «реальные пути улучшения архитектуры» — они очень правильные и полезные. Не спорю. Но как и любые хороши, проверенные годами и выстраданные из реального опыта догмы, они нуждаются в периодической проверке.
Зачем хомяк на облаке? Завтра появится функционал у дропбокса и твиттера, которые удобно использовать на хомяке, а хромос в планшете внезапно станет социальной нормой, например. Послезавтра мой хомяк вырастет в медведя, а цены на облако упразднят вдс как услугу. Понимаете, отработка «на хомяках» — очень хороший инструмент обучения, популяризации и исследования, полезный как клиентам, так и индустрии.
… но это я к вопросу о конкретно хомяках на облаке, а не в целом по статье. В конце концов, социальные сети вырасли из блогов очень быстро.
Вопрос статьи, скорее, «согласны ли облачники-хостеры (и не только облачники, смотрите приписку внизу) гласно или негласно разворачивать мелких стартаперов по стандартному пути апгрейда, или же могут рассмотреть этот сложный для них, но, возможно, интересный для потенциальных клиентов вариант»
Зачем хомяк на облаке? Завтра появится функционал у дропбокса и твиттера, которые удобно использовать на хомяке, а хромос в планшете внезапно станет социальной нормой, например. Послезавтра мой хомяк вырастет в медведя, а цены на облако упразднят вдс как услугу. Понимаете, отработка «на хомяках» — очень хороший инструмент обучения, популяризации и исследования, полезный как клиентам, так и индустрии.
… но это я к вопросу о конкретно хомяках на облаке, а не в целом по статье. В конце концов, социальные сети вырасли из блогов очень быстро.
Вопрос статьи, скорее, «согласны ли облачники-хостеры (и не только облачники, смотрите приписку внизу) гласно или негласно разворачивать мелких стартаперов по стандартному пути апгрейда, или же могут рассмотреть этот сложный для них, но, возможно, интересный для потенциальных клиентов вариант»
Я не соглашусь со 2м пунктом.
Почему все, всегда думают, что «стартап» это обязательно что-то «социальное» или «для всех»?! Есть стартапы, которые направлены на бизнес, а бизнес, как многие знают не любит простаивать, потому что время — деньги!
И если вы затеяли какой-то стартап, который бы перевернул индустрию, к примеру, а он у вас загнулся через 2-3 дня запуска, то бизнес разочаруется и уйдет к другому (сто процентов будет кто-то, кто дышит вам в спину и будет ждать любой вашей ошибки, чтобы воткнуть нож в спину).
Хватит думать материями твиттера, фликра и морем других социальных сервисов, которые созданы были «Just for fun», а по стечению обстоятельств вышли в топ.
Почему все, всегда думают, что «стартап» это обязательно что-то «социальное» или «для всех»?! Есть стартапы, которые направлены на бизнес, а бизнес, как многие знают не любит простаивать, потому что время — деньги!
И если вы затеяли какой-то стартап, который бы перевернул индустрию, к примеру, а он у вас загнулся через 2-3 дня запуска, то бизнес разочаруется и уйдет к другому (сто процентов будет кто-то, кто дышит вам в спину и будет ждать любой вашей ошибки, чтобы воткнуть нож в спину).
Хватит думать материями твиттера, фликра и морем других социальных сервисов, которые созданы были «Just for fun», а по стечению обстоятельств вышли в топ.
Как же Вы все любите жить в теоретическом царстве.
1. Облака — не дают НИКАКОЙ гарантии по поводу того, что Ваш стартап не загнется. Это все равно Ваша задача — обеспечивание надежности, будь то регулярные бэкапы на VPS или снэпшоты на EC2. Это все равно Ваша задача — обеспечивание масштабируемости — будь то дополнительные сервера на репликации или дополнительные app-сервера на EC2/RackSpace/где угодно. Единственные, кто дают какую-то «надежность» тут — это Google App Engine. Но он — едва ли «облачный хостинг провайдер», скорее «облачный провайдер приложений» — он дает свое приложение (BigTable, HTTP(s) и т.п.), с которым Вы можете работать.
Теперь давайте про ерунду про «уйдет к другому»…
Назовем условно «стартап» «провайдером», а его клиента «потребителем».
«Провайдер» не может быть большим — иначе бы он знал, сколько его приложение требует затрат на облака, сервера и т.п. (то есть для него статья бесполезна).
Значит «провайдер» маленький.
«Потребитель» не может быть большим, потому что большие компании не работают с маленькими (слишком большой риск, что загнется через 2-3 дня).
Значит «потребитель» маленький.
Значит обе компании маленькие. Значит обе компании гибкие. Значит вторая спокойно может потрепеть 2 дня простоя, неделю простоя или даже больше. Никто не будет использовать мелкого партнера в misson-critical местах.
Если же не вытерпел и ушел — можно найти нового (все-таки речь идет о маленьких компаниях, а не о контрактах с Кока-Колой, а о компаниях уровня «Пупкин и ко», что я выше уже и доказал).
Итого: все оригинальные аргументы остаются в силе.
1. Облака — не дают НИКАКОЙ гарантии по поводу того, что Ваш стартап не загнется. Это все равно Ваша задача — обеспечивание надежности, будь то регулярные бэкапы на VPS или снэпшоты на EC2. Это все равно Ваша задача — обеспечивание масштабируемости — будь то дополнительные сервера на репликации или дополнительные app-сервера на EC2/RackSpace/где угодно. Единственные, кто дают какую-то «надежность» тут — это Google App Engine. Но он — едва ли «облачный хостинг провайдер», скорее «облачный провайдер приложений» — он дает свое приложение (BigTable, HTTP(s) и т.п.), с которым Вы можете работать.
Теперь давайте про ерунду про «уйдет к другому»…
Назовем условно «стартап» «провайдером», а его клиента «потребителем».
«Провайдер» не может быть большим — иначе бы он знал, сколько его приложение требует затрат на облака, сервера и т.п. (то есть для него статья бесполезна).
Значит «провайдер» маленький.
«Потребитель» не может быть большим, потому что большие компании не работают с маленькими (слишком большой риск, что загнется через 2-3 дня).
Значит «потребитель» маленький.
Значит обе компании маленькие. Значит обе компании гибкие. Значит вторая спокойно может потрепеть 2 дня простоя, неделю простоя или даже больше. Никто не будет использовать мелкого партнера в misson-critical местах.
Если же не вытерпел и ушел — можно найти нового (все-таки речь идет о маленьких компаниях, а не о контрактах с Кока-Колой, а о компаниях уровня «Пупкин и ко», что я выше уже и доказал).
Итого: все оригинальные аргументы остаются в силе.
Просто поймите — Вы все рассчитываете на:
1) внезапный успех за ночь (практически не бывает в жизни, в основном все бизнесы развиваются медленно);
2) что этот успех будет единственным шансом на успех (я кстати также не говорил про что-то «социальное» или «для всех») — тоже не так, как правило шансов много и их надо использовать, упущенная одна возможность не разрушит бизнес. А если разрушит — хреновый это был бизнес.
1) внезапный успех за ночь (практически не бывает в жизни, в основном все бизнесы развиваются медленно);
2) что этот успех будет единственным шансом на успех (я кстати также не говорил про что-то «социальное» или «для всех») — тоже не так, как правило шансов много и их надо использовать, упущенная одна возможность не разрушит бизнес. А если разрушит — хреновый это был бизнес.
Все же, я считаю, что вы не правы.
Опять же, как вы говорили в 5м пункте, что «Преждевременная оптимизация — корень всего зла». Так вот при разработке какого-то продукта я могу протестировать его, попробовать какие-то стресс-тесты, но они из-за неимения больших финансов и, возможно, опыта не смогут создать 100% картину той ситуации, которая может быть при «боевых условиях». Т.е. возможно при своих тестах я упустил какое-то узкое место, которое при реальной нагрузке повалит сервер (VPS), а вот ежели размещаться в облаках и прочих «гибких» VPSах, которые работают по принципу «Scale On-Demand», то тут я получаю хоть какую-то (опять же про 100% не говорю), но гарантию, что приложение и сервер ВЫСТОЯТ, а я уже посмотрев на то, как работают пользователи, как ведет себя система смогу сложить более четкую картину и уже заняться оптимизацией.
А по поводу клиентов скажу вам вот что — есть сферы бизнеса ОЧЕНЬ, ОЧЕНЬ консервативные, куда войти-то просто так не всегда получается, а если уж тебе удалось туда войти и ПРИВЛЕЧЬ К СЕБЕ ВНИМАНИЕ, то тут позволять упасть в грязь лицом себе нельзя! Это первое, а второе — когда вы создаете стартап на свои средства, то это не просто прожить в случае «ну один ушел, будут другие», потому что как правило вы живете на 500 рублей в месяц и лишний клиент, который от вас ушел — это лишний кусок хлеба, который вы не съели на обед. Я считаю на этапе старта нельзя раскидываться клиентами, их надо на руках носить, а вот когда вы уже задали стандарт в отрасли, то там можно и фыркать и позволять себе всякие шалости.
Опять же, как вы говорили в 5м пункте, что «Преждевременная оптимизация — корень всего зла». Так вот при разработке какого-то продукта я могу протестировать его, попробовать какие-то стресс-тесты, но они из-за неимения больших финансов и, возможно, опыта не смогут создать 100% картину той ситуации, которая может быть при «боевых условиях». Т.е. возможно при своих тестах я упустил какое-то узкое место, которое при реальной нагрузке повалит сервер (VPS), а вот ежели размещаться в облаках и прочих «гибких» VPSах, которые работают по принципу «Scale On-Demand», то тут я получаю хоть какую-то (опять же про 100% не говорю), но гарантию, что приложение и сервер ВЫСТОЯТ, а я уже посмотрев на то, как работают пользователи, как ведет себя система смогу сложить более четкую картину и уже заняться оптимизацией.
А по поводу клиентов скажу вам вот что — есть сферы бизнеса ОЧЕНЬ, ОЧЕНЬ консервативные, куда войти-то просто так не всегда получается, а если уж тебе удалось туда войти и ПРИВЛЕЧЬ К СЕБЕ ВНИМАНИЕ, то тут позволять упасть в грязь лицом себе нельзя! Это первое, а второе — когда вы создаете стартап на свои средства, то это не просто прожить в случае «ну один ушел, будут другие», потому что как правило вы живете на 500 рублей в месяц и лишний клиент, который от вас ушел — это лишний кусок хлеба, который вы не съели на обед. Я считаю на этапе старта нельзя раскидываться клиентами, их надо на руках носить, а вот когда вы уже задали стандарт в отрасли, то там можно и фыркать и позволять себе всякие шалости.
> Google App Engine. Но он — едва ли «облачный хостинг провайдер», скорее «облачный провайдер приложений»
Это называется PaaS. Походу вы не в теме и облака тоже разные бывают.
Это называется PaaS. Походу вы не в теме и облака тоже разные бывают.
По поводу 5 пункта. Облака это не только оптимизация (вообще этот момент не самый основной). Разработка в облаке это использование готовых каналов обмена данными между приложениями, готовых каналов поставки приложений на конечные устройства, это последние технологии, которые преподносятся на блюдечке и разработчику остается их использовать мизинцем правой руки.
Когда вы делаете сайт на «хостинге» вы строите деревню в которой нет инфраструктуры, разработка в облаке это город, это готовая инфраструктура. Так что «новчикам» для опыта можно попробовать хостинг, это как большинство проходят разработку на ассемблере и потом переходят на уровень выше, облако это и есть уровень выше.
Когда вы делаете сайт на «хостинге» вы строите деревню в которой нет инфраструктуры, разработка в облаке это город, это готовая инфраструктура. Так что «новчикам» для опыта можно попробовать хостинг, это как большинство проходят разработку на ассемблере и потом переходят на уровень выше, облако это и есть уровень выше.
«большинство проходят разработку на ассемблере»
Может быть в 80ых, сейчас большинство начинает как раз, зачастую с высокого уровня — с PHP/Delphi/C++/C#/Java/Perl. Поспрашивайте людей рожденных около 90го года что такое «jnz» и потом делайте такие утверждения.
«Разработка в облаке это использование готовых каналов обмена данными между приложениями»
Это вообще бред. Облако — это тот же VPS, с той лишь разницей, что можно программно поднимать другие VPS. О каком «готовом канале» идет речь, который есть в облаках, но нет в VPS?
И, пожалуйста, отвечайте на то, что я говорю, а не на свои домыслы. Слово «хостинг», которое Вы так упорно мне цитируете, я вообще не использовал нигде в комментарии.
Может быть в 80ых, сейчас большинство начинает как раз, зачастую с высокого уровня — с PHP/Delphi/C++/C#/Java/Perl. Поспрашивайте людей рожденных около 90го года что такое «jnz» и потом делайте такие утверждения.
«Разработка в облаке это использование готовых каналов обмена данными между приложениями»
Это вообще бред. Облако — это тот же VPS, с той лишь разницей, что можно программно поднимать другие VPS. О каком «готовом канале» идет речь, который есть в облаках, но нет в VPS?
И, пожалуйста, отвечайте на то, что я говорю, а не на свои домыслы. Слово «хостинг», которое Вы так упорно мне цитируете, я вообще не использовал нигде в комментарии.
Вообще то я про PaaS, например GAE, MS Azure, какие там VPS??? Разработка ведется так если бы вы программировали для своего компа, все прозрачно. Не надо мыслить VPS ами относительно облаков, если вы работаете с VPS, то это нифига не облако, а жалкое подобие.
А здесь вы сами противоречите своему высказыванию про то, что облака бывают разные. Есть же облака типа IaaS, в которых как раз мыслят юнитами и ресурсами для VPS к примеру Rackspace Cloud. Тот же Azure дабы дать большую гибкость спускается и на уровень IaaS планируя предоставлять RDP доступ внутри виртуального облачного сервера.
1. «Новички», берите VPS и не страдайте «облаками»;
Так говорят олдфаги которые сами не осилили облака, а говорят они так потому, что уних будет боль в допе если «новичек» все осилит. Облака как разз в первую очередь новичкам и нужны. Потому, что:
a) Pay as you use
b) Дешевле
c) Если ресурс затратный и vps'a не хватает — когда загнетесь можно забыть и все
Так говорят олдфаги которые сами не осилили облака, а говорят они так потому, что уних будет боль в допе если «новичек» все осилит. Облака как разз в первую очередь новичкам и нужны. Потому, что:
a) Pay as you use
b) Дешевле
c) Если ресурс затратный и vps'a не хватает — когда загнетесь можно забыть и все
Облако это всего-лишь возможность увеличивать ресурсы по мере необходимости.
Это нисколько не круче обычного VDS/VPS по практическим возможностям.
При этом облака стоят заметно дороже чем их аналоги VDS.
По надежности они не лучше правильно настроенных ферм VDS-нод.
По скорости они хуже, т.к. есть накладные расходы на облако.
Тут нечего осиливать, зато можно потрясти модным словом в смете на новый проект перед спонсором.
Не более того.
Это нисколько не круче обычного VDS/VPS по практическим возможностям.
При этом облака стоят заметно дороже чем их аналоги VDS.
По надежности они не лучше правильно настроенных ферм VDS-нод.
По скорости они хуже, т.к. есть накладные расходы на облако.
Тут нечего осиливать, зато можно потрясти модным словом в смете на новый проект перед спонсором.
Не более того.
И это тоже.
>По надежности они не лучше правильно настроенных ферм VDS-нод.
По скорости они хуже, т.к. есть накладные расходы на облако.
Иначе говоря облако на коленках у кого-то недо хостера надежнее чем облако от Амазона? Я посчитал свои нагрузки и понял, что «впски за 5 баксов не хватит», если у меня сейчас свой сервер еле справляется с нагрузкой то о какой впс идет речь? Посчитал сколько будет стоит облако — облако обойдется дешевле дедика и его можно отмаштабировать.
А теперь давайте расмотрим стартап, такое реальный стартап или сервер, а не гостевуху «ололо потсаны^W хабрапиплы, зацените чо я сделал вчера в пьяном угаре! тут вот загладки синхронизируеются, а тут в пакмана можно играть!!1111». Например завязаный на работе с музыкой/видео. Если там, что-то надо кодировать — одной vps'ки уже не хватит, если вы уважаете свои пользователей, то все кодирование вы вынесите в облако (ничего не кодируется — облако простаивает, кодируется — работает). Или аналог дропбокса, далеко бы они ушли на впске?
А для 70% блогов на WP хватило бы любого статического блога, захостить можно где угодно ибо затраты ресурсов минимальны (считай cat index.htm | nc чототам), можно даже в том же дроп боксе захостить.
>По надежности они не лучше правильно настроенных ферм VDS-нод.
По скорости они хуже, т.к. есть накладные расходы на облако.
Иначе говоря облако на коленках у кого-то недо хостера надежнее чем облако от Амазона? Я посчитал свои нагрузки и понял, что «впски за 5 баксов не хватит», если у меня сейчас свой сервер еле справляется с нагрузкой то о какой впс идет речь? Посчитал сколько будет стоит облако — облако обойдется дешевле дедика и его можно отмаштабировать.
А теперь давайте расмотрим стартап, такое реальный стартап или сервер, а не гостевуху «ололо потсаны^W хабрапиплы, зацените чо я сделал вчера в пьяном угаре! тут вот загладки синхронизируеются, а тут в пакмана можно играть!!1111». Например завязаный на работе с музыкой/видео. Если там, что-то надо кодировать — одной vps'ки уже не хватит, если вы уважаете свои пользователей, то все кодирование вы вынесите в облако (ничего не кодируется — облако простаивает, кодируется — работает). Или аналог дропбокса, далеко бы они ушли на впске?
А для 70% блогов на WP хватило бы любого статического блога, захостить можно где угодно ибо затраты ресурсов минимальны (считай cat index.htm | nc чототам), можно даже в том же дроп боксе захостить.
Сколько там раз за последние пол года лежало облако Амазона?
Я могу сказать что простой по каналам и нодам у нас за последний год в отличие от Амазона нулевой.
Я могу сказать что простой по каналам и нодам у нас за последний год в отличие от Амазона нулевой.
Не одним амазоном же живы облака! Что все думают, раз амазон был первым, то только их и надо использовать?
Речь шла об облаках Амазона и обычных VDS нодах хостеров.
Понятно что есть альтернативы, но все они не панацея.
Они нестабильны, т.к. не до конца протестированы.
Они дороже, т.к. провайдер пытается отбить немалые расходы на программистов и свое ноу-хау.
Может быть года через 3 это будет хорошим подспорьем, но сейчас это просто новая волна.
Понятно что есть альтернативы, но все они не панацея.
Они нестабильны, т.к. не до конца протестированы.
Они дороже, т.к. провайдер пытается отбить немалые расходы на программистов и свое ноу-хау.
Может быть года через 3 это будет хорошим подспорьем, но сейчас это просто новая волна.
Идеи не переворачивают мир. Переворачивает мир сила, приложенная к рычагу ;)
«Lost in the cloud? Unfluff your hosting!» © Mediatemple.
Они вообще молодцы: не выдают каждый нанометр попугая, которым меряют CPU, а измеряют Grid Performance Unit'ами. 1 GPU = 7.24% of 1 CPU for 1 hour.
mediatemple.net/webhosting/gs/faq.php#63
Они вообще молодцы: не выдают каждый нанометр попугая, которым меряют CPU, а измеряют Grid Performance Unit'ами. 1 GPU = 7.24% of 1 CPU for 1 hour.
mediatemple.net/webhosting/gs/faq.php#63
Они очень правильно делают.
Нечего мерять в этих самых сферических попугаях привязанных к количеству просмотров.
По сути они измеряют именно в нагрузке на CPU.
Нечего мерять в этих самых сферических попугаях привязанных к количеству просмотров.
По сути они измеряют именно в нагрузке на CPU.
А в mediatemple.net/labs/cs/ будет еще лучше :)
Не совсем понятно — а чего вы, собственно, пытаетесь добиться? Вычислить минимум ресурсов и денег, которые вам необходимы для поддержки вашего продукта? А зачем такая точность?
Для меня главными свойствами облака являются его эластичность, т.е. возможность изменения количество ресурсов, потребляемых неким сервисом в зависимости от нагрузки, и минимальный порог вхождения в него, т.е. низкие затраты на одну оплачиваемую единицу времени.
Может, конечно, я говорю не о тех облаках, но я плотно работаю с Амазоновским облаком и просто не вижу необходимости во всех этих телодвижениях.
Предположим, что у нас есть либо а) продукт, спроектированный для управления потребными облачными ресурсами (т.е. в сам продукт встроено умение запускать новые сервера под себя), например, Animoto, либо б) продукт запущенный через сервис, который занимается тем, что масштабирует облачные ресурсы под этот сервис (скажем, CloudFoundry). Тогда задача, в принципе, решена — при отсутствии нагрузки будет использоваться минимум ресурсов, при росте нагрузке — столько, сколько нужно на этот момент. И когда нагрузка упадет — все снова вернется к минимуму.
Конечно, самый минимум и Амазона — 8 центов в час — слегка кусается. Я бы хотел, чтобы они дали возможность запускать еще мЕньшие сервера за еще меньшие деньги. Но, в приципе, их подход «платишь только за то, чем реально пользуешься» позволяет не тратить силы, время и деньги (в пересчете на зарплату даже одного программиста — не очень маленькие) на предварительно планирование, которое все равно не может давать точные результаты по определению.
Возможно, я просто не понял проблемы, стоящие перед автором топика.
Для меня главными свойствами облака являются его эластичность, т.е. возможность изменения количество ресурсов, потребляемых неким сервисом в зависимости от нагрузки, и минимальный порог вхождения в него, т.е. низкие затраты на одну оплачиваемую единицу времени.
Может, конечно, я говорю не о тех облаках, но я плотно работаю с Амазоновским облаком и просто не вижу необходимости во всех этих телодвижениях.
Предположим, что у нас есть либо а) продукт, спроектированный для управления потребными облачными ресурсами (т.е. в сам продукт встроено умение запускать новые сервера под себя), например, Animoto, либо б) продукт запущенный через сервис, который занимается тем, что масштабирует облачные ресурсы под этот сервис (скажем, CloudFoundry). Тогда задача, в принципе, решена — при отсутствии нагрузки будет использоваться минимум ресурсов, при росте нагрузке — столько, сколько нужно на этот момент. И когда нагрузка упадет — все снова вернется к минимуму.
Конечно, самый минимум и Амазона — 8 центов в час — слегка кусается. Я бы хотел, чтобы они дали возможность запускать еще мЕньшие сервера за еще меньшие деньги. Но, в приципе, их подход «платишь только за то, чем реально пользуешься» позволяет не тратить силы, время и деньги (в пересчете на зарплату даже одного программиста — не очень маленькие) на предварительно планирование, которое все равно не может давать точные результаты по определению.
Возможно, я просто не понял проблемы, стоящие перед автором топика.
Насколько я понял автор топика мечтает о понятной PaaS платформе с легко прогнозируемой стоимостью при разной нагрузке на сервис и автоматическим увеличением и уменьшением ресурсов в зависимости от нагрузки на приложение, при этом без написания каких либо специальных программных инструментов.
Грубо говоря, чтобы он пришел на сайт облачного провайдера, указал допустим тип CMS и двигая счетчик количества посетителей увидел приблизительную стоимость за час работы при такой нагрузке.
Грубо говоря, чтобы он пришел на сайт облачного провайдера, указал допустим тип CMS и двигая счетчик количества посетителей увидел приблизительную стоимость за час работы при такой нагрузке.
Опять же, а зачем? Чтобы убедить бухгалтерию, что на облаке дешевле?
Затем, что когда делаешь стартап на свои деньги (без инвесторов и пр.), то дорога каждая копейка и не хочется брать на много тыщ денег дедик, а хочется где-то сэкономить. Понятно, что когда ты увидишь реальную нагрузку на сервер и работу самой системы, то поймешь как и куда лучше идти, а пока ты гоняешь на своей домашней машине/ноуте свой продукт хоть головой в стенку бейся — непонятно сколько нужно будет тратить денег на инфраструктуру.
>когда делаешь стартап на свои деньги (без инвесторов и пр.), то дорога каждая копейка и не хочется брать на много тыщ денег дедик, а хочется где-то сэкономить
Именно для таких случаев и придумано облако — нулевой порог входа. Запустил в облаке и смотришь на нагрузку в _реальности_. Какой бы безденежный стартап ни был, деньги на самый минимум облачных ресурсов должны же быть.
Ладно, я, видимо, просто не въезжаю.
Именно для таких случаев и придумано облако — нулевой порог входа. Запустил в облаке и смотришь на нагрузку в _реальности_. Какой бы безденежный стартап ни был, деньги на самый минимум облачных ресурсов должны же быть.
Ладно, я, видимо, просто не въезжаю.
Автор всего лишь предложил идею, как можно сделать платформу более прогнозируемой. А вот стоит ли игра свеч — вопрос открытый.
Прогнозируемость стоимости услуг провайдера облачной платформы — важный фактор, влияющий на привлекательность того или иного облачного провайдера.
Путь «кейсов» выглядит очень привлекательно, как со стороны клиента, так и со стороны хостера. Однако, чтобы предоставить информацию о кейсах, должен выполняться ряд условий:
— Провайдер ограничивает действия пользователя, гарантирует оптимальность работы серверного ПО, в том числе и приложения пользователя (тем самым исключая «эффект кривого плагина для wordpress»)
— Провайдер накопил достаточный опыт для достаточного количества кейсов.
На рынке облачных услуг в РФ есть только одна компания, которая выолняет первое условие, и ни одной, которая бы выполняла второе и/или оба.
На мой взгляд, чаще достаточно знать минимальную и максимальную планку: сколько я заплачу, если нагрузка прыгнет до небес и как согласовать оплату больше, если мне действительно это нужно?
Это компромисное решение.
Путь «кейсов» выглядит очень привлекательно, как со стороны клиента, так и со стороны хостера. Однако, чтобы предоставить информацию о кейсах, должен выполняться ряд условий:
— Провайдер ограничивает действия пользователя, гарантирует оптимальность работы серверного ПО, в том числе и приложения пользователя (тем самым исключая «эффект кривого плагина для wordpress»)
— Провайдер накопил достаточный опыт для достаточного количества кейсов.
На рынке облачных услуг в РФ есть только одна компания, которая выолняет первое условие, и ни одной, которая бы выполняла второе и/или оба.
На мой взгляд, чаще достаточно знать минимальную и максимальную планку: сколько я заплачу, если нагрузка прыгнет до небес и как согласовать оплату больше, если мне действительно это нужно?
Это компромисное решение.
Что-то непонятно, зачем такая фишка хостерам: гемору много, а увеличения клиентов-то, скорее всего, не будет.
Вот и мне, как неопытному молодому человеку с идеей, которая перевернёт мир, непонятно: откуда взять все эти количества GET, POST, INSERT, а главное CPU.
… а потом…
Входной лог можно и нужно править, моделируя слешдот-моменты (и сделать это достаточно просто — взять и подмешать копии реальных сессий с модифицированными IP-адресами).
Все шаги вполне прозрачны и понятны даже полному новичку.
Мне одному кажется что прикинуть какая будет загрузка у проекта легче чем «моделировать слешдот-моменты»?
Исходя из своего опыта, я бы посоветовал новичкам уделять внимание не железу, а самой разработке. При кривом коде не спасет даже самая мощная архитектура.
Далее, если это серьезный бизнес-проект, то в него обычно надо вкладывать серьезные деньги. Если таких денег нет, то это уже несерьезный бизнес-проект (по крайней мере на данном этапе). А в этом случае лучше беспокоиться о качестве продукта, а не о мощности архитектуры.
Ну и конечно тестировать всегда полезно. Я для себя выбрал пока следующий сценарий — выбираю самое тяжелое (на мой взгляд) место проекта, выключаю кэширование и прочую оптимизацию, натравливаю туда стресс-тест типа Apache Benchmark и смотрю на результат. Если я получаю, скажем, 20 запросов в секунду в среднем, то меня это устраивает, и на этом стресс-тест можно заканчивать (для начинающих проектов). До сих пор такой метод не подводил, но позволял заметно сэкономить время.
Пилить облако вроде EC2 зачастую действительно не имеет смысла. Но в защиту автора хочу кивнуть на такой сервис как Heroku, где облачность объединяется с простотой развёртывания и подключения дополнительных сервисов.
А в чём проблема положить минимальную сумму на счёт облачного провайдера, залить туда сайт, перенаправить туда обычный повседневный трафик (не трогая, не отключая старый хост — разве что БД надо аккруатно перенести туда-обратно), и посмотреть, что получится. Только эксперимент покажет реальную нагрузку. Можете два дня посмотреть, все логи записать, и вернуться обратно на любимый VPS. Эти логи можно уже изучать сколько угодно, экстраполируя нагрузку при разном числе пользователей и характере их действий на сайте.
Между прочим, подобный безболезненный и недорого «тестовый переезд» может быть отдельной услугой у профи-админов.
Успехов.
PS: К слову, можно держать в облаке «выключенный» образ сайта, пока он не понадобится, и не платить за трафик и процессор (только за хранение образа в боеготовности). Написать скрипт, который при перегрузке VPS будет «будить» образ в облаке и перенаправлять трафик туда. Тогда VPS будет просто рулить трафиком, а всю нагрузку возьмёт на себя облако. Когда «слешдотовость» понизится, можно отключать облаков и возвращать VPS в обычный режим.
Между прочим, подобный безболезненный и недорого «тестовый переезд» может быть отдельной услугой у профи-админов.
Успехов.
PS: К слову, можно держать в облаке «выключенный» образ сайта, пока он не понадобится, и не платить за трафик и процессор (только за хранение образа в боеготовности). Написать скрипт, который при перегрузке VPS будет «будить» образ в облаке и перенаправлять трафик туда. Тогда VPS будет просто рулить трафиком, а всю нагрузку возьмёт на себя облако. Когда «слешдотовость» понизится, можно отключать облаков и возвращать VPS в обычный режим.
Ну и да, сказанное ничуть не противоречит основному тезису статьи: облачным хостерам следует таки указать стоимость обслуживания в сутки при «типичной нагрузке» для различных ситуаций.
Подозреваю, что зачастую основная проблема не инстанс веб-сервера поднять, а БД синхронизировать.
Их не надо одновременно запускать.
Пишется скрипт, который останавливает VPS, переливает БД напрямую из VPS в облако, запускает облако, перенаправляет трафик.
Время этой операции зависит только от объёма БД и ширины канала между VPS и облаком.
Можно потренироваться днём без отключения VPS, а боевую версию поставить в крон на ночь.
Успехов.
Пишется скрипт, который останавливает VPS, переливает БД напрямую из VPS в облако, запускает облако, перенаправляет трафик.
Время этой операции зависит только от объёма БД и ширины канала между VPS и облаком.
Можно потренироваться днём без отключения VPS, а боевую версию поставить в крон на ночь.
Успехов.
Звучит красиво, но как планируется поддерживать актуальность БД во время «переливания»? Я пока вижу выход в распределённых хранилищах без мастера, но это особая песня со своими куплетами.
Я подразумевал полную остановку сервиса на время миграции.
Для однократной миграции вполне вариант. Но делать это дважды в день, причём в час пик — это совсем неправильно. ;)
Вы сами пробовали таким заниматься? Видимо нет.
Самый правильный, в этом случае, сценарий — остановить работу сервиса на вашем VPS (чтобы данные не писались), перелить БД в облако, переключиться на облако. Но это опять же — простой от нескольких десятков секунд, до нескольких десятков минут (в зависимости от размеров БД).
Можно, конечно, сделать репликацию в облако, но это опять же лишние затраты.
Самое идеальное — держать БД в облаках, но это для старта слишком дорого.
Самый правильный, в этом случае, сценарий — остановить работу сервиса на вашем VPS (чтобы данные не писались), перелить БД в облако, переключиться на облако. Но это опять же — простой от нескольких десятков секунд, до нескольких десятков минут (в зависимости от размеров БД).
Можно, конечно, сделать репликацию в облако, но это опять же лишние затраты.
Самое идеальное — держать БД в облаках, но это для старта слишком дорого.
> Самый правильный, в этом случае, сценарий — остановить работу сервиса на вашем VPS (чтобы данные не писались), перелить БД в облако
>> Пишется скрипт, который останавливает VPS, переливает БД напрямую из VPS в облако, запускает облако, перенаправляет трафик.
По-моему я именно это и написал, разве нет?
> Но это опять же — простой от нескольких десятков секунд, до нескольких десятков минут (в зависимости от размеров БД).
>> Время этой операции зависит только от объёма БД и ширины канала между VPS и облаком.
Я пишу невидимыми буквами? :-)
> Самое идеальное — держать БД в облаках, но это для старта слишком дорого.
Думаю, что для небольшого стартапа нестрашно приостановить работу сервиса на пару минут где-нибудь ночью, чтобы протестировать переход в облако.
Есть ещё компромиссный вариант: залочить базу от записи так, чтобы сервис только отдавал страницы на чтение. А с добавлением данных юзеры подождут несколько минут. Но тут уже всё зависит от конкретного сервиса — надо, чтобы отправленные пользователем из браузера данные не потерялись.
>> Пишется скрипт, который останавливает VPS, переливает БД напрямую из VPS в облако, запускает облако, перенаправляет трафик.
По-моему я именно это и написал, разве нет?
> Но это опять же — простой от нескольких десятков секунд, до нескольких десятков минут (в зависимости от размеров БД).
>> Время этой операции зависит только от объёма БД и ширины канала между VPS и облаком.
Я пишу невидимыми буквами? :-)
> Самое идеальное — держать БД в облаках, но это для старта слишком дорого.
Думаю, что для небольшого стартапа нестрашно приостановить работу сервиса на пару минут где-нибудь ночью, чтобы протестировать переход в облако.
Есть ещё компромиссный вариант: залочить базу от записи так, чтобы сервис только отдавал страницы на чтение. А с добавлением данных юзеры подождут несколько минут. Но тут уже всё зависит от конкретного сервиса — надо, чтобы отправленные пользователем из браузера данные не потерялись.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обращение к облачным хостинг-провайдерам и их потенциальным клиентам