Микросервисы и точки отказа.

Меня аж трисёт. Как бы прокинуть мостик между ихним «есть деньги, но некуда девать» и нашим «есть кодеры, которых нечем занять» или «есть потребность в автоматизации, которую некем закрывать».

а меня так вообще четыресёт! или все же пока что двасёт?

я, на самом деле, об этой проблеме время от времени задумываюсь — она не только в программировании

вообще рф это очень перспективный рынок с одним мааааааленьким нюансом — в один момент могут все отобрать, или обложить запрещающими налогами, или...

вот поэтому те, у кого бабло, в рф не спешат, а те кто поспешили — сидят с замороженными акциями и дивидендами (надеюсь ты знаешь о чем я)

впрочем, возможно, что эта проблема даже и решаемая — в программировании

Ну, кроме совсем уже суровых ребят, которые умеют «потрошить слонов», т.е. делать (и потом сопровождать) свои собственные распределенные СУБД.

вот это как раз самое интересное

че посоветуешь почитать?

«слон» это постгрес (и там надо читать wal), или что?

Это не фичи, это просто какая-то абстрактная херня, даже не свойства языка программирования — просто абстрактная херня, на этой основе даже идеи языка нельзя создать.

пусть будет так — тебе на этой абстрактной основе даже идеи языка нельзя создать (а меня оставим за скобками)

тогда расскажи, какие примерно идеи ты считаешь возможной основой для языка

Примерно по этой причине современные SoC, вроде Apple M1, напичканы разными ASIC-модулями — потому что кусок кристалла, занимающий 1/20 от общей площади, выполняет свою задачу в десятки раз быстрее, чем может весь остальной кристалл

что конкретно делают эти ASIC? вообще очевидно, что специализированная хрень быстрее хрени общего назначения

на фоне 100-кратной неэффективности по сравнению с GPGPU

где ты внезапно увидел неэффективность у CPU? у CPU те транзисторы, которые в GPGPU пошли на ядра, расходуются на кэш — но в результате есть задачи, которые на CPU можно считать быстро, а на GPGPU  — медленно

SELECT MAX(Id) FROM theTable;

а оно разве че-то там блокирует? просто лезет в индекс по Id, смотрит его конец, и выдает, не?

Врываюсь в тред на розовом единороге!

Пацаны! Так что там с микросервисами? Можно результат на тринадцатой странице?

Ты так солидно это описываешь, будто «трехзвенка» — это не «пшп с мускулем».

РНР с мускулем это скорее все же двухзвенка; а если кто использует РНР для изготовления json из запроса в БД, то он применяет РНР не по делу — и я даже кажется уже видел обвязки к БД на нормальном языке, выдающие json и все в этом духе

если уж мы на клиенте вовсю запускаем js для отрисовки результата из json, то почему мы должны поручать РНР формировать запросы? это может делать js, а права доступа можно и нужно раздавать на уровне базы (в т.ч. и для каждой записи)

суровых ребят, которые умеют

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

просто лезет в индекс по Id, смотрит его конец, и выдает, не?

Если оно внутри транзакции, то вся таблица (точнее добавление и удаление) заблокируется до конца транзакции.

вообще рф это очень перспективный рынок с одним мааааааленьким нюансом — в один момент могут все отобрать, или обложить запрещающими налогами, или...

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

Другое дело, что со при доходе менее 200 тыс долларов в год ты никому не интересен.

впрочем, возможно, что эта проблема даже и решаемая — в программировании

Всё преимущество программирования заключается в том, что когда прижимают в одном месте — можно уехать в другое. На этом преимущества заканчиваются.

РНР с мускулем это скорее все же двухзвенка; а если кто использует РНР для изготовления json из запроса в БД, то он применяет РНР не по делу

Нынче почти всё, что обновляется через AJAX – это «json из запроса в БД». Иногда HTML/XML из запроса в БД. Но отдаётся всё-равно в JS в браузере.

это может делать js, а права доступа можно и нужно раздавать на уровне базы (в т.ч. и для каждой записи)

