The Other Road Ahead

Оригинал Перевод

Сентябрь 2001

(Эта статья объясняет почему многое в ПО следующего поколения может быть реализовано на серверной стороне, что это будет значить для программистов, и почему этот новый вид ПО будет хорошей возможностью для стартапов. Источниками статьи были диалоги в BBN Labs.)

Летом 1995-го я со своим другом Робертом Моррисом (Robert Morris) решили запустить стартап. PR-кампания перед IPO Netscape тогда шла полным ходом, и в прессе было полно разговоров об электронной коммерции. На тот момент в сети уже было порядка тридцати реальных электронных магазинов, и все они были сделаны вручную. Если в скором времени в сети должно было появиться множество онлайн-магазинов, была потребность в ПО для их разработки, и мы решили такое написать.

Сначала, где-то около недели мы думали, что это будет обычное приложение для ПК. Но потом у нас возникла идея разработать приложение, которое будет исполняться на нашем веб-сервере, с использованием браузера в роли пользовательского интерфейса. Мы попробовали переписать приложение для работы в Вебе, и стало понятно, что это правильное направление. Если мы писали наше ПО для исполнения на сервере, это было удобнее как для пользователей, так и для нас.

Оказалось, что это был отличный план. Теперь, как Yahoo Store, это ПО является самым популярным конструктором онлайн-магазинов, с ним работает порядка 14 тысяч пользователей.

Когда мы начинали разработку Viaweb, почти никто не понимал что мы имеем в виду, когда говорим, что ПО будет работать на сервере. Так было до тех пор, пока через год не запустился Hotmail, и люди начали его использовать. Теперь все знают, что это разумный подход. Теперь есть название для того, чем мы тогда были: провайдер приложений (Application Service Provider или ASP).

Я думаю, что значительная часть ПО следующего поколения будет разрабатываться по этой модели. Даже Microsoft, кто больше всех может потерять, кажется видит неизбежность переноса приложений с десктопов на сервер. Если такой перенос происходит, это означает совершенно другой мир для программистов. В этой статье описываются неожиданности, с которыми мы сталкиваемся как первопроходцы этого мира. А раз софт перемещается на серверы, то, что я описываю здесь, есть наше будущее.

Новое устройство?

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

Компьютеры сейчас на таком же этапе развития. Для того, чтобы пользоваться персональным компьютером, вы вынуждены изучить намного больше, чем вообще хотите знать что происходит внутри него. Однако компьютерами владеют более половины домохозяйств в Штатах. Моя мама пользуется компьютером для переписки по электронной почте и ведения счетов. Около года назад она была встревожена, когда получила от Apple письмо, в котором ей предлагали скидку при покупке новой версии операционной системы. Очевидно что-то не в порядке, если шестидесятипятилетняя женщина, которая хочет пользоваться только электронной почтой и счетами, вынуждена думать об установке новых версий операционной системы. Обычные пользователи не должны даже знать о терминах «операционная система», не говоря уж о «драйвер устройства» или «патч».

Теперь есть другой путь установки ПО, который не будет заставлять пользователей становиться системными администраторами. Веб-приложения — это программы, работающие на веб-серверах и использующие в роли пользовательского интерфейса веб-страницы. Для среднестатистического пользователя этот новый вид ПО будет проще, дешевле, более переносимым, более надёжным, и часто более мощным, чем приложение на персональном компьютере.

С веб-приложениями большинство пользователей не будут должны думать о чём-то ещё, кроме самих приложений. Все сложные и меняющиеся составляющие будут находиться где-то на сервере и обслуживаться специально обученными специалистами. И более того, вам вообще может быть не нужен компьютер, чтобы пользоваться приложением. Всё, что вам потребуется, это что-то с клавиатурой, экраном и веб-браузером. Возможно с беспроводным доступом в Интернет. Возможно этим будет ваш мобильный телефон. Чем бы это ни было, это будет бытовой техникой: будет стоить около $200, и выбирать будут, исходя из внешнего вида. Вы будете больше платить за доступ в Интернет, чем за оборудование, так же, как сейчас это происходит с телефонами [1].

Время отклика сервера на действие пользователя составляет порядка десятой доли секунды, поэтому пользователи тяжёлого интерактивного ПО (например, Photoshop) по-прежнему будут хотеть, чтобы вычисления шли на локальной машине. Но если вы посмотрите для чего большинство людей использует компьютеры, то согласитесь, что время отклика в секунду не будет для них проблемой. Моей маме на самом деле персональный компьютер не нужен, и большинству людей тоже.

Польза для пользователей

Недалеко от моего дома стоит машина с наклейкой «лучше смерть, чем неудобство». Большинство людей в большинстве случаев выбирают то, что требует меньше усилий. Если веб-приложения победят, то это будет потому что они более удобные. Причём как для пользователей, так и для разработчиков.

Чтобы использовать чистое веб-приложение, всё, что вам понадобится, это веб-браузер, имеющий доступ в Интернет. Поэтому вы можете использовать веб-приложение откуда угодно. Когда вы устанавливаете софт на свой ПК, вы можете пользоваться им только на этом ПК. Хуже того, ваши файлы заперты в этом ПК. Неудобство этой модели становиться всё более очевидным для людей, которые пользуются сетями.

Поворотной точкой стали веб-приложения электронной почты. Миллионы поняли, что должны иметь доступ к почте откуда угодно. А если вы читаете свою почту, то почему бы и не календарь тоже? Если вы обсуждаете с коллегами документ, то почему бы и не редактировать его? Почему вообще ваши данные должны быть привязаны к определенному компьютеру?

Сама идея «Вашего компьютера» исчезает и заменяется «Вашими данными». У вас должен быть доступ к своим данным с любого компьютера. Или даже с любого устройства, и устройство не обязательно должно быть компьютером.

Такие устройства не хранят данные, они должны быть как телефоны. На самом деле они могут стать телефонами, или наоборот, телефоны станут такими устройствами. А раз они становятся меньше, есть ещё один довод не хранить данные на них: то, что вы носите с собой, может быть потеряно или украдено. Оставить наладонник в такси — всё равно что авария диска, только в этом случае ваши данные попадают в чьи-то руки, а не просто стёрлись.

С программным обеспечением, полностью основанным на веб-технологиях, ни данные, ни приложения не хранятся на клиенте. Поэтому вам не нужно ничего устанавливать, чтобы использовать. А когда установка не нужна, то и не надо волноваться, что что-то установится не так. Не может быть несовместимости между приложением и операционной системой на вашем устройстве, поскольку приложение не исполняется в вашей операционной системе.

Посколько установка не требуется, попробовать софт перед покупкой станет легко и просто стандартным подходом. Должно стать возможно бесплатно потестировать приложение просто зайдя на сайт, где оно продаётся. Сайт Viaweb можно представить как один большой указатель на предложение пользователям тест-драйва.

После демо-версии подписка на сервис не должна потребовать ничего, кроме заполнения короткой формы (чем короче, тем лучше). И это должно быть последнее, что требуется от пользователя. Используя веб-приложения, вы должны получать обновления без доплаты, без каких-либо действий, или даже без уведомлений.

Апгрейды больше не будут такими шокирующими, как сейчас. С течением времени приложения будут незаметно становиться более мощными. Это потребует некоторых усилий со стороны программистов. Они будут должны проектировать приложения так, чтобы обновления не отражались на пользователях. Это новая задача, но пути её решения существуют.

С веб-приложениями все используют одну и ту же версию, и баги могут исправляться сразу после обнаружения. Поэтому веб-приложения должны иметь значительно меньшее количество багов по сравнению с приложениями на ПК. Сомневаюсь, что в Viaweb бывало больше, чем десять багов одновременно. Это на несколько порядков лучше, чем в случае приложений для ПК.

Веб-приложения могут совместно использоваться несколькими людьми. Это преимущество кооперативного ПО очевидно, но я могу поспорить пользователи захотят этого в большинстве приложений, как только поймут, что это возможно. Например, часто будет полезно позволять двум пользователям редактировать один документ. Viaweb позволяет нескольким пользователям редактировать сайт одновременно, в большей степени из-за того, что так проектировать правильно, чем потому что мы ожидали, что пользователи этого захотят, но оказалось, что многие хотели.

