Годы под солнцем. 20 лет в Sun Microsystems и Кремниевой долине

У Sun в то время фактически было два подразделения системных продуктов. Помимо подразделения рабочих станций, у Sun было ещё подразделение серверов. В ту эпоху, когда рабочие станции были на пике популярности, серверы фактически рассматривались как нечто второстепенное. О серверах задумывались только в тех случаях, когда требовалось хранить большие объемы данных, превышающие возможности рабочих станций, или выполнять задачи, требующие длительного времени, а пользователи рабочих станций не хотели, чтобы сервер слишком долго монополизировал ресурсы рабочей станции. По этой причине серверы обычно обладали значительным объемом памяти (оперативной или дисковой) и более быстрым процессором. Кроме того, поскольку они были дороже, их обычно использовали совместно.(Поэтому с точки зрения производителя объёмы их продаж были невысокими.) Когда я только пришёл в Sun, я спросил вице-президента подразделения рабочих станций Холла Ли, что такое сервер, поскольку в университете я никогда не слышал этого термина. Он ответил: «Сервер — это рабочая станция без рук (имея в виду клавиатуру) и без головы (имея в виду монитор)». Даже производственный отдел Sun в те годы, в отличие от рабочих станций, которые называли «настольными» (desktop), долгие годы настаивал на том, чтобы серверы называли «у стола» (deskside).

В январе 1989 года отдел серверов Sun потерял своего технического директора, возглавлявшего проект Sunburst. В то время основным продуктовым проектом отдела серверов была разработка сервера под названием SunUp, в котором использовались процессоры на основе технологии ECL, производимые компанией BIT из Сиэтла. Логические схемы ECL отличались более высокой скоростью работы и в то время применялись только в мэйнфреймах и суперкомпьютерах. По сравнению с технологией TTL, используемой в мини-компьютерах, рабочих станциях и персональных компьютерах (ПК), ECL была гораздо быстрее, но при этом потребляла значительное количество энергии и была дорогостоящей. В связи с этим серверное подразделение Sun Microsystems запустило проект по созданию производного продукта под названием Sunburst, который имел ту же архитектуру, что и SunUp, но в нецентральных областях использовал более дешевую технологию TTL/CMOS. Поскольку это был производный проект, его инженерная команда была гораздо меньше по сравнению с командой SunUp, насчитывавшей более сорока инженеров.

Учитывая мой опыт работы с крупными системами, Хол Ли пригласил к участию в моем собеседовании вице-президента серверного подразделения Лена Хьюза (Len Hughes). Поэтому он знал меня лично —. Вместо того чтобы нанимать нового сотрудника со стороны, он попросил Хол Ли «одолжить» меня.

Я только что завершил разработку спецификации M-bus. Рабочая станция, оснащённая материнской платой с процессором, оперативной памятью и логикой ввода-вывода (все настольные рабочие станции имели всего одну печатную плату), хотя и была интересной, но мне, как компьютерному архитектору, она начала надоедать. Поэтому, когда Холл обратился ко мне с предложением, оно показалось мне очень привлекательным — как с точки зрения более сложной архитектуры крупных машин, так и с точки зрения возможности разработки собственного продукта, — и я сразу же согласился.

С тех пор я больше не возвращался в отдел рабочих станций.

Боевой дух команды Sunburst был на низком уровне. Проект отставал от графика. Через две недели после того, как я присоединился к проекту Sunburst, мне позвонил Берни Лакрут (Bernie Lacroute) — вице-президент Sun Microsystems, курировавший всю инженерную деятельность в то время и являвшийся начальником Лина Хьюза. Он спросил меня, сможет ли проектная команда завершить проектирование основного чипа матрицы и передать его производителю в срок — до 21 мая, то есть через два с половиной месяца. Оценив текущий ход разработки и объем оставшейся работы, я, несмотря на то что очень хотел заниматься собственным продуктом и понимал, что отрицательный ответ, скорее всего, поставит под угрозу само существование проекта, честно признался, что это невозможно. Он, как и следовало ожидать, ответил, что такая задержка может вынудить компанию закрыть этот проект. Я сказал ему, что в таком случае ему лучше закрыть проект прямо сейчас, поскольку в его нынешнем состоянии он ни в коем случае не сможет достичь запланированных этапов. По крайней мере в последующий период он не воплотил свою угрозу в жизнь.

