TwitterПоговорим об облаках
Возвращаясь к вопросам бизнес-кейсов, хочу поинтересоваться у общественности, как вы решаете вопросы переноса имеющихся систем на “облако”.
Контекст вопроса: люди, с которыми я тесно работаю, потратили около миллиарда долларов на IaaS “облако”, и теперь я бьюсь головой об стену, чтобы вернуть им этот миллиард с прибылью. Задача как раз из тех, которые я обожаю: сложная, интересная и прекрасно уживающаяся с моими амбициями.
Убедить людей переходить на “облако” – не такая простая задача, как может показаться. И дело не в том, что клиенты требуют SaaS, но согласны платить только за услуги, предоставляемые независимыми компаниями (типа Microsoft / Google), а поскольку ты чувствуешь себя комфортно в B2B сегменте, ты вынужден:
- ублажать B2B партнёров, чтобы они нежились на твоём IaaS “облаке”;
- пихать B2B партнёров, чтобы они гоняли свои сервисы как SaaS для твоих клиентов.
Если вы считаете, что эта задача тривиальная, – я вас с удовольствием найму на должность продавца с базовым окладом в $300k в год (*). Ключевым моментом тут является составление правильного бизнес-кейса для потенциального клиента (включая и внутреннего; впрочем, если вы видели, как два подразделения создают свои собственные “облака”, – вы видели всё). Мой подход к таким бизнес-кейсам такой:
- Доходы:
- возможность продавать больше единиц продукции (спасибо масштабированию). +?%
- возможность привлечения большего количества партнёров. +4%
- Экономия:
- сервисы сидят в “облаке”, работают быстрее и расположены ближе, и поэтому 1% пользователей будет пользоваться сервисом на полгода больше;
- партнёры гоняют свои сервисы у тебя в “облаке”, что позволяет им не тратиться на собственный хостинг и на найм людей. Ещё 3%, а если использовать взаимозачёт, когда ты им платишь оговоренные выплаты минус стоимость “облака”, – то и все 5%;
- твои собственные сервисы становятся дешевле в создании и поддержке. Ещё 10% экономия.
Внимание, вопрос. Если вы делали бизнес-кейсы для “облачных” вычислений, какие факторы вы учитывали?
(*) Это является проявлением моего неприкрытого цинизма и не является публичной офертой.
Filed under: Бизнес, Мысли вслух
Подписаться по Email
Одна из лучших сторон облаков — скорость изменения количества задействованных ресурсов. Короче говоря, облака помогают _дешевле_ всех переживать области с высокой производной на графике нагрузки.
Это может быть день/ночь, сезон/несезон, да и просто дигг-эффект.
Это те самые 10% экономии, про которые я говорил. И я говорю про миллионы хитов в день как стандартную нагрузку, так что дигг-эффект погоды особо не делает.
Как по мне: вам не придется возится со своими сотрудниками, которые сделают то же самое:)
Я думаю скоро начнётся разделение провайдеров облаков на специализации. И вашему клиенту было бы неплохо понять свою. И если он сделает это прямо сейчас – это выделит его из серой тени остальных провайдеров, которых уже на данные момент достаточно. Т.е. нужно позиционировать себя как-то обособленно и не пытаться охватить весь рынок сразу 🙂
Что думаете по этому поводу, Макс?
Так же важно иметь инструменты позволяющие упростить переход и использование облаков. Пример – dropbox. Их фишка- это то самое настольное приложение, которое позволяет делать все действия как по щелчку пальцев.
Dropbox – это SaaS интерфейс к IaaS хранилищу.
А вот над позиционированием облака я как раз и работаю.
хотят откусить кусочек у амазона? я не говорю о том чтобы повторить успех, не реально уже. или быть может потеснить гугл с майкрософтом, ну или на крайний случай сейлсфорс или ракспэйс.
ниша то все, туту. списать придется лярд через пару годиков.
мы как бы в этой теме уже три года. уже все перегрето по самое не балуй.
ну ладно хоть у инвесторов открутили бабла, под шумок )) сильно все это напоминает события десятилетней давности.
прочитаем эту заметку через 2 года. посмеемся вместе.
Амазона в Австралии нет, и есть ряд условий, когда облако должно быть только австралийским и предоставляться австралийской компанией. Банки и государство на этом настаивают.
Я тоже сначала был скептиком.
Это, кстати, и должно стать одним из основных направлений. У меня есть клиент, который платит втридорога, но ему нужен местный хостинг, ибо 95% его клиентов — местные.
Упрощение использования – это ключ к B2sB (small B)
Обычно стартапы ждут много-кратного роста и это аргумент для старта в облаках…
Согласен. Я продвигаю теорию, что если большие рыбы не ловятся, можно поймать много средних рыб и вырастить их.
Интересную тему подняли Максим… На сегодня есть Saas BI проект (дабы не устраивать рекламы ссылку дам по запросу) – скорей всего проект в ближайшие пол года будет переезжать в облака: рассматриваемые варианты http://aws.amazon.com/ или http://www.microsoft.com/cloud/ (второй вариант скорее, т.к. изначально сервис разрабатывался на BI платформе от microsoft).
Думаю если не лезть в технические детали, то по каким критериям будем выбирать облако под проект.
1. Платформенная совместимость.
2. Эксклюзивные возможности сервиса (технические)
3. Оперативность технической поддержки сервиса, частота обновления и конечно “устойчивость”. Иначе и мой сервис будет лежать.
Скорей всего именно эти 3 фактора определят выбор поставщика
Далее при прочих равных условиях смотрим:
4. стоимость обслуживания годовую
5. маркетинговые пряники (описанные Вами в тексте,к примеру как вариант)
Поэтому стратегия продажи Iaas на мой взгляд должна начинаться с разработки уникальный возможностей сервиса, технических отличий от прочих конкурентов под конкретные СУБД, серверы и т.д. от мировых производителей, тем самым понять нишу своего сервиса.
Т.к. предложенное сейчас – экономия на издержках, масштабируемость и т.д., есть абсолютно у всех, и на этом фоне биться с тем же microsoft крайне затруднительно. Другое дело уникальное предложение.
Извиняюсь за сумбур, если что.
Объясните плз кто-нибудь – а зачем бизнесу облака? Какие-такие задачи хорошо ложатся на облачные технологии и не ложатся на что-либо другое?
почитайте “Теория и практика облачных сервисов”:
http://xnutsive.ru/29661501
Такую статью я и сам написать могу 🙂 Мне бы узнать, что ещё засунуть в бизнес-кейс.
Все равно нифига не понял.. Я знаю что такое J2EE и виртуализация на IBM SystemP платформах (это к слову о пиках нагрузки неиспользуемой мощности) – может ли кто нибудь из тех, кто в курсе перечисленных технологий объяснить мне почему эти т.н. облака – не велосипед (причем убогий).
Хотя я в-общем могу себе представить ситуацию, когда серверные
фермы (десятки-сотни простеньких 1-2 way серверов) или монстры типа 32-way сливают – задачи гидродинамики например, декодирование генома, крипторгафия.. итп – но это все Наука. А БИЗНЕСУ-то что в таком объеме считать приспичило?
Бизнес может считать риски в real time (это для трейдинга), и вовсе это не наука.
Мобильные операторы могут обрабатывать транзакции в real time (особо болезненно для припейда).
Для клиента ключевой момент – это перенос издержек из CapEx на OpEx, что позволяет запустить больше проектов, ибо CapEx требования снижаются. Это надо было поставить первым пунктом.
real-time и облака? где первое подразумевает предсказуемость (или даже – гарантированность) времени исполнения задачи и второе – где вообще о получении хоть какого-то ответа от узла не может быть речи?
[..]Мобильные операторы могут обрабатывать транзакции в real time[..]
Ну так они и обрабатывают.. с помощью специального софта, или (лучше)
RT операционных систем. Что – кто-то действительно серьезно подумывает о переносе RT биллинга в ‘облака’??
1. Одно другому не мешает. На облаке типизированные (типовые?) задачи вполне могут бегать в real time.
2. RT биллинг на “петле” (которая и нормирует предоставление услуг) облегчается за счёт переноса дополнительных вычислений в облако. Я некорректно выразился: эти дополнительные вычисления – типичная batch job.
[..]издержек из CapEx на OpEx[..]
То бишь – лучше платить ‘по-договору, за услуги’, чем ‘по кредиту’?Согласен – лучше.
А что в Австралии нельзя купить хостинг на мощном Unix-сервере с хранилищем данных?
Технология IBM SystemP как раз под такие вещи и создана – можно ‘нарезать’ любой сервер платформы (хоть самый дешевый 2-way, хоть самый топовый) на ‘ломтики’ (вирт.сервера), всего до 128шт (а может больше – могу ошибаться) – на каждый – залить свою ОС (Linux или AIX) и ‘распродать’ клиентам.
А самое главное – что здесь АППАРАТНАЯ реализация этой самой виртуализации, с абсолютной гарантией выделения количества квантов проц.времени на каждый вирт.сервер, причем на выбор – как жесткая (фиксированный min, max) так и плавающая (свободный max, uncapped). То есть арендуя ‘ломтик’ ты реально как бы покупаешь заданной мощности сервер.
А если есть готовая технология, значит ее можно продавать. Продают?
Если тебе надо масштабироваться без головной боли, это не самый плохой вариант.
Макс, извини, но это не ответ – масштабироваться может только специально заточенное под это приложение – это раз. База данных которая на 80% есть все любого бизнеса ‘облаком’ не масштабируется – это два. Сервисы (переложенные в код бизнес-процессы и задачи) ято составляет остьльные 20% горизонтально масштабируются на ура в enterprise- средах типа J2EE – это три.
Все уже укра.., прдон – придумано до нас..
Распределенные транзакции, серверные фермы, многопроцессорные системы типа IBM SystemP (p570 32-way Power7, а может и больше сейчас или p595 64-way) – это ж звери, эквивалентную мощность которых вы будете с пол-мира писюков по крохам собирать… да и вообще – затык будет имхо не в
проц.мощности, а в скорости обмена данными – с дисковой
подсистемой или памятью, межпроцесном обмене итп.
Ну да ладно – и все-таки приведите мне кто-нибудь пример,бизнес-задачи, которая реально требует ‘облака’?? И которая (хоть косвенно) связана с увеличением продаж?
1. согласен. 2. NoSQL+MapReduce помогут, но только для новых проектов. Со старыми проектами да, будет затык. 3. с точки зрения пользователя – да.
Ладно, бизнес-задачи:
1. обсчёт данных о посетителе сайта. Кто, что, что делал, зачем делал, что купил и т.п. Чтобы к тому моменту, когда пользователь придёт ещё раз, на него уже было составлено досье.
2. real-time биллинг услуг. Экономия до миллиона долларов в год только на том, что клиентам не надо давать рефанд.
есть ещё парочка, но вспомнил, что подписывал NDA 🙂
Знаю, что негусто, поэтому и обращаюсь к общественности.
Макс,
но помимо высокой параллелизации, которая в твоих примерах несомненно присутствует, для облачных вычислений, чтобы они считались адекватным средством решения проблемы, нужна еще и ресурсоемкость одной транзакции, а ее в твоих примерах никак нет..
Вот пример как просрали удачу в одном стартапе
Запустил стартап програмку. Пока все было средненько (3-5 тыщ уников/день и 30-60Гб трафика) пробем не было.
Но вот однажды Яху и СиНет почти одновременно похвалили програмку
И все легло … и лежало 3 дня… Видно было 100-200 тыщь желающих/день, но вобщем пока спохватились то да се волна спала … вобщем что бы могло быть никто так и не узнал.
А может вашему клиенту на основе его же IaaS какой-нибудь сервис? Например CDN.
CDN конечно не получится, но какое-нибудь хранилище с удобным API можно сделать.
Уже 🙂
cosmichorror,
На яве и ibm свет клином не сошёлся. Не все языки и платформы имеют подобную расширяемость.
Не все. Но так под задачу-то технологию и подбирают..
а не наоборот. Особенно сейчас, когда web-services уже существуют.
А вот куда к Бизнесу облака прикрутить я еще не понял. Но искренне хочу.
В общем, эту задачу телеги перед лошадью я сейчас и решаю. К сожалению, я не видел корпоративного планирования, которое позволяло бы реализовывать инициативы (которых сотни в каждый момент времени) в нужной последовательности.
Экономия:
IaaS – это операционные расходы, их можно списывать с налогов.
По сравнению с собственным установленым железом (капитальные расходы) экономия = размер налога*стоимость эквивалентного железа
Для протокола: CapEx тоже списывается с налогов посредством depreciation, только дольше.
это кому что нужно.
кому налоги прям щас списать
а кому за счет капекса ебиду приподнять
Еще идея – обратиться к конкурентам (есть как минимум 3 компании в Австралии, занимающихся IaaS).
Попросить их посчитать тебе бизнес-кейс как пользователю их сервиса.
Использовать их наработки в собственных целях
Интересный репорт http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment/at_download/fullReport Основная проблема это с безопасностью