Рискни. DOSить такие интерфейсы легче лёгкого. Потом прикрутишь ограничение на время работы запроса, на количество таблиц в соединении, на необходимые фильтры… И всё это будет проверять «PHP» (или аналог) на сервере.

Да. Ещё почти всегда надо делать INSERT/UPDATE после SELECT в одной транзакции. Если это не внутри PHP, а разрешено делать в JS, то «открыть транзакцию, сделать что-то типа SELECT MAX(Id) … FOR UPDATE и уснуть» гарантированно заблокирует таблицу.

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

ты даже видимо не знаешь как это делается

в json-морде стоит white-list на запросы (который девопсы и админы могут отключать для себя если надо, и у девелоперов вообще отстутствует)

Ещё почти всегда надо делать INSERT/UPDATE после SELECT в одной транзакции

сложные случаи (ну там параметры всякие, которые в sql не выражаются, типа сортировки по полю ?X и то, что требует именно функций, а не подзапросов) можно было бы класть во вьюху с функциями/тригеррами, и вайтлистить запросы ко вьюхе

гм... ты пример конкретный приведи на INSERT/UPDATE именно после SELECT? а то я все пытаюсь такой SELECT вставить подзапросом, а не перед INSERT/UPDATE

Ещё почти всегда надо делать INSERT/UPDATE после SELECT в одной транзакции

Зачем? o_O'

в json-морде

Ну вот тебе и третье звено.

гм… ты пример конкретный приведи на INSERT/UPDATE именно после SELECT?

Получить остаток (SELECT) на счёте отправителя, сравнить с запрашиваемой суммой. Сделать UPDATE для счёта отправителя, проверить наличие записи получателя (SELECT). Если есть, то UPDATE, если нет, то INSERT. Всё в одной транзакции.

Чтобы данные в INSERT соответствовали проверкам, проведённым в SELECT.

то, что требует именно функций, а не подзапросов

Тогда ещё и всю логику придётся в БД запихивать. А потом при переходе с Postgres на Oracle, например, всё переписывать. К тому же, в PL/SQL со структурами данных всё печально (указателей нет, структур нет, …).

че посоветуешь почитать?

Код. Я посоветую почитать код. Просветление гарантирую.

Ну а так, недавно попал в блог тараканов. Понравилось. Код их тоже можно почитать. Из уже классики — Jepsen. Посмотреть на Atomix.io (как, зачем).Так же можно посмотреть код ScyllaDB и их Seastar Framework. Приобщиться к SPDK и DPDK. Узнать, что TCP — не достаточно надежный (вообще говоря) протокол и для репликации не подходит (а все делают на нем, такие дела...). А так же, что в рамках линуксового IO-стека надежно (у нас ведь БД или что?) сбросить состояние памяти на диск невозможно. Ужаснуться и «микросервисы с состоянием» не писать никогда.

Ну а если серьезно, то я вижу движуху, которая направлена на то, чтобы распотрошить БД (которые сейчас черные ящики и вещи в себе) на фреймворки и библиотеки, которые можно будет потом переиспользовать как раз под эти цели. А пока что — не стоит даже браться.

Ты так солидно это описываешь, будто «трехзвенка» — это не «пшп с мускулем»

«пшп с мускулем» будет трехзвенкой только если есть ORM, желательно с кэшированием. Среднее звено в трехзвенке — это доменная модель, изолирующая бизнес-логику от БД. В какой-то момент людям понравилось виртуально переезжать с одной БД на другую, чтобы иметь возможность показать Ораклу жирный фак и на этом основании выцыганить лучшие условия по лицензированию. Сейчас ровно та же история с облаками. AWS — как женитьба: легко войти, трудно выйти (Забирать от них свой петабайт данных будешь самосвалом дисков и по конскому ценнику за гигабайт).

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

Это может быть и эффективный способ разработки, всё зависит от самой задачи и условий. Как я говорил выше, не стоит браться за сервисы с состоянием, так как это задача того же уровня сложности, что и распределенные БД.

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

