Ретроспектива архитектурных решений

Архитектура ПО есть результат процесса развития. И как всякий процесс -- этот процесс был наполнен диалектикой развития. Перед чтением налейте кружечку ароматного чая и усаживайтесь поудобнее.

Развитие ИТ насчитывает менее 80 лет. По меркам даже периода массовой индустриализации срок довольно небольшой. Для сравнения примерно столько же атомной энергетике, примерно 130 лет использования электроэнергии, около 200 лет использованию пару и сжатому воздуху, около 250 лет механическим калькуляторам, около 400 лет эпохи модерна.

В 40..50х годах 20 столетия с небольшими интервалами сразу в нескольких странах были созданы вычислительные машины. Они были чудовищно дорогие, с крайне высоким потреблением энергии и такой же невыносимо низкой надёжностью работы. Необходимость существования и оправдание цены этих машин как всегда представили военные. Это и задачи баллистических расчётов артиллерийских систем крупных кораблей, и задачи прицельного бомбометания, и расшифровка передач противника, и сокрытие шифрованием информации для своих военных. Все эти машины явились результатом интенсивного развития науки на протяжении предыдущих 100 лет. Вычислители уже тогда делились на две группы:

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

Специализированные машины настраивались на заводе-изготовителе и в таком виде эксплуатировались весь срок службы. Так, многие корабли ВМФ США, имея на борту по две механические системы наведения палубных орудий эксплуатировались до конца 60х годов 20 столетия. Многим кораблям к тому моменту исполнилось по 50..70 лет. Для корабля это не очень много, но учитывая стремительно развивающиеся системы управления боевыми кораблями (и не только) – корабли со специализированными вычислителями морально устарели. Моральное устаревание – это качественный переход, обозначающий наступление революции ИТ. Запомним этот период – конец 60х. Почти универсальные машины (на всех перечисленных принципах) отличались от специализированных тем, что их можно было “программировать”. В кавычках, потому что невозможно назвать это программированием в современном виде. Вычислительные системы на гидравлике программировались коммутацией вентилей и патрубков.

В электронных (электромеханических) вычислительных машинах пару десятков женщин-операторов быстро коммутировали соединительные провода из гнезда в гнездо, одновременно поглядывая в принципиальные электрические схемы. От вертикальных панелей с лампами шёл жар (вакуумные триоды имели рабочую температуру от 150 до 300 градусов Цельсия). И весь вычислитель потребляет около 200 кВт электрической мощности. Для сравнения, чтобы отопить квартиру зимой в Москве площадью в 50 м. кв нужна мощность примерно 10..12 кВт. Здесь же тоже стоит упомянуть о том, что в типичном вычислителе было от 3 до 7 тыс. ламп, и среднее время работы до выхода из строя очередной лампы – порядка 3..5 минут. Это хтонический ужас. Казалось бы, судьба монстров на вакуумных триодах решена: дорого, хлопотно, зачем так сложно. Архитектура вычислительных систем ясна и понятна:

Но в 60х годах 20 века произошла революция в ИТ, которая изменила баланс сил. А именно: поступление в массовую продажу полупроводниковых компонентов. Ох уж эти 60е!

Одновременно с развитием аппаратной базы пришло и понимание, что мало сделать вычислительную систему – ещё нужно сделать её так, чтобы, с одной стороны, – система выжимала при работе максимум из имеющихся средств. С другой стороны, стоять на табуретке, тянуться к раскалённым лампам где-то под потолком или гнуть спину, чтобы найти коннектор где-то возле пола – тоже крайне неудобно. Т.е. в очередной раз в развитии технических средств возник вопрос гармоничного сопряжения человека и техники. Но также оказалось важным понимать, что машина, которая способна выполнять множество разнообразных операций (даже если она дороже) – это несёт с собой больше потенциальных выгод, чем машины, которые делают что-то одно в широком применении (но нет, специализированные вычислители не сдались – майнинговые фермы передают привет). Универсальные машины в 60е одержали уверенную победу в раунде.

