Правило 13. Выбирайте правильные структуры, а не тренды

ИТ-сфера и архитектура, в частности, в последние годы перестали быть сугубо инженерной наукой с суровыми бородатыми мужчинами, бормочущими заклинания над компьютерами, отчего те начинали работать. С отраслью, как и со многими другими сферами деятельности, случилась популяризация в массах: в индустрию пришли деньги, за деньгами потянулись и различные сомнительные личности, а за ними нотации модные тенденции.

Одной из таких модных тенденций стала микросервисная архитектура. Суть её в том, что система дробится на небольшие блоки программного обеспечения, каждый из которых выполняет небольшой набор функций, а в идеале только одну.

Я не просто так взял в качестве иллюстрации игру Jenga. В собранном виде, перед началом игры, она выглядит как монолитная башня, составленная из одинаковых блоков. Каждый блок выполняет только одну функцию — удерживает вес башни. Часть блоков находятся сверху, и давление на них ниже, другие находятся в основании и, соответственно, удерживают больший вес, говоря техническим языком, более нагружены.

Вынимая блоки и помещая их на верх башни, вы меняете только структуру башни, перераспределяя нагрузку между блоками. Суть игры сводится к тому, чтобы найти такую точку, при которой давление в какой-то части конструкции станет запредельным, и изменение структуры башни, выемка блока или его водружение приведут к обрушению башни и проигрышу последней руки.

Идея микросервисной архитектуры в случае с игрой Jenga могла бы представлять из себя изготовление блоков из разных материалов, разного веса и с разными свойствами. Это позволило бы сделать башню более устойчивой, даже для случаев замены блоков.

Блоки из металла в основании могли бы держать большую нагрузку, чем деревянные; блоки, находящиеся сверху, можно делать из пластика, чтобы снизить вес; их можно делать цветными для индикации нагрузки и так далее.

Каждый блок в такой архитектуре теперь может иметь свои особые свойства, а за каждый блок отвечает отдельная команда. Каждая команда может модифицировать свои блоки, которые они вынули из башни, перед возвратом на место. При этом другие команды их в этом не ограничивают, они живут обособленной жизнью.

Многие ИТ-специалисты, работавшие раньше в тяжелых, монолитных организациях, где почти любое изменение требовало огромной бюрократической работы по согласованию, стали экспериментировать с новой архитектурой. Для некоторых сценариев использования такая архитектура подходила очень хорошо, и вынос небольших кусочков системы в отдельные модули и на другие технологии себя оправдывал. Это были взвешенные и технически обоснованные решения, которые требовали хорошего понимания первопричин принятия этих решений.

Решения принесли большую пользу в тех задачах, для которых они и были разработаны. После чего идеи микросервисной архитектуры были подхвачены рынком как революционно новое решение, которое, как волшебная таблетка, излечит любой ИТ-ландшафт и даст огромные преимущества.

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

Микросервисная архитектура стала трендом.

Довольно быстро ИТ-рынок наелся микросервисной архитектуры и осознал, что тотальная микросервизация разрушает бизнес, вместо его спасения.

На примере всё той же Jenga можно в этом убедиться. Каждая команда может поменять свой блок независимо от других, но каждая команда также должна вставить свой блок обратно в общую структуру башни.

Блоки плохо стыкуются друг с другом, даже если имеют одинаковый размер. Металл, дерево и пластик имеют разную текстуру, а значит, и разный коэффициент сопротивления скольжению. А что, если тяжелые металлические блоки оказываются сверху более легких пластиковых блоков и так далее?

Да и сама башня становится мало похожей на саму себя, если все блоки в ней отличаются друг от друга и размещаются произвольным образом. В итоге каждый блок начинает иметь свои уникальные положительные свойства, но конструкция в целом становится менее понятной и устойчивой. А некоторые зависимости становятся ещё более тесными, чем когда все блоки были одинаковыми.

Хорошим примером укрупнения вместо измельчения сервисов (во всяком с бизнес точки зрения, под капотом это может быть устроено иначе) выступает Московское метро, которое год за годом наращивает возможности своих сервисов и артефактов.

Так, карта “Тройка” позволяет ездить на всех видах транспорта: от автобуса до электрички. Я ещё помню, когда нужен был единый проездной ТАТ (троллейбус, автобус, трамвай), а билеты на метро и электричку нужно было покупать отдельно.

Сейчас карту “Тройка” можно пополнить с банковской карты, и, включив автопополнение, можно вообще исключить себя из этого процесса. А с прошлого года, приложив карту к турникету для прохода, можно активировать и удаленное пополнение карты.

Таким образом, турникет теперь выполняет две противоположные функции: списание денежных средств и пополнение баланса карты. То есть одно устройство совмещает в себе две функции, притом разнонаправленные, что является прекрасным примером применения ТРИЗ.

Применение правильных структур и шаблонов проектирования — вместо бездумного следования модному и широко известному — является обязательным правилом для архитектора.

Что же касается развития сервисов Московского транспорта, я очень надеюсь, что в будущем они позволят перейти с предоплаты на постплату. И эта практика распространится на прочие сервисы (такие как проезд по платным трассам) и разойдется по всей стране. Это освободит умы людей от рутинных операций по контролю за состоянием счёта.