Курс по SOA с Udi Dahan понравился с первого дня, хотя, собственно, до самого SOA ещё совершенно не добрались.

Первый день – back to basics. Половину дня говорили, в частности, о проблемах, стоящих перед современными распределёнными системами.

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

• Сетевые соединения надёжны.
  А случиться может что угодно: сгорит свитч, случайно перережут кабель, у провайдера будет накладка и т.д.
  
• Задержки, связанные с передачей по сети – не проблема.
  Разработчики тестируют приложения локально, тестеры – на тестлабах. Скорости там могут быть до 1000 раз выше, чем в реальной жизни. Использование lazy loading может быть бомбой замедленного действия с точки зрения производительности.
  
• Ширина канала – не проблема.
  Эффективная скорость, доступная на гигабитном канале – порядка 40 мегабайт в секунду. Это звучит не так круто, как “гигабит”.
  Если существуют столкновения между lazy loading и eagerly loading, то, возможно, речь должна идти о разных объектах?
  
• Сеть хорошо защищена.
  Нет принципиально полностью защищённых систем. Если мы обещаем полностью защищённую систему заказчику – мы врём.
  В основном проблема не столько в сети/архитектуре/инфраструктуре, сколько в людях.
  Мы мало что можем с этим сделать.
  Направления куда смотреть: периодическая смена сертификатов/ключей, моральная готовность к тому, что рано или поздно что-то случится. Бизнес должен иметь a threat model analysis, legal plan, public relations plan, стейкхолдеры должны быть в курсе такой возможности.
  
• Топология системы не изменится.
  Серверы умирают и добавляются, баллансировщики нагрузки – тоже, что-то уходит в облако, что-то переезжает в другую сеть.
  Клиенты меняют расположение и тип подключения (WiFi, 3G, LAN, WAN), могут появляться новые типы клиентов.
  Направления куда копать: не хардкодить адреса, делать конфигурацию максимально простой, автоконфигурирование/автонахождение.
  
• Админ знает, что делать в случае чего.
  Сложные конфигурационные файлы в каждом углу не лучший помощник админа. Запланированный (upgrade) и незапланированный (rollback, errors) downtime. Количество девяток в availability: 5 девяток (99.999%) – это примерно 5 минут в год. 4 девятки – это час в год. Честно планировать и документировать availability.
  Успешно применяемое решение: непрерывное обновление без downtime’а. Пример: ebay, flickr, amazon и т.д. Flickr: обновление версии на продакшне в среднем каждые 8 минут.
  Условия такого решения: обратная совместимость.
  Проблема: дольше итерация разработки –> больше проблем с обратной совместимостью –> сложнее делать апгрейд без даунтайма –> бизнес откладывает апгрейд (важные кампании, презентации, клиенты, тендеры) –> дольше итерация разработки.
  И наоборот: короткая итерация –> меньше кода –> меньше проблем с обратной совместимостью –> проще апгрейд без даунтайма –> короче итерация.
  
• Транспорт – не проблема.
  Сеть и CPU – это стоимость. Пример: сериализация/десериализация – это трата CPU. Использование “облачных” решений часто заставляет платить за CPU и тут отлично выплывает, насколько это влияет на стоимость.
  Решение: нет решения. Сеть и CPU всегда стоят денег.
  
• Система атомарна и монолитна.
  Часто говорят: stateless сервера – это путь к scalability. На практике это часто может привести к тому, что всё состояние смещается в одно место – в базу данных. И уже база данных становится узким местом. А база данных – это то, что очень сложно масштабировать вширь. Stateless серверы – отличное решение, предлагаемое производителями огромных дорогих серверов БД и гридов вроде Кохеренса :)
  От себя: представитель Кохеренса на прошлогодней YOW говорил то же самое: чем больше вы фанатично делаете stateless логики, тем больше мы имеем денег на продаже серверов БД и грида. Сам слышал. Дословно: “Самый лучший способ сделать что-то немасштабируемым – сделать это stateless”.
  
• Система закончена.
  Система никогда не заканчивается, пока жив бизнес, её использующий. Затраты на поддержку системы постоянны.
  Опытные разработчики создают новые фичи, джуниоры занимаются доработкой имеющегося кода и его поддержкой. Есть вопросы, почему многие системы со временем превращаются в один большой месс? :)
  
• Бизнес-логика может и должна быть централизована.
  Бизнес-требования не одинаковы в смысле частоты и вероятности изменения.
  Повторное использование: термин, придуманный много лет назад, не работает. Больше повторного использования –> больше зависимостей –> сильнее связанность –> сложнее изменять/поддерживать систему –> риск сломать.
  Куда копать: Бизнес-логика часто понимается “в лоб”. Объект “Customer”, имеющий поля “Name” и “Status” вовсе не обязательно является целиковым объектом с точки зрения требований. Действительно ли нам нужно одновременно управлять именем и статусом? Или это совершенно разные операции с точки зрения бизнеса? Более того, даже в реальной жизни “клиент” не имеет “статуса”, “статус” – это какая-то информация О клиенте, которая хранится и управляется отдельно.
  Вопрос: почему мы пихаем это всё в один объект и потом пытаемся пользовать его везде, создавая лишние зависимости?
  Решение: Разделять бизнес-требования по смыслу и по частоте изменения оных. Получатся “вертикальные” “независимые” срезы системы: в одном мы управляем именем клиента, в другом – статусом.
  Изменения требований, связанных с одним “срезом” не влияют на поведение других.
  Такой “срез” можно называть “design package”, в идеале он может содержать в себе все те же слои: UI, BL, DB, etc.
  Такие “срезы” можно (это не обязательно делать) размещать на отдельных серверах, развёртывать и апгрейдить отдельно, без остановки всей системы. Все блокировки и транзакции – внутри одного “среза”, избегаем распределённых транзакций!
  Ответ на вопрос: Какие данные должны изменяться согласованно (consistently, я никогда не знаю, как перевести на русский!), вместо вопроса “какие объекты у нас есть чтобы их изменить?”
  

Потом ещё говорили о том, что такое coupled code, как это измеряется, что значат эти метрики, как их применять… Потом говорили о разных видах распределённости и взаимодейтвии…

Я плохо рассказываю, потому, что было гораздо интереснее и полезнее, чем я рассказываю :) Хотя это просто заметки, 2% от того, что и о чём говорилось…
В перерывах (коих у нас три: два по 15 минут и один часовой) люди очень активно обсуждают то, что говорится на тренинге, между собой, для кого-то это совсем новые концепты, кто-то имел дело, но сейчас представилось под другим углом и т.д. Люди очень обдумывают, высказывают, анализируют. Значит отдача есть.

Я, наверное, больше не буду писать таких постов, про то, что было. Много слишком, плотность большая.

А завтра будет ещё интереснее :)

P.S. А Udi действительно замечательный докладчик.

P.P.S. В субботу Udi делает ещё один концерт (полный день), в каком-то виде это сжатый вариант его трёхдневного курса по NServiceBus. Стоимость билета - $100. Многие задумались, а не пойти ли и туда ещё. Я тоже думаю. Завтра спросим его, насколько сильно то, что будет там, перекликается с тем, что будет за неделю у нас. Может и схожу, не так уж и дорого.

P.P.P.S. А завтра – вечерний концерт Udi от YOW! Nights. Стоимость $10. Туда многие наши пойдут :)