Когда вы будете пользоваться веб-приложением, ваши данные будут надежнее защищены. Аварии дисков не уйдут в прошлое, но пользователи больше не услышат об этом. Это будет происходить в серверных центрах. И компании, предлагающие веб-приложения, будут делать резервые копии — не только потому, что у них будут работать грамотные сисадмины, которые знают о чем надо беспокоиться, но и потому что сервис-провайдер, теряющий данные пользователей, будет иметь большие неприятности. Когда люди теряют своим данные из-за поломки диска, они не могут бешенно сходить с ума, потому что злиться они могут только на самих себя. Когда компания потеряет их данные, они будут значительно злее.

Ну и последнее, веб-приложения должны быть менее уязвимы для вирусов. Если на терминале не запускается ничего, кроме браузера, меньше шансов получить вирус, и локальных данных, которые можно повредить, тоже нет. А программа, атакующая сами серверы, обнаружит их очень хорошо защищенными [2].

Веб-приложения будут меньше нервировать пользователей. Если заглянете в мысли среднестатистического пользователя Windows, вы найдете там огромную неудовлетворенную потребность в подобном софте. Если делать такой софт, это может стать мощным преимуществом.

Город кода

Для разработчиков самое явное отличие веб-софта от «обычного» в том, что веб-софт не состоит из одного цельного куска кода. Он будет представлять собой набор программ различного типа, а не один большой бинарник. Так что проектирование веб-приложений будет похоже на проектирование города, а не проектирование здания: помимо зданий вам понадобятся дороги, дорожные указатели, ремонтные, полицейские и пожарные службы, а также планы развития и ликвидации катастроф.

В Viaweb программный пакет состояло из сравнительно больших приложений, с которыми непосредственно работают пользователи, из программ, которые используют эти приложения, из программ, которые постоянно работают в фоне для определения проблем, из программ, которые пытаются рестартовать то, что сбойнуло, из программ, которые запускаются время от времени, чтобы собрать статистику или построить поисковые индексы, из программ, которые запускаются вручную для сборки мусора или для перемещения/восстановления данных, из программ, которые имитируют пользователей (для измерения производительности или поиска ошибок), из программ для диагностики сетевых аварий, из программ, выполняющих резервное копирование, из интерфейсов к внешним сервисам, из программ, которые управляют впечатляющей коллекцией циферблатов, показывающих статистику сервера в реальном времени (необходимые не только не только пользователям, но и нам), изменения (в том числе багфиксы) в открытом ПО и из огромного количества конфигурационных файлов и настроек. После того, как мы были куплены Yahoo, Тревор Блекуэлл (Trevor Blackwell) написал эффектную программу для переноса магазинов на новые серверы, расположенные в другой точке страны, без их выключения. Программы посылают нам пейджинговые сообщения, посылают факсы и электронную почту пользователям, собирают транзакции процессинга кредитных карт, и взаимодействуют с другими программами через сокеты, пайпы, http-запросы, ssh, пакеты udp, разделяемую память и файлы. Часть Viaweb даже состоит из «отсутствия» программ, так как один из ключевых принципов безопасности Unix — не позволять запускать лишних утилит, которые можно использовать для взлома серверов.

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

Но оборудование не только то, о чём нужно заботиться. Когда вы управляете им, вы можете больше предоставить пользователям. В случае персонального ПО вы можете определить минимальную конфигурацию оборудования, но вы не сможете потом дать больше. Если администрируете серверы, вы можете за один раз добавить всем пользователям функции пейджинговой связи, отправки факсов, управления по телефону или процессинга кредитных карт и т.д., просто установив соответствующее оборудование. Мы постоянно ищем новые возможности добавить различные функции на основе оборудования, не только для того, чтобы порадовать пользователей, но и чтобы выделиться по сравнению с конкурентами, которые не могут управлять техникой напрямую (потому что продают персональный софт или предоставляют свои веб-приложения через интернет-провайдеров).

Так как программное обеспечение в веб-приложениях будет представлять собой пакет программ, а не единый исполняемый файл, они могут быть написаны на нескольких языках программирования. Когда вы пишете персональный софт, вас практически заставляют писать на том же языке, на котором написана операционная система, то есть С или С++. Поэтому эти языки рассматриваются (особенно нетехническими сотрудниками, например, менеджерами или вице-президентами) как языки для «серьёзной» разработки. Но это является просто стереотипом, сложившимся в сфере разработки персонального софта. Для приложений, размещающихся на сервере, вы можете использовать любой язык какой захотите.[3] Сейчас многие программисты высшего класса используют языки, очень далекие от С и С++: Perl, Python или даже Lisp.

Для серверного ПО никто не может вам указывать какой язык использовать, потому что вы управляете системой в целом, вплоть до уровня аппаратного обеспечения. Языки программирования по-разному пригодны для различных задач. Вы сможете использовать язык, который наилучшим образом подходит для вашей задачи. А когда у вас есть конкуренты, то «сможете» превращается в «обязаны», потому что если вы не воспользуетесь этим преимуществом, воспользуются они.

Большинство наших конкурентов используют С и С++, что делает их ПО заметно хуже, потому что (помимо других проблем) они не могут работать с отсутствием состояния CGI скриптов. Если вы собираетесь что-то изменить, все изменения должны происходить на одной странице с кнопкой «Изменить» внизу. Так как я использовал Lisp, который многие по-прежнему считают языком для исследований, мы смогли сделать редактор Viaweb похожим на десктопное приложение.

Версии

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

С приложением на сервере вы можете делать доработки почти так же, как в программе, которую вы пишете для себя. Вы выпускаете версии как последовательность поэтапных изменений вместо внезапного большого взрыва. Обычно компания, производящая десктопное ПО, может выпустить одну или две версии за год. Для Viaweb мы часто делали три-пять версий в день.

Когда вы переходите к этой новой модели, то понимаете как много в процессе разработки ПО зависит от порядка выпуска версий. Множество отвратительнейших проблем, которые можно заметить в бизнесе разработки персонального ПО, связано с катастрофическим характером выпуска версий.

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

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

Персональный софт воспитывает определенный фатализм по отношению к багам. Вы знаете, что поставляете его с багами, и даже определяете механизмы их устранения (например, патчи исправлений). Так чего ради беспокоиться, что их будет немного больше? И вскоре вы обнаруживаете, что все элементы, о которых вы знаете, не работоспособны. Apple в этом году столкнулась с такой ситуацией. Они чувствовали нажим по отношению к выпуску новой версии операционной системы, который уже четыре раза откладывался, но некоторые составляющие (поддержка CD и DVD) еще не были готовы. И решение? Они выпустили версию без этих составляющих, и пользователи будут устанавливать их позднее.

Приложения на веб-серверах вы не обязаны запускать, пока они не заработают, и вы можете опубликовать их сразу как только закончите работу. Опытные коллеги могут подумать: да, это отлично звучит, если говорить, что вы не обязаны выпускать ПО, пока оно не будет работать, но что будет если вы пообещали выпустить новую версию к определенной дате? С веб-приложениями вы не обязаны давать таких обещаний, потому что версий как таковых нет. Ваше приложение изменяется постепенно и непрерывно. Некоторые изменения могут быть более значительны, чем другие, но подход с выпуском версий не гармоничен веб-приложениям.

Если кто помнит Viaweb, это может звучать странно, поскольку мы всегда анонсировали новые версии. Это делалось исключительно для целей PR. Деловая пресса, как мы поняли, оперирует номерами версий. Они выделяют вам разворот, если версия обновленная, то есть, если первая цифра в номере версии увеличилась, и только параграф, если версия для доработок, где изменения в номере после точки.

