Поговорим об облаках

Возвращаясь к вопросам бизнес-кейсов, хочу поинтересоваться у общественности, как вы решаете вопросы переноса имеющихся систем на “облако”.

Контекст вопроса: люди, с которыми я тесно работаю, потратили около миллиарда долларов на IaaS “облако”, и теперь я бьюсь головой об стену, чтобы вернуть им этот миллиард с прибылью. Задача как раз из тех, которые я обожаю: сложная, интересная и прекрасно уживающаяся с моими амбициями.

Убедить людей переходить на “облако” – не такая простая задача, как может показаться. И дело не в том, что клиенты требуют SaaS, но согласны платить только за услуги, предоставляемые независимыми компаниями (типа Microsoft / Google), а поскольку ты чувствуешь себя комфортно в B2B сегменте, ты вынужден:

  • ублажать B2B партнёров, чтобы они нежились на твоём IaaS “облаке”;
  • пихать B2B партнёров, чтобы они гоняли свои сервисы как SaaS для твоих клиентов.

Если вы считаете, что эта задача тривиальная, – я вас с удовольствием найму на должность продавца с базовым окладом в $300k в год (*). Ключевым моментом тут является составление правильного бизнес-кейса для потенциального клиента (включая и внутреннего; впрочем, если вы видели, как два подразделения создают свои собственные “облака”, – вы видели всё). Мой подход к таким бизнес-кейсам такой:

  • Доходы:
    • возможность продавать больше единиц продукции (спасибо масштабированию). +?%
    • возможность привлечения большего количества партнёров. +4%
  • Экономия:
    • сервисы сидят в “облаке”, работают быстрее и расположены ближе, и поэтому 1% пользователей будет пользоваться сервисом на полгода больше;
    • партнёры гоняют свои сервисы у тебя в “облаке”, что позволяет им не тратиться на собственный хостинг и на найм людей. Ещё 3%, а если использовать взаимозачёт, когда ты им платишь оговоренные выплаты минус стоимость “облака”, – то и все 5%;
    • твои собственные сервисы становятся дешевле в создании и поддержке. Ещё 10% экономия.

Внимание, вопрос. Если вы делали бизнес-кейсы для “облачных” вычислений, какие факторы вы учитывали?

(*) Это является проявлением моего неприкрытого цинизма и не является публичной офертой.

Подписаться по Email