Разные подходы

С одной стороны, я хотел как можно быстрее восполнить пробелы в знаниях о продукте Sunburst и наверстать отставание в графике проекта, но в то же время я понимал, что перейти от напряжённой работы к более спокойному режиму легко, а обратно — сложно. Поэтому я продолжал ходить на работу по субботам, как и в «Сайчжун». На самом деле это довольно распространённый режим работы в стартапах Кремниевой долины. Инженеры Sunburst заметили это и тоже начали выходить на работу по субботам. В полдень мы пошли вместе пообедать, я угостил всех.

Через три недели в один из дней в мой кабинет зашел инженер из Sunburst, о котором я знал, что он одновременно посещает вечерние курсы в Стэнфордском университете. Он сказал мне: «Дэвид (мое английское имя), ты не можешь так нас гонять. Так мы умрём».

Я был в шоке. Я чуть не закричал на него: «Инженеры в Sun Microsystems работали так более четырёх лет, и никто не умер!» Но в последнюю секунду я проглотил слова, которые уже были у меня на языке. Я внезапно понял, что нахожусь в совершенно иной среде и работаю с людьми, у которых совсем другой менталитет. Те, кто приходит работать в такую компанию, как Sun Microsystems, уже выходящую на биржу, отличаются от тех, кто устраивается в стартапы.

Усовершенствование продукта

По мере того как я учился, я начал пытаться усовершенствовать этот продукт, который теперь стал моим проектом. Поскольку этот продукт позиционировался как более дешевая (и более медленная) версия SunUp, я сначала занялся его стоимостью. Основная часть затрат на аппаратное обеспечение приходилась на микросхемы матриц логических элементов, производимые компанией LSI Logic. Опираясь на опыт переговоров со многими производителями аппаратного обеспечения, накопленный за время работы в SaiZhong, я пригласил торгового представителя LSI Logic для переговоров. Я представил ему сравнительные цены от нескольких других производителей матриц логических элементов, пытаясь снизить стоимость наших чипов LSI. Представитель LSI Logic, глядя на молодого и неопытного менеджера, сидевшего напротив него, широко улыбнулся и сказал: «У SunUp и LSI Logic есть договор, охватывающий все матрицы логических элементов. Цена фиксированная». Он, очевидно, был прав, и я ничего не мог изменить.

Что ещё я мог сделать, чтобы улучшить свой продукт? Я обнаружил, что CMOS-чипы памяти, которые Sunburst использовала для своего кэша, только что вышли на рынок в новом поколении: по той же цене, но с объёмом, в четыре раза превышающим прежний. Я поручил команде немедленно доработать исходный проект с учётом использования этих новых микросхем. Теперь, хотя Sunburst по-прежнему оставался более дешёвым устройством с более низкой тактовой частотой, его производительность при запуске приложений уже могла составить конкуренцию SunUp. Это вызвало напряжённость в отношениях между командами, работающими над этими двумя продуктами.

Три варианта ИТ-услуг от Ло Дусу

Помимо самого продукта, я также задумался, можно ли сократить расходы на проект. Это позволило бы выделить больше средств на покупку материалов для прототипов или наем дополнительного персонала. Я заметил, что значительная часть всех расходов проекта приходилась на сборы, взимаемые другими подразделениями Sun Microsystems. Среди них самые высокие составляли сборы за «ИТ-услуги», взимаемые ИТ-отделом головного офиса компании. В команде Sunburst был только я, менеджер, и восемь инженеров, и сборы за ИТ-услуги, которые они взимали, казались запредельно высокими. Как говорится, молодой бык не боится тигра: пользуясь тем, что я был новым менеджером, только что пришедшим в крупную компанию, я договорился о встрече с тогдашним директором по информационным технологиям (CIO) Sun Microsystems Биллом Радучелом (Bill Raduchel), чтобы «проверить» расходы на ИТ-услуги Sunburst.

