2024-12-10: Александр Бындю. Антихрупкость в ИТ
Прочитал книгу Саши Бындю «Антихрупкость в ИТ», пару лет она лежала у меня в очереди. Это — очень полезная книга для тех, кто хочет и кому нужно разобраться в устройстве современных ИТ-проектов. А нужно это тем руководителям, которые выступают как заказчики ИТ-проектов или хотят завести у себя ИТ-разработку. Не факт, что они хотят в этом разбираться, но тогда это превращается в игру «повезет — не повезет», которая знакома почти всем, кто искал себе бригаду для ремонта или, что серьезнее, психолога или врача в не очевидном случае. Это не значит, что прочитав книгу, и разобравшись в ней ты сам сможешь делать ИТ-проекты. Но ты сможешь вести квалифицированный диалог с ИТ. При этом в книге — множество ссылок для тех, кто захочет разобратья глубже в конкретных вопросах.
В книге описано множество граблей, которые являются типичными в ведении ИТ-проектов. И современные методы, которые правильно применять. Прежде всего это касается организации работ, включая модель «fix time and budget, flex scope», а также техник выявления целей проекта — impact mapping, user story mapping. Об этих техниках я хочу заметить следующее: в них содержание важнее формы, однако форма гарантирует, что содержание будет адекватным. Как применение scrum при соблюдении формы гарантирует отказ от микроменеджмента, от чрезмерной специализации и еще от ряда проблем в ходе проекта. Так и impact mapping гарантирует понимание целей и ценности проекта в виде изменений в деятельности конкретных стейкхолдеров и синхронизацию этого представления между разными стейкхолдерами. Естественно, для этого использование формы должно быть не догматичным, надо понимать лежащие за ними смыслы и достигать их.
Что касается части книги, посвященных трансформации монолита в микросервисную архитектуру, то я бы к ней сформулировал следующее замечание. Эдвард Йордан в книге «Смертельный марш» пишет, что каждое новое поколение ИТ-шников уверено, что с помощью новых. современных методов оно сможет успешно делать проекты, а не проваливать бюджет и сроки, как предыдущие поколения, но эта уверенность всегда оказывалась ложной. Йордан пишет это на основании 30-летнего опыта, увидим несколько поколений, и эти слова продолжают быть актуальными. Кстати, книгу Йордана я всем рекомендую, она остается актуальной, не взирая на многократную смену технологий разработки и ее организации. Так и тут: в книге — уверенность, что микросервисная архитектура — решение проблем, не взирая на увеличение сложности общей конструкции, о которой он говорит.
Реально микросервисная архитектура появилась для того, чтобы обеспечить горизонтальное масштабирование производительности, которое не могло обеспечить железо. за счет разворачивания множества инстансов и гибкого управления этим. Заодно повысилась отказоустойчивость в целом. За это платят сложностью конструкции, и увеличение нестабильности работы при обработке конкретного запроса пользователя. И вот этот эффект от микросервисов нужен не столь часто.
Позднее был обнаружен появился еще пара эффектов. Во-первых, если разбивать на микросервисы достаточно мелко и хорошо покрывать тестами, то можно не беспокоиться, что когда-то придется разбираться в сложном коде старого сервиса, его можно будет просто относительно дешево переписать. Во-вторых, поскольку обращения между сервисами — много дороже внутренних вызовов, предусмотренная архитектурой изоляция сервисов реально присутствует в коде, это борьба с влиянием закона Конвея. При этом API можно еще проконтролировать внешними средствами на соответствие спецификации. Вот эти причины реально играют при выборе микросервисной архитектуры, хотя не всегда осознаются. Хотя закон Конвея так просто не победишь, все равно появляются микролиты — комплекс микросервисов с сильным взаимодействием.
А вот с поставкой фич — сложнее. Она возрастает только в том случае, если новые фичи преимущественно реализуются за счет изменений 1-2 микросервисов. Это сильно повышает требования к декомпозиции, и этого удается достичь не всегда. Чаще запрос пользователя отрабатывает некоторый конвейер микросервисов, и для новой фичи его надо достраивать более, чем в одном месте. Это как с бизнес-процессами при функциональной организации компании: они протекают через большое количество отделов, и реорганизация затрагивает многие.
Но если вы выбрали микросервисную архитектуру, то книга дает очень хорошее описание, как они устроены. Что важно — это описание уровня заказчика, которое позволяет обсуждать архитектуру и реализацию с разработчиками. Обсуждать — важно, потому что они за полгода сделают проект и уйдут на другой, а заказчику жить с этим годы. Так что неплохо представлять, как оно устроено, какие заложены возможности масштабирования и развития и каким образом их предполагается реализовывать, когда потребуется.
Так что эту часть книги я тоже рекомендую всем, кто выбрал микросервисную архитектуру. Или тем, кто рассматривает ее как один из вариантов — там показано, в чем вам придется разбираться.
Что касается заключительных глав, посвященных low-code подходу, различным стратегиям трансформации старой системы, а также работе с техническим долгом, то они, опять-таки, актуальны для всех проектов, независимо от того, выбрали вы микросервисную архитектуру, или какую-то другую. Кстати, если говорить про low-code, то я помню предыдущую волну визуального программирования в начале нулевых, когда многие были уверены, что разработчики сделают платформы, некоторых конечные пользователи будут собирать системы, просто двигая квадратики. BPMN-движки родились именно тогда, как одна из ветвей этого подхода. И мы тоже для наших заказчиков примерно в те годы пробовали сделать платформу, где бы логику приложения бизнес-технологи заказчика настраивали через метаданные, хотя и не визуально. Оказалось, что сложновато, настраивали наши аналитики. Правда, во многих случаях — без обращения к разработчикам. Так что скепсис Саши по поводу повсеместной применимости, которые пропагандируют авторы платформ, я разделяю. Что не означает отсутствия преимуществ, о них в книге тоже хорошо написано.
На этом — все. Книга мне доставила реальное удовольствие, и я жалею, что так долго до нее добирался.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.