Основываясь на принципах таких известных исследователей с мировыми именами как Алан Тьюринг, Клод Шеннон, Андрей Колмогоров – доказали, что универсальные машины не просто возможны. Такие машины с быстрой заменой программ способны выполнять все задачи, под которые человек в состоянии написать программы. И здесь опять важны детали: есть конкретные аппаратные средства, они накладывают ограничения на то, какой должна быть программа. И это – та самая гармонизация аппаратуры и программы, которая и называется “архитектура”. Важно понимать, что аппаратные средства, как идею – можно описать сильно по-разному, делая акценты на какие-то “программируемые” свойства – широкое машинное слово, глубокий конвейер, устойчивость к высокоэнергетическим космическим лучам и т. п. И эти “запрограммированные” свойства будут в дальнейшем влиять и на программное обеспечение.

Аппаратные средства начиная с 60х годов развивались быстрыми темпами. Свои вычислительные системы строили в СССР, США, Германии, Великобритании, Франции, Японии. Все ведущие мировые государства приняли участие в этой гонке. Разработки стоили огромных денег, попутно решались задачи по исследованию материалов, обоснование приоритетных задач исследований, интеграция СВТ в экономику государств. Интересно проследить то, как архитектура аппаратных средств вписывалась в решаемые задачи. США и СССР – это задачи стратегического военного планирования, многочисленные симуляции превентивных ядерных ударов (США) и перехват скоростных межконтинентальных баллистических ракет и высотных бомбардировщиков (СССР). У Франции и Англии не было таких ресурсов (при наличии ядерного оружия), поэтому в этих странах решались не столько военные, сколько исследовательские задачи. У Японии вообще не было никакой регулярной армии (в соответствии с ограничениями по итогам Второй мировой войны) – там был больше научный интерес.

Постепенно, ко всем участникам этого процесса начало приходить понимание, что ИТ хоть и обязано своим появлением военному заказу, на самом деле, гораздо шире по кругу решаемых задач. На примере СССР можно показать, что архитектурные подходы начали расходиться у разных групп с самого начала: ЭВМ на троичной логике “Сетунь” и “Сетунь-2” (уникальная аппаратная архитектура даже спустя почти 70 лет), в Ереване была построена машина для оптимизированных математических расчётов, Минск вошёл в историю серией своих машин средней вычислительной мощности (нашли широкое применение в инженерных вычислениях и экономических прогнозах).

Военные системы проектировались под узкие задачи, но даже с учётом этого, показатель вычислительной мощности достигал 500 миллионов операций в секунду (при архитектурной возможности до 1 млрд 500 миллионов операций в секунду) – в 60е годы выдать такое – даже сейчас кажется чем-то невероятным. Серия ЭВМ БЭСМ вошла в историю как самобытная, отлично спроектированная и надёжная система. На момент своего появления БЭСМ была лучшей вычислительной системой в мире.

Подобное разнообразие аппаратных архитектур в СССР показало, что для решения различных задач – необходимо различное железо. Если военным нужны только узкий круг задач, то для широкого применения в экономике страны – нужны массовые поставки машин средней вычислительной мощности, но эти машины должны обладать универсальным набором функций. Примерно такие же процессы проходили и в остальных странах. Эволюция аппаратных архитектур была бескомпромиссной. Динозавры держались до последнего, но велоцирапторы нового поколения, такие как DEC сожрали их беспощадно. Новая компонентная база в виде транзисторных сборок и микросхем, модульная структура, гибкое наращивание памяти, выполняемых команд, средств хранения и отображения – все эти архитектурные находки дали преимущества мини-ЭВМ в виде габаритов, потребляемой мощности и, конечно, цены. Развитие архитектуры мини-ЭВМ дало толчок к развитию языков программирования.

До этого безраздельно управлявшие миром ассемблер и Фортран довольно быстро потеснились местом под Солнцем с Лиспом, Алголом, Паскалем, Симулой. Языки высокого уровня (ЯВУ) тех лет – это следствие аппаратной архитектуры. Система команд такой мини-ЭВМ, как PDP-11 будет пользоваться у олдов уважением за тот инженерный подход, который прослеживается в каждом решении этой машины.

Если посмотреть ассемблерный код после Си – становится понятно, почему Си такой, какой он есть. Кен Томпсон и Деннис Ритчи работали за PDP-11 – понятно, что они адаптировали свой язык к этой машине. Противоположному подходу следовали в то время другие исследовательские группы: появилась специализированная аппаратная архитектура под Лисп, под Паскаль, под Модула-2.