Она не столько сложная, сколько просто невоспроизводимая. Есть такое понятие — bus factor. Если в компании только один человек знает всё, то, если его переедет автобус (или он задолбается и уедет пары спускать на теплые моря), то у компании будут большие проблемы.

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

Вот если кто напишет фреймворк, который типичные для управления состоянием задачи упакует в удобные для [пере-]использования модули, как со временем сделали с Web-ом и графикой, то — другое дело. Но пока что мы еще не на этом уровне. Пока что идет этап, когда новые монолитные СУБД появляются, как грибы после дождя. Тема просто весьма профитовая, и её не очень хотят отдавать публике на халяву.

Вот если кто напишет фреймворк, который типичные для управления состоянием задачи упакует в удобные для [пере-]использования модули, как со временем сделали с Web-ом и графикой, то — другое дело. Но пока что мы еще не на этом уровне. Пока что идет этап, когда новые монолитные СУБД появляются, как грибы после дождя. Тема просто весьма профитовая, и её не очень хотят отдавать публике на халяву

Что значит «не хотят отдавать»? Будто у них есть, что отдавать. У меня типа есть наработки по этому вопросу, но там до конкретной реализации как до киева раком. Новых монолитных БД не так-то много, в большинстве случаев они просто продают решение задачи, которую они на самом деле не решили — как правило, это что-то распределенное, строго согласованное, и отказоустойчивое — манагеры и инвесторы за всё это время так и не смогли осилить CAP теорему, потому всерьез верят, что где-то можно купить телепорты для сверхсветовой передачи информации.

Если коротко описать мою идею — это inconsistency-aware методы работы с данными, то есть, вместо традиционных алгоритмов,, работающих с данными, пишутся алгоритмы, работающие с рассогласованностью данных вместо данных. Причем, этот подход безальтернативен на самом деле, примерно как по Грниспену, только готового «лиспа» для этой ниши еще не существует, но неизбежно любая распределенная система приходит к глючной и медленной неформальной реализации части алгоритмов работы с рассогласованностью данных.

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

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

Среднее звено в трехзвенке — это доменная модель, изолирующая бизнес-логику от БД

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

В какой-то момент людям понравилось виртуально переезжать с одной БД на другую, чтобы иметь возможность показать Ораклу жирный фак и на этом основании выцыганить лучшие условия по лицензированию

Если ты про то, чтобы логику совать в хрнанимые процедуры — то да, логика оказывается в оракле. Проблема в том, что у мускуля вообще не было никаких хранимых процедур, по крайней мере на заре своего становления — я именно потому упомянул именно PHP+MySQL, а не PHP+Oracle.

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

Спасибо, не понял.

тогда расскажи, какие примерно идеи ты считаешь возможной основой для языка

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

что конкретно делают эти ASIC? вообще очевидно, что специализированная хрень быстрее хрени общего назначения

Очень много кому это не очевидно. Тем более неочевидна степень этой быстроты, которая на фоне «развития» x86 стала запредельной, поскольку x86 крайне неэффективно расходует транзисторы даже для уровня процессора общего назначения.

у CPU те транзисторы, которые в GPGPU пошли на ядра, расходуются на кэш — но в результате есть задачи, которые на CPU можно считать быстро, а на GPGPU — медленно

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

в результате есть задачи, которые на CPU можно считать быстро, а на GPGPU — медленно

А я заявляю, что таких задач нету. И я всё еще жду контрпримера. То, что всё современное программирование застряло в каменном веке и почти не имеет средств разработки для высокопроизводительных вычислений — это не какие-то неустранимые недостатки GPGPU или FPGA, а конкретных рыночек в конкретном году. Тот самый рыночек, который, дай ему волю, полностью остановит прогресс, установит монополию, и будет продавать 30 сортов говна разного цвета, периодически ротируя ассортимент цветов.

РНР с мускулем это скорее все же двухзвенка; а если кто использует РНР для изготовления json из запроса в БД, то он применяет РНР не по делу — и я даже кажется уже видел обвязки к БД на нормальном языке, выдающие json и все в этом духе

