Есть такой известный (надеюсь, в узких кругах) блоггер – Стив Йегг (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 после того, как стали следовать навязанным им правилам. Но там, как обычно у Йегга, много букв, поэтому копипастить и переводить не буду. Тем не менее советую почитать.