Здесь важно обратить внимание, что если Си создавался под PDP-11, то под Лисп, Паскаль и Модула-2 – уже создавалась аппаратура. Т.е. архитектура на уровне языка начала определять архитектуру для аппаратуры. Эта инверсия контроля (IoC, inversion of control) поставила с ног на голову процесс разработки архитектуры. Это произошло также, как и ранее произошло с болтами и гайками – после их стандартизации вопрос “как делать болты и гайки” отошёл на второй план. Понятно, что болты и гайки делать не сложно, важнее вопрос “а что именно делать с помощью болтов и гаек?”. Этот сдвиг в подходах можно считать появлением системной архитектуры. Крупные организации, которые могли себе позволить мини-ЭВМ (и которые осознали, чем им полезны такие машины) оказались в интересном положении: аппаратные средства есть, машины теоретически могут всё, а практически, без ПО – это мёртвое железо.

Оживление коммерческих организаций, вызванное внедрением мини-ЭВМ создало загадочный рынок ИТ-специалистов. Программистами обзывали всех, кто не стеснялся сделать умное лицо и без страха прикоснуться к магическому ящику. Подключить клавиатуру, написать программу, поменять картридж в принтере – это была работа программиста, потому что других программистов для мира не было. Надо признать, что и самим программистам это было интересно и полезно, так как именно таким образом первые программисты не из академической среды осваивали технику, которая всё ещё была крайне дорогой. Хоть PDP-11 со своим потреблением в 1.5…3 кВт была тёплой (но уже совершенно не ламповой), и было приятно холодной зимой посидеть рядом (и многие буквально сутками сидели рядом, и даже дрались за машинное время – тоже буквально), но дома же есть холодильник, диван, любимая кружка для чая – все мечтали о том, чтобы можно было писать ПО прямо из дома.

И этот день настал. На рынке в массовом порядке стали появляться микрокомпьютеры. Intel, MOS, Zilog, Sharp, Hitachi, Motorola, Philips – все эти фирмы отметились выпуском своих микропроцессоров. С архитектурной точки зрения (после PDP-11) – это была катастрофа. Система команд процессоров фирмы Intel (8008, 8080, 8088) до сих пор вызывает у олдов скрежет зубов и ругань на чём свет стоит. Никакой ортогональности, 78 команд – что это за нищета инженерной фантазии? В отличие от PDP-11, где работа процессора могла быть изменена добавлением новой платы (либо новая команда, либо ускорение существующей команды, либо и то и другое вместе) – процессор 8080 в виде микросхемы таким теперь будет навсегда. Со всеми своими ошибками, неудачной схемой тактирования, невозможностью расширения – эти мелкие хищники принялись беспощадно уничтожать мини-ЭВМ. В этом ужасном аппаратном архитектурном решении оказалась заключена мощь атомной бомбы: десятки миллионов микропроцессоров воспитали десятки миллионов программистов, которые увязывали свои знания и опыт не на редкую неведомую архитектуру дорогостоящей машины, которая стоит в секретном подвале уважаемой фирмы, а с массовым микрокомпьютером, который стоит во множестве миллионов домов.

Экономические показатели добили рынок мини-ЭВМ. Так, серия домашних компьютеров Atari, которая включала множество моделей имела цену от 600 до 1500 долларов США в ценах 80х. PDP-11 и машины из этой серии начинались от 10_000 долларов США. И первая сумма не маленькая, и вторая неподъёмная для отдельного человека. ZX Spectrum как домашний компьютер имел цену в 99 фунтов стерлингов (около 120 долларов США).

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

Микрокомпьютеры, которые вошли в историю как “домашние компьютеры” обладали ужасно-прекрасными характеристиками. Такой домашний компьютер в виде моноблока подключался к телевизору. Устройством хранения был бытовой кассетный магнитофон, системного блока отдельно не было (был совмещён в одном корпусе с клавиатурой). Совмещение подчёркивало, что это “не эти вот все ваши мини-ЭВМ и мейнфреймы, это домашний компьютер!”. Тренд на совмещение вычислительного блока и клавиатуры (вместе с монитором – ещё вернётся через 30 лет – да-да, эти вот ваши смартфоны). Памяти на тех машинах в первых моделях было 4..16 кБ. Не 4..16 МБ, а 0.004..0.016 МБ!! На более поздних машинах типовой памятью были 64..128 кБ.