Это делают ВЕЗДЕ.

если уж мы на клиенте вовсю запускаем js для отрисовки результата из json, то почему мы должны поручать РНР формировать запросы? это может делать js, а права доступа можно и нужно раздавать на уровне базы (в т.ч. и для каждой записи)

Поздравляю, ты изобрел GraphQL.

неужели лепить свои менеджеры распределенных транзакций это охрененно сложная задача?

От того, что ты назовешь это «менеджером» или «завхозом распределенных транзакций» или «распределенными транзакциями по месту проживания» проблема не станет проще. Проблему распределенных транзакций когда-то нужно решить, и самая главная проблема в ней — это невозможность атомарного изменения состояния в распределенной системе. Вся модель машины Тьюринга основывается на атомарных переходах состояний — а какая часть кодеров во всей индустрии умеют реализовывать нетьюринговые вычислители? Один-два процента в лучшем случае.

Чтобы данные в INSERT соответствовали проверкам, проведённым в SELECT.

Получить остаток (SELECT) на счёте отправителя, сравнить с запрашиваемой суммой. Сделать UPDATE для счёта отправителя, проверить наличие записи получателя (SELECT). Если есть, то UPDATE, если нет, то INSERT. Всё в одной транзакции.

• Делаешь SELECT id, updated_at, … на счёте отправителя
• Делаешь SELECT на счёте получателя
• Делаешь все прочие SELECT’ы
• Делаешь нужные проверки
• Делаешь (в транзакции)
  • UPDATE … WHERE id = $1 AND updated_at = $2 на счёте отправителя
  • INSERT перевода от отправителя на счёт компании
• Делаешь
  • либо пополнение счёта получателя со счёта компании таким же способом как в предыдущем пункте
  • либо возврат средств отправителю таким же способом, если вдруг что

UPDATE … WHERE id = $1 AND updated_at = $2 на счёте отправителя
INSERT перевода от отправителя на счёт компании

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

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

Как бы я решал задачу — сначала делал вставку пустого получателя, в результате чего в таблице появлялось бы куча мусорных получателей, которые ничего не получали, но зато потом задача решается двумя UPDATE-ами в рамках традиционного SQL.

К слову, в некоторых СУБД есть операция INSERT OR UPDATE, и я в свое время больно ударился об нее, когда внезапно узнал, что она не гарантирует уникальности, если не блокировать таблицу целиком. При этом под капотом РСУБД прекрасно решают эту задачу без глобальных блокировок — но только для уникальных индексов.

А теперь получатель и отправитель являются сущностью одного типа

Они и тут являются сущностью одного типа.

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

Нет.

Если ты про отсутствие «промежуточной компании», то нет, так не делают. Все p2p переводы проходят через какой-либо сервис/банк. Посредник есть всегда, без посредника — это ты лично встретишься с человеком и передашь ему налик из рук в руки. Но для этого БД не нужна.

Если ты про отсутствие «промежуточной компании», то нет, так не делают. Все p2p переводы проходят через какой-либо сервис/банк. Посредник есть всегда, без посредника — это ты лично встретишься с человеком и передашь ему налик из рук в руки. Но для этого БД не нужна

Ты слишком привязываешься к конкретной задаче. Для конкретно нее возможно еще больше оптимизаций. Разговор был про универсальную проблему «обновить существующую или создать новую сущность». Универсального решения для нее нет, нужно приседать по-своему для каждого отдельного случая. А это значит, что нужна PHP-прокладка, инкапсулирующая эти упражнения.

Разговор был про универсальную проблему «обновить существующую или создать новую сущность».

UPSERT не подойдёт? В смысле INSERT … ON CONFLICT UPDATE …

Делаешь нужные проверки

Делаешь (в транзакции)

И к моменту начала транзакции какая-то проверка стала ложна из-за другого пользователя. Но ты об этом уже не узнаешь и спишешь в минус деньги со счёта, остатки со склада и т.д.