35 Responses to “Поговорим об облаках”

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

    Это может быть день/ночь, сезон/несезон, да и просто дигг-эффект.

  2. Это те самые 10% экономии, про которые я говорил. И я говорю про миллионы хитов в день как стандартную нагрузку, так что дигг-эффект погоды особо не делает.

  3. Как по мне: вам не придется возится со своими сотрудниками, которые сделают то же самое:)

  4. Я думаю скоро начнётся разделение провайдеров облаков на специализации. И вашему клиенту было бы неплохо понять свою. И если он сделает это прямо сейчас – это выделит его из серой тени остальных провайдеров, которых уже на данные момент достаточно. Т.е. нужно позиционировать себя как-то обособленно и не пытаться охватить весь рынок сразу 🙂

    Что думаете по этому поводу, Макс?

    Так же важно иметь инструменты позволяющие упростить переход и использование облаков. Пример – dropbox. Их фишка- это то самое настольное приложение, которое позволяет делать все действия как по щелчку пальцев.

  5. Dropbox – это SaaS интерфейс к IaaS хранилищу.
    А вот над позиционированием облака я как раз и работаю.

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

    ниша то все, туту. списать придется лярд через пару годиков.

    мы как бы в этой теме уже три года. уже все перегрето по самое не балуй.

    ну ладно хоть у инвесторов открутили бабла, под шумок )) сильно все это напоминает события десятилетней давности.

    прочитаем эту заметку через 2 года. посмеемся вместе.

  7. Амазона в Австралии нет, и есть ряд условий, когда облако должно быть только австралийским и предоставляться австралийской компанией. Банки и государство на этом настаивают.
    Я тоже сначала был скептиком.

  8. Это, кстати, и должно стать одним из основных направлений. У меня есть клиент, который платит втридорога, но ему нужен местный хостинг, ибо 95% его клиентов — местные.

  9. Упрощение использования – это ключ к B2sB (small B)
    Обычно стартапы ждут много-кратного роста и это аргумент для старта в облаках…

  10. Согласен. Я продвигаю теорию, что если большие рыбы не ловятся, можно поймать много средних рыб и вырастить их.

  11. Интересную тему подняли Максим… На сегодня есть Saas BI проект (дабы не устраивать рекламы ссылку дам по запросу) – скорей всего проект в ближайшие пол года будет переезжать в облака: рассматриваемые варианты http://aws.amazon.com/ или http://www.microsoft.com/cloud/ (второй вариант скорее, т.к. изначально сервис разрабатывался на BI платформе от microsoft).
    Думаю если не лезть в технические детали, то по каким критериям будем выбирать облако под проект.

    1. Платформенная совместимость.
    2. Эксклюзивные возможности сервиса (технические)
    3. Оперативность технической поддержки сервиса, частота обновления и конечно “устойчивость”. Иначе и мой сервис будет лежать.
    Скорей всего именно эти 3 фактора определят выбор поставщика
    Далее при прочих равных условиях смотрим:
    4. стоимость обслуживания годовую
    5. маркетинговые пряники (описанные Вами в тексте,к примеру как вариант)
    Поэтому стратегия продажи Iaas на мой взгляд должна начинаться с разработки уникальный возможностей сервиса, технических отличий от прочих конкурентов под конкретные СУБД, серверы и т.д. от мировых производителей, тем самым понять нишу своего сервиса.
    Т.к. предложенное сейчас – экономия на издержках, масштабируемость и т.д., есть абсолютно у всех, и на этом фоне биться с тем же microsoft крайне затруднительно. Другое дело уникальное предложение.
    Извиняюсь за сумбур, если что.

  12. Объясните плз кто-нибудь – а зачем бизнесу облака? Какие-такие задачи хорошо ложатся на облачные технологии и не ложатся на что-либо другое?

  13. почитайте “Теория и практика облачных сервисов”:
    http://xnutsive.ru/29661501

  14. Такую статью я и сам написать могу 🙂 Мне бы узнать, что ещё засунуть в бизнес-кейс.

  15. Все равно нифига не понял.. Я знаю что такое J2EE и виртуализация на IBM SystemP платформах (это к слову о пиках нагрузки неиспользуемой мощности) – может ли кто нибудь из тех, кто в курсе перечисленных технологий объяснить мне почему эти т.н. облака – не велосипед (причем убогий).

    Хотя я в-общем могу себе представить ситуацию, когда серверные
    фермы (десятки-сотни простеньких 1-2 way серверов) или монстры типа 32-way сливают – задачи гидродинамики например, декодирование генома, крипторгафия.. итп – но это все Наука. А БИЗНЕСУ-то что в таком объеме считать приспичило?

  16. Бизнес может считать риски в real time (это для трейдинга), и вовсе это не наука.
    Мобильные операторы могут обрабатывать транзакции в real time (особо болезненно для припейда).

    Для клиента ключевой момент – это перенос издержек из CapEx на OpEx, что позволяет запустить больше проектов, ибо CapEx требования снижаются. Это надо было поставить первым пунктом.

  17. real-time и облака? где первое подразумевает предсказуемость (или даже – гарантированность) времени исполнения задачи и второе – где вообще о получении хоть какого-то ответа от узла не может быть речи?

    [..]Мобильные операторы могут обрабатывать транзакции в real time[..]
    Ну так они и обрабатывают.. с помощью специального софта, или (лучше)
    RT операционных систем. Что – кто-то действительно серьезно подумывает о переносе RT биллинга в ‘облака’??

  18. 1. Одно другому не мешает. На облаке типизированные (типовые?) задачи вполне могут бегать в real time.
    2. RT биллинг на “петле” (которая и нормирует предоставление услуг) облегчается за счёт переноса дополнительных вычислений в облако. Я некорректно выразился: эти дополнительные вычисления – типичная batch job.

  19. [..]издержек из CapEx на OpEx[..]
    То бишь – лучше платить ‘по-договору, за услуги’, чем ‘по кредиту’?Согласен – лучше.

    А что в Австралии нельзя купить хостинг на мощном Unix-сервере с хранилищем данных?
    Технология IBM SystemP как раз под такие вещи и создана – можно ‘нарезать’ любой сервер платформы (хоть самый дешевый 2-way, хоть самый топовый) на ‘ломтики’ (вирт.сервера), всего до 128шт (а может больше – могу ошибаться) – на каждый – залить свою ОС (Linux или AIX) и ‘распродать’ клиентам.
    А самое главное – что здесь АППАРАТНАЯ реализация этой самой виртуализации, с абсолютной гарантией выделения количества квантов проц.времени на каждый вирт.сервер, причем на выбор – как жесткая (фиксированный min, max) так и плавающая (свободный max, uncapped). То есть арендуя ‘ломтик’ ты реально как бы покупаешь заданной мощности сервер.

    А если есть готовая технология, значит ее можно продавать. Продают?

  20. Если тебе надо масштабироваться без головной боли, это не самый плохой вариант.

  21. Макс, извини, но это не ответ – масштабироваться может только специально заточенное под это приложение – это раз. База данных которая на 80% есть все любого бизнеса ‘облаком’ не масштабируется – это два. Сервисы (переложенные в код бизнес-процессы и задачи) ято составляет остьльные 20% горизонтально масштабируются на ура в enterprise- средах типа J2EE – это три.
    Все уже укра.., прдон – придумано до нас..

    Распределенные транзакции, серверные фермы, многопроцессорные системы типа IBM SystemP (p570 32-way Power7, а может и больше сейчас или p595 64-way) – это ж звери, эквивалентную мощность которых вы будете с пол-мира писюков по крохам собирать… да и вообще – затык будет имхо не в
    проц.мощности, а в скорости обмена данными – с дисковой
    подсистемой или памятью, межпроцесном обмене итп.

    Ну да ладно – и все-таки приведите мне кто-нибудь пример,бизнес-задачи, которая реально требует ‘облака’?? И которая (хоть косвенно) связана с увеличением продаж?

  22. 1. согласен. 2. NoSQL+MapReduce помогут, но только для новых проектов. Со старыми проектами да, будет затык. 3. с точки зрения пользователя – да.
    Ладно, бизнес-задачи:
    1. обсчёт данных о посетителе сайта. Кто, что, что делал, зачем делал, что купил и т.п. Чтобы к тому моменту, когда пользователь придёт ещё раз, на него уже было составлено досье.
    2. real-time биллинг услуг. Экономия до миллиона долларов в год только на том, что клиентам не надо давать рефанд.
    есть ещё парочка, но вспомнил, что подписывал NDA 🙂
    Знаю, что негусто, поэтому и обращаюсь к общественности.

  23. Макс,
    но помимо высокой параллелизации, которая в твоих примерах несомненно присутствует, для облачных вычислений, чтобы они считались адекватным средством решения проблемы, нужна еще и ресурсоемкость одной транзакции, а ее в твоих примерах никак нет..

  24. Вот пример как просрали удачу в одном стартапе

    Запустил стартап програмку. Пока все было средненько (3-5 тыщ уников/день и 30-60Гб трафика) пробем не было.

    Но вот однажды Яху и СиНет почти одновременно похвалили програмку
    И все легло … и лежало 3 дня… Видно было 100-200 тыщь желающих/день, но вобщем пока спохватились то да се волна спала … вобщем что бы могло быть никто так и не узнал.

  25. А может вашему клиенту на основе его же IaaS какой-нибудь сервис? Например CDN.

  26. CDN конечно не получится, но какое-нибудь хранилище с удобным API можно сделать.

  27. Уже 🙂

  28. cosmichorror,
    На яве и ibm свет клином не сошёлся. Не все языки и платформы имеют подобную расширяемость.

  29. Не все. Но так под задачу-то технологию и подбирают..
    а не наоборот. Особенно сейчас, когда web-services уже существуют.

    А вот куда к Бизнесу облака прикрутить я еще не понял. Но искренне хочу.

  30. В общем, эту задачу телеги перед лошадью я сейчас и решаю. К сожалению, я не видел корпоративного планирования, которое позволяло бы реализовывать инициативы (которых сотни в каждый момент времени) в нужной последовательности.

  31. Экономия:
    IaaS – это операционные расходы, их можно списывать с налогов.
    По сравнению с собственным установленым железом (капитальные расходы) экономия = размер налога*стоимость эквивалентного железа

  32. Для протокола: CapEx тоже списывается с налогов посредством depreciation, только дольше.

  33. это кому что нужно.
    кому налоги прям щас списать
    а кому за счет капекса ебиду приподнять

  34. Еще идея – обратиться к конкурентам (есть как минимум 3 компании в Австралии, занимающихся IaaS).
    Попросить их посчитать тебе бизнес-кейс как пользователю их сервиса.
    Использовать их наработки в собственных целях

  35. Интересный репорт http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment/at_download/fullReport Основная проблема это с безопасностью