Некоторые из наших конкурентов предлагали персональное ПО с действительными номерами версий. Для таких версий само это, что кажется нам очевидным фактом их отсталости, позволяет получить всю возможную информационную поддержку. Мы не хотели упускать эту возможность, и тоже стали присваивать номера версий нашим приложениям. Когда мы хотели прорекламировать, мы собирали список всех разработок, которые были добавлены с прошлой «версии», лепили новый номер версии на приложение и выпускали пресс-релиз, информирующий о доступности новой версии. Поразительно, что никто не звонил нам по этому поводу.

К тому времени когда нас купили, мы проделали это три раза, и были на версии 4. Версии 4.1, если не подводит память. После того, как Viaweb стал Yahoo Store, острая необходимость в популяризации отпала, и хоть система и продолжала эволюционировать, сама идея с номерами версий была тихо похоронена.

Баги

Еще одним сильным техническим преимуществом веб-приложений является то, что вы можете воспроизвести бОльшую часть багов. Данные пользователей лежат прямо у вас на диске. Если у кого-то происходит сбой в вашем приложении, вы не обязаны пытаться угадать что там произошло, как это было бы в случае персонального ПО: вы можете воспроизвести сбой прямо во время телефонного разговора с ними. Вы даже можете уже знать об этом, если ваше приложение имеет сервис оповещения о сбоях.

Веб-приложения работают круглосуточно, поэтому код, который вы дописали, немедленно попадает в мясорубку. Баги проявляются быстро.

Разработчиков часто упрекают в том, что они отлаживают свой софт на пользователях. И я хочу высказаться в защиту этого. Для веб-приложений это на самом деле хорошая идея, потому что багов меньше, и они лёгкие. Когда вы часто выпускаете новые версии, то получаете намного меньше багов. А когда вы можете немедленно воспроизвести ошибку и мгновенно выпустить ее исправление, вы можете найти и исправить большую часть багов как только они проявят себя. У нас никогда не было одновременно такого количества багов, которого было бы достаточно для того, чтобы мы задумались о полноценной системе баг-трекинга.

Конечно, вы обязаны тестировать доработки, прежде чем выпускать их в промышленную систему, поэтому серьезных багов в релизе появляться не должно. Те немногие, которые неминуемо проскользнут, будут проявляться только в нестандартных условиях у небольшой группы пользователей, которые успеют столкнуться с этими багами пока никто еще не успел пожаловаться. И если вы устраняете ошибки сразу, то в результате среднестатистический пользователь увидит намного меньше багов. Думаю, что среднестатистический пользователь Viaweb вообще никогда не видел ошибок.

Устранение свежих ошибок намного легче, чем устранение старых. Как правило, значительно легче искать ошибку в коде, который вы только что написали. Когда ошибка появляется, вы часто можете определить что не так даже до того, как полезете в код, потому что это еще находится в подсознании. Исправление бага в коде, который вы написали полгода назад (средний срок, если версия выпускается раз в год), потребует намного больше усилий. И так как вы уже не чувствуете код так же хорошо, скорее всего, вы сделаете исправление не лучшим образом, а то и добавите других багов. [4]

Когда баги ловятся на ранних этапах, вы получаете меньше составных багов. Составные баги — это два отдельных бага, которые взаимодействуют друг с другом: вы спускаетесь вниз по лестнице, и когда вы цепляетесь за перила, то они остаются у вас в руке. В софте этот вид багов самый трудный для обнаружения, и кроме того, имеет свойство приносить худшие последствия. [5] Традиционный подход «сломай все и баги отсеятся» сам по себе генерирует множество составных багов. Непрерывный выпуск мелких версий не приводит к этому. Полы все время чисто подметены от любых потерянных мелочей, которые впоследствии могут в чем-нибудь застрять.

В этом помогает техника функционального программирования. ФП значит избегать побочных эффектов. Это что-то, более подходящее для научных исследований, чем для коммерческого ПО, но в случае веб-приложений оно превращается в по-настоящему полезную идею. Целиком программу трудно написать в чисто функциональном коде, но вы можете писать в таком стиле отдельные блоки. Такие части вашего приложения легче тестировать, поскольку у них нет состояния, а это очень удобно в случае, когда вы постоянно делаете и тестируете небольшие изменения. Я написал большую часть редактора Viaweb в таком стиле, и мы создали собственный скриптовый язык RTML как чисто функциональный язык.

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

Поддержка

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

Не так это устроено в Viaweb. В Viaweb поддержка бесплатна, потому что мы хотим слышать наших потребителей. Если у кого-то из них проблема, мы хотим знать об этом немедленно, чтобы воспроизвести ошибку и выпустить исправление.

Так что в Viaweb разработчики всегда были в тесном контакте с поддержкой. Сотрудники поддержки сидели в десяти метрах от программистов, и они знали, что могут в любой момент побеспокоить сообщением о новом баге. Мы могли прервать совещание совета директоров ради исправления серьёзной ошибки.

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

Наша политика устранения ошибок на лету изменила отношения между сотрудниками поддержки и высококлассными программистами. В большинстве компаний в поддержке работают низкооплачиваемые «вахтеры», а программисты — это маленькие копии Бога-Отца, творцы Вселенной. Какова бы ни была процедура сообщения об ошибках, она, скорее всего, направлена в одну сторону: сотрудник поддержки, который получил сведения об ошибке, записывает их в какую-либо форму и через некоторое время пересылает (возможно через службу качества) программистам, которые ставят их в план работы. Это было совершенно не так в Viaweb. В течение минуты после получения сообщения об ошибке от пользователя сотрудник поддержки мог уже стоять рядом с программистом и слышать от него «Черт, ты прав, это баг». Сотруднику поддержки было очень приятно услышать «ты прав» от суперспециалиста. Они привыкли приносить нам баги с тем же выражением лица, которое бывает у кота, несущего вам только что убитую мышь. Это также делало их более осторожными в оценках важности ошибки, потому что их реноме ставилось на карту.

После того, как мы были куплены Yahoo, сотрудники поддержки переехали далеко от программистов. Только тогда мы почувствовали что они были фактически сотрудниками службы качества и в некоторой степени маркетинга. Помимо отлова багов они были хранителями знаний о неясных багоподобных штучках, которые путали пользователей. [6] Еще они были в некотором роде фокус-группой представителей пользователей; мы могли спросить их какую из двух новых фич пользователи хотят больше, и они всегда оказывались правы.

Подход к делу

Иметь возможность выпускать программу незамедлительно — существенный мотиватор. Часто по пути на работу я думал об изменениях, которые мне хотелось внести в приложение, и вносил их в тот же день. Это также работало и для более крупных фич. Даже если на написание чего-то требовалось две недели (а на некоторых проектах и того больше), я знал, что смогу увидеть результат как только все будет реализовано.

Если бы мне приходилось ждать год до следующего релиза, я бы большинство таких идей отложил в долгий ящик, по крайней мере, на некоторое время. Дело в том, что, все-таки, идеи приводят к другим идеям. Вы когда-нибудь замечали, что, как только вы садитесь что-то написать, половина воплощенных в работе идей — это те идеи, которые посетили вас в процессе? То же самое происходит и с программами. Работа над реализацией одной идеи дает вам еще больше идей. Поэтому за откладывание вы заплатите не только задержкой в реализации своей идеи, но также и всеми идеями, к которым вы придете на данном этапе. На самом деле, откладывание препятствует появлению новых идей: как только вы начинаете размышлять о каком-то новом функционале, вы вспоминаете про свой «ящик» и думаете: «Но у меня же уже куча фишек для реализации в следующем релизе».

Крупные компании вместо реализации фич планируют их. По этой причине мы в Viaweb иногда сталкивались с трудностями. Инвесторы и аналитики спрашивали нас о том, что мы запланировали на будущее. Нашим настоящим ответом было бы: «У нас вообще нет планов». У нас были общие представления о том, что бы мы хотели улучшить, но если бы мы знали как, то уже давно бы это сделали. Что мы собираемся делать с течении следующих шести месяцев? Все, что могло бы привести нас к максимально выигрышному положению. Не знаю, осмелился бы я когда-нибудь так ответить, но такова была правда. Планы — это всего лишь синоним к слову «идеи». Когда нас посещали хорошие идеи, мы реализовывали их.