На территориях бывшего СССР компьютерщики собирали мелкими сериями машины, на которых было от 256 кБ и вплоть до 4 МБ. Скорость чтения и записи магнитных лент составляла от 400 до 1200 бод/сек. Тактовые частоты процессоров начинались от 1 МГц и до 12…20 МГц на поздних системах.

Приведённые аппаратные ограничения накладывали на архитектуру ПО свои жёсткие ограничения. Про архитектуру ПО можно сказать, что её …почти не было. Конечно, были ПЗУ с их зашитыми сервисными процедурами, интерактивными редакторами и, как правило – Бейсиком. Всё это как-то работало, народ пищал от счастья. И даже Бейсик, как типичный пример сочинительства, ярко демонстрировал отсутствие понимания архитектурных принципов при проектировании языка. Для тех, кто не имел возможности раздобыть мини-ЭВМ в персональное пользование – архитектурные принципы на микроэвм есть непозволительная роскошь. Экономили буквально на всём: на тактах процессора, на битах в байте, на совмещении хранения двух значений в одной ячейке памяти с помощью операции XOR. Не лучше дела обстояли и с периферией: например, в музыкальном чипе AY-8910 для расширения диапазона громкости использовался “грязный хак”: логарифмический расширитель амплитуды. И всё же, смотря на старший сегмент, программисты на домашних ПК старались делать по-взрослому: придерживались модульности, писали свои библиотеки, создавали в массовом порядке игровые движки. А ведь это всё планирование, концепции, реализации, поиск! Но, на необходимом уровне.

Тут, пожалуй можно сформулировать золотое правило архитектуры: правильное архитектурное решение лежит между минимально допустимыми возможностями, а с другой стороны – “богатыми” возможностями, но ими никто не будет пользоваться. И этот принцип стоит во весь рост даже сегодня, на всех коммерческих проектах по разработке ПО. В поздние периоды эпохи домашних компьютеров предпринимались (и продолжают предприниматься) попытки по созданию системного программного обеспечения. Вот именно для этих целей и нужны были на 8/16 битных компьютерах те самые 0.256..4 МБ ОЗУ и до 20 МГц тактовой частоты процессора. Иначе в рамках более слабых машин – системная архитектура обречена. Нельзя сказать, что все эти попытки были безуспешными, но и успешным успехом это назвать нельзя.

Лихие 90е на просторы бывшего СССР принесли модные западные веяния. Они выглядели сначала в виде PC, XT, а затем и AT. Всё это стремительно вытесняло домашние компьютеры, а вместе и с ними ПО. Из средства домашнего развлечения ЭВМ всё больше становились средствами производства, что диктовало условия к тому ПО, которое исполнялось на этих ЭВМ. Первобытный хаос в архитектуре решений начал сменяться аналогом родоплеменных отношений. Типичным порождением той эпохи стал MS-DOS. Дисковая операционная система той эпохи, действительно таковой не являлась. ДОС выполняла функции как драйвера дисков, абстракции файловых систем, так и первичного драйвера экрана, иногда драйвер сетевой карты и драйвер звуковой карты. Одной из самых важных функций ДОСа являлась командная оболочка. Она действует по принципу REPL (read-eval-print-loop). Уже давно нет тех режимов, которые поддерживал ДОС (и самого ДОС тоже уже нет), но в форме консоли эта командная оболочка успешно дожила до наших дней.

Особенностью командной оболочки было то, что она запускала программы, после чего ожидала их завершения. Это важное новшество по сравнению с домашними компьютерами: после запуска программы в них для возврата в исходное состояние обычно требовался аппаратный сброс машины. Также был класс программ (резиденты), которые запускались, оставались в памяти и продолжали работать, но управление возвращалось в командную оболочку. Так появились первые резидентные вирусы. На этих примерах можно сформулировать несколько архитектурных решений, которые актуальны до сих пор: единообразный доступ к системным функциям требует от программ поддерживать единый формат тела программы; ядро системы, которое управляет всем позволяет организовать взаимодействие нескольких программ, которые написаны разными программистами; терминал и командная оболочка предоставляют удобные абстракции ввода/вывода, которые достаточны практически для любых задач.

