Просто поймите — Вы все рассчитываете на:
1) внезапный успех за ночь (практически не бывает в жизни, в основном все бизнесы развиваются медленно);
2) что этот успех будет единственным шансом на успех (я кстати также не говорил про что-то «социальное» или «для всех») — тоже не так, как правило шансов много и их надо использовать, упущенная одна возможность не разрушит бизнес. А если разрушит — хреновый это был бизнес.
Как же Вы все любите жить в теоретическом царстве.
1. Облака — не дают НИКАКОЙ гарантии по поводу того, что Ваш стартап не загнется. Это все равно Ваша задача — обеспечивание надежности, будь то регулярные бэкапы на VPS или снэпшоты на EC2. Это все равно Ваша задача — обеспечивание масштабируемости — будь то дополнительные сервера на репликации или дополнительные app-сервера на EC2/RackSpace/где угодно. Единственные, кто дают какую-то «надежность» тут — это Google App Engine. Но он — едва ли «облачный хостинг провайдер», скорее «облачный провайдер приложений» — он дает свое приложение (BigTable, HTTP(s) и т.п.), с которым Вы можете работать.
Теперь давайте про ерунду про «уйдет к другому»…
Назовем условно «стартап» «провайдером», а его клиента «потребителем».
«Провайдер» не может быть большим — иначе бы он знал, сколько его приложение требует затрат на облака, сервера и т.п. (то есть для него статья бесполезна).
Значит «провайдер» маленький.
«Потребитель» не может быть большим, потому что большие компании не работают с маленькими (слишком большой риск, что загнется через 2-3 дня).
Значит «потребитель» маленький.
Значит обе компании маленькие. Значит обе компании гибкие. Значит вторая спокойно может потрепеть 2 дня простоя, неделю простоя или даже больше. Никто не будет использовать мелкого партнера в misson-critical местах.
Если же не вытерпел и ушел — можно найти нового (все-таки речь идет о маленьких компаниях, а не о контрактах с Кока-Колой, а о компаниях уровня «Пупкин и ко», что я выше уже и доказал).
Итого: все оригинальные аргументы остаются в силе.
«большинство проходят разработку на ассемблере»
Может быть в 80ых, сейчас большинство начинает как раз, зачастую с высокого уровня — с PHP/Delphi/C++/C#/Java/Perl. Поспрашивайте людей рожденных около 90го года что такое «jnz» и потом делайте такие утверждения.
«Разработка в облаке это использование готовых каналов обмена данными между приложениями»
Это вообще бред. Облако — это тот же VPS, с той лишь разницей, что можно программно поднимать другие VPS. О каком «готовом канале» идет речь, который есть в облаках, но нет в VPS?
И, пожалуйста, отвечайте на то, что я говорю, а не на свои домыслы. Слово «хостинг», которое Вы так упорно мне цитируете, я вообще не использовал нигде в комментарии.
Не понимаю я смысла держать хомяк (или даже вордпресс с 10к посещениями) в облаках. Взяли VPS за 5-10-20$ и расслабились — не такие это огромные деньги и все предсказуемо.
(поскольку этот вопрос всегда задают — то за 5$ это firstvds, дешево и сердито)
1. «Новички», берите VPS и не страдайте «облаками»;
2. Шансов на то, что Ваша идея перевернет мир — очень мало, и если такое случится — Ваши пользователи будут спокойно терпеть простои, пока Вы будете улучшать архитектуру (такое происходило с twitter, с flickr и еще с морем других сервисов);
3. Есть совершенно реальные пути улучшения архитектуры от простой до супер-навороченной и они не начинаются с облаков, iops и т.п.: 1 vps -> 1 сервер -> 3 сервера (приложение, база данных, статика) -> увеличение количества серверов баз банных через репликацию, увеличение числа серверов приложений и какой-нибудь nginx перед ними… но реально говоря, даже 3 сервера (сервер приложения, сервер с базой данных, сервер статики) Вам дадут ТАКОЙ мощный запас мощности, что надолго хватит — десятки миллионов запросов в день — на настолько уж нереально на трех современных серверах, за которые Вы будете платить фиксированную сумму без учета всяких IOPS и прочего (только траффик, но он более чем предсказуем на такой посещаемости);
4. «сайт на вордпрессе с 10к хостов в день генерирует вот такой профиль загрузки»
Сайты в облаках (а только они и берут за CPU, IOPS и т.п.) — они для тех, кто УЖЕ точно знает сколько у него будет IOPS, и прочего.
4а. «вот такой профиль загрузки» один хреново написанный плагин для вашего вордпресса и профиль будет СОВСЕМ другой; а может Вы посередине какой-нибудь страницы захотите записать файл размером в 50 мегабайт куда-нибудь — вот Вам и совсем другой профиль. Может у Вас картинка будет одна на 10кб, а может Вы тему используете с PNGшками размером под несколько мегов — совсем другой профиль загрузки будет.
5 (и самое важное) «Преждевременная оптимизация — корень всего зла» Д. Кнут Использование облаков на этапе когда Вы не знаете сколько Ваш сайт вообще требует ресурсов и НУЖНЫ ли ему «облака» — это самая настоящая преждевременная оптимизация.
Новичкам: читайте что такое «nginx», «php-fpm», «eaccelerator» и «memcached». (Гугл и поиск по Хабру в помощь) Будете это использовать — будет все ооооочень быстро работать.
Мой VPS не заметил даже SlashDot+Twitter+Facebook+HackerNews совместный эффект (статья разошлась), который я заметил только по логам гугл аналитики (сервер не лег и не тормозил). Хабраэффекты не замечаются.
nginx + php-fpm спокойно могут отдавать 10-20 страниц в секунду (а грамотно написанные скрипты с кэшем и eaccelerator — сотни могут давать), а это миллион-два-десять запросов в день. В статье речь идет о 15 тысячах запросов, даже если каждый из них делает еще 3 посещения (очень глубоко) и на все это еще приходится 30 картинок — это полмиллиона запросов в день всего (остается еще полмиллиона-миллион в запасе).
Просто отказывайтесь от Apache для личных целей, от бегемотов вроде WordPress и «эффекты» будут мало страшны. (Пока не узнаете что такое heise.de-эффект :)) вот это было страшно, боюсь представить какой-нибудь китайский эффект — у них там есть блоггер, которого читает миллиард людей в месяц — название даже если бы запомнил — не смог бы воспроизвести)
Взяли бы VPS вместо облаков. У меня вот за $20 предоплачено 200GB траффика (+сам VPS в той же сумме включен). Хабраэффект на счете никогда не сказывался.
Чего-то у вас 3D странное. Расстояние между близким и далеким предметом одинаковое — 8 пикселей.
По логике получается, что это 3D-то плоское (хотя и на какой-то глубине).
А я говорил еще месяц назад, что ни к чему хорошему это не приведет — такой массивный сбор данных о WiFi таким гигантом, как Гугл, а люди отмахивались…
На Хабре баллистические ракеты, кстати, чаще чем надо обсуждаются, но речь не об этом. Читая в первой строке «система управления, которая» — у меня в голове возникает CMS, у кого-то возникает CRM, у кого-то возникает DVCS — все это тоже «системы управления» и это — вещи, которые активно обсуждаются и являются темой Хабра.
Просто из уважения к читателям можно было написать «системой управления проектами», чтобы не лезть всем за хабракат, чтобы узнать о чем речь.
«не существует универсальной системы управления, которая»…
Очень верно, потому что существуют системы управления конвеером, системы управления доступом, системы управления версиями, сайтом, очередью, предприятием, контентом, задачами, финансами, и т.п… У Вас до хабраката настолько общие слова, что вообще не понятно о чем речь пойдет. Система управления ЧЕМ, репозитарии ЧЕГО, тикеты в КАКОЙ ОБЛАСТИ, работаете над КАКИМ проектом?
1) внезапный успех за ночь (практически не бывает в жизни, в основном все бизнесы развиваются медленно);
2) что этот успех будет единственным шансом на успех (я кстати также не говорил про что-то «социальное» или «для всех») — тоже не так, как правило шансов много и их надо использовать, упущенная одна возможность не разрушит бизнес. А если разрушит — хреновый это был бизнес.
1. Облака — не дают НИКАКОЙ гарантии по поводу того, что Ваш стартап не загнется. Это все равно Ваша задача — обеспечивание надежности, будь то регулярные бэкапы на VPS или снэпшоты на EC2. Это все равно Ваша задача — обеспечивание масштабируемости — будь то дополнительные сервера на репликации или дополнительные app-сервера на EC2/RackSpace/где угодно. Единственные, кто дают какую-то «надежность» тут — это Google App Engine. Но он — едва ли «облачный хостинг провайдер», скорее «облачный провайдер приложений» — он дает свое приложение (BigTable, HTTP(s) и т.п.), с которым Вы можете работать.
Теперь давайте про ерунду про «уйдет к другому»…
Назовем условно «стартап» «провайдером», а его клиента «потребителем».
«Провайдер» не может быть большим — иначе бы он знал, сколько его приложение требует затрат на облака, сервера и т.п. (то есть для него статья бесполезна).
Значит «провайдер» маленький.
«Потребитель» не может быть большим, потому что большие компании не работают с маленькими (слишком большой риск, что загнется через 2-3 дня).
Значит «потребитель» маленький.
Значит обе компании маленькие. Значит обе компании гибкие. Значит вторая спокойно может потрепеть 2 дня простоя, неделю простоя или даже больше. Никто не будет использовать мелкого партнера в misson-critical местах.
Если же не вытерпел и ушел — можно найти нового (все-таки речь идет о маленьких компаниях, а не о контрактах с Кока-Колой, а о компаниях уровня «Пупкин и ко», что я выше уже и доказал).
Итого: все оригинальные аргументы остаются в силе.
Может быть в 80ых, сейчас большинство начинает как раз, зачастую с высокого уровня — с PHP/Delphi/C++/C#/Java/Perl. Поспрашивайте людей рожденных около 90го года что такое «jnz» и потом делайте такие утверждения.
«Разработка в облаке это использование готовых каналов обмена данными между приложениями»
Это вообще бред. Облако — это тот же VPS, с той лишь разницей, что можно программно поднимать другие VPS. О каком «готовом канале» идет речь, который есть в облаках, но нет в VPS?
И, пожалуйста, отвечайте на то, что я говорю, а не на свои домыслы. Слово «хостинг», которое Вы так упорно мне цитируете, я вообще не использовал нигде в комментарии.
(поскольку этот вопрос всегда задают — то за 5$ это firstvds, дешево и сердито)
2. Шансов на то, что Ваша идея перевернет мир — очень мало, и если такое случится — Ваши пользователи будут спокойно терпеть простои, пока Вы будете улучшать архитектуру (такое происходило с twitter, с flickr и еще с морем других сервисов);
3. Есть совершенно реальные пути улучшения архитектуры от простой до супер-навороченной и они не начинаются с облаков, iops и т.п.: 1 vps -> 1 сервер -> 3 сервера (приложение, база данных, статика) -> увеличение количества серверов баз банных через репликацию, увеличение числа серверов приложений и какой-нибудь nginx перед ними… но реально говоря, даже 3 сервера (сервер приложения, сервер с базой данных, сервер статики) Вам дадут ТАКОЙ мощный запас мощности, что надолго хватит — десятки миллионов запросов в день — на настолько уж нереально на трех современных серверах, за которые Вы будете платить фиксированную сумму без учета всяких IOPS и прочего (только траффик, но он более чем предсказуем на такой посещаемости);
4. «сайт на вордпрессе с 10к хостов в день генерирует вот такой профиль загрузки»
Сайты в облаках (а только они и берут за CPU, IOPS и т.п.) — они для тех, кто УЖЕ точно знает сколько у него будет IOPS, и прочего.
4а. «вот такой профиль загрузки» один хреново написанный плагин для вашего вордпресса и профиль будет СОВСЕМ другой; а может Вы посередине какой-нибудь страницы захотите записать файл размером в 50 мегабайт куда-нибудь — вот Вам и совсем другой профиль. Может у Вас картинка будет одна на 10кб, а может Вы тему используете с PNGшками размером под несколько мегов — совсем другой профиль загрузки будет.
5 (и самое важное) «Преждевременная оптимизация — корень всего зла» Д. Кнут Использование облаков на этапе когда Вы не знаете сколько Ваш сайт вообще требует ресурсов и НУЖНЫ ли ему «облака» — это самая настоящая преждевременная оптимизация.
httpS://google.com/ редиректит на _http://google.ru (ошибка — переброс на нешифрованное соединение)
httpS://google.ru/ имеет неправильный сертификат (баг 2)
Новичкам: читайте что такое «nginx», «php-fpm», «eaccelerator» и «memcached». (Гугл и поиск по Хабру в помощь) Будете это использовать — будет все ооооочень быстро работать.
nginx + php-fpm спокойно могут отдавать 10-20 страниц в секунду (а грамотно написанные скрипты с кэшем и eaccelerator — сотни могут давать), а это миллион-два-десять запросов в день. В статье речь идет о 15 тысячах запросов, даже если каждый из них делает еще 3 посещения (очень глубоко) и на все это еще приходится 30 картинок — это полмиллиона запросов в день всего (остается еще полмиллиона-миллион в запасе).
Просто отказывайтесь от Apache для личных целей, от бегемотов вроде WordPress и «эффекты» будут мало страшны. (Пока не узнаете что такое heise.de-эффект :)) вот это было страшно, боюсь представить какой-нибудь китайский эффект — у них там есть блоггер, которого читает миллиард людей в месяц — название даже если бы запомнил — не смог бы воспроизвести)
(А Яндексу: ай-яй-яй, почему ж только ссылки-то на панорамы давать можно?)
По логике получается, что это 3D-то плоское (хотя и на какой-то глубине).
А я говорил еще месяц назад, что ни к чему хорошему это не приведет — такой массивный сбор данных о WiFi таким гигантом, как Гугл, а люди отмахивались…
и думается мне это еще не конец истории…
Просто из уважения к читателям можно было написать «системой управления проектами», чтобы не лезть всем за хабракат, чтобы узнать о чем речь.
Очень верно, потому что существуют системы управления конвеером, системы управления доступом, системы управления версиями, сайтом, очередью, предприятием, контентом, задачами, финансами, и т.п… У Вас до хабраката настолько общие слова, что вообще не понятно о чем речь пойдет. Система управления ЧЕМ, репозитарии ЧЕГО, тикеты в КАКОЙ ОБЛАСТИ, работаете над КАКИМ проектом?