В Viaweb, так же как и во многих других компаниях по разработке программного обеспечения, большинство кода имеет одного определенного владельца. Но если вам что-то принадлежит, то вы реально этим обладали: никто, за исключением владельца части программы, не может дать разрешение на ее релиз (или даже знать об этом). Как таковой защиты от поломок, кроме как страха выглядеть идиотом перед своими коллегами, не было, но и этого было более чем достаточно. Я, возможно, создал ложное представление о том, что мы просто безмятежно двигались вперед создавая код. Мы и правда быстро продвигались, но мы тщательно все продумывали перед тем, как выложить приложение на серверы. В плане надежности внимание важнее медленного продвижения. Именно благодаря повышенному вниманию к процессу военный летчик может ночью посадить 40 000 фунтовый самолет на скорости 140 миль в час на раскачивающуюся палубу авианосца, и при этом риска будет меньше, чем при разрезании хлеба среднестатистическим подростком.

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

Теория Брукса наоборот

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

Viaweb был написан всего тремя людьми. [7] Я очень старался нанять еще, потому что нам хотелось, чтобы нас купили, а мы знали, что было бы нелегко убедить покупателей заплатить высокую цену за фирму с тремя программистами. (Решение: мы наняли еще людей, но создали для них новые проекты.)

Когда вы пишете программы, имея в штате меньшее количество программистов, то вы экономите больше, чем только деньги. Как заметил Фред Брукс в своей книге «Мистический человеко-месяц», увеличение числа людей в проекте ведет к его замедлению. Количество возможных связей между разработчиками растет экспоненциально с увеличением размера группы: чем она крупнее, тем больше времени будет потрачено на обсуждение того, как приложения будут совместно работать, и тем больше ошибок проявится из-за непредвиденных зависимостей. К счастью, этот процесс также работает и в обратном направлении: чем меньше группа, тем выше по экспоненте растет эффективность процесса разработки приложений. Я не могу припомнить, чтобы программисты в Viaweb организовывали настоящие собрания. Мы никогда за раз не говорили больше, чем могли сказать по пути на обед.

Если тут и есть какой-то недостаток, то он состоит в том, что все программисты в некоторой степени должны также быть и системными администраторами. Когда вы разворачиваете приложение, кто-то должен наблюдать за серверами и, практически, единственные люди, кто это может сделать правильно, это те, кто это приложение и написал. В Viaweb наша система содержала в себе так много компонентов и менялась так часто, что не было четкой границы между приложением и инфраструктурой. Своевольное утверждение такой границы ограничило бы нас в выборе проектных решений. И поэтому, хотя мы постоянно надеялись, что однажды («через пару месяцев») все будет достаточно стабильно работать, чтобы мы могли нанять кого-нибудь, в чьи обязанности входило бы только забота о серверах, но этого так и не произошло.

Не думаю, что тут есть другой выход, пока вы все еще активно разрабатываете продукт. Веб-приложения никогда не станут тем, что вы пишете, сохраняете в репозиторий и идете домой. Это нечто живое, выполняющееся на ваших серверах прямо сейчас. Жуткий баг может не только уничтожить один из пользовательских процессов, но также он может уничтожить их все. Если ошибка в вашем коде разрушает некоторые данные на диске, то вы должны это исправить. И т. д. Мы выяснили, что нет необходимости проверять серверы каждую минуту (после первого года или около того), но вам определенно захочется следить за тем, что вы недавно изменили. Нельзя выпустить код поздно ночью, а потом уйти домой.

Наблюдение за пользователями

В серверном приложении вы находитесь в более тесном контакте со своим кодом. И вы также можете быть в более тесном контакте со своими пользователями. Intuit известен тем, что знакомит клиентов со своими решениями в розничных магазинах и просит зайти на их сайт из дома. Если вы когда-либо наблюдали за тем, как кто-то использует ваше приложение в первый раз, то вы знаете, какие сюрпризы, должно быть, его поджидали.

Приложение должно выполнять то, что, как думают пользователи, оно и должно делать. Но вам и в голову не придет то, что в голове у пользователей, уж поверьте, пока вы за ними не пронаблюдаете. А серверные приложения предоставляют вам информацию об их поведении без какой-либо конкретики. Вы не ограничены маленькими, искусственными фокус-группами. Вы можете увидеть каждый клик, сделанный каждым пользователем. Вам придется тщательно определить, на что вы собираетесь смотреть, потому что вы же не хотите нарушить частную жизнь людей, но даже наиболее общий статистический пример может быть довольно полезен.

Когда на вашем сервере есть пользователи, вам не нужно полагаться, например, на бенчмарки, которые являются эмуляцией пользователей. С серверными приложениями вы можете наблюдать за реальными пользователями. Чтобы решить, что оптимизировать, просто залогиньтесь на сервере и посмотрите, что потребляет все процессорное время. И вам также известно, когда завершить оптимизацию. Мы в итоге довели редактор Viaweb до такой точки, когда он стал больше зависеть от объема памяти, а не от быстродействия процессора, и, поскольку мы ничего не могли сделать для уменьшения размеров пользовательских данных (ну, ничего того, что считалось простым), мы знали, что надо бы на этом остановиться.

Для серверных приложений производительность имеет значение, потому что вы платите за оборудование. Число пользователей, которое вы можете поддерживать на одном сервере, является делителем ваших капитальных затрат, поэтому, если вы можете создать довольно производительное приложение, то вы сможете предоставлять его по цене ниже, чем у конкурентов, и получить прибыль. В Viaweb наши капитальные затраты в расчете на одного пользователя снизились до 5$. А сейчас они бы могли бы быть и еще меньше. Возможно, меньше, чем отправка счета за первый месяц. Сейчас оборудование вам ничего не стоит, если ваши приложения достаточно производительны.

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

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

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

Я изучал историю переходов по ссылкам людей, участвующих в тестовом запуске и выяснил, что на определенном шаге они запутывались и кликали мышью на кнопку браузера «Назад». (Если вы попробуете написать веб-приложение, то обнаружите, что кнопка «Назад» переходит в разряд одной из самых интересных философских проблем.) Поэтому я добавил в этом месте сообщение, разъясняющее пользователям, что они практически закончили, и чтобы они не нажимали на кнопку «Назад». Еще одна замечательная вещь в веб-приложениях это то, что вы получаете мгновенную реакцию на изменения: число людей, завершивших тестовый запуск, тут же возросло с 60% до 90%. А поскольку число новых пользователей зависит от числа завершивших тестдрайв, наш доход вырос на 50% только из-за этих изменений.

Оплата

В начале 90-х годов я прочел статью, в которой кто-то сказал, что программное обеспечение — это бизнес на основе подписки. Поначалу это утверждение показалось очень циничным. Но потом я осознал, что это отражает реальность: разработка программного обеспечения — это непрерывный процесс. Полагаю, что будет честнее, если вы открыто обозначите стоимость подписки вместо того, чтобы вынуждать людей покупать и устанавливать новые версии, чтобы они продолжали вам платить. И, к счастью, подписка — это естественный способ оплаты веб-приложений.

Хостинг приложений — это область, где фирмы будут играть роль в такой нише, которая вероятнее всего не будет заполнена бесплатным ПО. Хостинг приложений — это большой стресс, и тут придется потратиться. Никто не захочет делать это бесплатно.

Для компаний веб-приложения — это идеальный источник дохода. Вместо того, чтобы начинать каждый квартал с чистого листа, у вас будет периодический доход. Поскольку ваше приложение раскручивается постепенно, вам не нужно беспокоиться, что новая модель потерпит крах; новая модель, как таковая, и не будет нужна, и если вы внесете в приложение нечто, что пользователи воспримут в штыки, то вы тут же узнаете об этом. У вас нет проблем со счетами, неподлежащих оплате: если кто-то не будет платить, вы просто отключаете сервис. Тут также отсутствует возможность для пиратства.

