Некоторые паттерны говорят нам о том, каким должен быть код. Если он выглядит так и вам нужно добиться этого - значит, делайте вот так. Такие шаблоны полезны, поскольку они дают обширный набор готовых решений для разных проблем, и улучшают ваш код каждый раз, когда вы сталкиваетесь с похожим контекстом.
Но существуют и другие шаблоны, которые меньше касаются кода и больше - того, как код пишется, кем и в какой организации. "Его Величество Монолит" является одним из таких образцов. Но прежде чем мы погрузимся в исследование его красоты, давайте сначала рассмотрим противоположную модель архитектуры, ориентированной на микросервисы (или сервисы в широком понимании этого слова).
M/SOA - это рецепт, позволяющий разбить приложение на множество более мелких частей, запустить каждую из них, как отдельное приложение, а затем позволить их созвездию решить главную проблему, которая вас действительно волнует.
Это отличный шаблон. Нет, правда. Без всякого сарказма. Если вы работаете в Amazon, Google или любой другой организацией по разработке ПО с тысячами разработчиков, это прекрасный способ распараллелить работу над релизами. Каждый сервис может представлять собой собственную команду со своим графиком, персоналом и целями. Он может эволюционировать независимо (хотя бы частично) от всех остальных сервисов, составляющих целое.
Когда вы достигаете определенного масштаба, просто не существует другого разумного способа добиться координации усилий. В противном случае все будут наступать друг другу на ноги, и вам придется иметь дело с бесконечными конфликтами слияний. Честно говоря, я слышал, что Facebook довольно неплохо умеет готовить монолиты, независимо от того, величественны они или нет - но это тема для другого обсуждения.
Другими словами, M/SOA соответствует организационной форме очень крупных корпораций. И это прекрасно!
Беда случается, когда люди смотрят, скажем, на Amazon, Google или кого-то еще, кто может дирижировать этим оркестром, и думают: эй, если это работает для "успешных ребят", значит, это сработает и для меня. Бдзынь! Неверно!
Шаблоны, имеющие смысл для организаций, на порядок превышающих вашу - часто совершенно противоположны тем, которые имеют смысл для вас. Это и есть суть культа карго. "Если я буду танцевать, как эти бегемоты, то я тоже стану одним из них". Извините, но так это не работает.
Это касается не только технических моделей, но и общих организационных подходов. Вы не должны управлять отделом кадров, как компания из 50,000 человек, если у вас всего 50, кажется очевидным для большинства из нас (за редким исключением).
Проблема преждевременного превращения вашего приложения в набор сервисов заключается в том, что оно нарушает правило #1 распределенных систем: постарайтесь обойдитсь без распределенных систем! По крайней мере, если вы можете избежать этого.
Каждый раз, когда вы заменяете взаимодействие между объектами на взаимодействие между системами, вы сталкиваетесь с новым миром множества обязательств и новых точек отказа. Что делать, когда сервисы не работают, как ожидается? Как согласованно менять состояние системы? И все прочие проблемы с запуском множества сервисов.
Вся эта игра стоит свеч, когда у вас нет выбора. Но у большинства людей выбор есть. У нас есть альтернатива. Итак, позвольте мне представить: Его Величество Монолит!
Описание вашей системы как "монолитной" обычно является предметом насмешек. Вам приходится бороться с насмешками других программистов! Но я говорю: не подставляйте другую щеку, а примите монолит с гордостью и бравадой! Не превращайте вашу систему в монолитный дизайн волею случая, а делайте это намеренно и с высоко поднятой головой. Любой монолит, достойный возведения, стоит сделать величественным!
Так что же такое величественный монолит? Это интегрированная система, которая объединяет столько ненужных концептуальных моделей, сколько возможно. Устраняет столько ненужной абстракции, сколько может. Распределение вашей системы - это большая проблема, которая только мешает вам делать вашу работу.
Я пишу Basecamp как величественный монолит с 2003 года. Последняя итерация, третья версия, выводит этот паттерн на новый уровень и собирает в него не только интернет-часть, но и все наши нативные платформы.
Basecamp 3 доступен через Интернет, а также как нативные мобильные приложения для iOS и Android, приложения для настольных компьютеров на Windows и Mac, и даже через электронную почту. Вот так много платформ для одновременного жонглирования! И я считаю, что единственный возможный способ сделать это с небольшой командой из десятка программистов - это явно выбрать и посвятить себя служению Величественному Монолиту во всей его неоднозначной славе.
Вот в чем состоит прессинг, который заставляет нас принять эту модель:
Basecamp - это большое приложение. Буквально сотни экранных форм разных видов. У нас 200 контроллеров с общим количеством 900 методов! Добавьте сюда 190 классов с 1473 методами. И это именно то, что находится непосредственно в папке app/*, не говоря уже о наших интерфейсах, таких, как текстовый редактор Trix.
Basecamp - небольшая команда. У нас всего 12 программистов и многие из них заняты тем, чтобы системы, которые мы создавали за последнее десятилетие, работали. Кроме того, у нас всего 7 дизайнеров (считая Джейсона, моего партнера и нашего генерального директора).
Basecamp доступен на 6 платформах: Web + iOS + Android + Mac + Windows + Email.
Basecamp имеет миллионы пользователей и каталог многих приложений, которые мы будем поддерживать до конца Интернета.
Таким образом, широкий охват, серьезные обязательства и очень маленький бюджет - наша реальность. Работа в подобной ситуации просто несовместима с такой трудоемкой моделью, как M/SOA. Этот подход не очень совместим с написанием 100% нативных приложений, но он для гибридной модели работает идеально.
Кроме этих формальным ограничений мы стремимся писать красивый, понятный и лаконичный код. Код, который заставляет нас улыбаться в тот момент, когда мы его пишем, а также когда нам позже приходится расширять или исправлять его. Такая миссия просто не совместима с бесконтрольно выросшим монолитом. Он просто должнен быть величественным.
Одно из преимуществ красивого монолита состоит в том, что люди, работающие над ним, также неплохо понимают его в целом. Гораздо проще терять эти знания и ответственность при развитии небольших систем. У нас такое было с несколькими внешними общими службами, такими как Basecamp ID (общая аутентификация для всех поколений приложения Basecamp). "О, ты должен поговорить с Джеффом об этом".
Эта особенность заставляет нас делать приложение понятным и обозримым для отдельных людей, а не для команд. Что, в свою очередь, снова заставляет вас не торопиться и размышлять над тем, что вы делаете. Если ваш стандарт разработки невысок - вы не просто писаете в своем собственном углу, вы мочитесь на весь этот величественный монолит, который мы все полируем каждый день. Не делайте этого!
Во многих отношениях это прямо соответствует сути восприятия программистами Ruby и Rails. Большинство из них получает шанс писать красивый код. Наши системы - как приглашение стать лучше, более продуктивным программистом.
Его Величество Монолит не претендует на обеспечение отказоустойчивой архитектуры, ведущей вас по пути к славе. Это дурацкая затея. Многие программисты превратят любую архитектуру, созданную с помощью любого инструмента, в большую кучу дерьма, известную как Ball of Mud. Так не беспокойтесь слишком много о спасении тех, кто считает, что владеет серебряной пулей, и заключается она в сервисной архитектуре.
Если вы управляете небольшой командой, а не техническим бегемотом - возьмите монолит и сделайте его величественным!
