Insight IT

Обзор Riak

Иван Блинков — Tue, 13 Nov 2012 02:09:00 +0400

Riak - распределенная opensource база данных, разработанная на Erlang и спроектированная в расчете на:

Высокую доступность и устойчивость к сбоям;
Масштабируемость и простоту обслуживания;
Универсальность.

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

Высокая доступность и устойчивость к сбоям

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

Масштабируемость и простота обслуживания

Добавление нового сервера тривиально путем копирования конфига и одной команды.
Перераспределение данных и все остальное прозрачно происходит за сценой.
Минимальный рекомендуемый размер Riak кластера - 5 серверов, меньшее количество не дает раскрыть весь потенциал.
Одинаково легко обслуживать как маленький, так и большой кластер.
Есть коммерческая Enterprise версия с поддержкой от Basho, компании-разработчика Riak (изначально выходцы из Akamai), равноправной зашифрованной репликацией между датацентрами и поддержкой SNMP.
Есть встроенный веб-интерфейс для мониторинга и управления кластером, у меня правда так и не дошли руки его освоить:

Универсальность

Схема отсутствует, ключи и данные - произвольные бинарные строки. Ключи располагаются в пространствах имен (bucket).
Сериализация - на усмотрение разработчика, популярные варианты - Erlang'овский BERT, JSON для других платформ, можно использовать просто как файловую систему.
Модульная система хранилищ данных, альтернатив много, основная - Google LevelDB; еще интересный вариант с хранением полностью в оперативной памяти - получается продвинутый распределенный кэш с репликацией, поиском и пр.
Гибко настраиваемое количество узлов кластера, которые должны подтвердить успешность операции, чтобы она считалась успешной: можно указывать для всего кластера, пространства имен и даже конкретного запроса. Riak в любом случае остается eventually consistent базой данных (AP из CAP теоремы), но с возможностью управлять балансом производительности операций и надежностью выполнения запросов.
Три интерфейса доступа (API):
- Google ProtocolBuffers - для основного использования в боевых условиях.
- HTTP REST - для использования в языках, где нет готового клиента на ProtocolBuffers и для того, чтобы по-быстрому что-то посмотреть из консоли через curl. Хотя по факту клиенты для большинства языков программирования есть и проще делать запросы через интерпретатор.
- Еще есть прямой интерфейс Erlang-сообщений, но даже из самого Erlang им пользоваться не рекомендуют, не говоря уже о реализациях Erlang node (BERT) на других платформах.
Вместе с данными хранятся метаданные для разных целей, которые используются в соответствующих типах запросов:
- Векторные часы для разрешения конфликтов версий данных (обязательно, есть автоматическое разрешение);
- Индекс для полнотекстного поиска (концептуально позаимствован у Lucene/Solr, опционально);
- Индекс для простых выборок (по бинарным и числовым полям, опционально);
- Связанные ключи (отдаленный аналог внешних ключей, опционально).
Встроенная поддержка MapReduce, фазы можно реализовывать на Erlang или JavaScript; для обоих языков есть библиотека с наиболее популярными случаями, которые можно использовать для образца.
Есть поддержка выполнения операций до/после операций записи/чтения (hooks), чаще всего используются для построения полнотекстного индекса, но можно реализовать и свои, специфичные для приложения.

Недокументированные возможности

Пока я их нашел всего две:

Счетчики: как такового API в для увеличения/уменьшения числовых значений (increment/decrement) в Riak нет, так как он не лезет внутрь хранящихся данных. Зато есть векторные часы, которые растут с каждой операцией записи по ключу. Чтобы реализовать увеличение (increment) необходимо записать в Riak пустую бинарную строку с опцией return_body, и у вернувшегося значения сложить все поля в векторных часах. Пример на Erlang. Если нужно еще и уменьшение (decrement) этого можно добиться с помощью пары счетчиков "плюс и минус" и вычитать второе значение из первого. Для авто инкремента основных ключей не самый лучший вариант, но для не особо критичных случаев вполне себе работает.
Выборка по списку ключей (multiget): такого API тоже нет, но здесь на выручку приходит MapReduce. Это, пожалуй, наиболее популярное его применение. На вход подаем имеющийся список ключей и используем фазы из готовой библиотеки: reduce_set_union и map_identity. Данные возвращаются неотсортированные и требуют небольшой обертки на выходе, но все равно это намного быстрее, чем последовательно проходить по списку ключей и делать для каждого обычный get. Пример на Erlang.

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

