7 стадий развития веб-приложений

это отредактированный перевод со слайдов презентации тов. John Engates
формат: номер слайда, краткое содержание и (мои редкие каменты)

1. Этапы становления веб-ресурсов
   автор: John Engates
2. Регламент:
   
   • Что мы ждём от веб-приложений
   • Как это бывает
   • Неплохие примеры
   • Вопросы и ответы
     
     
3. Чего мы ждём от сайтов
   
   
   • Масштабируемость
   • Высокая отдача
     
   • Эффективность
   • Простота управления
   • Низкая стоимость (обслуживания, в том числе)
   • Изобилие рюшечек Богатый функционал
   • И что он будет нам делать бабло, много бабла!
   
   Это и есть семизначная мантра клиента-директора, думающего о заказе корпоративного сайта
4. Высокая готовность. Определение:
   Высокая готовность (High Availability HA) — это такой подход к проектированию и реализации, который бы гарантировал известную степень уверенности в их (проектирования и разработки) непрерывности. Так-то!
   Как это выглядит на примерах:
   
   • ваш сайт всегда работает и доступен
   • юзеры счастливы
   • вы не теряете денег из-за технических простоев
   • (и это не увеличивает затраты на обслуживание сверх необходимого)
   Это была мантра техдира проекта
5. Что на самом деле называется масштабируемостью
   Масштабируемость (расширяемость) — это ожидаемое свойство системы, которое показывает её возможность к росту доходов в приятной форме, или легко наращивать функционал по необходимости
   (Дядька загнул круто. Я реально запарился с переводом. Короче, масштабируемость — это способность системы к расширению и росту. Ну и увеличению доходности, да)
   Вариант от pika здесь
   
   Чем не выражается масштабируемость:
   
   • чисто наращиванием мощностей (2МГц -> 3МГц)
   • чем-то вроде операционных систем (Solaris vs Linux)
   • особенностью софтовых технологий (Java — Python — Rails)
   • особенностями платформ (Intel — AMD)
   • оптимизацией кода (10 строк против 1000, утверждает этот дядька, ничего не решает)
   • выбором технологии хранения (SAN vs NAS)как я и догадывался, это разные инфраструктуры хранения данных. см. каменты ниже
   
   
6. большими красными буквами
   
   РАСШИРЯЕМОСТЬ И ПРОИЗВОДИТЕЛЬНОСТЬ — НЕ ОДНО И ТОЖЕ
   
   
7. картинки с примерами
   красивые машинки, автомобильные развязки и писсуары
8. картинки
9. картинки
10. картинки
11. картинки
12. картинки
13. Истина первая:
    
    Ничто не может множится, если таковым не спроектировано.
    (Вариант: Ничто не может быть масштабным, если не спроектировано масштабируемым.)
    
    
14. Истина вторая:
    
    Если что-либо было спроектировано как конструктор, может наращиваться без проблем.
    Вариант от pika: Даже если система спроектирована под масштабирование, все равно это будет больно.
    
    
15. Очень интересная картинка «шкала боли» (игра слов с предыдущими пунктами scaling — scale, в адекватном переводе затруднился)
16. Типовые сценарии развития
    
    Этап 1. Начало
    
    • Простая архитектура
      — файрвол и балансировщик
      — пара веб-серверов так и написано, не приврал
      — сервер БД
      — внутреннее хранилище
      
      
    • Невеликая сложность и проблемность, быстрая разработка, богато фич разного рода и всё быстро
    • Никакой избыточности (втч и в рабочей силе), низкая стоимость работ — прекрасный стартап!
      
      
17. Этап второй, всё тоже самое, но чуть-чуть по-больше
    
    • Успешное ведение бизнеса — залог хороших отношений с законом
    • Добавим немного файрволов и балансировщиков
    • Добавим чуть больше веб-серверов для производительности
    • Устаканим схему БД и соптимизируем её с помощью DBA (консультанта)
    • Добавим баз
    • Переведём хранилище на SAN или DAS
    • Всё ещё просто, подходит для перспективных приложений
    
    
18. Этап третий — Первые симптомы
    
    • Публичность
    • Устанавливается Squid или Vanish в режиме обратных прокси, или очень хороший балансировщик — для кеширования статичного контента
    • Добавляем ещё сколько-то веб-серверов (управление контентом уже доставляет немалый головняк)
    • Единственная БД не будет разделена когда-либо (раздельные операции чтения-записи имеются в виду — вся запись ведётся на единственный мастер сервер с несколькими вторичными серверами для чтения)
    • Может возникнуть необходимость чё-нить переписать в приложении
    
    
