понедельник, 17 октября 2011 г.

[prog] Нашел интересное в очередном потоке сознания Стива Йегга

Есть такой известный (надеюсь, в узких кругах) блоггер – Стив Йегг (Steve Yegge). Читать его высерпотоки сознания мне довольно тяжело – слов много, живым английским в достаточной степени я не владею, посему крупицы смысла в потоках словесных кренделей вылавливать непросто (хотя ему можно почти все простить за замечательную заметку Execution in the Kindom of Nouns). Аналогичная история произошла и с его недавним опусом Stevey's Google Platforms Rant – очень много слов о совершенно не интересующей меня проблеме – способности или неспособности Google к созданию платформ.

Тем не менее, в начале этого здоровенного опуса есть очень хорошие фрагменты, касающиеся того, как Amazon изменил принципы построения своих систем, в результате чего Amazon стал платформой. Началось все с письма менеджера Джефа Безоса (Jeff Bezos) следующего содержания:

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn't do this will be fired.

7) Thank you; have a nice day!

Что в моем вольном переводе будет выглядеть приблизительно так:

1) Все команды начиная с данного момента должны предоставлять данные и функциональность своих компонентов посредством сервисов со специфицированными интерфейсами.

2) Компоненты должны взаимодействовать друг с другом посредством этих интерфейсов.

3) Не должно быть никаких других форм взаимодействия: ни непосредственной линковки, ни прямого чтения хранилищ данных другой команды, ни модели разделяемой памяти, ни каких “черных входов” или чего-то подобного. Единственная разрешенная форма коммуникации – вызовы интерфейсов через сеть.

4) Без разницы какая технология будет использоваться. HTTP, CORBA, Publisher-Subscriber, слабанная на коленке – все равно. Безосу это по барабану.

5) Все без исключения интерфейсы должны с самого начала проектироваться с прицелом на взаимодействие с внешним миром. Т.е. команды должны планировать и проектировать свои интерфейсы так, чтобы их можно было предоставить разработчикам вне компании. Без исключений.

6) Любой, кто не будет выполнять вышеозначенного, будет уволен.

7) Всем спасибо и хорошего дня!

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

Было это в 2002-м году.

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

Как бы мне хотелось продемонстрировать свою “вумность” и “исключительность” и с довольным видом сказать, что уж я-то давным-давно дошел до этих правил своим умом и уже много лет применяю их на практике. К сожалению для меня это не так :)

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

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

Еще одним интересным моментом в этом же опусе было перечисление ряда проблем, с которыми столкнулись разработчики в Amazon после того, как стали следовать навязанным им правилам. Но там, как обычно у Йегга, много букв, поэтому копипастить и переводить не буду. Тем не менее советую почитать.

17 комментариев:

Сергей комментирует...

"раз уж их в приказном порядке вводил менеджер" - я бы перефразировал - раз их вводил основатель и совладелец компании :)

eao197 комментирует...

@Sergey Nikulov

Он оно как, Михалыч! ;)

Мне было лень искать, кто это такой. Но так история становится еще интереснее.

имя комментирует...

а почему такое пренебрежение линковкой (и я даже бы иногда не гнушался разделяемой памятью) ???

по-моему, правильно было бы сформулировать именно "возможность асинхронно использовать"

имя комментирует...

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

eao197 комментирует...

@имя:

Ты спрашиваешь мое мнение? Или же как я понимаю возможные причины возникновения этих принципов в Amazon?

Просто это могут быть две большие разницы (хотя надеюсь на обратное ;)

имя комментирует...

я и то, и другое спрашиваю -- мне все интересно

насчет амазона -- думаю там поступили так из-за того, что рассчитывали на своих разработчиков не слишком высокого класса

eao197 комментирует...

@имя:

Для комментария слов получится слишком много, поэтому я попытаюсь сделать отдельную заметку.

>своих разработчиков не слишком высокого класса

А впечатление об уровне разработчиков в Amazon взяты из рассказов Йегга? Или еще какая-то информация на эту тему встречалась?

