On the way to perfect computing

Многие слышали о технологиях которые используют Google, Microsoft, Yahoo у себя внутри.
В основном, это благодаря количеству усилий, которые они тратят на популяризацию себя.
Многие другие популярные ресурсы также имеют свои технологии, разработанные in-house, некоторые со временем выпускают их в мир(как например LiveJournal’s Memcached)

Одним из таких интересных ресурсов является Amazon.com. Недавно я встретил интервью с Werner Vogels на acmqueue.com – где описывается их путь от книжной лавки к компании которая является драйвером инноваций(публичные сервисы S3, EC2,etc)

Существует два пути разработки архитектуры продуктов: при использовании первого – создается простой сервис который будет работать на одной-двух машинах.Если такой сервис выстреливает – начинается усиленная работа над масштабированием узких мест.
Второй путь – изначально закладывать требования масштабирования при разработке. Это, конечно требует некоторого опыта, но потом будет легче.

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

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

• Также важно чтобы каждая часть продукта была децентрализованной – режем продукт на части, каждую часть закрываем в черный ящик, в черном ящике пробиваем дырки – веб-интерфейсы – методы доступа к этой части. Теперь каждая часть может жить своей личной жизнью и развиваться без проблемм – ну, почти без проблемм . Таким образом мы получаем loosely coupled services model

• Очень хорошо сформулировал, что при разработке важно не создавать технологию ради технологии, а создавать технологию чтобы помочь заказчику. Ведь технология без пользователей бесполезна

• У них большая экспертиза в отслеживании поведения пользователя. При вводе новых фич они отслеживают фидбек через изменения в поведении пользователей – некоторые фичи люди начинают исопльзовать сразу же, другие отвергают сразу же, к некоторым необходимо им привыкнуть – такие случаи отслеживать труднее… В лубом случае – для он-лайн сервиса мониторинг действий пользователя, профайлинг своей системы при этом – очень хорошая идея.

В заключение, приведу список challenges которые привел Вернер – он мне понравился полнотой описания:
larger data sets, faster update rates, more requests, more services, tighter SLAs (service-level agreements), more failures, more latency challenges, more service interdependencies, more developers, more documentation, more programs, more servers, more networks, more data centers.

Полная версия статьи здесь