В очередной раз приветствую читателей моего бложика.
Сегодня я спешу поделиться с вами фидбэком на преинтереснейшую книгу, ссылку на которую я нашёл в одной из статей Мартина Фаулера,-
"Release It! Design and Deploy Production-Ready Software" Michael Nygard, 2007.
Почему это важно? Вот несколько причин:
Достаточное количество паттернов и антипаттернов описываются на почти 350 страницах вполне понимабельным для обычных инженеров языком. Минимум скучных и сложных UML диаграмм, но множество рассказов из реальной жизни, как казалось бы незначительные проблемы в коде при некоторых обстоятельствах кладут на лопатки многомиллионные продукты. Каждый такой рассказ читается как небольшой детектив с убийцей, на которого бы никто и не подумал в начале.
Для прояснения некоторых вопросов автор иногда не на долго уходит в детали реализации пулов, протоколов, частей сетевой инфраструктуры, транспортного уровня, о чём лично мне тоже было интересно почитать.
В книге почти не встречается код, но иногда автор приводит небольшие куски на Java и немного говорит о некоторых нюансах в ней. То есть привязка к какому то конкретному языку тут минимальна.
Есть небольшая глава о работе по выкатке продуктов и как делать их саппортабельными для админов и прозрачными для сбора информации о работе для разработчиков. Есть намётки плана обновления всей инфраструктуры "на горячую" при выкатке новой версии.
В общем, после прочтения подмывает начать задумываться о многих вещах. Само собой тут вы не прочитаете про современные контейнеры, системы конфигурирования, но и без этого пищи для размышлений тут более чем достаточно.
Как утверждает автор книги, почти всегда ещё на стадии проектирования можно выбрать несколько альтернатив и они почти все имеют примерно равные трудозатраты, но разный профит. Конечно, бывают и исключения, но заранее впилить тот же Circut Breaker в коннекшен к каждой внешней системе, разложить таймауты на соединения, заметить Unbalanced Capacities связанных систем, вспомнить про Unbounded Result Sets когда тащите от куда то данные, специально разделить некоторые казалось бы однородные ресурсы, чтобы проблемы в одной части системы не убивали другие - это всё не требует чрезмерного усложнения системы, но на порядок повышает её живучесть.
Жаль, что подобные важные вопросы не рассматривались во время учёбы в ВУЗе.
В общем, редкая и весьма доступная книжка для тех, кому не всё равно :-)
Читается на языке оригинала достаточно быстро, чтобы не терять мысль, с минимумом излишне редких слов :-)
Сегодня я спешу поделиться с вами фидбэком на преинтереснейшую книгу, ссылку на которую я нашёл в одной из статей Мартина Фаулера,-
"Release It! Design and Deploy Production-Ready Software" Michael Nygard, 2007.
"Hope is not a design method"
В этой книге затрагиваются такие важнейшие качества программного продукта как стабильность, расширяемость, безопасность, доступность, администрирование и мониторинг.Почему это важно? Вот несколько причин:
- Современное приложение редко является изолированным. Сбоить может что угодно - от внешних ресурсов до железа. Вряд ли вы, как разработчик, хотите, чтобы недоступность какого-то не особо критичного ресурса прибивала бы ваше приложение сколько бы узлов его вы не продублировали.
- Простой в работе продукта - это почти всегда потеря клиентов и бабла. А если это ещё высоконагруженный сервис типа популярного магазина или диспетчерской службы, то каждая минута down time'а будет обходиться в какие то нереальные суммы (даже по меркам 2007 года).
- Имея предоставленные нам высокоуровневые абстракции мы часто полагаем, что все сложные проблемы за нас уже решены и что нам остаётся только самым простым образом собрать из них наше приложение. Мы не читаем документацию методов, которые используем. Special for Java dev: не обрабатываем исключения там, где это необходимо, и не понимаем их значений. Мы не делаем выводов даже после факапов на стадии релиза!
- Abstraction leak. Не понимая того, как работают некоторые вещи (будь то потоки, пулы или firewalls), бывает очень сложно понять причины проблем, которые видны только на уровне программных объектов и появляются они конечно же только на продакшене под нагрузкой и в особом окружении.
- Далеко не все просчёты можно закостылить хоть как то по мере необходимости и реализовать оперативно. Особенно это касается расширения системы, которая на ваших глазах прямо сейчас начинает задыхаться от нагрузки в проде.
- Если вам необходимо планировать закупку железа, оценивать предельную нагрузку, выдавать SLA на систему или разбираться со срочными проблемами в проде без его остановки, то без анализа результатов постоянного мониторинга его состояния это сделать практически невозможно. А создать возможность для этого самого мониторинга иногда нужно ещё на стадии проектирования.
- Как маркетинг и пользователи иногда убивают приложения :-)
- Когда вы тестируете приложение, то вы ведь наверно хотите, чтобы его результаты коррелировали с тем, что будет на проде, ведь так? :-)
- Иногда некоторые проблемы вылезают только на продакшене из-за отличия боевого окружения от тестового.
В общем, если вы не отвечаете за хороший такой, серьёзный продукт, который разрабатываете, или можете всегда списать (или переложить) проблемы на что (или кого) угодно - книжка не для вас :-)
Достаточное количество паттернов и антипаттернов описываются на почти 350 страницах вполне понимабельным для обычных инженеров языком. Минимум скучных и сложных UML диаграмм, но множество рассказов из реальной жизни, как казалось бы незначительные проблемы в коде при некоторых обстоятельствах кладут на лопатки многомиллионные продукты. Каждый такой рассказ читается как небольшой детектив с убийцей, на которого бы никто и не подумал в начале.
Для прояснения некоторых вопросов автор иногда не на долго уходит в детали реализации пулов, протоколов, частей сетевой инфраструктуры, транспортного уровня, о чём лично мне тоже было интересно почитать.
В книге почти не встречается код, но иногда автор приводит небольшие куски на Java и немного говорит о некоторых нюансах в ней. То есть привязка к какому то конкретному языку тут минимальна.
Есть небольшая глава о работе по выкатке продуктов и как делать их саппортабельными для админов и прозрачными для сбора информации о работе для разработчиков. Есть намётки плана обновления всей инфраструктуры "на горячую" при выкатке новой версии.
В общем, после прочтения подмывает начать задумываться о многих вещах. Само собой тут вы не прочитаете про современные контейнеры, системы конфигурирования, но и без этого пищи для размышлений тут более чем достаточно.
Как утверждает автор книги, почти всегда ещё на стадии проектирования можно выбрать несколько альтернатив и они почти все имеют примерно равные трудозатраты, но разный профит. Конечно, бывают и исключения, но заранее впилить тот же Circut Breaker в коннекшен к каждой внешней системе, разложить таймауты на соединения, заметить Unbalanced Capacities связанных систем, вспомнить про Unbounded Result Sets когда тащите от куда то данные, специально разделить некоторые казалось бы однородные ресурсы, чтобы проблемы в одной части системы не убивали другие - это всё не требует чрезмерного усложнения системы, но на порядок повышает её живучесть.
Жаль, что подобные важные вопросы не рассматривались во время учёбы в ВУЗе.
В общем, редкая и весьма доступная книжка для тех, кому не всё равно :-)
Читается на языке оригинала достаточно быстро, чтобы не терять мысль, с минимумом излишне редких слов :-)
Комментариев нет:
Отправить комментарий