имя комментирует...

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

кстати, "линковку" можно понять не так, как понял я

видимо, мне надо написать пост для прояснения моего вопроса

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

eao197 комментирует...

@имя:

>кстати, "линковку" можно понять не так, как понял я

А ты как ее понял?

имя комментирует...

для начала назовем разработчиками тех, кто разрабатывает подсистему, и "чужими" других разработчиков или кастомеров амазона, кто будет ее юзать

сам по себе расчет на юзабельность подсистемы чужими правильный

линковка может быть 2 типов:

1. линкуем к себе код чужих -- это настолько дико, что я даже и не рассматривал, хотя, если вспомнить, что чужими может быть соседняя команда, то решение запретить такое обсуждаемо и имеет смысл

2. линковка своего кода к проекту чужих

я рассматривал этот случай, и удивлялся, с чего его запретили

тут надо дополнить важный момент: этот код должен быть весьма простым, реализующим например чтение постоянно растущего файла (типа tail -f) и распихивание его по структурам и классам с++

при этом читать можно сразу *бинарные* данные (а не tlv) -- и тут как раз нужна именно линковка, т.к. независимая компиляция запросто может создать бинарную несовместимость

да, для "чужих" этот код тоже не подарок, но при условии, что он тупо парсит поток, ошибок там может не быть с достаточно большой вероятностью

сам же поток можно сделать доступным чужим только на чтение средствами файловой системы (и кстати -- разделяемая память тоже может только читаться)

(т.к. поток не является персистентным, то вовсе не обязательно учить новую версию программы читать старую версию потока -- соответственно можно обойтись без tlv или аналогов)

т.е. основная (правильная) мысль приказа "сделать невозможным чужим сломать наш сервис" может достигаться более гибкими и удобными средствами

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

имя комментирует...

"то вовсе не обязательно учить новую версию программы читать старую версию потока"

я хотел сказать, что необязательно заставлять старую версию программы понимать новую версию потока

да, это дает некоторый организационный гемор, но вполне возможно терпимый

________________________

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

имя комментирует...

а еще у нас есть сокеты и пайпы

опять же передача бинарных данных через них подразумевает линковку, а с сериализацией в с++ не густо -- рефлексии в стандарте нет (хотя, впрочем, есть gcc-xml), а руками выписывать тоже не хочется

имя комментирует...

так что под линковкой я подразумевал не "работа своей и слинкованной чужой части в едином адресном пространстве", а "передача бинарных данных через средства IPC и линковка маленького кода для их парсинга"

eao197 комментирует...

@имя:

>так что под линковкой я подразумевал не "работа своей и слинкованной чужой части в едином адресном пространстве", а "передача бинарных данных через средства IPC и линковка маленького кода для их парсинга"

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

В Amazon, имхо, под линковкой явно подразумевалось включение всего своего кода в чужой процесс.

eao197 комментирует...

@имя:

>а вот твой краткий пересказ основных моментов -- вдохновил

Справедливости ради -- я пересказал только основные моменты из преамбулы большого рассказа Йегга. Амбула там была совсем на другую тему :)

имя комментирует...

>Амбула там была совсем на другую тему :)

я его *разговорный* английский не понимаю

так на какую, по-твоему, тему амбула?

eao197 комментирует...

@имя:

>так на какую, по-твоему, тему амбула?

Как я понял, основной смысл в том, что в Google нет цели создавать платформы. Они там хорошо создают продукты. Но никто не заботиться о превращении продуктов в платформы. Т.е. то, что умеют делать не только Microsoft, но даже Amazon. А вот Google не умеет. И это плохо, и это нужно менять и прочее bla-bla-bla.

Как раз это проблемы Google, которые меня не кааются и не интересуют. А вот упомянутая для иллюстрации история из Amazon-а оказалась намного интереснее и полезнее.

PS. Я еще помню о том, что хотел рассказать, почему считаю подход Amazon-а разумным. Но это требует времени, которое пока не нашлось.