Подводные камни

Если в Вашем приложении необходима функциональность постраничного просмотра отсортированных данных (pagination), то будьте готовы реализовать её на клиенте. То есть Riak быстро сделал нужную выборку всех "страниц" и уже на клиенте её придется отсортировать и выкинуть лишнее. Вообще в большинстве случаев результаты запросов к Riak приходят в произвольном порядке из-за его распределенной природы.
В продолжение к предыдущему: в REST Solr интерфейсе есть аргументы (в ProtoBuf это тоже добавили в одной из последних версий), которые, казалось бы, достаточны для реализации постраничного просмотра: sort, start, rows - что еще нужно? На практике оно работает не так, как было бы логично. Сортировка по значению (заданная в sort) применяется ПОСЛЕ того, как была отсчитана страница по start и rows. Они отмеряются по ключам или рейтингу значения в полнотекстном поиске и никак иначе. С тем же успехом эти 5-10 значений можно очень быстро отсортировать и на клиенте. Зачем-то это может быть и нужно, но в моем случае оказалось совершенно бесполезно.
У Riak есть 4 основных типа запросов: простой get/set, полнотекстовый поиск, вторичные ключи (secondary indices), МapReduce и проход по связанным ключам (link walking).
- Если Ваши данные являются сериализованным JSON, BERT или XML, то в большинстве случаев Вам нужны лишь первые два из них, исключение - упомянутая выше выборка по списку ключей через MapReduce.
- Основной сценарий использования вторичных индексов - метаданные к произвольным неструктурированным бинарным данным, например в случае с аналогом файловой системы. Либо совсем примитивные случаи, когда правда нужно сделать простую выборку по одному целочисленному полю, что бывает редко.
- Если данные сериализованы, то связанные ключи проще хранить внутри данных, а не средствами СУБД. Разницы в производительности нет, в итоге делается тот же MapReduce с теми же фазами.
Хоть Riak "из коробки" и правда надежнее многих других СУБД и 1-2 упавших/отключенных сервера в кластере внешне практически не заметны, есть одно но. Если один узел упал - соединения всех подключенных к нему клиентов теряются. Два основных пути преодоления этого момента:
- Если кластер клиентов и кластер Riak расположены на разных серверах, то между ними можно поставить отказоустойчивый TCP балансировщик нагрузки, в частности HAProxy или IPVS здесь наиболее органично вписываются.
- Если на одних и тех же, то есть вариант поставить балансировщик нагрузки перед клиентами (для веба возможно и в HTTP/HTTPS режиме), а каждый клиент подключается к своему локальному серверу Riak и если один, другой или оба сразу упали, то отрубать весь физический сервер целиком.

Выводы

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

Как уже упоминалось, практически единственный сценарий, где Riak совсем не справляется, это выборки по большим объемам данных с сортировкой и постраничным выводом. Но даже в этом случае никто не мешает использовать отдельный сервис, который будет индексировать нужным образом данные и подготавливать список идентификаторов для последующей multiget выборки из Riak. К слову, проекты по этой части уже появляются, например Yokozuna - интеграция полноценного Solr с Riak (Riak Search - лишь частичный порт Solr+Lucene на Erlang).

Архитектура Amazon

Иван Блинков — Sun, 17 Feb 2008 21:47:00 +0300

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

Источники информации

Как и многие статьи об архитектурах высоконагруженных систем на этом блоге, эта запись представляет собой перевод статьи, автором которой является Todd Hoff. Источниками информации для оригинала послужили:

Ранний Amazon от Greg Linden
Как Linux позволил Amazon сэкономить миллионы
Интервью с Werner Vogels'ом - техническим директором Amazon
Асинхронные архитектуры - краткий пересказ речи Werner Vogels'а от Cris Loosley
Познание технологической платформы Amazon - диалог с Werner Vogels
Блог Werner Vogels'а - построение масштабируемых распределенных систем

Платформа

Статистика

Более чем 55 миллионов учетных записей активных покупателей.
Более миллиона активных розничных партнеров по всему Миру.
Для построения страницы осуществляется доступ к 100-150 сервисам.

Архитектура