Это последнее «преимущество» может вылиться и в проблему. Некоторая пиратская активность выгодна компаниям по разработке программного обеспечения. Если какой-то пользователь и вправду не купил бы ваше приложение ни за какую цену, вы бы ничего не потеряли от того, что он использует пиратскую копию. В действительности, вы даже выигрываете от этого, т. к. он является еще одним пользователем, помогающим сделать ваше приложение эталонным, или который сможет купить копию приложения позже, когда закончит университет.

Компании по возможности любят проводить ценовую дискриминацию, что означает назначить каждому клиенту как можно более высокую цену, какую только можно позволить. [8] Программное обеспечение особенно подходит для ценовой дискриминации, т. к. предельные затраты близки к нулю. Вот почему некоторые приложения для запуска на компьютерах Sun стоят больше аналогов для Intel: фирма, использующая Sun, не заинтересована в экономии денег и может заплатить больше. Пиратство, в сущности, является низшим уровнем ценовой дискриминации. Думаю, что компании по разработке ПО это понимают и намеренно не замечают некоторые виды пиратства. [9] Что касается серверных приложений, то для них придумают другое решение.

Веб-приложения хорошо продаются, особенно в сравнении с десктопным ПО, потому что его легко купить. Вы могли бы подумать, что решение людей что-то купить, и последующая покупка — это два отдельных шага. Так я думал раньше в Viaweb, по мере того, как размышлял на эту тему в принципе. На самом деле, второй шаг может перейти обратно в первый: если что-то сложно купить, люди начнут сомневаться, а надо ли им это. И наоборот: вы больше продадите, если это легко купить. Я покупаю больше книг, потому что существует Amazon. Веб-приложение просто самая простая в мире вещь, которую можно купить, особенно если вы только что сделали онлайн демо-версию. Пользователи не должны совершать много действий, а только вводить номер кредитной карты. (Вынуждайте совершать их больше действий на свой страх и риск.)

Иногда веб-приложения распространяются через интернет-провайдеров, выступающих в качестве реселлеров. Это плохая идея. Вам придется заниматься управлением серверов, потому что вам нужно постоянно улучшать как аппаратное, так и программное обеспечение. Если вы упустите непосредственный контроль над серверами, вы упустите большинство преимуществ разработки веб-приложений.

Некоторые из наших конкурентов таким образом зарубили сук, на котором сидели. Обычно, как я полагаю, это происходило потому, что у них был излишек членов правления, которые обрадовались такому огромному потенциально прибыльному каналу, и не осознали, что это уничтожит продукт, который они надеялись через него реализовать. Продавать веб-приложения через интернет-провайдеров — это как продавать суши посредством вендинговых автоматов.

Клиенты

Кем будут ваши клиенты? Для Viaweb это изначально были частные лица и небольшие фирмы, и, как мне кажется, в веб-приложениях это станет устоявшимся правилом. Такие пользователи готовы попробовать что-то новое частично потому, что они более гибкие, и отчасти потому, что они хотят меньше тратиться на новые технологии.

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

Аргументы против такого подхода обычно тесно связаны с безопасностью: если для работников доступ упрощен, то таковым он будет и для злоумышленников. Некоторые более крупные продавцы неохотно использовали Viaweb, потому что они полагали, что информация о кредитных картах клиентов будет в большей безопасности на их собственных серверах. Нелегко было это решить дипломатичным путем, но в действительности данные почти наверняка безопаснее было хранить на нашей стороне, а не на их. Кто может нанять лучших людей для управления безопасностью: технологичный стартап, чей бизнес полностью работает на серверах, или продавец одежды? У нас не только лучшие люди, отвечающие за безопасность, но и мы сами уделяем ей больше внимания. Если кто-то взломает серверы продавца одежды, то это повлияет в основном на одну торговую фирму, а это дело, возможно, замнут, и, в худшем случае, уволят одного человека. Если кто-то взломает наши сервера, то это повлияет на тысячи торговых фирм, и, возможно, все окажется в новостях по CNet, и мы потеряем свой бизнес.

Если вы хотите сохранить ваши деньги, то вы храните их под матрасом у себя дома, или отдаете в банк? Это применимо к любому аспекту управления серверами: не только к безопасности, но и ко времени безотказной работы, пропускной способности, управлению нагрузкой, резервному копированию, и т.д. Наше существование зависит от правильного выполнения перечисленных вещей. Наличие проблем с сервером были для нас абсолютно недопустимы, как для создателя игрушек недопустимы опасные игрушки, или вспышка сальмонеллеза для кухонного комбайна.

Крупные компании, которые используют веб-приложения, в некоторой степени передают часть IT-функций в аутсорс. Как бы резко это ни звучало, я считаю, что, в целом, это хорошая идея. Так у фирм больше шансов получить лучшее обслуживание, чем если бы они организовывали собственный штат системных администраторов, которые могут стать своенравными и невосприимчивыми, потому что они не подвергаются напрямую конкурентному давлению: продавец работает с клиентами, разработчик – с приложениями конкурентов, а у системного администратора, как у старого холостяка, в распоряжении всего несколько внешних факторов, удерживающих его на плаву. [10] В Viaweb внешних факторов для удержания себя на плаву было в изобилии. Люди, звонящие нам, были клиентами, а не просто коллегами. Если сервер заклинивало, мы тут же подрывались; уже сама мысль об этом заставляет почувствовать всплеск адреналина, даже спустя годы.

Поэтому, обычно, веб-приложения будут верным решением и для крупных фирм. Однако до них это дойдет в последнюю очередь, как это было с настольными компьютерами. И частично по той же самой причине: убедить крупные компании в том, что им нужно кое-что более дорогое, будет стоить огромную кучу денег.

Всегда существует тенденция к тому, что богатые клиенты покупают дорогие решения, даже когда дешевые решения лучше, т. к. люди, предлагающие дорогие решения, могут потратиться даже больше, пытаясь их продать. Мы в Viaweb всегда были категорически против такого подхода. Мы потеряли нескольких торговых представителей высокого класса, которые ушли к компаниям по веб-консалтингу, убедивших их в том, что они будут в более выгодном положении, если они заплатят полмиллиона долларов за заказной онлайн-магазин на их собственном сервере. Как правило, в выгодное положение они так и не попадали, т. к. обнаружилось, что при наступлении сезона рождественских покупок на их сервер возрастала нагрузка. Viaweb представлял собой гораздо более сложный продукт, чем то, что было у большинства торговых представителей, но у нас не было возможности сообщить им об этом. Работая за $300 в месяц, мы не могли позволить себе направить к клиентам команду прилично одетых и влиятельных людей для презентации продукта.

Основную долю того, за что крупные фирмы платят повышенную цену, составляют затраты на продажу им дорогих вещей. (Если Министерство обороны платит 1000$ за сиденья для унитазов, то это отчасти из-за того, что требуется много средств для продажи сидений для унитазов за 1000$.) И это одна из причин, по которой интранет ПО продолжит процветать, даже если это и плохое решение. Оно просто дороже. И вы ничего не сможете с этим поделать, поэтому наилучшим планом действий будет обратить свое внимание сначала на более мелких клиентов. Все остальное приложится в нужное время.

Сын сервера

Ничего нового в запуске приложение на сервере нет. В действительности, это устаревшая модель: все приложения для суперЭВМ являются серверными. Если серверные приложения — это такая хорошая идея, то почему она проиграла другим? Почему настольные компьютеры затмили суперЭВМ?

Поначалу настольные компьютеры не рассматривались как прямая угроза. Все первые пользователи были поголовно компьютерными специалистами или людьми увлеченными. Им нравились микроЭВМ, т. к. они были дешевле. Впервые у вас был свой собственный компьютер. Фраза «персональный компьютер» сейчас прочно вошла в обиход, но когда ее впервые использовали, она обладала намеренно ярким звучанием, как сегодня фраза «персональный спутник».

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