После короткой беседы я объяснил цель своего визита и вежливо выразил недовольство столь высокой стоимостью ИТ-услуг. Я спросил, есть ли возможность снизить эту стоимость. Билл, улыбаясь, посмотрел на меня, медленно открыл средний ящик своего стола и достал таблицу с тремя различными вариантами ИТ-услуг. Мой взгляд сразу же упал на стоимость каждого пакета, указанную внизу таблицы. К моему удивлению, я обнаружил, что они все одинаковы!

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

Проект был отменен

Одновременное существование двух проектов — SunUp и Sunburst — продлилось недолго. Обычно SunUp завершала составление бюджета на новый финансовый год, начинающийся 1 июля, примерно в начале июня. Будучи молодой, активной и творческой компанией, она в течение года всегда запускала больше проектов, чем могла поддерживать в долгосрочной перспективе. Результаты процедуры составления бюджета на новый финансовый год обнажили реальность. Настал момент, когда проекты пришлось закрыть. Дефицит бюджета серверного отдела, судя по всему, был не столь значительным. Отказ от гораздо более мелких производных проектов казался удобным решением.

Однажды вечером в конце июня 1989 года Эрик Шмидт (Eric Schmidt), заместитель генерального директора, сменивший Лаку на посту руководителя всего инженерного подразделения, пригласил меня в свой кабинет. (Лаку уже ушел из Sun и стал «L» в названии стартапа HAL Computer Systems, занимавшегося разработкой нового 64-разрядного микропроцессора SPARC.)«H» — это Хеллер (Heller), другой соучредитель его компании.) Он сообщил мне, что проект Sunburst будет закрыт. Затем он рассказал мне о проекте «SunDragon», который Sun недавно запустила совместно с Xerox.

Исследовательский центр Xerox в Пало-Альто (Palo Alto Research Center, сокращённо PARC) с 1985 года занимался исследованиями в области архитектуры многопроцессорных компьютеров. Группа высококвалифицированных инженеров мирового уровня, в том числе Билл Ганнинг (Bill Gunning), создавший чип интерфейса Ethernet с тактовой частотой 3 ГГц, и главный архитектор Прадип Синдху (Pradeep Sindhu), впоследствии основавший компанию Juniper Networks, уже разработала высокопроизводительную многопроцессорную архитектуру с несколькими шинами Dynabus.Dynabus — это инновационная шина с разделением циклов (split-cycle), поддерживающая когерентность кэша (cache coherence). Они даже создали набор микросхем VLSI с матрицей логических элементов для демонстрации этой технологии. Их проект в Xerox назывался «Дракон» (поскольку в западной культуре дракон — это многоголовое чудовище).

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

Именно в это время, в 1988 году, Sun Microsystems столкнулась с сильной конкуренцией со стороны Silicon Graphics на рынке серверов. Последняя начала выпускать многопроцессорные серверы. Многопроцессорные системы позволяют значительно расширить производительность системы по сравнению с тем, что может обеспечить один процессор. Не менее важно, что многопроцессорные системы обеспечивают резервирование. Если один процессор выходит из строя, остальные процессоры могут продолжать поддерживать работу системы. Оба этих аспекта чрезвычайно важны для серверов. В то время у Sun, можно сказать, полностью отсутствовали технические знания в области многопроцессорных систем.

PARC компании Xerox и Sun Microsystems находились в Кремниевой долине. Географическая близость и взаимно выгодные общие интересы способствовали созданию идеального союза. Осенью 1988 года Sun Microsystems и Xerox подписали соглашение о совместной разработке. В январе 1989 года команда Xerox, состоящая из девяти инженеров мирового уровня и одного менеджера, разместилась на территории кампуса Sun в Маунтин-Вью. Вместе с несколькими недавно нанятыми инженерами Sun так родился проект Sun «Dragon». В качестве руководителя проекта Sun назначила Стива Борна (Steve Bourne), изобретателя известной оболочки Bourne Shell для операционной системы Unix.