Что мы на самом деле подразумеваем под словом "масштабируемость"? Обычно говорят, что сервис является масштабируемым, если в случае расширения ресурсов системы производительность растет пропорционально. Рост производительности обычно означает увеличение количества выполняемых в единицу времени работ, но с другой стороны он может означать и рост объемов выполняемых работ, например размер обрабатываемых наборов данных.
Amazon пришлось претерпеть большое архитектурное преобразование в процессе перехода от двух-уровневой монолитной системы к полностью распределенной децентрализованной платформе для сервисов и приложений.
Все началось с одного приложения, обменивающегося данными с внутренним интерфейсом, написанного на C++.
Оно росло. За годы усилий, направленных на масштабирование, Amazon сфокусировался на масштабировании баз данных для хранения постоянно растущего объема информации о предметах, покупателях, заказах, для поддержки нескольких интернациональных сайтов. В 2001 году стало ясно, что исходное веб-приложение больше не в состоянии масштабироваться такими темпами. Базы данных были разбиты на маленькие части и для каждой их них был построен отдельный интерфейс, выполненный в виде сервиса, который являлся единственным способом получить доступ к данным.
Базы данных стали общим ресурсом, что затрудняло рост бизнеса в целом. Интерфейсы, связанные с пользователями и базами данных, были сильно ограничены в своей эволюции, так как они одновременно использовались множеством разных команд разработчиков и процессов.
Их архитектура тесно связана и построена вокруг сервисов. Ориентированная на сервисы архитектура дала им необходимый уровень изоляции для построения множества программных компонентов быстро и независимо.
Система выросла до сотен сервисов и не меньшего количества серверов приложений, агрегирующих информацию, полученную от сервисов. Приложение, генерирующее страницы для Amazon.com, является одним из таких серверов. То же самое можно сказать и про приложения, служащие в роли интерфейса для Веб-сервисов, сервиса, обслуживающего покупателя, интерфейса для продавцов.
Многие другие технологии очень трудно масштабировать до размеров Amazon, особенно технологии коммуникационной инфраструктуры. Они отлично работают до какого-то предела в размерах системы, а после перестают справляться с выполнения своих обязанностей. Именно это подтолкнуло Amazon на создание своих технологий в этой области.
Не ограничиваясь одним конкретным подходом, некоторые части системы используют Java/Jboss, но они являются всего лишь сервлетами.
C++ используется для обработки запросов, в то время как Perl и Mason - для составления контента.
Amazon предпочитает не пользоваться промежуточным программным обеспечением, так как оно в большинстве случаев является каркасом, а не средством разработки. Если используется промежуточное программное обеспечение, то разработчик становится заперт в использование тех принципов разработки, которые выбрал разработчик промежуточного ПО. Если появится необходимость использовать какие-либо другие решения, ничего не выйдет - вы заперты. Один и тот же цикл используется для обработки всех типов событий: сообщений, задержек в передаче данных, AJAX, и так далее. Слишком громоздко. Если бы промежуточное программное обеспечение было бы доступно в виде более мелких компонентов, скорее на правах средства разработки, чем каркаса для системы, тогда Amazon был бы более заинтересован в нем.
Кажется, что SOAP веб стек собирается заново решать все те же проблемы распределенных систем.
Если предложить разработчиком на выбор работу над SOAP и REST веб-сервисами, то только 30% выберут SOAP, это скорее всего будут разработчики на .NET и Java, привыкшие использовать WSDL файлы для генерации интерфейсов удаленных объектов. Оставшиеся 70% выберут REST - это будут пользователи PHP и Perl.
Обе категории разработчиков имеют возможность получить интерфейс к объектам Amazon. Разработчики заинтересованы просто выполнить свою работу, не заботясь о том, что происходит на другом конце провода.
Идея Amazon заключалась в построении открытого сообщества вокруг своих сервисов. Веб-сервисы были выбраны благодаря своей простоте. Но так это выглядит только снаружи. Внутри же находится архитектура, ориентированная на сервисы. Доступ к данным может быть получен только через соответстыующий интерфейс. Этот процесс описан в WSDL, но они используют свои собственные механизмы транспортировки и инкапсуляции данных.
Команды разработчиков очень небольшие и организуются вокруг сервисов
- Сервисы являются независимыми единицами предоставления функционала в рамках Amazon
- Если у разработчика возникает новая бизнес-идея или проблема, которую ему хотелось бы решить, он собирает команду для ее решения или реализации. Количество участников ограничено 8-10 людьми. Команды из такого количества человек обычно называют пиццерийными, так как для того, чтобы ее накормить достаточно двух пицц.
- Команды очень небольшие, но они уполномочены решать поставленную задачу любыми доступными способами, именно так, как они считают нужным. – В качестве примера задачи, поставленной перед такой командой, может служить поиск фраз в рамках книги, уникальных для конкретного текста. – Экстенсивное A/B тестирование используется для интеграции новых сервисов. Они смотрят на произведенное влияние на систему и выполняют экстенсивные измерения.
Развертывание
- Они создают специальную инфраструктуру для управления зависимостями и развертывания.
- Цель состоит в том, чтобы иметь все необходимые сервисы развернутыми на новом оборудовании, в том числе код приложений, системы мониторинга и лицензирования и так далее.
- Результатом развертывания является виртуальная машина, которая запускается с помощью EC2.
Работа с покупателями для того, чтобы убедиться, что внедрение нового сервиса того стоит
- Фокусировка на конкретно на тех возможностях, которые планируется предоставить покупателям
- Разработчики принуждаются работать в первую очередь с упором на предоставление пользователям новых возможностей, а не на внедрение новых технологий и уже после этого осознавание того, зачем это делалось
- Все начинается с пресс-релиза о новых возможностях, предоставляемых пользователям, а после чего ведется работа по определению того факта, планировалось ли все же что-то значимое для пользователей или нет?
- Дизайн должен быть минимален. Простота - залог успеха, когда речь идет о больших распределенных системах
Управление состояниями, как основная проблема крупномасштабных систем
- Изнутри они теоретически могут предоставить практически бесконечный объем дискового пространства.
- Не все, но многие операции имеют состояния. Например, оформление покупки продукта.
- Сервис отслеживания последних открытых страниц использует рекомендации, базирующиеся на идентификационных номерах сессий.
- Они следят за всем, так что в любом случае цель вовсе не в поддержании состояний. Достаточно небольшой набор состояний требует поддержания с помощью сессий. Сервисы уже хранят всю необходимую информацию, остается лишь ими воспользоваться.
Три свойства системы или теорема Eric Brewer'а:
- Три свойства системы: стабильность, доступность, переносимость возможных распадений сети
- В большинстве случаев для любой системы с общими данными выполняются два свойства из трех
- Возможность разделения: распределение узлов по небольшим группам, которые могут иметь доступ к другим группам, но не могут получить доступ к конкретному произвольному узлу системы
- Стабильность: запишите какие-либо данные, а затем прочитайте их же - получите те же самые данные обратно. Для распределенных систем это далеко не всегда так.
- Доступность: не всегда имеется возможность произвести чтение или запись каких-либо данных. Система иногда сообщает, что она не может произвести запись, так как она хочет остаться целостной.
  - Для масштабирования системы необходимо разбиение ее на части, что приводит к выбору между стабильностью и доступностью. Необходимо найти некий баланс между ними.
  - Выберите определенный подход в соответствии с нуждами сервиса.
  - В процессе выбора продуктов приоритет предоставляется доступности: все запросы на добавление товаров в корзину учитываются, так как именно они приносят прибыль. Даже если возникают какие-либо ошибки, они скрываются от покупателя, и разработчики разбираются с ним позже.
  - В процессе подтверждения заказа покупателем важна надежность, так как сразу несколько сервисов одновременно используют одни и те же данные: работа с кредитными картами, доставка, составление отчетов.