И всё бы это было хорошо, но есть нюанс: теперь архитектурный хаос отступил, всё стало сложнее, место хаоса заняла двухэтажная ДОС. Это усложнило жизнь программистам, и упростила жизнь пользователям. А пользователи – это деньги! МС-ДОС прекрасно доказала своим фактом существования, что она была прогрессивной системой. Но, как и в любой истории, у МС-ДОС был как расцвет, так и неизбежный закат. Причиной всему несколько неудачных архитектурных решений. Абстракция процессов не была поддержана аппаратно: процессы работали в одном адресном пространстве. Абстракция драйверов также была условной: не было никакой защиты памяти процессов друг от друга. Несколько пользователей на одном ПК не были предусмотрены вообще с самого начала.

Появившиеся к тому моменту процессоры Intel начали поддерживать защищённый режим, для которого была возможность непосредственно обращаться к 4 ГБ ОЗУ, вместо примерно 1 МБ, которыми оперировал МС-ДОС. И из-под МС-ДОС можно было даже обращаться к этим 4 ГБ ОЗУ, но это уже был неизбежный конец из-за ограничений архитектурного решения. Но, всё же, спасибо МС-ДОС, за возможность запускать DOOM, Wolfenstein, VisiCalc, Lexicon и конечно – Norton Commander! Одним из принципиальных архитектурных решений было введение оверлеев – программ, которые могли подгружать свои части по мере исполнения программы. Что-то вроде змеи, у которой голова во время перемещения тела – сама себе подменяет части тела по мере необходимости. На таких домашних компьютерах, как ZX Spectrum (128 кБ) из-за того, что процессор мог адресовать физически только 64 кБ ОЗУ использовалась заметно более простая и грубая техника – физическая смена страниц памяти по 16 кБ. Как всегда, простота более ранних машин была заменена усложнением программных техник старших машин, благодаря возросшей вычислительной мощи и усложнением архитектурных абстракций.

Этот этап развития архитектурных решений (как и всегда) обусловлен увеличением вычислительных мощностей. Переход от 4 МБ/80386/20 МГц к 16 МБ/80486 DX 100/100 МГц дал возможность кардинально сократить разрыв в интерфейсе между машиной и человеком. Количественный рост дал переход в качество: на сцену выходит Windows 3.11 for Workgroups, следом за ним пара Windows 95/98 и последняя ОС из этого семейства – Windows ME (которая в отличии от Windows 98 для своей установки требовала уже не 16 МБ ОЗУ, а целых немыслимых 32, что, впрочем, не мешало ей работать после установки на 16 МБ). Эти первые потребительские ОС вводили ряд интересных архитектурных решений: тут и графический интерфейс пользователя, и мультимедийные возможности, и кооперативная многозадачность. Это был большой шаг вперёд, даже с учётом всех недостатков.

Например, кооперативная многозадачность страдала от захвата процессора какой-либо неисправной программой. Все олды помнят, как выскакивал синий экран, при попытке извлечь CD из привода, при работе WinAmp. Формально, поддерживался вход для нескольких пользователей, фактически же разделение пространств пользователей не поддерживалось по архитектурному решению с самого начала. Таким образом появились не только архитектурные слои “системный низ – пользовательский верх”, но и вариации “графический интерфейс пользователя – системная консоль”, которые хоть и были отнесены к разных архитектурным уровням, но здесь проглядывается не только вертикальное деление, но и горизонтальное. Хотя и в неполной мере, что по сути является протекающей абстракцией из-за того, что на уровне архитектурного решения с одной стороны это не было продумано, а с другой стороны до времён, когда это всё потребуется надо было дожить (в этом смысле, надо отдать должное руководству Microsoft, которое правильно применило практическое архитектурное правило про необходимое и достаточное). Такое быстрое грязное решение привело к тотальному засилью вирусов, и до текущего момента Windows продолжает от них страдать. Ради “Quake 3” и “Unreal Tournament 2” можно было и потерпеть.

