Про архитектуру: как на самом деле работает ваш софт
Завод
Допустим вы решили построить завод.
Disclaimer: Я очень слабо разбираюсь в реальном производстве, поэтому все примеры чисто умозрительные.
подбирается место исходя из логистической доступности, подводится вода, электричество, газ, строятся дороги и фундамент.
При этом проект самого завода хоть и индивидуальный, но основан на огромной типовой базе наработок, основанной в свою очередь на массе реальных физических расчетов.
В результате на выходе вы получаете физический объект с предсказуемыми свойствами, возведение и дальшнейшая эксплуатация которого — процесс также вполне себе предсказуемый.
Да конечно бывают и аварии и перебои поставок, переориентация производства, снижение или наращивание объемов производства и так далее.
Но завод от этого не перестает быть заводом. Даже если его продать или перекрасить.
Например никому не придет в голову приделать сбоку от цеха горячего литья — салон красоты, потому что это невозможно физически.
Получается что архитектура реального физического завода основана на вполне конкретных законах физики и химии, посему является неизменной:
верх это верх, низ это низ, гравитация тянет вниз, пар идет вверх, тепло нужно отводить.
В отличие от архитектуры программ.
Программный завод
Теперь представим этот же завод, но в виде программы:
программная симуляция, набор инструкций описывающих заводские процессы.
Так вот разница начинается даже не с самого завода или процессов, а сразу со среды.
Правда не окружающей, а со среды выполнения.
Среда выполнения — место в котором программа вашего завода выполняется, это натуральное Зазеркалье, пополам со «Страной Оз», со своими Алисами, Чеширскими котами и железными гомо-дровосеками.
Да, все настолько странно и необычно. Добро пожаловать в дурдом!
Начнем с банального, но для многих не очевидного:
среда выполнения программ не имеет никакой привязки к реальным физическим процессам и их ограничениям.
Программы не стареют, не изнашиваются, не заканчиваются. Любой аппаратный сбой, с точки зрения программы это просто сбой.
Либо «да» либо «нет», либо 0 либо 1.
Сбой может быть обработан с продолжением выполнения, а может и нет, тогда выполнение остановится.
А с точки зрения самой программы окружающий мир просто замрет. И даже не спрашивайте откуда я это знаю.
Даже столь фундаментальный процесс как течение времени, в среде выполнения программ является управляемым:
можно остановить, перезапустить, поставить на паузу или перезапустить заново.
Сама среда выполнения также не является статичной:
потоки данных, ввод-вывод, отображение — все является изменямым.
сама среда выполнения тоже может оказаться программой, запущенной внутри другой программы.
Например сможете вообразить и осмыслить такую постановку задачи:
Завод должен автоматически расширяться в 10 раз при увеличении входящего потока ресурсов и затем самостоятельно скукоживаться обратно при его уменьшении.
А для современной программной системы такое является одним из самых популярных требований, часто можно найти в техзаданиях. Обычно где-то до пятой страницы.
Абстракции и инструкции
Что такое по своей сути любая программа?
Задаются снаружи, живым человеком (обычно) в виде требований.
Так вот следуя этой логике, ключевые свойства программы — ее изменяемость и выполняемость, все.
Сами технологии, языки программирования и фреймворки являются всего лишь договоренностями, они только задают определенные правила поведения и хорошего тона.
Но из-за отсутствия привязки к реальным физическим процессам — абсолютно ничего не ограничивает от их нарушения:
Завод перевернутый вверх тормашками, с дымом идущим вниз?
Пусть завод пообщается с другими заводами, они обмениваются сообщениями и подписываются друг у дружке на события!
Поэтому в мире ИТ «сталелитейный завод с пристройкой сбоку в виде салона красоты» является на самом деле частым явлением:
Покупали завод, салон красоты дали в нагрузку, бесплатно. Затем совместили ради оптимизации активов и понеслась.
Продуктовая линейка компании Oracle не даст соврать )
Надежность и отказоустойчивость
Требования к архитектуре ПО в плане надежности и отказоустойчивости — такой же частый гость техзаданий как и пассаж про масштабируемость выше. Получается что люди действительно в эту самую надежность верят, ее сильно хотят и готовы за нее платить.
Как думаете что будет если снести несущую стену в здании?
Строение если не упадет то накренится или даст трещнину. Одним словом — станет непригодным.
А что будет если снести какую-то важную часть программы?
По большому счету.. ничего. Прервется выполнение, может быть.
Вы начали строить новый заводской корпус. Залили бетонную основу, начали возводить каркас.
И тут внезапно просят откатить изменения и сделать «как было».
Объем и сложность этих работ представили?
А в виртуальном мире программ:
Откат изменений — обычная ежедневная рутина. Дешево, быстро и предсказуемо. Студенты на практике делают.
Каждый день и каждый час мы сносим и перестраиваем. Сносим и перестраиваем.
Вообщем шанс все сломать и просрать в мире программ чрезвычайно мал, надо сильно и долго стараться чтобы такое случилось.
Отсюда и происходит специфический подход к надежности современного ПО, описывающийся одной фразой:
П#хуй, пляшем.
Fail Fast approach — по научному.
Так что скажите спасибо что программисты не строят дома и спите спокойно.
Хотя мы еще не закончили экскурсию в дурку.
Производительность & масштабируемость
Возьмем популярную задачу для яжархитектора:
Спроектировать масштабируемую систему, которая может выдержать миллион пользователей.
Как думаете какой будет самый популярный первый ответ на такой запрос?
Кластер-шардинг-докер-баланс-йо-йо-йо-Альбукерке-жжот!
Никакие намеки и осторожные вопросы про контекст не помогают.
Едва услышав про «миллион миллион ююююзеров», мамкины архитекторы и сеньоры-помидоры немедленно делают стойку и отвечают заученной мантрой:
ехал кластер через докер..
Но если представить, что 1 млн пользователей это.. за сутки? Oкажется что это лишь 42 тысячи в час или 700 в минуту.
Что, уже не так впечатляет? А если это не в сутки а за месяц? Или 1 млн не пользователей, а суммарно их запросов?
Понимаю что смешно, но некоторые на самом деле не отличают.
Если еще чуть-чуть подумать, то окажется что есть пиковые часы, вне которых у вас лишь 10-20% загрузки от максимума. Есть часовые пояса, есть просто неактивные пользователи, которых обычно как раз большинство.
И если это все учесть, то окажется что от общей массы из огромного 1 млн пользователей остаются 2-3 тысячи активных, разбитых по нескольким часовым поясам.
Что вообщем-то даже ниже чем нагрузка на местный интернет-магазин или форум на каком-нибудь PHP+MySQL, развернутые на копеечном хостинге.
Я уже рассказывал, что многие современные программисты не умеют считать?
Откровенно про масштабируемость.
да, действительно можно сделать так чтобы ваше «облачное SaaS решение по продаже кормов для рыбок по подписке» не легло под любой нагрузкой.
Чтобы оно не засбоило, из-за внезапного стократного роста пользователей, а само автоматически масштабировалось в обе стороны при колебаниях нагрузки.
Но стоить это будет такой крови, сил и средств — что вы просто ох#еете.
И само собой разумеется что такое масштабирование нужно будет неоднократно обкатывать, проверять и тестировать.
Даже если это будет развернуто в каком-нибудь Amazon Cloud и обеспечиваться самой платформой, даже за большие деньги с золотыми пистолетами консультантами.
Потому что законы Мерфи никто не отменял. А это единственные законы, которые работают в ИТ всегда.
Эпилог
«архитектура программных систем» - такой набор правил хорошего тона для обитателей дурдома.
Придуман, что характерно, самими обитателями, просто более старшего поколения.
Строгое и последовательное соблюдение этих правил, хоть и повысит ваш авторитет в глазах обитателей айтишной дурки тусовки, но вот с реальными результатами может и не сложиться.
Потому что большая часть этих правил выглядит как знаменитое «покрась танк в красное и он поедет быстрее» (RED MEAN FASTA из вархаммера да).
Это некие догмы, не рассчитанные на логическое осмысление и даже обсуждаемые с очень большим скрипом в айтишном дурдоме приличном обществе.
Так что вспоминайте этот текст, когда вам в следующий раз начнут продавать «облачно-распределенную архитектуру», «кластеры метаданных» и прочие интересные вещи.
P.S. Видели когда-нибудь как два взрослых трезвых мужика в деловых костюмах дерутся посреди дорогого офиса из-за кубиков на доске?
А я видел, это называется защита архитектурной концепции.
