Платформы и технологические стеки

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

Платформа — это всегда модульное рассмотрение, обсуждение платформы всегда связано с её сервисами, т.е. внешним поведением, предоставляемом на интерфейсе к другим модулям. Для программных модулей этот интерфейс обычно называется API (application program interface), программный интерфейс приложения. Если речь идёт не о программной системе, то можно говорить просто об интерфейсе приложения, или прикладном интерфейсе. Прикладной — это определяемый использующей системой платформы (согласованного в части выполнения каких-то сервисов набора модулей) или модуля. Приложение — это использующая система для платформы модуля, части приложения находятся в операционном окружении модуля.

Основной вопрос при обсуждении платформ — это так называемая видимость интерфейсов . Интерфейсы какого-то низкого системного уровня не должны быть видны снаружи модуля, то есть невозможно соединение модулей иначе, чем через предусмотренные в нём интерфейсы. Грубо говоря, если у вас коробочка с каким-то разъёмом, то нельзя воткнуть внешнее устройство не в этот разъём, а куда-нибудь внутрь коробочки, мимо этого разъёма. Для обсуждения видимости интерфейсов используется диаграмма модульных уровней, диаграмма холархии системных уровней. Каждый уровень отделён от другого уровня каким-то интерфейсом. Реализации нижестоящих уровней тем самым могут быть сменены так, что использующая система этого не заметит. А итоговую холархию называют платформенным стеком или технологическим стеком (stack, стопка — диаграммы похожи на стопку подносов в столовой или стопку листов бумаги в пачке). Вот пример различных технологических стеков для организации связи :

На диаграмме видно, что в разных стандартах связи определяются пять уровней (по отношению часть-целое) модулей, которые можно разделить реализующих передачу физического сигнала (physical), передачу данных (Data Link), использующую передачу физического сигнала, и так далее. Неважно, что делают эти уровни платформенного стека, но главное тут то, что никакой модуль вышестоящего уровня «не видит» модули более низкого уровня (не имеет к ним доступа, не может туда «воткнуться»), чем находящийся непосредственно под ним, и интерфейсы реализующих сервисы этих платформенных уровней стандартизованы — как стандартизован и сам набор этих уровней.

Есть два способа чтения таких модульных диаграмм: на некоторых диаграммах «платформа» именуется стандартом, а реализация этого стандарта находится как бы «между уровнями» (ровно этот способ показан на диаграмме, он самый распространённый), и показ собственно модулей (именование платформ), тогда API этих модулей либо считаются проименованные самим модулем (скажем, модуль TensorFlow имеет API TensorFlow, и поэтому его не нужно отдельно прописывать), или если платформенный уровень реализует стандарт, то он прописывается где-то в границах реализующего его модуля отдельной строчкой поближе к границе использующего модуля, или даже выносится и явно прописывается «между платформами», как это сделано в картинке стека безопасности приложений  — стандарты указаны сбоку картинки платформенного стека, а каждая плашка обозначает слой модулей:

Верхняя скобка для стандарта интерфейса в использующую систему от custom code ведёт как бы в никуда при таком способе показа, поэтому чаще используется способ предыдущей картинки, где платформа обозначается не по назначениям/именам её модулей/слоёв, а назначение указывается сбоку.

Часто оба этих способа перемешивают, получая гибридную диаграмму. Вот, например, модульная диаграмма компилятора искусственных нейронных сетей, где верхние строки — наименования программных модулей-пакетов реализации нейронных сетей (например, пакет MXNet), а нижние — интерфейсных стандартов для какой-то аппаратуры (например, стандарт OpenCL) :

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

Деньги обычно приходят от удачного и массового использования верхнего, прикладного уровня. Но вот «перетряхивание» всего технологического/платформенного стека, перестройка всех рынков идут тогда, когда меняется принцип реализации самого нижнего уровня модулей, меняется платформа нижнего уровня. Например, когда в компьютерах поменялись механические или пневматические элементы на лампы, компьютеры стали масштабируемы и они начали напоминать уже функционально современные компьютеры, а не калькуляторы прошлых лет. Замена ламп на дискретную полупроводниковую технику позволила наладить массовый выпуск компьютеров и это разительно изменило компьютерную технику. Замена дискретной электроники на большие полупроводниковые интегральные схемы опять перевернуло весь компьютерный рынок со всеми надстройками программного обеспечения. Замена CPU на GPU перевернула рынок искусственного интеллекта. Замена людей-исполнителей на роботов-исполнителей переворачивает все промышленные предприятия. Эта особенность делает технологические/платформенные/модульные стеки удобными для обсуждения стратегии компании — обсуждается, что из модулей будет компания делать сама, а что закупать вовне, какие стандарты интерфейсов для этих модулей она будет устанавливать сама, а какие брать уже готовыми .