ОС семейства Unix, в отличии от МС-ДОС и настольных Windows уже полностью изолирует с помощью аппаратуры процессы друг от друга, драйвера от пользовательских программ, а пользователей от пользователей. Архитектурное построение имеет более завершённый, системный вид. Положенная в основу Unix идея, что ”всё есть файл” является прекрасным примером продуктивной идеи (возможно, потому что создатели Unix, в отличии от создателей МС-ДОС и Windows всё-таки закончили университет). Абстракции потоков ввода-вывода были заложены ещё на ZX Spectrum, а в Unix эта абстракция настолько прочно укоренилась, что спустя 40 лет – она существует по всей планете: они реализованы в виде Unix-сокетов, TCP-сокетов, именованных сокетов, UDP-сокетов и много ещё такого, что большая часть читателей и не слышала никогда (и не услышит). Все эти реализации оседлали абстракцию потоков.

Важным архитектурным решением во всех ОС было представление информации на физических носителях в виде файлов и каталогов. Введение такой абстракции позволило унифицировать процесс хранения информации для всех программ, медиа и т.п. Доступ к данным стал предсказуем, стабилен, удалось изолировать механизм управления информации от потребителей информации, что дало возможность модифицировать драйвера не затрагивая всё остальное. Программы под управлением ОС, располагая заведомо большим объёмом ОЗУ (но не бесконечным) начали использовать архитектурную абстракцию “библиотеки”.