Подводим итоги

Для того, чтобы строить реально масштабируемые системы, Вам необходимо изменить свой склад ума. Вероятностный подход к хаосу может принести неплохие результаты. В традиционных системах мы представляем себе идеальный мир, где не происходит никаких чрезвычайных ситуаций, а затем мы в этом же мире пытаемся построить реализацию по-настоящему сложных алгоритмов. При первом же удобном случае вся система гарантированно рушится, это реальность, пора бы уже к этому привыкнуть. Например, неплохим решением мог бы стать подход, использующий быструю перезагрузку и тем самым быстрое восстановление работоспособности. При достаточной избыточности данных и сервисов этот подход может дать практически 100% отказоустойчивость. Необходимо создание самовосстанавливающихся и самоорганизующихся операций.
Создание инфраструктуры, в которой компоненты ничего друг с другом не разделяют. Сама инфраструктура может стать общим ресурсом для разработки и развертывания с теми же недостатками, что и совместные ресурсы в логике и на уровне данных. Это может вызвать запирание и блокировку данных. Архитектура, ориентированная на сервисы, позволяет создание параллельных изолированных процессов разработки, позволяющих масштабировать будущие разработки для соответствия темпам роста.
Откройте систему с помощью собственной API для создания экосистемы вокруг Ваших приложений.
Единственный способ управлять большой распределенной системой - разрабатывать ее как можно более простой. Это достигается благодаря отсутствию скрытых требований и зависимостей в ее структуре. Минимизируйте использование технологий до того уровня, который Вам необходим для решения конкретно Ваших проблем и задач. Создание дополнительных искуственных и ненужных уровней в системе никогда не пойдет ей на пользу.
Организация вокруг сервисов дает гибкость. Параллельная работа возможна, так как на выходе получается сервис. Этот факт резко сокращает время, необходимое для выхода на рынок. Построение инфраструктуры позволяет сервисам реализовываться очень быстро.
Определенно будут возникать проблемы со всем, что пускает пыль в глаза еще до реальной реализации.
Для внутреннего управления сервисами стоит использовать SLA.
Кто угодно может быстро добавлять веб-сервисы к их продукту. Достаточно лишь реализовать часть продукта в виде сервиса и начать его использовать.
Построение инфраструктуры производится для обеспечения производительности, надежности и контролирования издержек. После ее построения Вы никогда не сможете сказать после очередной неудачи, что в этом виновата компания Х. Ваше программное обеспечение не всегда является более надежным, чем любой другой, но зато у Вас появляется возможность быстро устранять неполадки и развертывать ее, в отличии от продуктов других компаний.
Используйте систему оценивания и целенаправленные обсуждения для отделения "хорошего" от "плохого". Бывшие сотрудники Amazon в своих презентациях неоднократно демонстрировали свою глубоко засевшую привычку ставить покупателей перед выбором и смотреть какой из вариантов сработает лучшим образом, и уже на результатах такого рода тестов строить свои решения.
Avinash Kaushik называет это избавлением от "гиппопотамов", наиболее высоко оплачиваемых людей. Осуществляется оно с помощью A/B тестирований и веб-аналитиков. Если у вас есть выбор пути развития, реализуйте оба, позвольте людям ими пользоваться, и посмотрите какой из альтернативных результатов приведет в лучшим результатам.
Создайте экономичную культуру. Amazon использовал двери в роли столов, например.
Знайте, что Вам необходимо. Amazon имеет печальный опыт с ранней системой рекомендаций, которая не сработала: "Это было не то, что требовалось Amazon. Рекомендации книг в Amazon требовали работы с разбросанными данными, всего лишь несколько рейтингов или покупок. Она должна работать быстро. Система должна иметь необходимый масштаб для работы с массивным количеством клиентов и огромным каталогом. Все, что было необходимо: лишь усовершенствовать обнаружение книг из глубин каталога, откуда читатели не могли достать из самостоятельно."
Работа в сторонних проектах, просто так как Вы в них заинтересованы, часто является намного более продуктивной и инновационной, чем просто работа за деньги. Никогда не недооценивайте мощь блуждания в той сфере, которая Вам интересна.
Вовлеките всех в производство еды для собак. Пойдите на склад и упаковывайте книги во время рождественской суеты. Это называется командной работой.
Создайте специальный сайт для тестирования нововведений перед выпуском их в вольное плавание.
Непоколебимая, кластеризованная, реплицирующая, распределенная файловая система является идеальным решением для хранения данных, доступных только для чтения, используемых веб-серверами.
Предусмотрите способы отменить изменения, если обновление не удалось. Если нужно, напишите соответствующие программные средства.
Переключитесь на глубоко сервис-ориентированную архитектуру.
Во время интервью обращайте внимание на три критерия: энтузиазм, креативность, компетентность. Самым крупным залогом успеха Amazon.com был энтузиазм.
Наймите Боба, кого-то кто знает свое дело, обладает невероятными способностями и знанием системы, и что самое важное, умеет решать даже самые невообразимые проблемы просто нырнув в них с головой.
Инновация может прийти только снизу. Те, кто находится ближе всего к проблеме, являются наиболее вероятными людьми, кто смог бы ее решить. Любая организация, зависящая от инноваций, должна уметь пользоваться хаосом. Лояльность и подчинение - не наш метод.
Креативность должна лезть из всех щелей.
У всех должна быть возможность эксперементировать и учиться. Позиции, подчинение и традиции не должны играть какой-либо роли. Для процветания инновации балом должен править точный расчет.
Выберите путь инноваций. Перед лицом всей компании, Jeff Bezos может дать старый кроссовок Nike в роли награды "Просто сделай это" тому, кто привнес инновацию.
Не платите за производительность. Предоставьте хороший повод задрать нос и высокую оплату труда, но оставляйте это простым. Распознать выдающуюся работу можно и другими методами. Оплата по заслугам звучит неплохо, но в условиях большой организации это практически невозможно. Используйте не-денежные награды, такие как тот старый кроссовок. Если преподнести это как способ сказать спасибо, кто-то оценит.
Вырастайте быстро. Большие парни вроде Barnes и Nobel у Вас на хвосте. Amazon не был ни первым, ни вторым, ни даже третим книжным магазинам в Сети, но их взгляд на работу и драйв в итоге позволили им вырваться вперед.
В дата-центрах персонал проводит только 30% времени в работе над вопросами создания инфраструктуры, остальные 70% они проводят за размещения поставок тяжелого оборудования, управлением программным обеспечением, балансировкой нагрузок, техническими работами, изменениями в масштабе и так далее.
Запретите клиентам прямой доступ к базе данных. Это значит появление возможность масштабировать сервис и делать его более надежным не вовлекая при этом клиентов. Это очень похоже на возможность Google независимо вносить улучшения в части системы, что приводит к улучшениям в работе всех остальных ее компонентов.
Создайте единый универсальный механизм получения доступа к сервисам. Это позволяет более легко агрегировать информацию, полученную от сервисов, децентрализованно прокладывать маршруты передачи запросов, распределенно следить за ними, а также получать доступ к другим инфраструктурным механизмам.
Предоставление свободного доступа ко всем сервисам Amazon.com разработчикам со всех уголков Мира также было достаточно значимым компонентом успеха, так как это привлекло на порядок больше инноваций, чем они могли надеяться построить самостоятельно.
Разработчики сами знают какими инструментами они владеют лучше всего, какие из них делают их наиболее продуктивными.
Не накладывайте слишком много ограничений на инженеров. Предоставляйте стимулы для использования некоторых вещей, например интеграцию с системами мониторинга и другими инструментами инфраструктуры. Для всего остального старайтесь предоставлять возможность командам функционировать максимально независимо.
Разработчики, они как художники; они делают свою работу лучше всего только тогда, когда им предоставляют свободу это делать, но в любом случае им требуются качественные инструменты. Имейте много вспомогательных инструментов, имеющих само-помогающую природу. Поддерживайте окружение вокруг разработки сервисов, которое никогда не будет вмешиваться в сам процесс разработки.
Вы построили это, вы и поддерживаете. Это позволяет разработчикам почувствовать повседневную работу их приложения, а также предоставляет им постоянный контакт с покупателями.
Раз в пару лет разработчики должны проводить некоторое время в отделе по работе с клиентами. Это позволит им выслушать покупателей, ответить на электронные письма, и реально осознать влияние тех вещей, которые они реализовали с помощью как технологи.
Пользуйтесь "голосом покупателя", который являлся бы реалистичной историей от покупателя о какой-то конкретной части сайта. Это поможет менеджерам и инженерам осознать тот факт, что все эти технологии построены для реальных людей. Статистика отдела по работе с клиентами является ранним индикатором того, что вы делаете что-то не так, а также указывает на то, что реально является болевыми точками для ваших покупателей.
Инфраструктура Amazon, подобно Google, является огромным конкурентным преимуществом. Они могут строить комплексные приложения на основе примитивных сервисов, которые сами по себе просты до безобразия. Они могут независимо масштабировать свою работу, поддерживать доступность не распараллеленной системы, быстро реализовывать новые сервисы без необходимости массивных изменений в конфигурации.