вторник, Ноябрь 28, 2006
Закон Мура и Экономика Изобилия
Преодоление нового рубежа стоимости вычислений, подмеченное Крисом Андерсоном, заставляет в очередной раз задуматься о возможностях будущих информационных технологий и о том, как они изменят нашу жизнь. Андерсон рассматривает это с точки зрения своей концепции "длинного хвоста", который таким образом сможет стать еще длиннее.
На мой взгляд стоимость MIPS уступает по масштабу последствий другой тенденции, а именно -- быстрому росту степени проникновения широкополосных интернет-соединений. Именно под воздействием этой тенденции наиболее существенно ускоряется рост доступных ИТ-ресурсов -- за счет удаленных провайдеров, а не только локальных средств. За считанные секунды можно подключиться, например, к Google с его масштабной инфраструктурой и задействовать ее для поиска ответа на интересующий вопрос, заставляя миллиарды долларов инвестиций работать несколько миллисекунд на себя.
Прирост каких-то сотен процентов производительности на десктопе просто теряется на фоне этой картины, потому что объем локальных ресурсов не идет ни в какое сравнение с тем, что мы можем получать по сети. Сами сетевые сервисы безусловно сильно выигрывают от удешевления их ресурсов. Значительная часть Web 2.0 ни за что бы не произошла, если бы создателю соответствующего сайта не хватило лимита кредитной карты на самый начальный капитал, покрывающий в основном стоимость аренды серверов. Таким образом благодаря снижению стоимости оборудования, снижаются барьеры выхода на рынок, а потребители получают большее разнообразие всевозможных сервисов. Именно провайдеры этих сервисов станут главными первичными бенефициарами снижающейся стоимости оборудования, передавая эту экономию своим пользователям.
Сами же провайдеры дальше способствуют снижению стоимости вычислений, но уже не столько за счет Закона Мура (кстати, на самом деле он Мор, а не Мур), сколько за счет повышения эффективности использования IT-ресурсов. Сетевой провайдер может обеспечить в разы более высокий средний уровень утилизации CPU, чем среднестатистическая корпорация и, тем более, индивидуальный пользователь. Это дает еще один многократный выигрыш в себестоимости технологий, но получаемый за счет архитектуры, а не плотности транзисторов. Другие выгодные прелести такой смены архитектуры связаны со снижением стоимости услуг, сопутствующих внедрению IT, таких как поддержка и обновление, не говоря об исключении ненужного посредничества в канале поставки IT. С точки зрения "экономики изобилия", стоимость поддержки одного пользователя для провайдера в долгосрочной перспективе стремится к нулю.
Это нисколько не отменяет весьма полезных завоеваний в расширении локальных возможностей ПК и мобильных устройств. Они позволят создать ряд полезных функций, без которых через некоторое время нам будет трудно представить свою жизнь. Однако ряд традиционных функций, в первую очередь бизнес-приложений, будет экономнее и удобнее использовать через сеть. И эта тенденция уже очевидна и понятна почти всем игрокам.
На мой взгляд стоимость MIPS уступает по масштабу последствий другой тенденции, а именно -- быстрому росту степени проникновения широкополосных интернет-соединений. Именно под воздействием этой тенденции наиболее существенно ускоряется рост доступных ИТ-ресурсов -- за счет удаленных провайдеров, а не только локальных средств. За считанные секунды можно подключиться, например, к Google с его масштабной инфраструктурой и задействовать ее для поиска ответа на интересующий вопрос, заставляя миллиарды долларов инвестиций работать несколько миллисекунд на себя.
Прирост каких-то сотен процентов производительности на десктопе просто теряется на фоне этой картины, потому что объем локальных ресурсов не идет ни в какое сравнение с тем, что мы можем получать по сети. Сами сетевые сервисы безусловно сильно выигрывают от удешевления их ресурсов. Значительная часть Web 2.0 ни за что бы не произошла, если бы создателю соответствующего сайта не хватило лимита кредитной карты на самый начальный капитал, покрывающий в основном стоимость аренды серверов. Таким образом благодаря снижению стоимости оборудования, снижаются барьеры выхода на рынок, а потребители получают большее разнообразие всевозможных сервисов. Именно провайдеры этих сервисов станут главными первичными бенефициарами снижающейся стоимости оборудования, передавая эту экономию своим пользователям.
Сами же провайдеры дальше способствуют снижению стоимости вычислений, но уже не столько за счет Закона Мура (кстати, на самом деле он Мор, а не Мур), сколько за счет повышения эффективности использования IT-ресурсов. Сетевой провайдер может обеспечить в разы более высокий средний уровень утилизации CPU, чем среднестатистическая корпорация и, тем более, индивидуальный пользователь. Это дает еще один многократный выигрыш в себестоимости технологий, но получаемый за счет архитектуры, а не плотности транзисторов. Другие выгодные прелести такой смены архитектуры связаны со снижением стоимости услуг, сопутствующих внедрению IT, таких как поддержка и обновление, не говоря об исключении ненужного посредничества в канале поставки IT. С точки зрения "экономики изобилия", стоимость поддержки одного пользователя для провайдера в долгосрочной перспективе стремится к нулю.
Это нисколько не отменяет весьма полезных завоеваний в расширении локальных возможностей ПК и мобильных устройств. Они позволят создать ряд полезных функций, без которых через некоторое время нам будет трудно представить свою жизнь. Однако ряд традиционных функций, в первую очередь бизнес-приложений, будет экономнее и удобнее использовать через сеть. И эта тенденция уже очевидна и понятна почти всем игрокам.
technorati tags: longtail, utility computing, ondemand, saas
среда, Ноябрь 22, 2006
Следующий Google будет построен на Amazon
Amazon.com хорошо известен потребителям -- больше 60 миллионов из них Amazon считает активными. На этом сайте свои товары им предлагает свыше миллиона продавцов, помимо хозяина площадки. Но есть у Amazon и третий бизнес, целевой аудиторией которого являются разработчики. И именно в этот бизнес Amazon наиболее активно наращивает инвестиции, стремясь сделать его таким же масштабным (и, по всей видимости, low-margin), как и бизнес электронной коммерции.
Пару месяцев назад число сервисов, базирующихся на информационных и вычислительных ресурсах Amazon.com, пополнилось новинкой Elastic Compute Cloud (EC2). Благодаря EC2, любой разработчик может приобрести время на выделенном сервере или произволного размера кластере, вооружившись не более чем кредитной картой. На самом деле все сервера выделяются из пула виртуализированных машин, каждая из которых эквивалентна Xeon 1.7GHz с 1.75GB памяти. Стоимость составляет вполне конкурентоспособные $0.10 за CPU-час, соответствующие $73/месяц, не считая стоимости трафика. Более важно то, что масштабировать свой data-центр вверх/вниз можно динамично, по мере изменения нагрузки.
Таким образом, путем нехитрых манипуляций, можно не сильно напрягаясь арендовать собственный кластер с root-доступом и хорошей связью. Что делать с этим новообретенным богатством подскажет Google, который большую часть своего бизнеса держит на воспетых прессой commodity-серверах. Для этого он использует собственный технологический стэк, который был частично клонирован в рамках проекта Apache Lucene и сейчас называется Hadoop. Так вот, Hadoop примерили на EC2, и, надо сказать, они неплохо смотрятся вместе.
Для сравнения: Sun Grid Compute Utility, предназначенный именно для параллелизации вычислений в "эластичной" среде, стоит $1/CPU-час. При этом доступ к ресурсам Compute Utility осуществляется только через Compute Server API, и никаким root-доступом не пахнет. Значит эту платформу можно подключать только в качестве расширения собственных вычислительных ресурсов, от которых отказаться совсем не удастся.
Очевидно, что на EC2 можно поставить не только Hadoop, но и любой другой технологический стэк (например, LAMP или JEE) в том числе вовсе не обязательно (кстати, как и Hadoop) связанный с Web. Но теперь фанаты функционального программирования, воодушевленные успехами Google, могут получить нечто очень похожее на его инфраструктуру, если именно этого им не хватало для построения решений "масштаба Web". Ведь хорошие идеи и ресурсы не всегда находят друг друга. Спешить, однако, пока не стоит, так как EC2 (как и Sun Grid) вполне оправданно находится в бете, закрытой для публики. Но, если вам это интересно, то записаться в очередь сейчас самое время.
Пару месяцев назад число сервисов, базирующихся на информационных и вычислительных ресурсах Amazon.com, пополнилось новинкой Elastic Compute Cloud (EC2). Благодаря EC2, любой разработчик может приобрести время на выделенном сервере или произволного размера кластере, вооружившись не более чем кредитной картой. На самом деле все сервера выделяются из пула виртуализированных машин, каждая из которых эквивалентна Xeon 1.7GHz с 1.75GB памяти. Стоимость составляет вполне конкурентоспособные $0.10 за CPU-час, соответствующие $73/месяц, не считая стоимости трафика. Более важно то, что масштабировать свой data-центр вверх/вниз можно динамично, по мере изменения нагрузки.
Таким образом, путем нехитрых манипуляций, можно не сильно напрягаясь арендовать собственный кластер с root-доступом и хорошей связью. Что делать с этим новообретенным богатством подскажет Google, который большую часть своего бизнеса держит на воспетых прессой commodity-серверах. Для этого он использует собственный технологический стэк, который был частично клонирован в рамках проекта Apache Lucene и сейчас называется Hadoop. Так вот, Hadoop примерили на EC2, и, надо сказать, они неплохо смотрятся вместе.
Для сравнения: Sun Grid Compute Utility, предназначенный именно для параллелизации вычислений в "эластичной" среде, стоит $1/CPU-час. При этом доступ к ресурсам Compute Utility осуществляется только через Compute Server API, и никаким root-доступом не пахнет. Значит эту платформу можно подключать только в качестве расширения собственных вычислительных ресурсов, от которых отказаться совсем не удастся.
Очевидно, что на EC2 можно поставить не только Hadoop, но и любой другой технологический стэк (например, LAMP или JEE) в том числе вовсе не обязательно (кстати, как и Hadoop) связанный с Web. Но теперь фанаты функционального программирования, воодушевленные успехами Google, могут получить нечто очень похожее на его инфраструктуру, если именно этого им не хватало для построения решений "масштаба Web". Ведь хорошие идеи и ресурсы не всегда находят друг друга. Спешить, однако, пока не стоит, так как EC2 (как и Sun Grid) вполне оправданно находится в бете, закрытой для публики. Но, если вам это интересно, то записаться в очередь сейчас самое время.
technorati tags: amazon, google, ec2, sungrid, mapreduce, hadoop, utilitycomputing, ondemand, haas
пятница, Ноябрь 10, 2006
Модель продаж SaaS
Модель продаж SaaS кардинально отличается от подходов вендоров традиционных корпоративных приложений.
Если Вы когда-либо имели дело с продажами ПО корпоративным клиентам, то вероятно знаете, насколько неблагодарное это дело. Отсутствие четких критериев возврата инвестиций, непрозрачная модель принятия решений, высокие риски провала внедрения -- все это вынуждает вендоров и их партнеров тратить огромные суммы на содержание армии дорогостоящих маркетолов, эккаунт-менеджеров и технических специалистов, большую часть своего времени проводящих в роли пресейл-консультантов. В итоге, сами же клиенты оплачивают их тяжкий труд, причем платят они в конечном счете и за работу вендора или интегратора с другими клиентами, не приведшую к контракту с ними.
Типичная модель продаж SaaS -- прямая. Единственный ее канал -- интернет, и никакие посредники, даже сотрудники самого разработчика, в процессе продаж не задействованы, за редким исключением. В отличие от коробочных приложений, Web-приложения можно попробовать не имея для этого ни сервера, ни каких-либо специфических знаний по установке, настройке и администрированию приложения, а также его базы данных, операционной системы и прочих внешних зависимостей. Достаточно иметь Web-браузер, а времени на непосредственную оценку приложения потребуется гораздо меньше, чем на бесконечные переговоры с вендором о том, как все будет прекрасно. В результате процесс продаж SaaS превращается в самообслуживание, а расходы на продажи у SaaS-разработчиков не переменные (не пропорциональны числу новых клиентов), как у традиционных вендоров ПО, а постоянные, как и стоимость разработки.
Скорость принятия решения увеличивается еще и потому, что речь не идет об очередных не всем понятных инвестициях в IT. SaaS требует commitment не больше, чем на год, а чаще всего на месяц. Такая модель оплаты позволяет принципиально новым категориям бюджетодержателей принимать IT-решения. Так, нередко менеджеры небольших групп переводят свои отделы на SaaS пока CIO планирует инсталляцию аналогичного решения на следующий год. Согласование c CIO обходят, так как ресурсы информационной службы не задействуются, а деньги на небольшие ежемесячные отчисления можно найти в "прочих расходах", обходясь также без визы CFO. Таким образом механизм убеждения клиента упрощается донельзя: нравится -- берите, желательно у нас не спрашивая.
Демонстрации, выезды к клиенту, индивидуальные технические и коммерческие предложения уходят в прошлое, а с ними и высокая стоимость индивидуальной поддержки, на которой, собственно, и базируется прибыль вендоров бизнес-приложений. Те, кто работает по-старому, просто увеличивают расходы клиента, который за все это личное внимание (как правило, к своему CIO) в конечном счете заплатит, поделившись этой платой и с самим CIO (порой и не подозревая об этом). Полагаю, что с течением времени желающих будет становится все меньше. Более эффективные модели IT постепенно вытеснят исторически сложившиеся.
Siebel тратит столько денег на продажи, потому что он вынужден убеждать умных людей сделать глупость.Так на проходившем в San Jose в рамках On Demand Summit круглом столе один из участников охарактеризовал неэффективность продаж "коробочных решений" по сравнению с их Web-альтернативами.
Если Вы когда-либо имели дело с продажами ПО корпоративным клиентам, то вероятно знаете, насколько неблагодарное это дело. Отсутствие четких критериев возврата инвестиций, непрозрачная модель принятия решений, высокие риски провала внедрения -- все это вынуждает вендоров и их партнеров тратить огромные суммы на содержание армии дорогостоящих маркетолов, эккаунт-менеджеров и технических специалистов, большую часть своего времени проводящих в роли пресейл-консультантов. В итоге, сами же клиенты оплачивают их тяжкий труд, причем платят они в конечном счете и за работу вендора или интегратора с другими клиентами, не приведшую к контракту с ними.
Типичная модель продаж SaaS -- прямая. Единственный ее канал -- интернет, и никакие посредники, даже сотрудники самого разработчика, в процессе продаж не задействованы, за редким исключением. В отличие от коробочных приложений, Web-приложения можно попробовать не имея для этого ни сервера, ни каких-либо специфических знаний по установке, настройке и администрированию приложения, а также его базы данных, операционной системы и прочих внешних зависимостей. Достаточно иметь Web-браузер, а времени на непосредственную оценку приложения потребуется гораздо меньше, чем на бесконечные переговоры с вендором о том, как все будет прекрасно. В результате процесс продаж SaaS превращается в самообслуживание, а расходы на продажи у SaaS-разработчиков не переменные (не пропорциональны числу новых клиентов), как у традиционных вендоров ПО, а постоянные, как и стоимость разработки.
Скорость принятия решения увеличивается еще и потому, что речь не идет об очередных не всем понятных инвестициях в IT. SaaS требует commitment не больше, чем на год, а чаще всего на месяц. Такая модель оплаты позволяет принципиально новым категориям бюджетодержателей принимать IT-решения. Так, нередко менеджеры небольших групп переводят свои отделы на SaaS пока CIO планирует инсталляцию аналогичного решения на следующий год. Согласование c CIO обходят, так как ресурсы информационной службы не задействуются, а деньги на небольшие ежемесячные отчисления можно найти в "прочих расходах", обходясь также без визы CFO. Таким образом механизм убеждения клиента упрощается донельзя: нравится -- берите, желательно у нас не спрашивая.
Демонстрации, выезды к клиенту, индивидуальные технические и коммерческие предложения уходят в прошлое, а с ними и высокая стоимость индивидуальной поддержки, на которой, собственно, и базируется прибыль вендоров бизнес-приложений. Те, кто работает по-старому, просто увеличивают расходы клиента, который за все это личное внимание (как правило, к своему CIO) в конечном счете заплатит, поделившись этой платой и с самим CIO (порой и не подозревая об этом). Полагаю, что с течением времени желающих будет становится все меньше. Более эффективные модели IT постепенно вытеснят исторически сложившиеся.
technorati tags: saas
LinkedIn
vCard
Лента