На начальном этапе крупных проектов по разработке оборудования всегда уделяется чрезмерное внимание аппаратному обеспечению, особенно в 80-х и 90-х годах. Однако Стив, очевидно, был человеком, ориентированным исключительно на программное обеспечение. Вероятно, после нескольких конфликтов мнений эти талантливые, но довольно гордые инженеры из Xerox быстро утратили уважение к руководителю из Sun. Команда Xerox пригрозила вернуться в Xerox PARC. Проект, казалось, вот-вот рухнет.

Эрик (который сам в своё время перешёл из PARC в Sun) попросил меня присоединиться к команде Sun Long, чтобы «оценить, есть ли у этого проекта и команды реальная ценность», а затем доложить ему.

Собеседование

Я до сих пор помню тот день… когда я предстал перед Глэдис, «управляющей» в Бонне (в высокотехнологичной индустрии Кремниевой долины мы обычно называем секретарей менеджеров или высшего руководства «управляющими»). Это считается более уважительным титулом, который также отражает более широкий круг их обязанностей, поскольку им часто приходится заботиться обо всем подразделении своего начальника.), она вручила мне двухдневный график собеседований, заполненный именами, должностями, номерами кабинетов и временем встреч. Несколько имен принадлежали руководителям из других отделов. Это был полноценный график собеседований для соискателей! Они приняли мои запросы на встречи за собеседования при приеме на работу!

Я не знал, как объяснить это этой даме. Улыбаясь, я взял ручку, вычеркнул некоторые имена и добавил несколько должностей (поскольку не знал имен людей, ответственных за эти направления). Я сказал Глэдис, что мне нужно встретиться с этими людьми, и попросил её назначить время. Я до сих пор помню выражение лица этой бедной дамы. (На её месте я, скорее всего, отреагировал бы точно так же.)

Результаты этой «собеседовательной» процедуры оказались весьма приятными. Стив объяснил мне, почему он организовал это собеседование: он не знал меня и не понимал, за что именно мне следует отвечать в рамках проекта.

Практически все ключевые должности в проекте занимали сотрудники Xerox под руководством менеджера компании Жана Гастинеля (Jean Gastinel). Жан — энергичный, увлечённый, но тихо говорящий французский джентльмен — уже много лет возглавлял проект «Dragon» в Xerox. Фактически, именно он руководил и проектом «Sun Dragon». Жан очень дружелюбно и терпеливо рассказал мне об истории проекта, его архитектуре, членах проектной команды и их обязанностях. Его знания и энтузиазм по поводу проекта «Dragon» в Sun заставили меня почувствовать, что этот проект — его жизнь. Мы очень быстро стали общаться как два старых друга, и Жан оставался моим незаменимым партнёром вплоть до того момента, когда команда Xerox в 1993 году завершила свою миссию и покинула Sun.

Проди Синду был главным архитектором проекта. Еще когда я работал в отделе рабочих станций над проектированием M-bus, я несколько раз встречался с ним на корпоративных совещаниях: он представлял отдел серверов и был изобретателем Dynabus с разделяемым циклом (шины, используемой в архитектуре системы Dragon для соединения ЦП и памяти). Во время тех встреч между нами иногда возникали профессиональные споры с оттенком соперничества по поводу двух разных архитектур шин. Спустя столько лет я до сих пор не могу забыть первые слова, которые Проди сказал мне на той «собеседовательной» встрече: «Ты пришел сюда, чтобы найти недостатки в Dynabus?»

В то время все известные мне шины, поддерживающие многопроцессорные системы, включая M-bus, разработанную мной на основе NuBus от Texas Instruments, были шинами с общим циклом (shared-cycle).В системе с шиной с общим циклом, когда один процессор получает право доступа к шине и отправляет запрос на данные из памяти, он удерживает это право до тех пор, пока не получит запрошенные данные из памяти, не позволяя другим процессорам использовать шину. Такая конструкция интуитивно очень понятна. Что ещё более важно, она обеспечивает «атомарность» (atomicity) операций чтения или записи данных, то есть никакой другой процессор не может вклиниться в текущую операцию чтения или записи. Это позволяет многопроцессорной системе с несколькими кэшами легко достигать согласованности данных (data consistency).