Не думаю, что многие люди осознают, как хрупки и неуверены стартапы на ранней стадии. Многие стартапы начинаются почти случайно: пара молодых людей, либо с постоянной работой, либо школьники, пишут прототип чего-то, что могло, если это выглядело многообещающим, перерасти в фирму. В таком зачаточном состоянии любое значительное препятствие намертво заморозит стартап. Написание ПО для суперЭВМ требовало слишком много обязательств. Компьютеры для разработки ПО были дороги, и, т. к. клиентами были крупные фирмы, вам понадобился бы впечатляющий торговый персонал, чтобы им это продать. Начинать стартап по созданию ПО для суперЭВМ было бы гораздо более серьезным делом, чем просто совместное ковыряние программ на своем Apple II по вечерам. Поэтому и не было большого числа стартапов по созданию такого ПО.

Появление настольных компьютеров вдохновило на создание новых приложений, потому что разработка программ казалась достижимой целью для «зачаточных» стартапов. Разработка была дешевой, и клиентами были физические лица, с которыми можно было установить контакт через компьютерные магазины или даже торговлю по почте.

Приложение, которое перевело настольные компьютеры в господствующую тенденцию, называлось VisiCalc, первый редактор таблиц. Его написали на чердаке два парня, и оно творило такие вещи, которые ни одно приложение для суперЭВМ осуществить не могло. [11] VisiCalc был в то время таким прорывом, что люди покупали Apple II только для того, чтобы запускать его. И это было началом нового тренда: настольные компьютеры победили потому, что стартапы создавали под них приложения.

Кажется, что серверные приложения были бы как нельзя кстати, т. к. стартапы их напишут. Сейчас компьютеры такие дешевые, что вы можете начать с того же, что и мы, т.е. использовать настольный компьютер в качестве сервера. Недорогие процессоры поглотили рынок рабочих станций (вы сейчас едва ли услышите это словосочетание) и по большей части через рынок серверов; серверы Yahoo, которые справляются с нагрузками, как и все прочие серверы в Интернет, все они оснащены недорогими процессорами Intel, что установлены в вашем настольном компьютере. И, когда вы написали приложение, все, что вам нужно продать, это веб-сайт. Почти все наши пользователи пришли напрямую на наш сайт посредством сарафанного радио и отсылками в прессе. [12]

Viaweb был типичным «зачаточным» стартапом. Нам было страшно организовывать фирму, и, в течение первых нескольких месяцев успокаивали себя, воспринимая все это как эксперимент, который мы могли прервать в любой момент. К счастью, помимо технических были и другие проблемы. В ходе написания приложения наш веб-сервер играл роль настольного ПК, используемого в процессе разработки, и был соединен со всем остальным миром через телефонную линию связи. Единственными нашими тратами на данном этапе были еда и аренда.

Сейчас для стартапов еще больше причин для создания веб-приложений, потому что разработка ПО для настольных компьютеров уже не так интересна. Если сейчас вы хотите писать приложения для настольных компьютеров, то вы делаете это на условиях Microsoft, вызывая их API и работая с их глючной OS. И если вам удастся написать нечто такое, что выстрелит, вы, возможно, обнаружите, что вы просто занимались маркетинговыми исследованиями для Microsoft.

Если фирма хочет создать платформу, на основе которой будут реализовываться стартапы, то она должна быть такой, чтобы программисты сами захотели бы ее использовать. Что означает, что она должна быть недорогой и хорошо спроектированной. Когда Mac впервые появился, он был популярен среди компьютерных профессионалов, и многие из них писали под него приложения. [13] В случае с Windows это было менее заметно, т. к. программисты ей не пользовались. Сейчас люди, которые хороши в разработке приложений, склонны к использованию Linux или FreeBSD.

Не думаю, что мы бы организовали стартап для создания ПО для настольных компьютеров, потому что такое ПО должно запускаться на Windows, а перед тем, как писать ПО под Windows, нам пришлось бы ей пользоваться. Веб позволяет обойти Windows, и предоставлять ПО, работающее на Unix, напрямую пользователям через браузер. Это отличный шанс, чтобы освободиться от зависимостей, что очень напоминает появление ПК 25 лет назад.

Microsoft

Давным давно, когда появились настольные компьютеры, IBM был гигантом, которого все боялись. Сложно сейчас представить, но я очень хорошо помню это чувство. Сейчас же устрашающим гигантом выступает Microsoft, и я не думаю, что они не понимают угрозу, маячащей перед ними, как это делала фирма IBM. В конце концов, Microsoft намеренно начала вести свой бизнес в слепой зоне IBM.

Я как-то упоминал ранее, что, например, моей матери вообще не нужен настольный компьютер. И, вероятно, большинству пользователей это тоже не надо. Вот в чем проблема Microsoft, и они это знают. Если приложения запускаются на удаленных серверах, никому не нужна Windows. Что же будет делать Microsoft? Смогут ли они воспользоваться своим контролем над ПК, чтобы предотвратить появление или ограничить это новое поколение приложений?

Предположу, что Microsoft разработает некоторого сорта гибрид серверного и десктопного приложения, где операционная система работает совместно с серверами, которыми они управляют. Как минимум, файлы точно будут доступны пользователям, которым это надо. Не думаю, что Microsoft впадет в крайность и организует вычисления на сервере, где в качестве клиента будет выступать только браузер, если они могут этого избежать. Если в качестве клиента вам нужен только браузер, то на клиентской машине вам не нужен Microsoft, а если Microsoft не управляет клиентом, то они не смогут вынудить пользователей перейти на их серверные приложения.

Я считаю, что Microsoft будет сложно удерживать технологии в жестких рамках. Будет слишком много различных типов клиентов, чтобы обеспечивать контроль над ними всеми. А если приложения Microsoft работают только с некоторыми клиентами, конкурентам удастся их обскакать, предлагая приложения, работающие на любом клиенте. [14]

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

Дело не только в том, что их обставят конкуренты, но и в том, что они сами себе роют яму. По мере развития веб-приложений они столкнутся не только с техническими проблемами, но и со своим принятием желаемого за действительное. Им нужно поглотить свой текущий бизнес, и я представить не могу, что они пойдут на это. Та самая целеустремленность, которая их так далеко завела, теперь будет работать против них. IBM была в точно таком же положении, и ей не удалось с этим справиться. IBM сделала запоздалый и нерешительный выход на рынок микроЭВМ, потому что они испытывали двойственное чувство, ставя под угрозу свою дойную корову – использование суперЭВМ. Аналогично Microsoft будет стеснен в своих действиях, желая сохранить настольные решения. Надежный источник денег может превратиться в довольно тяжелую ношу.

Я не утверждаю, что никому не удастся доминировать в области серверных приложений. Вероятно, в конце концов, кто-то это сделает. Но я хочу сказать, что пройдет довольно много времени занятной неразберихи, прямо как на заре микроЭВМ. Это было хорошее время для стартапов. Многие мелкие фирмы расцвели, создавая крутые вещи.

Больше, чем просто стартап

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

В стартапе по созданию веб-приложений все, что ассоциируется у вас со стартапами, доводится до крайности. Можно создавать и запускать продукт даже с меньшим количеством людей и даже с меньшим бюджетом. Только вам придется быть еще быстрее, и снизить уровень формальностей. Можно запускать продукт в буквальном смысле слова, с тремя людьми в гостиной чей-то квартиры, и сервером у интернет-провайдера. У нас все так и было.

Со временем команды стали меньше, быстрее, и более непринужденными. В 1960 под разработкой ПО подразумевалась комната, полная людей в очках с роговой оправой в узких черных галстуках, усердно пишущих по 10 строк кода в день в бланках для кодирования IBM. В 1980 это была команда из 8-10 человек, приходящих в офис в джинсах и печатающих в терминалах vt100. Теперь это пара парней, сидящих в гостиной с ноутбуками. (А джинсы оказались не самым последним пунктом в обеспечении атмосферы непринужденности и свободы.)