Под Windows они известны как DLL (динамически загружаемая библиотека), в Linux/*nix – как SO (разделяемый объект). У них несколько разные принципы работы, но суть сводится к общему знаменателю: если какой-либо программный артефакт требуется разным программам – не нужно этот артефакт каждый раз загружать во все программы. Достаточно программный код загрузить один раз, и использовать его везде. Такая библиотека, по сути – является “микросервисом в пространстве того же процесса”. Наиболее известная программа, которая практиковала это архитектурное решение – WinAmp. По сути, весь полезный функционал был расположен в различных DLL, к которым обращалась программа-оболочка для выполнения дополнительных действий. Но это были не просто DLL, это были плагины – DLL, к составу которых предъявляются специальные требования по интерфейсу со стороны хост-программы. Такой подход привёл к тому, что WinAmp начал приобретать пугающие черты ОС внутри ОС.

Но в таком архитектурном решении есть нюанс: высокая скорость работы DLL/SO внутри одного процесса как положительное качество привело к возможности сбоя всего хост-процесса и всех его плагинов из-за одного некачественного плагина. Что-то вроде вирусной инфекции, которая началась в одном органе и распространилась на все органы тела. Другая проблема (о которой ниже) не решается вообще никакими средствами в рамках одной (даже очень мощной) локальной машины. Усложнение архитектуры ПО, как по вертикали, так и по горизонтали явилось платой за удобства, функциональные возможности и надёжность. Сложное ПО перестали писать одиночки, коллектив программистов стал основной боевой единицей. Разработка без архитектурного и рабочего плана заведомо ведёт к катастрофе на любом проекте. За всё приходится платить.

Как только первые компьютеры начали влиять на жизнь человечества, так почти в тот же момент появилась известная фраза:

На тот период эта фраза как-то не очень хорошо осмысливалась, но как только в начале 2000х к нам ворвался интернет – всем сразу стало понятно: без интернета жизни нет! Произошёл тихий сдвиг парадигмы архитектуры от “всё локально” к “всё по сети”. Многие архитекторы старой закваски прошли мимо этой тихой революции: они всё ещё мыслят объектами в рамках локальной машины (даже если проектируют распределённую систему). Даже если все части программы работают на одной локальной машине – они с высокой вероятностью всё-равно работают через сеть! Типичный пример, браузер: тут и PWA c их Web-workers, и львиная доля баз данных (PostgresQL, MariaDB), и даже настольные приложения на базе Electron. Это существенное усложнение архитектурных подходов в решениях, которое поднимает планку технической квалификации всех участников процесса разработки ПО.

Если в начале 2000х требование “уметь работать с сетью” к программисту было скорее экзотикой, чем хоть как-то обоснованной необходимостью, то теперь, программист который не понимает основы сетевого обмена – скорее экзотика, чем норма. Сетевой обмен, как архитектурное решение является неизбежным злом, когда приложение требует своего масштабирования. Такая архитектура сейчас известна под именем “микросервисная”. Она плоха во всём:

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

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

Если в состав системы попадает неисправный компонент – он всего лишь один из многих, что при правильно построенной архитектуре не приводит к падению всего приложения, что может оказаться критичным в масштабных системах. И опять эволюция архитектурного решения идёт по пути усложнения. Что важно отметить:

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

Тут можно отметить постепенный отход от переусложнённой аппаратуры к более простым решениям: CISC на ARM/RISC. Сами процессоры семейства CISC обзавелись микрокодом, что несколько их роднит с PLM/PLC/ASIC. Более того, появились в последнее время процессоры, которые прямо на борту имеют внушительное ядро программируемых вентилей, что позволяет прямо в коде программы описать конфигурацию этого программируемого ядра и тем самым ускорить исполнение программы на этом специфическом расширении. Это ядро в отличии от подобных решений в духе ПЗУ теряют свою конфигурацию при отключении питания (т.е. динамически загружать конфигурацию связей вентилей – это для них нормальный режим работы).

Приведённые в качестве примера выше аппаратные архитектуры приводят к тому, что и архитектурные подходы в ПО тоже меняются:

Распределённые приложения используют преимущества архитектурного стиля REST и вполне в этом преуспели. На каждом человеке есть несколько вычислительных систем, которые в сотни раз мощнее чем мини-ЭВМ 80х. Умные часы, смартфоны, трекеры, видеорегистраторы, умные калькуляторы, планшеты, нетбуки, ноутбуки, всевозможные электронные девайсы и умные датчики. Изобилие таких устройств не имеет эффекта, если все они не связаны в общее информационное поле.

И конечно они связаны!) Всё это приводит к тому, что ИТ из изолированной техносферы перешагнуло в реальный мир создавая цифросферу. Вместо биосферы, вместо текстосферы и социосферы. Как и любое явление – только человек отвечает за то, как он будет использовать это явление. Цифросфера, которая медленно (не очень), но верно обволакивает нас – может оказаться как спасением, так и смертельной угрозой. В рамках статьи не будем вдаваться в этот важный вопрос. Сосредоточимся на архитектурных особенностях цифросферы.

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

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

Всё это принесёт с одной стороны масштабные экономические и социальные выгоды, а с другой создаст угрозу глобального сбоя с самыми печальными последствиями. Мы каждый день слышим про новый ИИ, который побил очередные рекорды “умности”. С одной стороны прекрасно, с другой стороны стоит задуматься, что может наделать такой ИИ, если он окажется не в тех руках. Главным образом описанные угрозы и определяют архитектурные решения систем уровня завтра:

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

Отказ в системах с конвергенцией может быть не просто опасен для жизни кого-то – это может быть катастрофа для большой группы людей. Чем больше масштабы системы, тем выше должна быть её надёжность с выходом на новые качества надёжности. Намеки на такие среды обработки информации мы уже можем видеть сейчас: .Net Framework, Java, компонентно-ориентированное программирование, компонентная среда с внешним контролем согласованности среды исполнения, адаптируемое аппаратное обеспечение (которое частично стирает разницу между аппаратурой и ПО).

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

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

Отрицание старых подходов (в виде единственного загруженного бинарника в ОЗУ) отрицается новым решением в виде модулей WASM. Снятие противоречия этого отрицания отрицания явилось в виде лёгких и безопасных контейнеров, которые не требуют специальных механизмов от ОС для своего поддержания. Как и не требует прав администратора системы, в отличии от такой технологии контейнеризации, как Docker.

Все эти усложнения архитектуры не дались ни дёшево, ни быстро. Явное отделение тела программ сначала от прямых команд процессора, затем и от прямых системных вызовов, а сейчас вообще от прямого контакта ОС в различных средах привело к повышению мобильности программ, надежной изоляции к программам неустановленного доверия и т. п. Технологии разделения ПО на переиспользуемые части прошли путь от монолитных бинарников, через маленькие утилиты, которые связывались стандартными каналами ввода/вывода, через сетевые соединения и сейчас начали внедряться интеллектуальные роутеры-конвертеры при поддержке REST-среды – всё это позволяет строить крайне устойчивые и крайне масштабируемые системы, которые способны работать без остановки годами.

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