Или ты про то, что updated_at должно работать как виртуальная транзакция и обновляться при каждой операции?

в результате есть задачи, которые на CPU можно считать быстро, а на GPGPU — медленно

А я заявляю, что таких задач нету. И я всё еще жду контрпримера.

Любую непаралеллящуюся свёртку. Например, вычисление сиракузской последовательности.

И к моменту начала транзакции какая-то проверка стала ложна из-за другого пользователя. Но ты об этом уже не узнаешь и спишешь в минус деньги со счёта, остатки со склада и т.д

Кстати, да, по идее прочитанную запись нужно залочить до момента ее обновления.

Любую непаралеллящуюся свёртку. Например, вычисление сиракузской последовательности

Зачем? Зачем кому-то вычислять сиракузскую последовательность? Это не задача, это «решение», а я просил задачу.

Спасибо, не понял.

Давай я соберу всё в одном месте, чтобы нам не растекаться мыслью по древу (по веткам дискуссии).

1. «Микросервисы», как таковые, делают только большие overstuffed компании, которые нанимают людей потоком, имеют кучу внутренних проектов, и им нужно вот это всё как-то менеджить (через изоляцию функционала друг от друга — indirection). Микросервис только тогда микросервис, когда команда делает только его. Микросервисы должны быть каждый в своем репозитарии и релизится независимо от других.

2. Все остальные делают т.н. fine-grained сервисы (или вариации на тему SOA), где критерий нарезки будет уже именно техническим. Например, нарезка делается по границам масштабирования. Или — отказоустойчивости. Здесь одна команда может делать кучу таких сервисов. И они могут быть все упакованы в один модуль — как этой команде удобнее. Основной критерий fine-grained — все сервисы сидят в одном monorepo и релизятся одновременно.

3. Сервисы, что микро-, что fine- обычно не имеют состояния. Перенос сервисной парадигмы на работу с состоянием приводит к появлению антипаттерна. Базы данных исторически выделились в отдельную категорию не просто так. Подробности ниже.

4. Поэтому «микросервисная архитектура» всегда будет неполной — в ней будет вонючая монолитная СУБД, просто воплощение мерзости и регресса (в кавычки не беру, эти люди реально так думают). Успокаивает лишь то, что БД дается облаком в виде сервиса, т.е. проходит «обряд очищения».

5. В те славные времена PHP не был трехзвенкой потому, что был гвоздями прибит к MySQL. Трехзвенка — только тогда трехзвенка, когда одну БД можно легко заменить на другую. Некоторые приложения были на столько простыми, что прямое использование SQL этому не мешало. Но в общем случае перейти с блокировщика на версионщик (или обратно) было весьма проблематично. В целом, критерием наличия сервера приложений было использование ORM и кэширования на сервере приложений. Сервер с кэшированием — это уже сервер с состоянием, но это один из немногих паттернов работы с состоянием, который «условно нормально» вписывается в сервисную парадигму. Например, кэшировать иммутабельные данные очень даже просто.

6. Точно так же, возможность эффективного локального кэширования данных может стать критерием нарезки на сервисы в рамках fine-grained парадигмы.

7. «Распределенная БД» появляется тогда, когда возникает необходимость делать join меду данными в своем локальном кэше и в удаленных источниках данных. В этом случает на помощь могут прийти sql-федераторы, такие, как https://trino.io/ и PrestoDB. Они заточены на аналитику, но так же могут относительно шустро работать и в режиме выполнения точечных запросов (OLTP). ORM поверх такого sql-федератора даст уже нормальный такой экспириенс работы со сложно-структурированным распределенным состоятнием, как с локальным.

8. В плане консистентности нужно разделять два случая: (1) неконситсентность НЕ приводит к невозможности прочитать и обработать данные. И (2) — приводит к... В случае (1) нам вполне достаточно просто CRDT. А в случае (2) нужно что-то git-подобное, когда создаются полноценные версии одного объекта данных, и на этапе merge можно оставить только одну. Значительная часть аналитических задач требует как минимум repeatable read, а лучше — SI. (2) требует уже SSI, поэтому для чего-то серьезного я выберу Postgres, а не MySQL. Несмотря на то, что последний в ряде важных бенчмарков быстрее.