В стартапах много стресса, и, к сожалению, это также доводится до крайности в сфере веб-приложений. У многих компаний по разработке ПО, особенно в начале, были моменты, когда разработчики спали под столами и т.п. Тревожным сигналом может стать тот факт, что ничто не может препятствовать переходу этого явления в постоянную практику. Истории про то, как кто-то спит под столом, обычно заканчиваются так: и вот, наконец, мы сохранили все изменения и пошли домой, и отсыпались всю неделю. В веб-приложениях нельзя взять и внести все изменения. Вы можете работать по 16 часов в день так долго, как того захотите. А т.к. можете вы, и ваши конкуренты тоже, вы уже вынуждены это делать. Вы можете, поэтому вы должны. Закон Паркинсона наоборот.

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

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

Десктопные приложения вынуждают пользователей становиться системными администраторами. Веб-приложения вынуждают таковыми становиться программистов. В общей сумме стресса получается меньше, но его доля на программистов больше. Это не всегда плохо. Если вы затеяли стартап и конкурируете с крупной фирмой, то это хорошо. [15] Веб-приложения предлагают прямой путь к тому, чтобы превзойти ваших конкурентов. А стартапы большего и не требуют.

И так хорошо

Единственное, что может вас отпугнуть от создания веб-приложений, это убогость веб-страниц при использовании в качестве пользовательского интерфейса. Признаю, это проблема. Нам и правда хотелось добавить пару вещей в HTML и HTTP. Но на самом деле, важно то, что веб-страницы и так хороши.

Здесь прослеживается аналогия с первыми микроЭВМ. Процессоры в этих машинах на самом деле не были предназначены для использования в качестве центральных процессоров. Они были предназначены для использования в светофорах и т.п. Но люди вроде Эда Робертса, создателя Altair, поняли, что они хорошо подходили и для этих целей тоже. Можно было совмещать один из этих чипов с какой-нибудь памятью (в первом Altair было 256 байт памяти), добавить переднюю панель переключателей, и вот перед вами работающий компьютер. Возможность собрать свой собственный компьютер была такой захватывающей идеей, что появилась куча людей, которые хотели их купить, хотя их число и было ограничено.

Веб-страницы создавались не для того, чтобы служить интерфейсом веб-приложениям, но они и так хороши. А для значительного числа пользователей приложений, которыми можно воспользоваться из любого браузера, будет достаточно, чтобы действительно пересилить неприятие некоторой неповоротливости в UI. Может, у вас и не получается создать с помощью HTML самую красивую электронную таблицу, но вы можете создать такую таблицу, которой несколько людей могут пользоваться одновременно из различных мест без специального клиентского ПО, или которая может объединять реальные данные, или которая может присылать вам уведомление, когда срабатывают определенные условия. Что более важно, можно создавать новые виды приложений, у которых еще нет названий. VisiCalc был не просто приложением для суперЭВМ с версией для микроЭВМ, в конце концов, это был новый тип приложений.

Конечно, серверные приложения не обязаны быть веб-приложениями. У вас мог бы быть и какой-нибудь другой клиент. Но я уверен, что это плохая идея. Было бы очень удобно, если бы можно было допустить, что все установят ваш клиент. Так удобно, что вы могли бы легко себя убедить, что они все так и поступят, но если они не захотят, то вы будете повязаны по рукам и ногам. Поскольку веб-приложения не делают никаких предположений о клиентской стороне, она будут работать везде, где работает веб. А это уже большое преимущество, и оно будет только увеличиваться по мере распространения новых веб-устройств. Вы понравитесь пользователям, потому что ваше приложение просто работает, а ваша жизнь станет проще, потому что вам не придется настраивать его под каждого нового клиента. [16]

У меня такое чувство, что я просмотрел эволюцию сферы веб также подробно, как и любой из нас, но я не могу предсказать, что произойдет с клиентским наполнением. Вероятно, грядет конвергенция, но в какой точке? Я не могу определить лидера. Единственное, что я могу предсказать, это разногласие между AOL и Microsoft. Чем бы в итоге ни оказалась технология Microsoft .NET, она, вероятнее всего, будет включать соединение ПК с сервером. Пока AOL не начнет качать права, их либо отодвинут в сторону, либо превратят в прослойку между клиентом Microsoft и серверным ПО. Если Microsoft и AOL затеют войну за клиента, единственное, что точно сработает для обоих, это просмотр веб-страниц, т.е. веб-приложения будут единственным ПО, которое работает везде.

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

Почему бы и нет?

Э. Б. Уайта позабавил тот факт, что, как рассказал ему друг-фермер, многие изгороди с электрическим током на самом деле не находятся под напряжением. Когда коровы научились держаться от них подальше, уже не было необходимости пропускать ток через изгородь. «Вставайте, коровы! – писал он, – Идите на свободу, пока ваши тираны храпят!»

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

Вот две вещи, которые вы должны знать о бизнесе: сделать то, что пользователи полюбят, и зарабатывать больше, чем тратите. Если вы хорошо это усвоите, вы будете опережать большинство стартапов. Во всем остальном вы разберетесь по ходу дела.

Возможно, поначалу вы не сможете зарабатывать больше, чем тратите, но как только этот разрыв начнет достаточно быстро сокращаться, у вас все наладится. Если вы начнете с меньшим количеством денежных средств, то это, по крайней мере, поспособствует выработке привычки к бережливости. Чем меньше вы тратите, тем легче заработать больше своих трат. К счастью, запуск веб-приложения может очень дешево обойтись. Мы запустились с бюджетом меньше $10,000, а сегодня это еще дешевле. Нам пришлось потратить тысячи на сервер, и еще несколько тысяч на SSL. (Единственной фирмой, продающей SSL ПО в то время, была Netscape.) Сейчас вы можете арендовать гораздо более мощные серверы, уже с SSL, и заплатить за это меньше, чем пришлось заплатить нам только за полосу пропускания. Вы могли бы сейчас запустить веб-приложение за стоимость, меньшую стоимости хорошего офисного кресла.

Что касается создания того, что полюбят пользователи, тут есть несколько общих советов. Начните с создания чего-то понятного и простого, чем вы бы сами захотели воспользоваться. Быстро выпустите версию 1.0, и затем продолжайте улучшать приложение, внимательно прислушиваясь к пользователям по ходу дела. Клиент всегда прав, но разные клиенты правы насчет разных вещей; наименее опытные пользователи покажут, что нужно упростить и пояснить, а самые опытные укажут, какой функционал нужно добавить. Самое лучшее, что может делать приложение, это отличаться простотой, но чтобы этого добиться, нужно сразу верно определить все сценарии работы «по умолчанию», а не ограничивать пользователей в выборе. Не важничайте, если приложение конкурента вышло плохим; эталон, с которым нужно сравнивать свое приложение, это то, чем оно могло бы быть, а не то, что получилось у конкурентов. Все время пользуйтесь своим ПО. Viaweb был разработан как конструктор онлайн-магазинов, но мы также использовали его для создания и своего собственного сайта. Не слушайте маркетологов, дизайнеров и продуктовых менеджеров только из-за названия их должностей. Если у них есть хорошие идеи, воспользуйтесь ими, но это вам решать; приложения должны разрабатывать специалисты, которые понимают, что такое дизайн, а не дизайнеры, которые немного знают, что такое приложения. Если вы не можете ни спроектировать приложение, ни реализовать его, не надо запускать стартап.

А теперь давайте обсудим конкуренцию. То, чего вы боитесь, это не предполагаемые группы программистов как вы, а реальные фирмы, с офисами и бизнес-планами, продавцами и т.д., так ведь? Ну, они больше боятся вас, чем вы их, и правильно делают. Гораздо проще паре хакеров разобраться в том, как арендовать офисное помещение или нанять людей для ведения продаж, чем для фирмы любого размера написать приложение. Я побывал по обе стороны баррикад, и знаю, о чем говорю. Когда Viaweb был куплен фирмой Yahoo, я внезапно обнаружил, что я работаю на крупную компанию, и это было равносильно бегу по пояс в воде.

Я не хочу принижать Yahoo. У них было несколько хороших специалистов, менеджеры высшего звена были настоящими монстрами. Для крупной компании это редкость. Но все же, они продуктивны всего лишь на десятую долю маленького стартапа. И ни одна крупная фирма не сможет сделать лучше. Что в Microsoft пугает, так это то, что такая крупная компания вообще может разрабатывать приложения. Они как гора, которая может передвигаться.

