(В этой статье объясняется, почему большая часть программного обеспечения следующего поколения может стать серверным, что это будет значить для программистов и почему этот новый вид ПО открывает прекрасные возможности для стартапов. Она основана на докладе в BBN Labs.)
Летом 1995 года мы с моим другом Робертом Моррисом решили основать стартап. PR-кампания накануне IPO Netscape тогда шла полным ходом, и в прессе много говорили об интернет-торговле. В то время в Сети было, пожалуй, магазинов тридцать, и все сделаны вручную. Если интернет-магазинов должно было стать много, понадобился бы софт для их создания, поэтому мы решили его написать.
Первую неделю или около того мы собирались сделать обычное десктопное приложение. Затем однажды нам пришла в голову мысль запустить программу на нашем веб-сервере, используя браузер в качестве интерфейса. Мы попробовали переписать софт для работы через Веб, и стало ясно, что именно этим путем и надо идти. Если мы напишем программу так, чтобы она работала на сервере, это будет намного проще и для пользователей, и для нас самих.
План оказался удачным. Теперь, под названием Yahoo Store, это программное обеспечение является самым популярным конструктором интернет-магазинов, насчитывающим около 14 000 пользователей.
Когда мы запускали Viaweb, почти никто не понимал, что мы имеем в виду, говоря, что программа работает на сервере. Люди начали понимать это только тогда, когда год спустя запустился Hotmail. Сейчас всем известно, что это вполне жизнеспособный подход. Для того, чем мы занимались, теперь есть название: Application Service Provider, или ASP.
Я думаю, что большая часть ПО следующего поколения будет написана по этой модели. Даже Microsoft, которой есть что терять больше всех, похоже, осознает неизбежность ухода некоторых вещей с десктопа. Если софт переберется с десктопов на серверы, для разработчиков это будет совсем другой мир. В этой статье описываются те удивительные вещи, которые мы увидели, будучи одними из первых гостей в этом новом мире. В той степени, в какой программное обеспечение действительно перемещается на серверы, то, что я здесь описываю, — это будущее.
Следующий шаг?
Когда мы оглянемся назад на эпоху десктопного ПО, думаю, мы поразимся неудобствам, с которыми мирились люди, точно так же, как сейчас мы поражаемся тому, с чем приходилось мириться первым владельцам автомобилей. Первые двадцать-тридцать лет нужно было быть автоэкспертом, чтобы владеть машиной. Но автомобили давали такое колоссальное преимущество, что множество людей, не разбирающихся в них, все равно хотели их иметь.
Компьютеры сейчас находятся именно в этой фазе. Когда у вас есть настольный компьютер, вам в итоге приходится узнавать гораздо больше того, что вы хотели бы знать о происходящем внутри него. И тем не менее он есть более чем в половине американских домохозяйств. У моей мамы есть компьютер, который она использует для электронной почты и ведения бухгалтерии. Около года назад она была встревожена, получив письмо от Apple с предложением скидки на новую версию операционной системы. Что-то явно не так, когда шестидесятипятилетней женщине, которая просто хочет использовать компьютер для почты и счетов, приходится думать об установке новых операционных систем. Обычные пользователи не должны знать даже слов «операционная система», не говоря уже о «драйвере устройства» или «патче».
Теперь появился другой способ доставки ПО, который избавит пользователей от необходимости становиться системными администраторами. Веб-приложения — это программы, которые работают на веб-серверах и используют веб-страницы в качестве пользовательского интерфейса. Для обычного пользователя такое новое программное обеспечение будет проще, дешевле, мобильнее, надежнее и зачастую мощнее, чем десктопное ПО.
С веб-софтом большинству пользователей не придется думать ни о чем, кроме самих приложений, которые они используют. Все сложное и постоянно меняющееся хозяйство будет крутиться где-то на сервере, обслуживаемое людьми, которые хорошо в этом разбираются. И поэтому для работы с программами вам обычно не понадобится компьютер как таковой. Все, что будет нужно, — это устройство с клавиатурой, экраном и веб-браузером. Возможно, с беспроводным доступом в Интернет. Возможно, это будет также и ваш мобильный телефон. Что бы это ни было, это станет бытовой электроникой: вещью стоимостью около $200, которую люди выбирают в основном по внешнему виду корпуса. За интернет-услуги вы будете платить больше, чем за само «железо», как сейчас происходит с телефонами. [1]
На то, чтобы клик дошел до сервера и вернулся обратно, уйдет около десятой доли секунды, поэтому пользователям софта с очень интенсивным взаимодействием, такого как Photoshop, по-прежнему захочется, чтобы вычисления происходили на десктопе. Но если посмотреть на то, для чего большинство людей использует компьютеры, задержка в десятую долю секунды проблемой не будет. Моей маме десктопный компьютер на самом деле не нужен, и таких людей очень много.
Выгода для пользователей
Недалеко от моего дома стоит машина с наклейкой на бампере: «лучше смерть, чем неудобство». Большинство людей в большинстве случаев выбирают вариант, требующий наименьших усилий. Если веб-софт победит, то потому, что он удобнее. И судя по всему, так оно и будет — как для пользователей, так и для разработчиков.
Чтобы пользоваться чисто веб-приложением, вам нужен только браузер с подключением к Интернету. То есть вы можете использовать веб-приложение где угодно. Когда вы устанавливаете программу на свой десктопный компьютер, вы можете использовать ее только на этом компьютере. Хуже того, ваши файлы оказываются заперты на этой машине. Неудобство такой модели становится все более очевидным по мере того, как люди привыкают к сетям.
Первой ласточкой здесь стала веб-почта. Миллионы людей теперь понимают, что доступ к письмам должен быть независимо от того, где вы находитесь. И если можно просматривать почту, почему нельзя календарь? Если можно обсуждать документ с коллегами, почему нельзя его редактировать? Почему вообще какие-либо ваши данные должны быть заперты на каком-то компьютере, стоящем на далеком рабочем столе?
Сама идея «вашего компьютера» уходит в прошлое и сменяется идеей «ваших данных». У вас должна быть возможность добраться до своих данных с любого компьютера. Вернее, с любого клиента, а клиентом вовсе не обязательно должен быть компьютер.
Клиенты не должны хранить данные; они должны быть подобны телефонам. На самом деле они могут стать телефонами или наоборот. А по мере того как клиенты становятся меньше, появляется еще одна причина не держать на них свои данные: вещь, которую носишь с собой, можно потерять или ее могут украсть. Оставить свой PDA в такси — это все равно что сбой диска, только ваши данные не испаряются, а попадают в руки кому-то другому.
В случае с чисто веб-софтом ни ваши данные, ни приложения не хранятся на клиенте. Поэтому, чтобы им пользоваться, не нужно ничего устанавливать. А когда нет установки, вам не приходится беспокоиться о том, что установка пойдет не так. Не может быть несовместимости между приложением и вашей операционной системой, потому что софт вообще не работает на вашей операционной системе.
Поскольку установка не требуется, станет легко и привычно пробовать веб-софт перед тем, как «купить» его. Следует ожидать возможности бесплатно протестировать любое веб-приложение, просто перейдя на сайт, где оно предлагается. В Viaweb весь наш сайт был словно гигантская стрелка, указывающая пользователям на пробную версию.
После ознакомления с демоверсией регистрация на сервисе не должна требовать ничего, кроме заполнения короткой формы (чем короче, тем лучше). И это должно быть последней работой, которую приходится делать пользователю. С веб-софтом вы должны получать новые релизы без дополнительной платы, без каких-либо усилий и, возможно, даже не зная об этом.
Обновления перестанут быть теми масштабными потрясениями, какими они являются сейчас. Со временем приложения будут незаметно становиться мощнее. Это потребует определенных усилий со стороны разработчиков. Им придется проектировать программное обеспечение так, чтобы его можно было обновлять, не сбивая пользователей с толку. Это новая проблема, но способы ее решения существуют.
В веб-приложениях все пользуются одной и той же версией, а ошибки можно исправлять сразу же, как только они обнаружены. Так что в веб-софте должно быть гораздо меньше багов, чем в десктопном. Сомневаюсь, что в Viaweb у нас когда-либо было одновременно хотя бы десять известных багов. Это на порядки лучше, чем в десктопном софте.
Веб-приложения могут использоваться несколькими людьми одновременно. Это очевидный плюс для приложений совместной работы, но я готов спорить, что пользователи начнут требовать этого от большинства приложений, как только поймут, что такое возможно. Часто будет полезно, например, позволить двоим редактировать один и тот же документ. Viaweb позволял нескольким пользователям редактировать сайт одновременно — скорее потому, что так было правильнее написать программу, чем из-за наших ожиданий, что пользователям это понадобится, но выяснилось, что многим это было нужно.
Когда вы используете веб-приложение, ваши данные будут в большей безопасности. Сбои жестких дисков не уйдут в прошлое, но пользователи о них больше не услышат. Они будут происходить внутри серверных ферм. И компании, предлагающие веб-приложения, действительно будут делать резервные копии — не только потому, что у них будут настоящие системные администраторы, заботящиеся о таких вещах, но и потому, что ASP, потерявший данные клиентов, попадет в очень, очень крупные неприятности. Когда люди теряют собственные данные из-за сбоя диска, они не могут сильно злиться, ведь злиться можно только на себя. Когда же компания теряет их данные за них, они разозлятся куда сильнее.
Наконец, веб-софт должен быть менее уязвим для вирусов. Если на клиенте не запускается ничего, кроме браузера, вероятность запуска вирусов ниже, и локально повреждать нечего. А программа, атакующая сами серверы, столкнется с тем, что они очень хорошо защищены. [2]
Для пользователей веб-софт будет менее стрессовым. Думаю, если бы вы заглянули в душу среднестатистического пользователя Windows, вы обнаружили бы там огромное и практически нетронутое желание получить программное обеспечение, подходящее под это описание. Вырвавшись наружу, оно могло бы стать мощной силой.
Город из кода
Для разработчиков самое заметное отличие веб-софта от десктопного состоит в том, что веб-приложение не является единым куском кода. Это будет набор программ разного типа, а не один большой бинарник. И поэтому проектирование веб-софта похоже скорее на проектирование города, чем здания: помимо зданий вам нужны дороги, дорожные знаки, коммунальные службы, полиция и пожарные, а также планы как развития, так и действий при всевозможных бедствиях.
В Viaweb программное обеспечение включало довольно крупные приложения, с которыми пользователи взаимодействовали напрямую; программы, которые использовались теми программами; программы, которые постоянно работали в фоновом режиме, отслеживая проблемы; программы, пытавшиеся перезапустить службы в случае сбоя; программы, которые запускались время от времени для сбора статистики или построения поисковых индексов; программы, запускавшиеся нами вручную для сборки мусора ресурсов либо для переноса или восстановления данных; программы, которые притворялись пользователями (для измерения производительности или выявления багов); программы для диагностики сетевых неполадок; программы для создания бэкапов; интерфейсы к внешним сервисам; софт, управлявший внушительным набором индикаторов, отображавших статистику серверов в реальном времени (хит среди посетителей, но и для нас незаменимый); модификации (включая исправления багов) ПО с открытым исходным кодом; а также огромное количество конфигурационных файлов и настроек. Тревор Блэквелл написал впечатляющую программу для переноса магазинов на новые серверы по всей стране без их отключения после того, как нас купила Yahoo. Программы отправляли нам сообщения на пейджер, слали факсы и электронные письма пользователям, проводили транзакции через платежные шлюзы для кредитных карт и общались друг с другом через сокеты, пайпы, http-запросы, ssh, udp-пакеты, общую память и файлы. Часть Viaweb даже состояла из отсутствия программ, поскольку один из ключей к безопасности Unix — не запускать ненужные утилиты, которые посторонние могли бы использовать для взлома ваших серверов.
Софтом дело не ограничивалось. Мы тратили много времени на размышления о конфигурациях серверов. Серверы мы собирали сами из комплектующих — отчасти для экономии денег, отчасти для того, чтобы получить ровно то, что нам требовалось. Нам приходилось задумываться о том, достаточно ли быстрые каналы связывают нашего вышестоящего ISP со всеми магистральными сетями (backbones). Мы серийно меняли поставщиков RAID.
Но «железо» — это не только повод для беспокойства. Контролируя его, вы можете дать пользователям больше. В случае с десктопным приложением вы можете указать определенные минимальные требования к аппаратуре, но не можете добавить ничего сверху. Если же вы сами администрируете серверы, то можете в один шаг предоставить всем своим пользователям возможность отправлять сообщения на пейджер, или слать факсы, или посылать команды по телефону, или принимать кредитные карты и т. д. — просто установив соответствующее оборудование. Мы всегда искали новые способы добавлять функции с помощью аппаратуры не только потому, что это радовало пользователей, но и как способ выделиться на фоне конкурентов, которые (либо потому, что продавали десктопный софт, либо перепродавали веб-приложения через ISP) не имели прямого контроля над оборудованием.
Поскольку софт веб-приложения представляет собой набор программ, а не один бинарник, его можно писать на сколь угодно большом количестве разных языков. Создавая десктопное ПО, вы практически вынуждены писать приложение на том же языке, что и лежащая в основе операционная система — то есть на C и C++. В результате эти языки (особенно среди нетехнических людей, вроде менеджеров и венчурных инвесторов) стали считаться языками для «серьезной» разработки ПО. Но это было лишь следствием того, как десктопный софт приходилось доставлять. Для серверного ПО вы можете использовать любой язык, какой захотите. [3] Сегодня многие лучшие хакеры используют языки, весьма далекие от C и C++: Perl, Python и даже Lisp.
В случае с серверным софтом никто не может диктовать вам, какой язык использовать, потому что вы контролируете всю систему вплоть до «железа». Разные языки хороши для разных задач. Вы можете использовать тот, который лучше всего подходит для каждой. А когда у вас есть конкуренты, «можете» превращается в «обязаны» (мы вернемся к этому позже), потому что если этой возможностью не воспользуетесь вы, ей воспользуются ваши конкуренты.
Большинство наших конкурентов использовали C и C++, и это делало их софт заметно хуже, поскольку (помимо прочего) они не знали, как обойти отсутствие сохранения состояния в CGI-скриптах. Если нужно было что-то изменить, все правки должны были происходить на одной странице с кнопкой Update внизу. Как я уже писал в другом месте, используя Lisp, который многие до сих пор считают академическим языком, мы смогли сделать так, чтобы редактор Viaweb вел себя скорее как десктопная программа.
Релизы
Одно из важнейших изменений в этом новом мире — то, как вы выпускаете релизы. В бизнесе десктопного ПО выпуск релиза — это огромная травма, при которой вся компания обливается потом и напрягает все силы, чтобы вытолкнуть единый гигантский кусок кода. Очевидные аналогии напрашиваются сами собой — как в отношении процесса, так и в отношении получившегося продукта.
С серверным ПО вы можете вносить изменения почти так же, как в программе, которую пишете для себя. Вы выпускаете софт в виде череды инкрементальных изменений вместо редкого большого взрыва. Типичная компания, создающая десктопное ПО, может выпускать один или два релиза в год. В Viaweb мы часто делали от трех до пяти релизов в день.
Переходя на эту новую модель, понимаешь, насколько разработка ПО зависит от способа его выпуска. Многие из самых неприятных проблем в бизнесе десктопного софта обусловлены катастрофическим характером релизов.
Когда выпускаешь всего одну новую версию в год, с багами обычно разбираются оптом. За некоторое время до даты релиза собирается новая версия, в которой половина кода была выдрана и заменена, что порождает бесчисленное количество багов. Затем в дело вступает команда специалистов по QA и начинает их подсчитывать, а программисты идут вниз по списку, исправляя их. До конца списка они обычно не доходят, да и вообще никто толком не знает, где этот конец. Это как вылавливать обломки со дна пруда. Вы никогда по-настоящему не знаете, что происходит внутри программы. В лучшем случае получается некая статистическая корректность.
В случае с серверным ПО большинство изменений малы и инкрементальны. Это само по себе снижает вероятность появления багов. Это также означает, что перед релизом софта вы точно знаете, что нужно тестировать тщательнее всего: то, что вы изменили последним. Вы получаете гораздо более уверенный контроль над кодом. Как правило, вы знаете, что происходит внутри него. Вы, конечно, не помните исходный код наизусть, но когда читаете его, делаете это подобно пилоту, сканирующему приборную панель, а не детективу, пытающемуся распутать некую тайну.
Десктопное ПО порождает определенный фатализм по отношению к багам. Вы знаете, что поставляете продукт, напичканный ошибками, и вы даже создали механизмы для компенсации этого (например, выпуск патчей). Так зачем переживать из-за еще нескольких штук? Вскоре вы уже выпускаете целые функции, о неработоспособности которых прекрасно знаете. Apple сделала это ранее в этом году. Они чувствовали давление необходимости выпустить новую ОС, дата релиза которой откладывалась уже четыре раза, но часть программ (поддержка CD и DVD) не была готова. Решение? Они выпустили ОС без недоделанных компонентов, а пользователям придется устанавливать их позже.
С веб-софтом вам никогда не приходится выпускать программу до того, как она заработает, и вы можете выпустить ее сразу же, как только она начинает работать.
Ветеран индустрии может подумать: звучит прекрасно — говорить, что вам никогда не приходится выпускать софт до того, как он заработает, но что делать, если вы пообещали сдать новую версию программы к определенной дате? В случае с веб-софтом вы бы не стали давать такого обещания, потому что никаких версий нет. Ваш софт меняется постепенно и непрерывно. Некоторые изменения могут быть масштабнее других, но концепция версий просто органически не подходит веб-софту.
Если кто-то помнит Viaweb, это может прозвучать странно, ведь мы постоянно анонсировали новые версии. Делалось это исключительно в PR-целях. Отраслевая пресса, как мы выяснили, мыслит номерами версий. Вам посвятят большой материал ради мажорного релиза, то есть смены первой цифры в номере версии, и, как правило, от силы абзац за точечный релиз, то есть новую цифру после точки.
Некоторые наши конкуренты предлагали десктопный софт и действительно имели номера версий. И за эти релизы, сам факт которых казался нам свидетельством их отсталости, они получали всевозможное освещение в прессе. Мы не хотели упускать возможность, поэтому тоже начали присваивать номера версий своей программе. Когда нам хотелось публичности, мы составляли список всех функций, добавленных со времени последнего «релиза», цепляли на софт новый номер версии и выпускали пресс-релиз, сообщавший, что новая версия доступна прямо сейчас. Удивительно, но никто ни разу нас на этом не поймал.
К моменту, когда нас купили, мы проделали это трижды, так что добрались до Версии 4. Если память мне не изменяет, Версии 4.1. После того как Viaweb стал Yahoo Store, такой отчаянной потребности в пиаре уже не было, поэтому, хотя софт продолжал развиваться, саму концепцию номеров версий тихо свернули.
Баги
Второе крупное техническое преимущество веб-софта заключается в том, что вы можете воспроизвести большинство багов. Данные пользователей лежат прямо у вас на диске. Если кто-то ломает вашу программу, вам не нужно гадать, в чем дело, как пришлось бы в случае с десктопным софтом: вы можете воспроизвести ошибку прямо во время телефонного разговора с клиентом. Возможно, вы даже уже знаете о ней, если в ваше приложение встроен код для отслеживания ошибок.
Веб-софт используется круглосуточно, так что все ваши действия немедленно проходят жесткую проверку практикой. Баги всплывают быстро.
Софтверные компании иногда обвиняют в том, что они позволяют пользователям отлаживать их программы. И это именно то, к чему я призываю. Для веб-софта это на самом деле отличный план, потому что багов меньше и они быстротечны. Когда вы выпускаете софт постепенно, у вас с самого начала возникает намного меньше ошибок. А когда вы можете мгновенно воспроизводить ошибки и выкатывать изменения, вы можете находить и устранять большинство багов сразу после их появления. У нас никогда не было одновременно столько багов, чтобы стоило заводить формальную систему их учета.
Разумеется, изменения следует тестировать до релиза, так что критические ошибки не должны попадать наружу. Те немногие, что неизбежно проскользнут, будут связаны с пограничными случаями и затронут лишь немногих пользователей, столкнувшихся с ними до того, как кто-то позвонит с жалобой. Пока вы исправляете баги сразу же, итоговым результатом для обычного пользователя становится гораздо меньшее количество ошибок. Сомневаюсь, что средний пользователь Viaweb вообще когда-либо видел баг.
Исправлять свежие баги проще, чем старые. Найти ошибку в коде, который вы только что написали, обычно удается довольно быстро. Когда она проявляется, вы часто уже знаете причину еще до того, как заглянете в исходник, потому что подсознательно уже беспокоились об этом. Исправление бага в коде, написанном шесть месяцев назад (обычное дело, если вы выпускаете релизы раз в год), требует куда больше усилий. И поскольку вы уже хуже понимаете этот код, вы с большей вероятностью исправите его некрасиво или даже добавите новых багов. [4]
Когда вы отлавливаете баги на ранней стадии, вы также сталкиваетесь с меньшим числом составных ошибок. Составные баги — это взаимодействие двух отдельных ошибок: вы спотыкаетесь на лестнице, а когда хватаетесь за перила, они отрываются прямо у вас в руке. В программном обеспечении такие баги труднее всего обнаружить, и они, как правило, приводят к наихудшим последствиям. [5] Традиционный подход «все сломать, а потом отфильтровать баги» неизбежно порождает массу составных ошибок. А софт, выпускаемый серией небольших изменений, естественным образом к этому не ведет. С пола постоянно сметаются любые валяющиеся предметы, которые позже могли бы куда-нибудь забиться.
Здесь помогает применение техники под названием функциональное программирование. Функциональное программирование подразумевает отказ от побочных эффектов. Это то, что чаще встретишь в научных статьях, чем в коммерческом софте, но для веб-приложений это оказывается невероятно полезным. Писать целые программы в виде чисто функционального кода тяжело, но можно писать таким образом существенные фрагменты. Это облегчает тестирование таких частей вашего ПО, поскольку у них нет состояния, а это крайне удобно в ситуации, когда вы постоянно вносите и тестируете мелкие правки. Я написал в таком стиле большую часть редактора Viaweb, а наш скриптовый язык, RTML, мы сделали чисто функциональным языком.
Людям из индустрии десктопного ПО в это будет трудно поверить, но в Viaweb баги стали почти игрой. Поскольку большинство попадавших в продакшн багов было связано с пограничными случаями, сталкивавшиеся с ними пользователи обычно были продвинутыми, проверявшими границы возможностей. Продвинутые пользователи более снисходительны к багам, особенно с учетом того, что вы, скорее всего, внесли их в процессе добавления какой-то функции, о которой они сами просили. На самом деле, поскольку ошибки были редки и для столкновения с ними требовалось делать что-то сложное, продвинутые пользователи часто гордились тем, что поймали баг. Они звонили в службу поддержки скорее с чувством триумфа, чем гнева, словно только что обыграли нас и заработали очко.
Поддержка
Когда вы можете воспроизводить ошибки, это меняет ваш подход к клиентской поддержке. В большинстве софтверных компаний поддержка существует для того, чтобы клиенты почувствовали себя лучше. Они звонят вам либо по поводу известного бага, либо просто делают что-то не так, и вам нужно выяснить, что именно. В любом случае от них мало чему можно научиться. И поэтому к звонкам в поддержку принято относиться как к сущей головной боли, которую хочется максимально изолировать от разработчиков.
В Viaweb все было устроено иначе. В Viaweb поддержка была бесплатной, потому что мы хотели получать обратную связь от клиентов. Если у кого-то возникала проблема, мы хотели узнать о ней немедленно, чтобы воспроизвести ошибку и выпустить исправление.
Поэтому в Viaweb разработчики всегда находились в тесном контакте с техподдержкой. Сотрудники службы поддержки сидели метрах в десяти от программистов и знали, что всегда могут прервать любое занятие сообщением о настоящем баге. Мы могли уйти с заседания совета директоров, чтобы исправить серьезный баг.
Наш подход к поддержке радовал всех. Клиенты были в восторге. Представьте, каково это — позвонить на линию поддержки и почувствовать, что к вам относятся как к человеку, принесшему важную новость. Сотрудникам поддержки это нравилось, потому что они действительно помогали пользователям, а не читали им скрипты по бумажке. А программистам это нравилось потому, что они могли воспроизвести баг, а не просто слушать смутные пересказы о нем из вторых рук.
Наша политика исправления багов на лету изменила отношения между техподдержкой и хакерами. В большинстве софтверных компаний сотрудники поддержки — это низкооплачиваемый живой щит, а хакеры — маленькие копии Бога-Отца, создатели мира. Какова бы ни была процедура сообщения о багах, она, скорее всего, односторонняя: сотрудники поддержки, узнав о баге, заполняют какую-то форму, которая со временем передается (возможно, через QA) программистам, а те ставят ее в свой список задач. В Viaweb все было совсем иначе. Через минуту после того, как клиент сообщал о баге, сотрудник поддержки мог стоять рядом с программистом и слышать от него: «Черт, ты прав, это баг». Поддержку приводило в восторг это признание «ты прав» от хакеров. Они приносили нам баги с тем же выжидающим видом, с каким кошка приносит только что пойманную мышь. Кроме того, они стали внимательнее оценивать серьезность проблемы, ведь теперь на кону стояла их честь.
После того как нас купила Yahoo, сотрудников поддержки отсадили далеко от программистов. Только тогда мы поняли, что они фактически выполняли роль тестировщиков (QA) и в какой-то степени маркетологов. Помимо отлова багов, они были хранителями знаний о более тонких вещах, похожих на баги, — например, о функциях, которые сбивали пользователей с толку. [6] Они также служили своего рода заменой фокус-группы: мы могли спросить их, какая из двух новых функций нужнее пользователям, и они никогда не ошибались.
Боевой дух
Возможность выпускать софт немедленно — отличный мотиватор. Часто по дороге на работу я думал о каком-то изменении, которое хотел внести в программу, и делал его в тот же день. Это работало и для более крупных фич. Даже если на написание чего-то требовалось две недели (мало какие проекты занимали больше времени), я знал, что смогу увидеть результат в работающей программе сразу, как только закончу.
Если бы мне пришлось ждать следующего релиза целый год, я бы отложил большинство этих идей на полку — по крайней мере, на какое-то время. Но дело в том, что одни идеи порождают другие. Замечали ли вы, что когда садишься что-то писать, половина вошедших в текст мыслей приходит в голову прямо в процессе письма? То же самое происходит и с софтом. Работа над реализацией одной идеи дает вам новые идеи. Поэтому, отправляя идею «на полку», вы теряете не только время на ее внедрение, но и все те идеи, к которым привела бы ее реализация. На самом деле отправка идеи на полку, вероятно, даже подавляет появление новых: только вы начинаете думать о новой фиче, как взгляд падает на полку, и вы думаете: «но у меня и так полно нового, что нужно сделать к следующему релизу».
Что делают большие компании вместо внедрения фич — так это планируют их. В Viaweb у нас иногда возникали из-за этого проблемы. Инвесторы и аналитики спрашивали нас о планах на будущее. Честным ответом было бы: у нас нет никаких планов. У нас были общие соображения о том, что мы хотим улучшить, но если бы мы знали как, мы бы уже это сделали. Что мы собирались делать в следующие шесть месяцев? Все, что выглядело наиболее выигрышным. Не знаю, решался ли я когда-нибудь дать такой ответ, но это было правдой. Планы — это просто другое название для идей, лежащих на полке. Когда нам приходили в голову хорошие идеи, мы их реализовывали.
В Viaweb, как и во многих софтверных компаниях, у большей части кода был один конкретный владелец. Но если ты владел чем-то, ты владел этим по-настоящему: никому, кроме автора фрагмента программы, не требовалось одобрять релиз (или даже знать о нем). Не существовало никакой защиты от поломок, кроме страха показаться идиотом в глазах коллег, и этого было более чем достаточно. Возможно, у вас сложилось впечатление, будто мы просто беспечно строчили код. Мы действительно двигались быстро, но очень тщательно думали, прежде чем выкатывать софт на эти серверы. А внимательность важнее для надежности, чем медлительность. Благодаря предельной концентрации пилот ВМС может посадить 20-тонный самолет на скорости 220 км/ч на качающуюся палубу авианосца ночью безопаснее, чем обычный подросток режет бублик.
Такой способ создания программ — палка о двух концах, конечно. Он работает намного лучше для небольшой команды хороших программистов, заслуживающих доверия, чем для большой компании с посредственными сотрудниками, где дурные идеи отсеиваются комитетами, а не теми людьми, которым они пришли в голову.
Брукс наоборот
К счастью, веб-софт действительно требует меньше программистов. Когда-то я работал в компании средней руки, выпускавшей десктопное ПО, где во всем инженерном отделе трудилось более 100 человек. Лишь 13 из них занимались собственно разработкой продукта. Все остальные занимались релизами, портированием и тому подобным. В случае с веб-софтом вам нужно (максимум) всего 13 человек, потому что нет никаких релизов, портирования и всего остального.
Viaweb был написан силами всего трех человек. [7] На меня постоянно давили с требованием нанять больше людей, потому что мы хотели продать компанию, а мы знали: покупателям сложно заплатить высокую цену за компанию, в которой всего три программиста. (Решение: мы наняли еще людей, но создали для них новые проекты.)
Когда вы можете писать софт меньшим числом программистов, это экономит не только деньги. Как отметил Фред Брукс в Мифическом человеко-месяце, добавление людей в проект, как правило, замедляет его. Количество возможных связей между разработчиками растет экспоненциально с ростом группы. Чем больше группа, тем больше времени они будут проводить на совещаниях, согласовывая, как их программы будут работать вместе, и тем больше багов они получат из-за непредвиденных взаимодействий. К счастью, этот процесс работает и в обратную сторону: по мере уменьшения команд разработка софта становится экспоненциально эффективнее. Не помню, чтобы у программистов в Viaweb вообще хоть раз было настоящее совещание. Нам никогда не требовалось сказать друг другу больше, чем мы успевали обсудить по дороге на обед.
Если здесь и есть минус, то он заключается в том, что все программисты должны в какой-то степени быть еще и системными администраторами. Когда вы хостите софт, кто-то должен следить за серверами, и на практике единственные, кто может делать это как следует, — это те, кто написал эту программу. В Viaweb наша система состояла из стольких компонентов и менялась так часто, что четкой границы между софтом и инфраструктурой не существовало. Произвольное проведение такой границы ограничило бы наши проектные решения. И поэтому, хотя мы постоянно надеялись, что однажды («через пару месяцев») все станет достаточно стабильным, чтобы мы смогли нанять человека, чьей единственной заботой были бы серверы, этого так и не произошло.
Не думаю, что это вообще возможно как-то иначе, пока вы активно развиваете продукт. Веб-софт никогда не будет чем-то таким, что можно написать, закоммитить и пойти домой. Это живой организм, работающий на ваших серверах прямо сейчас. Серьезный баг может не просто уронить процесс одного пользователя — он может уронить процессы всех. Если баг в вашем коде повредит какие-то данные на диске, чинить придется вам. И так далее. Мы обнаружили, что следить за серверами каждую минуту не обязательно (примерно после первого года), но определенно стоит приглядывать за тем, что вы недавно изменили. Нельзя выкатить код поздно ночью и просто уйти домой.
Наблюдение за пользователями
С серверным ПО вы находитесь в более тесном контакте со своим кодом. А еще вы можете быть в более тесном контакте со своими пользователями. Компания Intuit известна тем, что знакомилась с покупателями в розничных магазинах и просила разрешения пойти к ним домой и посмотреть, как они работают. Если вы хоть раз наблюдали за тем, как кто-то впервые использует вашу программу, вы знаете, какие сюрпризы их ожидали.
Программа должна делать то, чего от нее ждут пользователи. Но вы, поверьте мне, не будете иметь ни малейшего представления о том, что думают пользователи, пока сами за ними не понаблюдаете. А серверное ПО дает вам беспрецедентную информацию об их поведении. Вы не ограничены маленькими искусственными фокус-группами. Вы можете видеть каждый клик каждого пользователя. Нужно тщательно взвешивать, на что именно вы смотрите, чтобы не нарушать приватность пользователей, но даже самые общие статистические выборки могут быть чрезвычайно полезны.
Когда пользователи находятся на вашем сервере, вам, к примеру, не нужно полагаться на бенчмарки. Бенчмарки — это имитация пользователей. С серверным софтом вы можете наблюдать за реальными пользователями. Чтобы решить, что оптимизировать, просто зайдите на сервер и посмотрите, что съедает весь процессор. И вы также знаете, когда пора остановиться: в конце концов мы довели редактор Viaweb до состояния, когда он упирался в оперативную память, а не в процессор, и поскольку мы ничего не могли сделать для уменьшения объема пользовательских данных (во всяком случае, простыми путями), мы поняли, что на этом можно и закончить.
Эффективность важна для серверного софта, потому что за железо платите вы сами. Количество пользователей, которое вы можете обслужить на одном сервере, — это делитель ваших капитальных затрат, поэтому, если вы сделаете свой софт очень эффективным, вы сможете сбивать цены конкурентов и все равно оставаться в плюсе. В Viaweb мы снизили капитальные затраты на одного пользователя примерно до 5 долларов. Сейчас было бы еще меньше — вероятно, меньше, чем стоимость отправки им счета за первый месяц. Железо сейчас практически бесплатно, если ваш софт достаточно эффективен.
Наблюдение за пользователями может направлять вас как в дизайне, так и в оптимизации. В Viaweb был скриптовый язык RTML, который позволял продвинутым пользователям определять собственные стили страниц. Мы обнаружили, что RTML превратился в своего рода ящик для предложений, потому что пользователи обращались к нему только тогда, когда готовые стили страниц не позволяли сделать то, что им хотелось. Изначально редактор размещал полосы кнопок поперек страницы, но после того, как несколько пользователей использовали RTML, чтобы разместить кнопки по левой стороне, мы сделали это опцией (фактически вариантом по умолчанию) в готовых стилях страниц.
Наконец, наблюдая за пользователями, часто можно заметить, когда они испытывают трудности. А поскольку клиент всегда прав, это сигнал о проблеме, которую нужно исправить. В Viaweb ключом к привлечению пользователей был онлайн-тест-драйв. Это была не просто серия слайдов, подготовленная маркетологами. В нашем тест-драйве пользователи реально работали с программой. Это занимало около пяти минут, и в итоге они получали настоящий, работающий магазин.
Тест-драйв был тем каналом, через который мы получали почти всех новых пользователей. Думаю, то же самое справедливо для большинства веб-приложений. Если пользователи смогут успешно пройти тест-драйв, продукт им понравится. Если они запутаются или заскучают — нет. Поэтому все, что мы могли сделать для увеличения доли людей, прошедших тест-драйв, увеличивало наши темпы роста.
Я изучил пути переходов пользователей, проходивших тест-драйв, и обнаружил, что на определенном шаге они путались и нажимали кнопку «Назад» в браузере. (Если вы попробуете писать веб-приложения, вы обнаружите, что кнопка «Назад» становится для вас одной из самых интересных философских проблем.) Поэтому в том месте я добавил сообщение, сообщавшее пользователям, что они почти закончили, и напоминавшее не нажимать кнопку «Назад». Еще один плюс веб-софта — мгновенная обратная связь от изменений: процент людей, завершивших тест-драйв, сразу же вырос с 60% до 90%. А поскольку количество новых пользователей прямо зависело от числа пройденных тест-драйвов, рост нашей выручки увеличился на 50% только благодаря этому изменению.
Деньги
В начале 1990-х я прочитал статью, автор которой утверждал, что софт — это бизнес по подписке. Поначалу это утверждение показалось мне очень циничным. Но позже я понял, что оно отражает реальность: разработка программного обеспечения — это непрерывный процесс. Я считаю, что гораздо честнее открыто взимать абонентскую плату, вместо того чтобы заставлять людей постоянно покупать и устанавливать новые версии просто ради того, чтобы они продолжали вам платить. И, к счастью, подписка — это естественный способ оплаты веб-приложений.
Хостинг приложений — это область, где компании будут играть роль, которую вряд ли займет бесплатный софт (freeware). Хостинг приложений сопряжен с большим стрессом и реальными расходами. Никто не захочет заниматься этим бесплатно.
Для компаний веб-приложения являются идеальным источником дохода. Вместо того чтобы начинать каждый квартал с чистого листа, вы имеете регулярный поток выручки. Поскольку ваш софт развивается постепенно, вам не нужно беспокоиться о том, что новая версия провалится; новой версии как таковой может вообще никогда не быть, а если вы сделаете в софте что-то, что не понравится пользователям, вы узнаете об этом сразу. У вас нет проблем с неоплаченными счетами: если кто-то не платит, можно просто отключить услугу. И нет никакой возможности для пиратства.
Это последнее «преимущество» может обернуться проблемой. Некоторый уровень пиратства выгоден софтверным компаниям. Если какой-то пользователь ни при каких обстоятельствах не купил бы ваш софт, вы ничего не теряете от того, что он использует пиратскую копию. На самом деле вы выигрываете, потому что он — еще один пользователь, помогающий вашему продукту стать стандартом, или тот, кто может купить копию позже, когда закончит школу.
Когда есть возможность, компании прибегают к так называемой ценовой дискриминации, то есть берут с каждого клиента столько, сколько тот может себе позволить. [8] Софт особенно удобен для ценовой дискриминации, поскольку предельные издержки близки к нулю. Вот почему запуск некоторого софта на машинах от Sun стоит дороже, чем на машинах с Intel: компания, использующая Sun, не стремится экономить деньги, и с нее вполне можно взять больше. Пиратство — это фактически низший уровень ценовой дискриминации. Думаю, софтверные компании это понимают и намеренно закрывают глаза на некоторые виды пиратства. [9] С серверным софтом им придется придумывать какое-то другое решение.
Веб-софт хорошо продается, особенно по сравнению с десктопным ПО, потому что его легко купить. Можно подумать, будто решение о покупке и сама покупка — это два отдельных шага. Так думал и я до Viaweb, если вообще задумывался над этим вопросом. На самом же деле второй шаг может оказывать обратное влияние на первый: если вещь трудно купить, люди могут передумать и решить, что она им вообще не нужна. И наоборот: вы продадите больше, если купить товар легко. Я покупаю больше книг просто потому, что существует Amazon. Веб-софт — это, пожалуй, самая простая для покупки вещь на свете, особенно если вы только что прошли онлайн-демо. От пользователя не должно требоваться ничего сложнее, чем ввести номер кредитной карты. (Требовать большего вы будете на свой страх и риск.)
Иногда веб-софт предлагают через интернет-провайдеров, выступающих в роли реселлеров. Это плохая идея. Вы сами должны администрировать серверы, потому что вам нужно постоянно совершенствовать и железо, и софт. Если вы отказываетесь от прямого контроля над серверами, вы теряете большую часть преимуществ разработки веб-приложений.
Некоторые наши конкуренты выстрелили себе в ногу именно таким образом — как правило, я думаю, потому, что ими командовали люди в костюмах, которые воодушевились этим огромным потенциальным каналом сбыта и не поняли, что это погубит продукт, который они надеялись через него продавать. Продавать веб-софт через интернет-провайдеров — все равно что продавать суши через торговые автоматы.
Клиенты
Кто будет клиентами? В Viaweb поначалу это были частные лица и небольшие компании, и я думаю, что это правило останется в силе для веб-приложений. Это те пользователи, которые готовы пробовать новое, отчасти потому, что они более гибки, а отчасти потому, что хотят снизить затраты за счет новых технологий.
Веб-приложения часто будут лучшим решением и для крупных компаний (хотя они не сразу это осознают). Лучший интранет — это интернет. Если компания использует настоящие веб-приложения, софт будет работать лучше, серверы будут администрироваться лучше, а сотрудники получат доступ к системе отовсюду.
Главный аргумент против такого подхода обычно сводится к безопасности: если сотрудникам получить доступ проще, то и злоумышленникам тоже. Некоторые крупные продавцы не решались использовать Viaweb, полагая, что данные кредитных карт клиентов будут в большей безопасности на их собственных серверах. Было непросто высказать это дипломатично, но на самом деле в наших руках данные почти наверняка находились в большей безопасности, чем в их. Кто может нанять лучших специалистов по безопасности: технологический стартап, весь бизнес которого заключается в управлении серверами, или розничный продавец одежды? У нас не только были лучшие специалисты, думающие о безопасности, — мы и беспокоились о ней куда сильнее. Если кто-то взломает серверы продавца одежды, это затронет максимум одного торговца, это, вероятно, удастся замять, а в худшем случае уволят одного человека. Если же взломают наши серверы, это может затронуть тысячи продавцов, наверняка попадет в новости на CNet и может поставить крест на нашем бизнесе.
Если вы хотите сберечь свои деньги, вы прячете их дома под матрасом или несете в банк? Этот довод применим ко всем аспектам администрирования серверов: не только к безопасности, но и к аптайму, пропускной способности, распределению нагрузки, резервному копированию и т. д. Само наше существование зависело от того, чтобы делать эти вещи правильно. Проблемы с серверами были для нас категорическим табу, как опасная игрушка для производителя игрушек или вспышка сальмонеллеза для пищевого комбината.
Крупная компания, использующая веб-приложения, в той же мере отдает IT на аутсорсинг. Как бы радикально это ни звучало, я считаю, что в целом это хорошая идея. Таким путем компании, скорее всего, получат лучший сервис, чем от штатных системных администраторов. Сисадмины могут становиться раздражительными и нерасторопными, потому что они не испытывают прямого давления конкуренции: продавцу приходится иметь дело с клиентами, разработчику — с софтом конкурентов, но сисадмина, как старого холостяка, мало какие внешние силы держат в узде. [10] В Viaweb у нас было более чем достаточно внешних сил, державших нас в узде. Люди, звонившие нам, были клиентами, а не просто коллегами по работе. Если сервер зависал, мы подскакивали; от одной мысли об этом у меня даже годы спустя происходит выброс адреналина.
Так что веб-приложения обычно будут правильным ответом и для крупных компаний. Однако они поймут это последними, точно так же, как было и с персональными компьютерами. И отчасти по той же причине: убедить крупные компании в том, что им нужно что-то более дорогое, приносит очень большие деньги.
Богатые клиенты всегда склонны покупать дорогие решения, даже когда дешевые лучше, потому что компании, предлагающие дорогие решения, могут больше тратить на их продажу. В Viaweb мы постоянно с этим сталкивались. Мы уступили нескольких крупных продавцов веб-консалтинговым фирмам, которые убедили их, что им будет лучше заплатить полмиллиона долларов за созданный на заказ интернет-магазин на собственном сервере. Им, как правило, лучше не было, в чем не один из них убедился, когда наступил сезон рождественских покупок и нагрузка на их сервер выросла. Viaweb был намного более продвинутым продуктом, чем то, что получила большая часть этих продавцов, но мы не могли позволить себе рассказать им об этом. При цене в 300 долларов в месяц мы не могли направить к клиентам команду безупречно одетых людей с авторитетными голосами для проведения презентаций.
Значительная часть того, за что переплачивают крупные компании, — это расходы на сам процесс продажи им дорогих вещей. (Если Министерство обороны платит тысячу долларов за сиденья для унитазов, то отчасти потому, что продать сиденье для унитаза за тысячу долларов стоит немалых денег.) И это одна из причин, почему интранет-софт будет продолжать процветать, хотя это, вероятно, плохая идея. Он попросту дороже. С этой дилеммой ничего не поделаешь, поэтому лучший план — сначала ориентироваться на более мелких клиентов. Остальные подтянутся со временем.
Сын сервера
В работе программ на сервере нет ничего нового. На самом деле это старая модель: приложения для мейнфреймов сплошь серверные. Если серверный софт — такая хорошая идея, почему он проиграл в прошлый раз? Почему персональные компьютеры затмили мейнфреймы?
Сначала персональные компьютеры не казались особой угрозой. Первыми пользователями были исключительно хакеры — или радиолюбители, как их тогда называли. Микрокомпьютеры нравились им своей дешевизной. Впервые можно было получить собственный компьютер. Словосочетание «персональный компьютер» сейчас вошло в обиход, но когда оно прозвучало впервые, в нем слышалась намеренная дерзость, подобно тому как сегодня прозвучало бы выражение «персональный спутник».
Почему настольные компьютеры взяли верх? Я думаю, потому, что у них был лучший софт. А причина, по которой софт для микрокомпьютеров оказался лучше, заключалась, на мой взгляд, в том, что его могли писать маленькие компании.
Не думаю, что многие осознают, насколько хрупки и неуверенны стартапы на самых ранних стадиях. Многие стартапы начинаются почти случайно: пара ребят, работающих где-то или учащихся, пишут прототип чего-то, что, если покажется многообещающим, может перерасти в компанию. На этой зародышевой стадии любое серьезное препятствие способно мгновенно убить стартап. Написание софта для мейнфреймов требовало слишком больших начальных вложений. Компьютеры для разработки стоили дорого, а поскольку клиентами были крупные компании, требовался солидный штат продавцов, чтобы продать им продукт. Открытие стартапа для создания программ под мейнфреймы было бы куда более серьезным делом, чем просто написание чего-то на коленке на своем Apple II по вечерам. И поэтому стартапов, пишущих под мейнфреймы, практически не было.
Появление персональных компьютеров породило массу нового софта, потому что разработка приложений под них казалась зарождающимся стартапам достижимой целью. Разработка обходилась дешево, а клиентами были частные лица, до которых можно было дотянуться через компьютерные магазины или даже по почте.
Программой, которая вывела персональные компьютеры в мейнстрим, стала VisiCalc — первая электронная таблица. Она была написана двумя парнями, работавшими на мансарде, и тем не менее делала то, чего не умела ни одна программа для мейнфреймов. [11] VisiCalc стала для своего времени таким прорывом, что люди покупали Apple II только ради того, чтобы запустить ее. И это положило начало тенденции: персональные компьютеры победили потому, что стартапы писали под них софт.
Похоже, что на этот раз серверный софт будет хорош, потому что писать его будут стартапы. Компьютеры сейчас настолько дешевы, что можно начать, как это сделали мы, используя настольный ПК в качестве сервера. Недорогие процессоры поглотили рынок рабочих станций (сейчас это слово даже редко услышишь) и почти завоевали рынок серверов; серверы Yahoo, выдерживающие самые высокие нагрузки в интернете, оснащены теми же недорогими процессорами Intel, что стоят и в вашем домашнем компьютере. А как только программа написана, все, что вам нужно для ее продажи, — это веб-сайт. Почти все наши пользователи приходили прямо на наш сайт благодаря сарафанному радио и упоминаниям в прессе. [12]
Viaweb был типичным зародышевым стартапом. Мы до смерти боялись основывать компанию и первые несколько месяцев успокаивали себя тем, что относились ко всему происходящему как к эксперименту, который можем свернуть в любую минуту. К счастью, почти не было никаких препятствий, кроме технических. Пока мы писали софт, нашим веб-сервером был тот самый настольный компьютер, на котором велась разработка, подключенный к внешнему миру через модемное dialup-соединение. Единственными нашими расходами на этом этапе были еда и аренда жилья.
Сейчас у стартапов еще больше причин писать веб-приложения, потому что разработка десктопного ПО перестала приносить прежнее удовольствие. Если вы хотите писать десктопное ПО сейчас, вам приходится делать это на условиях Microsoft, вызывая их API и обходя баги их операционной системы. И если вам удастся создать что-то по-настоящему успешное, вы можете обнаружить, что просто провели исследование рынка для Microsoft.
Если компания хочет создать платформу, на которой стартапы будут строить свои продукты, она должна сделать ее такой, чтобы самим хакерам хотелось ею пользоваться. Это значит, что она должна быть недорогой и хорошо спроектированной. Mac был популярен среди хакеров, когда только появился, и многие из них писали под него софт. [13] С Windows такое увидишь реже, потому что хакеры ею не пользуются. Люди, которые действительно хорошо умеют писать софт, сейчас, как правило, сидят на Linux или FreeBSD.
Не думаю, что мы запустили бы стартап для разработки настольного ПО, ведь десктопный софт должен работать под Windows, а чтобы писать софт под Windows, нам пришлось бы ею пользоваться. Веб позволил нам обойти Windows с фланга и доставлять софт, работающий на Unix, прямо пользователям через браузер. Это освобождающая перспектива, во многом похожая на появление персональных компьютеров двадцать пять лет назад.
Microsoft
Когда появились настольные компьютеры, гигантом, которого все боялись, была IBM. Сейчас в это трудно поверить, но я прекрасно помню это ощущение. Теперь пугающий гигант — это Microsoft, и я не думаю, что они настолько же слепы к нависшей над ними угрозе, как была IBM. В конце концов, Microsoft намеренно построила свой бизнес в слепой зоне IBM.
Ранее я упоминал, что моей маме на самом деле не нужен настольный компьютер. Большинству пользователей он, вероятно, тоже не нужен. Для Microsoft это проблема, и они это понимают. Если приложения работают на удаленных серверах, Windows никому не нужна. Что сделает Microsoft? Смогут ли они использовать свой контроль над десктопом, чтобы предотвратить или ограничить появление этого нового поколения программного обеспечения?
Мое предположение: Microsoft разработает некий гибрид сервера и десктопа, где операционная система будет тесно взаимодействовать с подконтрольными им серверами. Как минимум, файлы будут централизованно доступны пользователям, которым это нужно. Я не думаю, что Microsoft решится на крайность и перенесет все вычисления на сервер, оставив на клиенте только браузер, если у них будет возможность этого избежать. Если в качестве клиента вам нужен только браузер, вам не нужна Microsoft на стороне клиента, а если Microsoft не контролирует клиента, она не может подталкивать пользователей к своим серверным приложениям.
Думаю, Microsoft будет трудно удержать джинна в бутылке. Будет слишком много разных типов клиентов, чтобы контролировать их все. И если приложения Microsoft будут работать только с некоторыми клиентами, конкуренты смогут превзойти их, предложив приложения, работающие с любого клиента. [14]
В мире веб-приложений для Microsoft нет автоматически гарантированного места. Возможно, им удастся отвоевать себе нишу, но я не думаю, что они будут доминировать в этом новом мире так же, как в мире настольных приложений.
Дело даже не столько в том, что им подставит подножку конкурент, сколько в том, что они оступятся сами. С ростом популярности веб-софта они столкнутся не только с техническими проблемами, но и с собственными иллюзиями. То, что им необходимо сделать, — это каннибализировать собственный бизнес, а я сомневаюсь, что они на это пойдут. Та самая целеустремленность, которая привела их к текущему успеху, теперь будет работать против них. IBM находилась в абсолютно такой же ситуации и не смогла с ней справиться. IBM вышла на рынок микрокомпьютеров с опозданием и без энтузиазма, потому что колебалась, не желая ставить под угрозу свою дойную корову — мейнфреймы. Microsoft точно так же будет скована стремлением спасти десктоп. Дойная корова может оказаться чертовски тяжелым грузом на вашей шее.
Я не утверждаю, что в серверных приложениях никто не займет доминирующего положения. Рано или поздно кто-то, вероятно, это сделает. Но я думаю, нас ждет долгий и прекрасный период веселого хаоса, прямо как на заре микрокомпьютеров. Это было отличное время для стартапов. Множество мелких компаний процветало, и они добивались этого, создавая классные вещи.
Стартапы, только еще больше
Классический стартап быстр и неформален, в нем мало людей и мало денег. Эти немногочисленные сотрудники вкалывают не покладая рук, а технологии многократно усиливают эффект принимаемых ими решений. Если они побеждают, то срывают огромный куш.
В стартапе, создающем веб-приложения, все, что ассоциируется со стартапами, доведено до крайности. Написать и запустить продукт можно еще меньшим числом людей и с еще меньшими деньгами. Приходится действовать еще быстрее, а атмосфера может быть еще более неформальной. Можно буквально запустить продукт втроем, сидя в гостиной съемной квартиры, имея лишь сервер, размещенный на колокации у провайдера. Мы именно так и сделали.
Со временем команды становились все меньше, быстрее и неформальнее. В 1960 году разработка ПО означала комнату, полную мужчин в роговых очках и узких черных галстуках, старательно пишущих по десять строк кода в день на бланках кодирования IBM. В 1980 году это была команда из восьми-десяти человек, ходивших в офис в джинсах и набиравших код на vt100. Сейчас это пара парней с ноутбуками, сидящих в гостиной. (И джинсы, как оказалось, были далеко не пределом неформальности.)
Стартапы — это стресс, и в сфере веб-приложений он, к сожалению, также доведен до крайности. У многих софтверных компаний, особенно на начальном этапе, бывают периоды, когда разработчики спят прямо под столами. Тревожная особенность веб-софта заключается в том, что ничто не мешает такому режиму стать нормой по умолчанию. Истории о ночевках под столами обычно заканчиваются словами: «затем наконец мы выпустили релиз, разошлись по домам и спали неделю». Веб-софт не выпускается в виде финального релиза никогда. Можно работать по 16 часов в сутки сколь угодно долго. А поскольку вы можете так работать — и ваши конкуренты тоже могут, — вам фактически приходится это делать. Можешь — значит должен. Закон Паркинсона, работающий наоборот.
Хуже всего даже не рабочие часы, а груз ответственности. У программистов и системных администраторов традиционно разные поводы для беспокойства. Программисты волнуются о багах, а сисадмины — об инфраструктуре. Программист может провести тяжелый день по локоть в исходном коде, но в какой-то момент он идет домой и забывает о нем. Сисадмин никогда не отключается от работы до конца, но когда его будят вызовом пейджера в 4 утра, ему обычно не требуется делать ничего запредельно сложного. В веб-приложениях эти два вида стресса сливаются воедино. Программисты становятся сисадминами, но лишаются тех четких границ, которые обычно делают эту работу терпимой.
В Viaweb первые шесть месяцев мы занимались только написанием софта. Мы вкалывали допоздна, как и положено на раннем этапе стартапа. В компании, производящей коробочное ПО, это была бы самая тяжелая фаза, но для нас она показалась курортом по сравнению со следующим этапом — когда мы пустили пользователей на наш сервер. Вторым по значимости плюсом продажи Viaweb компании Yahoo (после денег) была возможность переложить всю полноту ответственности за происходящее на плечи крупной корпорации.
Настольный софт вынуждает становиться системными администраторами пользователей. Веб-софт принуждает к этому программистов. В совокупности стресса в мире становится меньше, но на долю программистов его выпадает больше. Это не обязательно плохая новость. Если вы стартап, конкурирующий с корпорацией, это отличная новость. [15] Веб-приложения дают понятный способ переработать своих соперников за счет чистой выносливости. Большего стартапу и не нужно.
Достаточно хорошо
Одной из причин, которая может отпугнуть вас от разработки веб-приложений, является убожество веб-страниц в качестве пользовательского интерфейса. Это действительно проблема, признаю. Было несколько вещей, которые нам очень хотелось бы добавить в HTML и HTTP. Однако важно то, что веб-страницы оказались «достаточно хороши».
Здесь напрашивается параллель с первыми микрокомпьютерами. Процессоры в тех машинах изначально вовсе не предназначались для роли ЦПУ в полноценных компьютерах. Их создавали для устройств вроде светофоров. Но парни вроде Эда Робертса, создавшего Altair, поняли, что они «достаточно хороши». Можно было соединить такой чип с некоторым объемом памяти (256 байт в первом Altair) и переключателями на передней панели — и получить работающий компьютер. Возможность иметь собственный персональный компьютер вызывала такой восторг, что нашлось огромное количество желающих купить его, каким бы ограниченным он ни был.
Веб-страницы не создавались для интерфейсов приложений, но они достаточно хороши. И для внушительного числа пользователей софт, которым можно пользоваться из любого браузера, сам по себе будет достаточным преимуществом, чтобы перевесить любые неудобства интерфейса. Возможно, на 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] Понимая, что львиная доля денег кроется в услугах, компании, создававшие легкие клиенты, обычно пытались совместить железо с онлайн-сервисом. Этот подход не сработал: отчасти потому, что для производства потребительской электроники и для управления онлайн-сервисом нужны компании совершенно разного профиля, а отчасти потому, что пользователям эта идея ненавистна. Модель «раздавать бесплатно станки и зарабатывать на лезвиях» может работать для Gillette, но бритва требует гораздо меньших обязательств, чем веб-терминал. Производители мобильных телефонов довольствуются продажей устройств, не пытаясь привязать к себе еще и доходы от услуг связи. Вероятно, именно такой должна быть модель и для интернет-клиентов. Если бы кто-то просто начал продавать симпатичную коробочку с веб-браузером, способную подключаться через любого провайдера, каждый технофоб в стране купил бы себе такую.
[2] Безопасность всегда больше зависит от того, чтобы не совершать глупых ошибок, чем от каких-либо архитектурных решений, однако сама специфика серверного софта заставит разработчиков относиться к предотвращению ошибок более щепетильно. Взлом сервера может нанести столь катастрофический ущерб, что ASP (желающие остаться в бизнесе), вероятнее всего, будут очень трепетно относиться к безопасности.
[3] В 1995 году, когда мы запускали Viaweb, предполагалось, что Java-апплеты станут технологией, на которой все поголовно будут писать серверные приложения. Нам апплеты казались старомодной идеей. Скачивать программы для запуска на клиенте? Проще довести концепцию до конца и выполнять программы на сервере. Мы потратили на апплеты минимум времени, но бесчисленное множество других стартапов угодило в эту смоляную яму. Мало кто выбрался оттуда живым, иначе Microsoft не сошло бы с рук исключение поддержки Java в последней версии Explorer.
[4] Эту мысль высказал Тревор Блэквелл, добавив: «затраты на написание софта растут быстрее, чем линейно по отношению к его объему. Возможно, главным образом из-за исправления старых багов, и эти затраты могли бы расти более линейно, если бы все ошибки выявлялись оперативно».
[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 целую стаю производителей дешевых комплектующих. Масла в огонь подлило и то, что в критический период руководство компанией перешло к людям в костюмах.
[14] Единственное, что здорово помогло бы веб-приложениям и не позволило Microsoft затмить собой следующее поколение софта, — это хороший браузер с открытым исходным кодом. Mozilla имеет открытый код, но, похоже, сильно пострадала из-за того, что слишком долго оставалась корпоративным продуктом. Компактный, быстрый и активно поддерживаемый браузер сам по себе стал бы замечательной вещью и, вероятно, подтолкнул бы компании к созданию небольших интернет-устройств.
Помимо прочего, правильный браузер с открытым исходным кодом способствовал бы непрерывному развитию HTTP и HTML (как это происходило, например, с Perl). Веб-приложениям очень помогла бы возможность различать клик по ссылке и фактический переход по ней; для этого потребовалось бы лишь банальное улучшение HTTP, позволяющее запрашивать несколько URL в одном запросе. Выпадающие каскадные меню тоже были бы весьма кстати.
Если хотите изменить мир — напишите новый Mosaic. Думаете, уже слишком поздно? В 1998 году многие думали, что поздно запускать новую поисковую систему, но Google доказала обратное. Для чего-то нового всегда найдется место, если существующие варианты работают из рук вон плохо. Только убедитесь сначала, что это работает на всех свободных операционных системах: новые вещи всегда начинаются с их пользователей.
[15] Тревор Блэквелл, который, пожалуй, знает об этом на собственном опыте лучше кого бы то ни было, пишет:
«Я бы пошел еще дальше и сказал, что, поскольку разработка серверного софта настолько изматывает программистов, она вызывает фундаментальный экономический сдвиг не в пользу крупных корпораций. Она требует от разработчиков такого уровня самоотдачи и упорства, на который они готовы идти лишь в том случае, если работают на собственную компанию. Софтверные компании могут нанимать квалифицированных людей для работы в щадящих условиях и могут нанимать неквалифицированных людей, готовых терпеть трудности, но они не способны нанять высококлассных спецов, которые будут рвать жилы на работе. А раз капитал больше не имеет решающего значения, крупным компаниям практически нечего предложить».
[16] В исходной версии этого эссе я советовал избегать Javascript. Для 2001 года это был дельный совет, но сейчас Javascript работает как надо.
Спасибо Саре Харлин, Тревору Блэквеллу, Роберту Моррису, Эрику Рэймонду, Кену Андерсону и Дэну Гиффину за вычитку черновиков этого текста; Дэну Бриклину и Бобу Франкстону — за информацию о VisiCalc; и снова Кену Андерсону — за приглашение выступить в BBN.