9. Ни RR, ни (S)SI уже не масштабируемы. Поэтому, scale-up — это наше всё (как Пушкин — у филологов), если мы работаем со сложным состоянием. Люди, которые втирают нам про scale-out, в следующем предложении будут говорить, что «джоины — не нужны, как и транзакции».

10. Поэтому, микросервисы и SOA — это антипаттерн, когда мы сталкиваемся с необходимостью работы с состоянием. Но, «не всё так однозначно». В облаке у нас в распоряжении только машины с эфемерными дисками, т.е. состояние приходится хранить в «где-то еще» (S3, DynamoDB, Aurora, NAS) и тянуть на воркеры для интенсивной обработки, где данные придется кэшировать. Это — т.н. cloud-native архитектуры.

А я заявляю, что таких задач нету.

Если говорить о сфероконических GPGPU, то — да. Если же говорить о конкретных моделях, то существующие GPGPU/FPGA/ASIC хорошо работают тогда, когда есть большое количество вычислений над небольшим количеством данных, и (что важно), что в процессе не создается большое количество промежуточных данных. Пример — вычисление декартова произведения (сложность — O(N^2))или перемножение матриц (сложность — O(N^3)). В общем случае, есть класс т.н. систолических архиткектур, которые, грубо говоря, сводятся к множеству глубоко вложенных циклов над массивом. Вот они очень хорошо акселерируются на указанных классах устройств. А, например, комбинаторный обход динасически порождаемого дерева решений — нет. Поэтому, например, SAT-солверы на GPGPU сливают своим аналогам на CPU (на FPGA ситуация сильно лучше, но «есть нюансы»).

В общем случае стоит смотреть не на то, что это (CPU, GPU или FPGA), а какая у железки архитектура памяти. Тупо передать слово из RAM в CPU требует в 600 раз больше энергии, чем перемножить два слова. Поэтому, скоро будет рулить in-memory computing.

В этом свете, CPU — это машина состояний над вполне определенной архитектурой памяти: 3 уровня кэшей, сложный prefetching, скрывающий задержки. Всё ориентировано на ускорение произвольного доступа. FPGA ориентированы на потоковую обработку. GPGPU — на «матричную» (prefetcher у них довольно таки простой).

Ты опоздал лет на десять. Мода сейчас на микромонолиты.

Еще и микрофронтэнд

девопс - это религия смузихлебов-самокатчиков… иногда эти наркоманы придумывают откровенную хрень

Что плохого в микрофронтэндах?

ты их и так можешь сколько угодно сделать без какой-то дичи, придуманной обосранным петухом-фронтендером с самотыком в жопе:

/app1 /app2 /app3

Микрофронтэнды это когда на одной странице несколько блоков, разрабатываемых разными командами. Что-то вроде iframe, но без iframe. Ты наверное не разобрался.

И что мешает их разрабатывать отдельно? git submodules не?

Суть в том, что они могут быть на разных технологиях. Один блок на typescript + react. Второй на vue, третий на angular. Каждый блок разрабатывается отдельной командой, никак не зависящей от других.

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

может быть на разных языках программирования

Один блок на typescript + react.

typescript компилируется в js react компилируется в js

Второй на vue, третий на angular.

vue компилируется в js angular компилируется в js

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

…Ага и от тех кто бек пишет, и от лошка-девжопса… и от работодателя, который им деньги платит тоже не зависят…

<div id="vue-govno"></div>
<div id="react-govno"></div>

import { createApp } from 'vue'

import App from './App.vue'

const app = createApp(App)


app.mount('#vue-govno')

import ReactDOM from 'react-dom'

// ...

ReactDOM.render(<App />, document.getElementById('react-govno'))

Ооооого! Это уже микропен…сервисы?

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

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