Не давайте себя запугать. Вам под силу то, что не может Microsoft, и они могут сделать то, что у вас не получится. И никто вас не остановит. Вам не нужно спрашивать чье-либо разрешение на разработку веб-приложений. Вам не придется решать вопросы с лицензированием, или запрашивать место на полке розничных магазинов, или пресмыкаться перед владельцами ОС, чтобы ваше приложение вошло в ее состав. Вы можете предоставлять приложение напрямую через браузер, и никто не может встать между вами и потенциальными пользователями без закрытия веб сети.

Вы, может, и не поверите, но я гарантирую, что Microsoft боится вас. Самодовольные менеджеры среднего звена, может, и нет, но Билл точно, потому что он когда-то был на вашем месте, в далеком 1975 году, когда последний раз появился новый способ распространения ПО.


Примечания

[1] Понимая, что бОльшая доля денег в предоставлении услуг, компании, разрабатывающие тонкие клиенты, обычно пытаются объединять аппаратные решения с онлайн-решениями. Этот подход не очень хорош, частично из-за того, что вам необходимы две различных фирмы, одна из которых будет разрабатывать аппаратную часть, а вторая предоставлять онлайн-услуги, и частично потому что пользователи ненавидят эту идею. Продавать дёшево бритвы и зарабатывать потом на продажах лезвий может себе позволить Gilette, но бритва — это намного меньшее вложение, чем веб-терминал. Компаниям, продающим мобильные телефоны, хватает выручки от продажи устройств, и они не пытаются получить весь доход от телефонной связи. Вероятно это должно быть моделью и для интернет-устройств. Если кто-то просто продаёт красивую маленькую коробочку с веб-браузером, которую вы можете использовать с любым интернет-провайдером, каждый обыватель купит себе такую.

[2] Безопасность всегда боится ошибок, больше, чем любые другие проектные решения, но характер серверного ПО заставляет разработчиков уделять ещё больше внимания защите от взлома. Компрометация сервера может нанести такой значительный ущерб, что провайдеры приложений (которые не хотят прогореть) должны позаботиться о безопасности.

[3] В 1995 году, когда мы начинали Viaweb, Java-апплеты рассматривались как технология, которую все будут использовать для разработки серверных приложений. Нам апплеты казались устаревшей идеей. Загружать для запуска программы на клиента? Проще дойти до логического конца и запускать программы на сервере. Мы немного потратили времени на апплеты, но исчезающе мало по сравнению с другими стартапами, которых заманили в эту смоляную яму. Немногие смогли оттуда выбраться живыми, или Microsoft не смогла сбежать, выбросив поддержку Java из своих последних версий IE.

[4] Эта идея от Тревора Блекуэлла (Trevor Blackwell), который добавил «стоимость создания ПО растет быстрее, чем его размер. Воможно это главным образом по причине необходимости исправления старых багов, и рост стоимости будет ближе к линейному, если все баги будут отыскиваться немедленно.»

[5] Баг, который найти труднее всего, может быть видом составного бага, когда действие одного бага компенсируется действием другого. Когда вы исправляете один баг, другой проявляет себя. Но кажется, что исправление является причиной ошибки, так как это последнее изменение, которое вы сделали только что.

[6] В Viaweb однажды мы устроили соревнование на описание худшей проблемы в нашем софте. Два сотрудника поддержки разыграли между собой первый приз, указав на такие вещи, которые я до сих пор вспоминаю с содроганием. Мы тут же устранили эти ошибки.

[7] Роберт Моррис написал систему заказов, которую покупатели использовали для размещения заказов. Тревор Блэквелл написал генератор изображений и менеджер, который продавцы использовали для просмотра заказов, статистики, настройки доменных имен, и т.д… Я написал редактор, которым пользовались продавцы для создания своих сайтов. Система заказов и генератор изображений были написаны на C и C++, менеджер — в основном на Perl, а редактор — на Lisp.

[8] Ценовая дискриминация так распространена (как часто вы слышали, чтобы розничный продавец заявлял, что их покупательская способность означала бы более низкие цены для вас?), что я был сильно удивлен, когда узнал, что в США законом Робинсона-Патмана 1936 года она объявлена незаконной деятельностью. К принятию такого закона, кажется, не особо-то и принуждали.

[9] Наоми Кляйн из No Logo говорит, что бренды одежды, пользующиеся популярностью у «городской молодежи», не особо-то и стараются предотвращать магазинные кражи, потому что в их целевом рынке магазинные воры также являются ведущими игроками в моде.

[10] Фирмы часто задаются вопросом, что отдать в аутсорс, а что нет. Один возможный ответ: отдавать в аутсорс любую работу, которая напрямую не подвергается конкурнтному давлению, потому что, таким образом, ее аутсорс подставит ее под это самое давление.

[11] Этими двумя парнями были Дэн Бриклин и Боб Фракстон. Дэн написал прототип на Basic за пару дней, затем в течении следующего года они работали вместе (в основном по ночам) над созданием более мощной версии, написанной на языке компьютера 6502. Дэн в то время учился в Гарвардской школе бизнеса, а Боб официально имел постоянную работу, где писал приложения. «В ведении своего бизнеса не было крупных рисков, – писал Боб, – Если не получится, то не получится. Ничего особенного».

[12] Это не совсем так просто, как я это озвучил. Потребуется много мучительного времени, чтобы сарафанное радио заработало, и у нас не было частых освещений в прессе, пока мы не наняли PR фирму (и правда лучшая в своем деле) за $16,000 в месяц. Однако, правда в том, что единственным значимым каналом был наш собственный сайт.

[13] Если Mac был такой крутой, почему он проиграл? Опять же, дело в цене. Microsoft сконцентрировался на создании ПО, и выпустила толпу поставщиков дешевых компонентов для оборудования Apple. Но это также не помогло, that suits took over during a critical period.

[14] Единственное, что помогло бы веб-приложениям, и удержало бы следующее поколение приложений от being overshadowed by Microsoft, это хороший open-source браузер. Mozilla является open-source браузером, но, кажется, пострадало от слишком длительного пребывания в амплуа корпоративного приложения. Маленький быстрый браузер, который активно бы поддерживали, уже само по себе было бы здорово, а также, возможно, вдохновило бы фирмы на реализацию небольших веб-устройств.

Кроме того, подходящий open-source браузер стал бы причиной дальнейшего развития HTTP и HTML (как, например, это было Perl). Это очень помогло бы веб-приложениям распознавать выделение ссылки и проход по ней; все, что для этого понадобится, будет банальным расширением HTTP, что позволит содержать несколько URL в запросе. Каскадное меню также было бы хорошо реализовать.

Если вы хотите изменить мир, напишите новую Mosaic. Думаете, слишком поздно? В 1998 многие люди думали, что слишком поздно запускать новый поисковый движок, но Google доказал обратное. Всегда есть место для чего-то нового, если текущие решения довольно убоги. Сначала убедитесь, что оно работает на всех бесплатных операционных системах, т.к. новое начинается с их пользователей.

[15] Тревор Блэквелл, который, возможно, из своего личного опыта знает об этом больше, чем кто-либо, пишет: «Я бы добавил, что, т.к. серверные приложения слишком суровы с программистами, это вызывает существенный экономический отток из крупных фирм. От программистов требуется некоторая энергия и преданность делу, которое они смогут проявить только тогда, когда это их собственная фирма. Фирмы по разработке ПО могут нанять опытных людей для работы в не особо требовательной среде, а могут нанять неопытных людей, чтобы они испытывали трудности, но они не могут нанять высококвалифицированных людей, чтобы те надрывались на работе. С тех пор как капитальные вложения перестали быть обязательным элементом, крупные фирмы мало чем могут заинтересовать.»

[16] В первоначальной версии этого эссе я советовал избегать Javascript. Такой план был хорош для 2001 года, но Javascript сейчас и правда работает.