19. Картинка «Расширяемость применительно к серверам баз данных»
20. Этап четвёртый — Боли усиливаются
    
    • Кеширование на memcache
    • Репликация не работает для всего (единственная база для записи — много баз для записи — результат: репликация работает долго)
    • Приходит осознание необходимости разделения баз (конечно же, если ваша БД поддерживает этот механизм)
    • Приходит осознание распределённых хранилищ для контента
    • Необходимо серьёзное преобразование архитектуры приложения и базы (а разрабы могут не обладать подобным скилом)
    
    
21. Этап пятый — Реально головняк!
    
    • Приходит м-р Паника и остаётся у вас жить.
      Разве мы не могли сделать всё это раньше? (Список этого:
      — Полное переосмысление приложения\бизнес-модели
      — И почему мы не запланировали расширяемость системы на момент принятия решений по архитектуре? )
    • Невозможность делимости как фичи приложения — что ещё мы можем использовать? (Варианты
      — Разделение основанное на географическом принципе, по фамилии, по userID, etc
      — Создание кластеров пользователей (пользовательская кластеризация)
    • Поведение приложения должно быть идентично на каждом пользовательском кластере
      
    • Использование стурктуры хешей или мастер-сервера БД для определения какого пользователя на какой кластер подключить
      
      
22. Этап шестой — Приход, мал-мала полегчало
    
    • Расширяемая архитектура приложения и базы
    • Удовлетворительное быстродействие
    • Снова можно добавлять новую функциональность
    • Оптимизация чего-нибудь в коде
    • Продолжаем расти, но теперь вполне управляемо
    
    
23. Этап седьмой — Исход в неизвестность
    
    • Где нас ещё поджидают узкие места?
      — Обеспечение питанием, площадь размещения
      — Каналы и прочее — насколько велик ваш хостер?
      — Проблемы систем защиты и балансировщиков нагрузки
      — Хранилища данных
      — Люди и проблемы
      — Технологические ограничения расширяемости баз данных — всё ещё хотите хранить данные по схеме ключ-значение?
    • Что там насчёт «все яйца в одну корзину»?
      — один датацентер
      — одна копия данных
      — проблемы репликации данных и балансировки по географичекому принципу
    
    
24. Добрые советы
    
    • Не изобретайте колесо, скопируйте у кого-нибудь другого
    • Думайте просто
      — Все вещи, сделанные проще некуда — не так уж просты. — А. Эйнштейн
      
    • Думайте горизонтально… не вертикально… в любых случаях (может, это идиома какая?)Насколько затратно? — вместо — Насколько быстро?
    • Используйте подходящее обеспечение и оборудование
    • Решайте проблемы легко и просто
      — Приводите планы в действие
      — Разделяйте различные сервисы
      — Не проводите много изменений за один раз (это называется итеративность)
25. Ещё немного добрых советов
    
    • Не тратьте времени на оптимизацию оптимизации («Преждевременная оптимизация преждевременна» ©#phpclub@undernet.org)
      — Возьмите вашу [правильно спроектированную] архитектуру, часто подстраивайте решения [под неё], и редко оптимизируйте (или никогда)
    • Проверяйте возможности к расширению подходящими нагрузочными тестами
      — Сделайте это привычной практикой до того, как вы начнёте думать об их необходимости
    • Используйте кеширование до того, как почуствуется необходимость
    • Много памяти и 64-битная платформа помогут вам (Use the Force, Luck! :)
    • Проверяйте новые возможности до того, как выбор между производительностью и масштабируемостью станет проблемой
      — Nice to have vs. have to have. И будет вам щасте:)
      
      
26. Изменения и доступность сервиса
    
    • Нельзя недооценивать необходимость правильной постановки технологического процесса и документирования
    • Управляйте релизами!
      — Разработка — тестирование — выпуск
      — Наличие методик проведения этих действий
    • Используйте системы контроля версий
      — Понятно, да: RCS, CVS, Subversion
    • Отслеживайте выпуски (короче, issue tracking — добрый совет использовать трекинговую систему. имхо помощь в разработке оказывают специализированные системы багтрекинга, а не хлам типа trac — у него другие задачи. Если и использовать систему контроля, то это должен быть комбайн, в котором прозрачно отслеживаются таймлайны, что-то типа eGroupWare. этот совет дополняет предыдущий)
      
    • Используйте стандарты кодирования
    • Управляйте изменениями
      — Планирование — тестирование — реализация
      — Это критично для инфраструктуры с высокой готовностью (HA)

Дальше там реклама и спасибы.
конец

первый перевод здесь
переводил, т.к. тема интересна; оказалось более 1000слов, более 7500знаков. могу сделать статью, и продать! :) если найдутся покупатели. ничего особенно нового не узнал. надеюсь, кому-нибудь окажется полезным