Статья посвящена анализу и сравнению двух моделей построения систем — монолитной и с разделением на микросервисы. В ней мы с разных сторон оценим оба этих подхода и связанную с ними сложность, убедившись в превосходстве последнего. Представим микросервисы и прочие архитектуры в реалистичном свете, не воскрешая то, что должно оставаться мёртвым.
Писатель ужасов Г. Ф. Лавкрафт в своём коротком произведении «Nameless ciry» приписал безумному вымышленному поэту эту ставшую известной цитату:
That is not dead which can eternal lie / And with strange aeons even death may die.
Если нечто может бездействовать вечно, не значит, что оно умерло / А в течение неопределённой вечности даже смерть может оказаться конечной
Да, здесь и сейчас я позволю себе отнести эту фразу к монолитам (и прочим явлениям), а не вымышленным богам, спящим в океане в предвкушении поглощения человечества.
Эта статья представляет размышления и по своей сути сугубо субъективна. Если вас интересует более технический, объективный подход к конкретным решениям и тематическим обсуждениям, то рекомендую обратить внимание на эти прекрасные книги:
- Fundamentals of Software Architecture: An Engineering Approach
- Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures
- Building Microservices: Designing Fine-Grained Systems
Определение: микросервисы не обязательно нужно приравнивать к Kubernetes. По крайней мере, для меня это совершенно другое. Более чистой реализацией микросервисов я нахожу архитектурный шаблон «функция как услуга» (FaaS, Function as a Service) хотя в этой статье термин «микросервис» нужно представлять как можно обобщённей.
Последняя оговорка: я не буду выступать против монолитов в тех случаях, где они рационально уместны, например, в очень ограниченных/небольших масштабах, прототипах, по причинам безопасности и в аналогичных контекстах. И хотя монолиты определённо могут выступать допустимым архитектурным стилем, нельзя пренебрегать анализом проблемы, которую ПО должно решать, атрибутами качества и пониманием области, в которой это ПО действует.
Проверка на соответствие действительности:
В прогрессе нет неизбежности.
Многие неудачные идеи часто возвращаются после того, как они были достаточно долго скрыты.
Одна из таких идей – монолиты. Как и любая другая идея, даже они с определённой позиции нужны. И я хочу, чтобы вы поняли меня правильно. Существуют совершенно рациональные причины для их ситуативного использования – тем не менее здесь я буду рассуждать о том, что считаю основной проблемой:
Проблема монолитов значительно шире чисто технической стороны (то есть одной развёртываемой единицы) и становится следствием отсутствия логического разделения задачи, ведущего ко вторичным проблемам, таким как неудачное определение масштабов работ и сложности с коммуникацией.
Как мы умудрились оказаться в такой ситуации?
▍ Синтаксические оковы и золотые молотки
Представьте себе человека, только что окончившего колледж, какую-то программу или даже просто самоучку, который теперь готов начать работать с ПО «профессионально», что бы это не означало в современном мире. Он знает весь синтаксис одного или нескольких языков. Но может ли он проектировать? Скорее всего, нет. Знания синтаксиса недостаточно для создания ПО.
Если я запихну весь код в ящик, окажется ли это правильным в любом случае?
Архитекторы-строители могут жаловаться, что большинство начинающих ознакомляются с чертежами строительства недостаточно тщательно, что ведёт к медленной цепочке обратной связи и замедляет освоение профессии. Разрезание ленточки при запуске дома – это роскошь, которую могут себе позволить немногие и не очень часто.
И я по факту не сильно верю в архитекторов ПО (как в должность) – их даже нет во многих крупных технологических компаниях – но я твёрдо верю в архитектуру ПО и его проектирование.
Хотя искусство проектирования ПО уже утрачено, даже в эпоху, когда мы начали создавать программные продукты невероятно быстро.
ПО не ограничено физикой подобно зданиям. Оно ограничивается лишь воображением, проектом и организацией. Если коротко, то оно ограничивается возможностями людей, а не возможностями мира. «Мы встретились с врагом, которым оказались мы сами». — Мартин Фаулер, «Who Needs an Architect?»
ПО является результатом социо-технических процессов. Оно не создаётся в ходе одного только программирования. Здесь можно вспомнить закон Конвея и то, как:
«любая организация, проектируя систему (определяемую в широком смысле), будет создавать дизайн, структура которого будет копировать структуру коммуникации внутри этой организации».
Было бы легко провести здесь некую параллель с микросервисами. Что, если проблема не в технологии? Лично для меня абсолютно логично утверждение, что многие организации и люди, решительно отвергающие микросервисы, никогда не оказывались в успешных условиях. Я считаю, что в подобных организациях зачастую наблюдаются тенденции к научному менеджменту (тейлоризму), «линейно-функциональной организации» и созданию не до конца соответствующих стандарту продуктов. Всё это по причине отсутствия диалога с потребителем, использования «метрик тщеславия» и принятия решений на основе мнений самых высокооплачиваемых сотрудников. Звучит грубо и несправедливо? Так всё было устроено в большинстве компаний, где мне довелось работать, и о которых я слышал.
Испытывая боль, дискомфорт и неудачи мы, как это характерно для людей в целом стремимся замкнуться, замереть, смиряемся и прочими способами закрепляем те модели поведения, которые нас к этому ведут. Мы будто отказываемся от тех же убеждений и знаний, которые в противном случае используем. И здесь раздаются обезумевшие крики: «Всё это из-за микросервисов, верните мой золотой молоток!»
Учитывая, что «мы не можем решить проблемы, используя ту же модель мышления, с помощью которой их создали»—утверждение, которое принадлежит, возможно, Альберту Эйнштейну – не будет ли полностью адекватным ответом на сложность микросервисов, облачных структур и всему этому ажиотажу возвращение к чему-то «простому», что «работало»? Так что давайте подумаем о том, почему монолиты могут быть столь привлекательной идеей (или протоптанной тропой) в современном мире ПО.
▍ Нет, монолит всё равно не решение
Камиль Гржибека написал прекрасную статью по теме модульных монолитов. Но я хочу оспорить идею о том, что для этого необходим монолит – монолит лишь добавляет боль в принципы построения структуры и декомпозиции, которые в ином случае работают очень хорошо. На деле вы также можете встроить черты подобной архитектуры в конфигурацию по шаблону «функция как услуга». Из важных общих моментов в наших с Камилем подходах можно выделить то, что с помощью продуманной программной архитектуры (то есть модулей) можно разделить систему на хорошие логические элементы, и его проект на основе DDD (Domain Driven Design, предметно-ориентированное проектирование) хороший тому пример. Это здорово.
Следовательно: если вы ненавидите микросервисы, то упускаете суть.
Микросервисы не обязательно должны означать, что каждая Лямбда (или любая FaaS, которая придёт вам на ум) является полностью самодостаточной, свободно движущейся платонической вселенной без сложных модульных/ориентированных на классы взаимодействий – мой DDD-проект Get-a-Room и моя онлайн-книга по DDD показывают насколько. И они не развёртываются принудительно в космосе как спутники – они являются частью некоего контекста, обычно сервиса, с его собственными интерфейсами.
Если реализовать это разумно и аккуратно (как указано в ссылках), вы получите независимую возможность развёртывания, меньшую поверхность ошибок и более точное инфраструктурное отражение вашей системы, не прибегая к монолитной реализации – то, что Камиль правомерно называет единственным истинным свойством «монолитных» систем.
И даже в этой монолитной модели вы наверняка используете асинхронную коммуникацию с шинами сервисов/событий и прочие приёмы для передачи команд и запросов в другие модули. И именно здесь я нахожу иронию – как это не оказывается более логичным и естественным в ландшафте FaaS?
Модульный монолит – это лишь одна развёртываемая единица, но с хорошим отчётливым разделением кода. Конкретно в нём нет ничего плохого, но теперь мы устремляемся к смешиванию инфраструктурной части с фактическим кодом приложения – что уже нехорошо!
Высокоуровневое представление относительного перехода от плохого к хорошему монолиту, а затем к фактическим микросервисам
Перевод:
1) Связывание конкретной реализации с абстрактным «контекстом». Невозможно отделить «контекст» от развёртываемой единицы.
2) Частичное разделение деталей конкретной реализации друг от друга. «Контекст» и развёртываемая единица по-прежнему находятся 1:1.
3)Полное разделение (кода) по деталям реализации. Теперь «контекст» полностью абстрагирован и гибок.
Позвольте мне быть честным и указать на кое-что немного болезненное: как уже упоминалось выше, те же люди, которые терпят неудачи с микросервисами, зачастую также терпят их и при использовании своей «современной» архитектуры, своей системы коммуникации, при разделении обязанностей… Ведь что такое микросервисы, как не просто инфраструктурное представление этих же, пусть и более абстрактных, концепций? Отчего вдруг с модульным монолитом, да и любым другим, будет легче работать или понимать его, чем нечто, что ясно определено, независимо и семантически дифференцировано?
Микросервисы, в сочетании с обычной логической декомпозицией и проблемно-ориентированным проектированием, могут сделать ваше решение намного более экспрессивным без огромного объёма лишних издержек. Это не так уж сложно.
Иными словами, мне интересно:
Как может одна огромная неопределённая хреновина представлять более удачную архитектуру в сравнении с небольшой грамотно определённой хреновиной?
Мне реально интересно.
Намного более сдержанным подходом здесь, естественно, будет напомнить самим себе о 8 заблуждениях распределённых вычислений и всех способах, которыми сетевые коммуникации могут дать сбой. Добавляя дополнительную зависимость в сеть, мы делаем её в целом более медленной и хрупкой. Это верно отчасти, но каждая архитектура тоже представляет «наименее худший» вариант, поэтому даже человек крайних взглядов должен иметь возможность выбирать, что будет более (или менее) важным – наличие разделения обязанностей, независимой инфраструктуры и возможности развёртывания или же их отсутствие.
▍ Высокая сложность = медленная смерть
По молодости меня ввели в заблуждение, что основной сложностью ПО является математика или нечто похожее и пугающее, что я ненавидел. Намного позже я понял, что это не так – основная сложность по своей природе лингвистическая и процессуальная. Учитывая, что большинство ПО является корпоративным или создаётся для бизнеса, то значительным аспектом является точный и качественный перенос процессов в код.
Поэтому если кто-то также ошибочно считает, что «сложный код» обуславливается «алгоритмами» и «загадочными чёрными ящиками», то я с радостью это заблуждение развею. Хороший код должен, по меньшей мере быть понятным в синтаксисе и структуре (дизайне системы и архитектуре приложения), а также включать достаточный объём грамотной документации, объясняющей и визуализирующей процессы, которые в самом коде неочевидны.
Хороший код примитивен, скучен и предсказуем.
Без лишнего погружения в разбор «плохого и хорошего» кода отмечу лишь, что есть множество средств, которые окажутся полезными для понимания сложности ПО – такой как цикломатическая сложность и зацепление. Могу с уверенностью сказать, что за всю свою карьеру я гораздо чаще использовал степень бакалавра по английскому языку (и полученные гуманитарные знания), чем любой из освоенных мной технических навыков, поскольку этот опыт значительно упрощает решение семантических и организационных проблем.
Сгенерировано с помощью DALL·E. Запрос: an oil painting in the style of the old masters with the devil sitting with a hooded cloak, wrapped and surrounded by snakes made of spaghetti engraved with programming code (картина маслом в стиле старых мастеров – дьявол сидит в плаще, окружённый змеями из спагетти, на которых выгравирован код).
Спагетти-код – это промысел дьявола, и он говорит не только о плохом программировании, но также о пренебрежении и непонимании того, что фактически с его помощью моделировалось. Уверен, что есть должности, на которых трудятся одарённые математики-алгоритмисты и учёные по данным, которые используют «программирование» в широком смысле слова, но не в ориентированном на процессы или социо-техническом контексте. Для остальных же из нас, кто создаёт подобные системы, спагетти-код представляет самое страшное, чего стоит бояться.
Слова обозначают определённые вещи, и если вы этого не понимаете, то должны пересмотреть свою профессию. И мне больно осознавать, что автору классической книги «Clean code» пришлось сильно углубляться в эту тему, чтобы всё прояснить.
Причём наиболее важными словами являются требования или некий аналогичный принцип, используемый вами.
Современные организации вполне могут попросить сотрудников создать что-то не до конца понятное, а инженеры ПО легко могут сказать, что они не могут что-либо протестировать, потому что не знают, как это должно работать (даже если они сами это создали). И это не сложность – это глупость. Иначе такое не назовёшь.
Вследствие недостаточного понимания этой фактически наблюдаемой сложности/глупости, отчасти возникшей в результате отсутствия полноценных или логичных требований, многие организации считают, что разработчики смогут решить (бизнес) сложность на основе любой информации, хорошей или плохой. Увы, это не так.
Типичным заблуждением является предположение, что авторы непонятного кода каким-то образом смогут ясно выразить свои мысли в комментариях.
Корпоративное ПО никогда не может превзойти моделируемый предмет и уровень, на котором он представляется. Индивидуальная способность к осмысливанию, компетентность, внимание и прочие факторы снижают изначальную ценность этого предмета, как только процесс реализации и поставленные требования сталкиваются с реальностью. Так что лучше быть к этому готовым.
Недавно я наблюдал подобное поведение, называемое «логическим долгом», которое прекрасно отражает то, о чём я говорю.
В теории мы вроде как легко можем говорить об имманентной сложности – природе самой проблемы – но в реальности она таким образом не раскрывается. Вместо этого в качестве вторичного эффекта возникает усложнение или, возможно, даже значительная побочная сложность, привносимая со стремлением всё исправить. В результате создаётся ещё больше проблем. Поэтому вместо того, чтобы сохранять чистоту и нацеливаться на корень проблемы (так как мы не можем её полноценно определить), мы уступаем перед искусственной срочностью и прочими вещами, создавая тем самым логический и технический долг.
Возможно, вас заинтересует моя статья по теме технического долга:
Так что реально важный вопрос звучит так: «Неужели мы тоже излишне всё усложняем?» Усложнение, в противоположность сложности, представляет класс проблем, имеющих известные, предсказуемые решения. Не являются ли микросервисы более усложнёнными? В некоторых аспектах да. Хотя не обязательно, если вы используете FaaS или аналогичные подходы. Но при этом вы, естественно, получаете и преимущества.
Пожалуй, самым значимым плюсом микросервисов является то, что они помогают хорошо понять закон Галла:
Сложная работоспособная система всегда развивается из простой системы, которая работала. Сложная система, спроектированная с нуля, никогда не работает и патчами не исправляется. В итоге вам необходимо начинать заново с простой рабочей системы.
Небольшие, «примитивные», вещи работают, естественно, когда у них есть чётко определённые ответственности. Я, как вы уже поняли, утверждаю, что эффективнее использовать для разработки и развёртывания более явный и семантический, лишённый двусмысленности, подход. Как раз микросервисы и позволяют вам его реализовать.
Из-за грубых характерных для монолитной базы кода ограничений такие решения оказываются логически более уязвимы к внесению побочной сложности. Давайте также посмотрим в глаза реальности и поймём, что сложность – это не просто «небольшое трение», она может стать концом вашей работы, карьеры и даже жизней других людей. Число проектов, которые терпят неудачу из-за сложности (включая побочную сложность в результате неудачного планирования, коммуникации и так далее), настолько велико, что сложно даже выбрать примеры. Но ради интереса предлагаю обратить внимание на следующие:
- Windows Vista;
- крушение Boeing 737 Max;
- функциональность автономных автомобилей Tesla;
- система здравоохранения Великобритании;
- катастрофа космического шаттла NASA Challenger;
- «глюк» в Knight Capital Group, стоивший $400M+;
- шведская образовательная платформа «Открытая школа»;
- любые реализации SAP (если верить моим источникам).
Судя по числу анекдотов и различных историй из интернета, в действительности неудачу терпит большинство проектов ПО, что для меня выглядит достаточно правдоподобным.
Дополнительно по теме сложности рекомендую почитать классическую работу Фреда Брукса «No Silver Bullet: Essence and Accident in Software Engineering» (1986) и ознакомиться с концепцией Cynefin.
Сложность не является абстрактной, она осязаема. Спросите любого, кто пишет код.
Насколько мне известно, инженерное искусство стремится к сокращению числа неизвестных и сложности. Если в итоге этого не происходит, то это уже не инженерия. И сокрытие деталей системы в неопределяемом чёрном ящике лично для меня явно выглядит неудачной идеей.
Таким образом, монолит заключает в себе стремительный регресс. Нацеливаясь на простоту, он по своей сути не может справиться с обработкой нарастающей сложности. Естественно, в монолите вы получаете меньше швов, но они нужны, чтобы разделять, именовать и идентифицировать различные нужды. Именование является одним из двух «трудных аспектов» в компьютерной науке, и при этом всё равно не таким трудным, как проектирование ПО. Здесь вам необходимо именовать, разделять и дифференцировать множество элементов, переходя от чана со спагетти к микросервисам. Да, может быть проще в некотором смысле развернуть монолит, но каждое изменение в нём может влиять на всё остальное. Это плохо.
При этом будет недальновидным использовать такие сравнения, как «Ну мы же не Netflix» или «У нас не комплексная система». Дело в том, что практически всё в сфере вычислений является распределённым – то есть у вас уже есть распределённая система.
Монолиты обладают техническими свойствами, отличными от микросервисов, но болевые места последних особо досаждают некоторым специалистам из-за неразрешённой сложности и нечётких ментальных моделей. По Фрейду нападки на микросервисы можно также воспринимать как замашки агрессоров, объясняющие, чего им самим не хватает.
Люди и их коллективы (то есть команды) являются центральным аспектом модели DevOps. Чисто логически ничто не указывает на то, что всеми микросервисами не может обладать и управлять одна команда. Разногласие возникает, когда речь заходит о распределении всего. И я задаюсь вопросом: «Почему это должно быть проблемой – создавать системы с границами и просить людей отвечать за разные части?»
То же касается тех, кто жалуется, что микросервисы плохие или трудные, так как могут потребовать (?) совместного развёртывания изменений – вы полностью упустили важнейшую работу по изолированию вашего сервиса. Это не проблема микросервисов, это ваша проблема.
Так что, может, пора менять своё мнение? Жёсткий факт: если ваша организация неспособна адаптироваться к конкретным, в основном непересекающимся продуктам/возможностям/принципам, тогда да, с микросервисами будет нелегко. Но они всё равно могут оказаться более удачным решением (в качестве переходного этапа), чем грязевой ком монолита, так как вы получите описанные выше преимущества, в которых я не сомневаюсь. Это вполне может того стоить.
▍ Утрата языка и последствия
Мы слишком много думаем о ПО и слишком мало о всём, что его окружает.
Код предназначен для решения проблем. Если мы не сможем изложить задачу и желаемое состояние, то не должны (даже не можем) предложить и создать для неё решение.
Я бы сказал, что ошибки в управлении и проблемы с процессами возникают в результате использования решения без полного понимания задачи и учитывания того, что всё со временем меняется.
Если, не дай Бог, код реально станет проблемой, то мы окажемся в глубокой ж*пе, окружённые вдвое бо́льшим числом проблем. И это произойдёт по логике вещей, поскольку код делает «что-то», но это «что-то» ещё нужно определить (примечание: не в положительном «гибком» смысле).
И «бизнес» никогда не будет жаловаться на первую «неизвестную/непостижимую» проблему (которая осязаема), только на новую, которую вы только что создали, стараясь быть «хорошим мальчиком» и качественно делать свою работу.
Это вы в образе хорошего мальчика. Печально, но хороший мальчик, тем не менее, делает лишь то, что ему велят. А вот книжка, которую можете почитать своей собаке.
Рассмотрим более широкую картину.
Я считаю, что отчасти такое положение дел вызвано недостатком обучения людей в нашем обществе критическому и рациональному мышлению. Наша система образования также не обеспечивает качественную подготовку бизнес-аналитиков, инженеров и прочих IT-специалистов. Отлично по этому поводу написал Джим Ахо в своей статье.
Меня сильно пугает то, куда катиться наша система образования. Утрата критического мышления, соответствующих контексту действий и инициативы, утрата языка (плохая грамматика = плохой код, и это вполне реальная проблема) никак не повышают статистическую вероятность создания эффективных организаций, «вещей» и решений для жизненных проблем.
И сфера Big Tech согласна, что эти навыки важны, о чём писала Ирина Станеску на LinkedIn:
За свою 14-летнюю карьеру на должностях в крупных технологических компаниях, таких как Google и Uber, из всех навыков я чаще всего использовала письмо. И нет, я не имею ввиду написание кода. Я говорю об английском письме. Электронные письма, диздоки, презентации, обратная связь, код-ревью и так далее.
Подобно Данте, всё глубже спускающемуся в ад, мы видим всё больше свидетельств этого падения и его влияния на разработку ПО. Основным примером такого положения дел являются давние идеи, которые от замысла переносятся никак не к реализации, а только к пунктам Powerpoint и срочным «целевым группам», которые создаются, а затем просто распускаются. Принятие плохо обученных людей, которые едва справляются со своими управленческими обязанностями, представляет настолько удручающее состояние, что даже его оценки в финансовых убытках будет недостаточно.
Я приведу вам пару личных примеров, пусть даже и не столь экстремальных.
▍ «Простая» мега-задача
Я помню, как много лет назад пытался объяснить Kanban своему коллеге, который работал на стороне проекта/продукта. Немного поразмыслив, он сказал:
«А нельзя это просто объединить в один пункт: выполнить задачу?»
▍ Схема с чёрным ящиком для решения всех задач
Однажды мне пришлось буквально обозвать представленную на рассмотрение «архитектуру» «диаграммой Дональда Дака», так как она должна была отражать ключевую функциональность, но по факту едва дотягивала даже до мультяшной зарисовки. И я не горжусь этим своим заявлением, но где-то нам приходиться проводить линию между искренностью и учтивым киванием, ведущим к провалу. Сроки поджимали, а великие умы придумали вот это?
В стремлении исправить ситуацию мы с тех пор продумали и наладили работу этой ключевой области, а сам тот случай просто стал напоминанием, что плохие вещи случаются, когда к самостоятельной работе допускаются не те люди. Было бы приятно узнать об этой обратной стороне медали из всех этих беззаботных исследований DX (Developer Experience, опыт разработчика).
Примечание: это не оправдывает ARB* или ITIL*, но чёрт побери – некоторым людям реально нужно менять карьеру.
Architecture Review Board – ревизионная комиссия по архитектуре.
Information Technology Infrastructure Library – библиотека инфраструктуры информационных технологий.
Без знания языка и сопровождающих навыков/организации/структуры никак не получится решить эту дилемму со сложностью. Я ещё не встречал профессионала, умеющего выражать области, модели, границы и технические интерфейсы, который после налаживания работы микросервисов захотел бы вернуться к монолитной архитектуре (хорошим контр-примером является случай с Amazon Prime).
К тому же я редко вижу критику, которая адекватно – или в принципе – демонстрирует какие-либо познания профессиональных особенностей, описанных в основной литературе по нашей профессии. Просто невозможно узнать, как люди готовились к использованию микросервисов, но для меня немыслима сама возможность этих их провалов, проделай они всю необходимую подготовку (как я уже неоднократно говорил).
Возможность работать с микросервисами и современными распределёнными архитектурами, как всегда, основывается на вашем применении навыков, которые всегда были частью обязанностей инженера ПО. Этой широты и «грамотности» нам не хватает сейчас, когда в результате 10-15 лет ультра-нишевых должностных обязанностей и 6-недельных программ подготовки к IT-профессии индустрия оказалась в упадке и заполнена людьми с низким уровнем навыков, а также страдающими от всего этого организациями.
Я имею ввиду следующее: вы увидите, что крупные технологические компании много внимания уделяют вашим социальным, а также литературным навыкам, выражающимся в код-ревью, проектировании систем и аргументировании возможных решений. А вы нет? Создание распределённых систем в 2023 году уже не является чем-то «уникальным». Всё это несложно освоить, но бо́льшую часть из этих навыков вы получите не за клавиатурой. Клавиатурный воин-интроверт – это не тот образ, который предполагался для инженера ПО.
Кто-то должен в чём-то проявить инициативу: почему, чёрт возьми, наши организации и кадровики принимают всё это? Утрата грамотности и всех этих важных общечеловеческих качеств в результате тупого набора синтаксиса понижает наши шансы на получение достойной профессии. Роберт К. Мартин даже писал о разработке ПО, как о не заслуживающей называться «профессией» в строгом смысле слова. Ведь, в конце концов, чем конкретно мы овладеваем? Я думаю, этот вопрос уместен, когда мы с трудом справляемся с масштабной «инженерной» частью в плане нашего взаимодействия со стейкхолдерами.
▍ Напоследок: более простое будущее
Сложность и индустрия самосовершенствования в некотором смысле похожи. Иронично, но книги о самосовершенствовании или тонко завуалированные программы (даже что-то безобидное вроде Bullet Journal) будут преподносить некую ключевую ценность или достоинство как желаемое, сообщая что именно это конкретное руководство «раскроет» вам, как можно, следуя программе, получить это желаемое – время, деньги, энергию, сон, стройное тело, что угодно.
Согласно свойственному нам стайному и банальному человеческому поведению, мы будем планировать и структурировать эту необходимую работу, следуя нашей новой философии жизни или смутному сиюминутному порыву. А ведь большинство книг по самосовершенствованию в действительности не работают. Я считаю всё дело в том, что во многих случаях их авторы действительно верят в свою программу – для них она сработала! Возможно, она сработала и для некоторых других. Но суть такова, что психология – это поистине сложная (в реальном своём смысле) штука. То, сработает она для вас или нет, тоже будет в основном определяться удачей, настойчивостью и тем, что лучше подходит именно вашей личности.
Большинство программ заявляются как простые или нечто в таком духе, чтобы это вписывалось в контекст. Тем не менее они лишь нацелены на увеличение, то есть призывают «делать больше того или другого». Я всегда считал себя больше редукционистом, и меня привлекал дзен-буддизм (хотя последователем этого духовного течения я никогда не был).
Но я пытаюсь жить по правилу меньшего: удалять лишние варианты. Носи одну стрижку. Одевайся однообразно. В итоге будешь свободнее.
В качестве награды я получаю высвобожденную энергию, которую могу направить туда, где она реально нужна. Я существенно расширяю возможность тратить время на те занятия, которые мне интересны, что явно не касается большинства людей, мечущихся между работой, детьми, развлечениями и прочими задачами.
Не позволяйте своему увлечению решением сложных задач погрязнуть в пучине усложнения и неопределённости.
Ответом на уменьшение сложности будет стремление к меньшему числу движущихся деталей и к более точным определениям назначения той или иной вещи. Не создавайте то, что уже существует в готовом и доступном виде. Не создавайте то, что не понимаете и не можете нарисовать, обсудить или объяснить. Несмотря на то что в монолите внешне как бы меньше движущихся деталей, это лишь потому, что мы скрываем их в чёрном ящике без пояснений.
Пользуйтесь литературой по проектированию – нам нужно стремиться расширять словарный запас, а также оценивать, к примеру, аффордансы (термин Дональда Нормана) и то, как ограничения в действительности могут улучшить нашу работу. Проясняйте задачу и упрощайте её решения. Технологическая среда излишне стремится к новизне, и это больше вредит нам, нежели помогает. Но микросервисы не являются какой-то очередной «новинкой», это инфраструктурное представление отчётливых ответственностей, которое всегда останется актуальным.
Узнавайте о новых акциях и промокодах первыми из нашего Telegram-канала ?
