А врутреняя эмуляция проца интел написана на основе низкоуровнейвой опенсурс ос профессора из норвегии вроде, да еще и копирайты выпелины) ну или что то вроде.

Я думаю про метрики

Продуктовые ? Что-то связанное с ростом community
Стоимость доработок / поиск подрядчиков
HR метрики: уход / приход кандидатов / стоимость поиска кандидатов

Может кому-то попадался кейс с продуктом, который не был open source, а после стадии open, как-то качественно улучшил свои метрики?

если community есть, то внешний аудит кода и багфиксы

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

конечно не сидеть, а развивать. Если просто сидеть - community не получится

Когда-то давно видел исследования касательно качества (или кол-ва ошибок) в коде. Это тоже некоторая метрика качества

Выращивание community вокруг своего отпочкованного в open source куска enterprise - задача уровня "космические корабли бороздят". Т.е. больше репутационная, нежели бизнесовая. Тут и перед клиентами можно козырять, мол наше решение на open source и никакого вам вендорлока, и студентов завлекать можно "за еду", и в рейтингах ИТ-компаний быть на шаг впереди конкурентов.
А на практике надо нанимать и удерживать спецов c hr, которые бы выращивали это community, готовили спеки, принимали коммиты, были евангелистами и топили за идею. Достаточно хлопотно и дорого для средней компании.

И “публичный” код в разработке заметно дороже чем “для внутреннего использования”.

публичный код это продукт, а внутренний код - частное решение

cuba studio

Возможно, можно еще вспомнить про .NET
Но это тоже скорее про community

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

Поясню на примере. У нас есть микросервис отвечающий за клиентов. Их заведение, авторизацию и т.д. В его базе данных хранятся данные клиента: идентификатор (уникальный), ФИО, Пол, Дата рождения и т.д. В смежных таблицах или прямо в таблице клиента хранится номер телефона, Email и т.д.

Также есть микросервис диалогов между пользователями. Одним из требований к нему является выдача данных диалога в котором указаны ФИО, пол и телефон пользователя, который оставил конкретное сообщение. Этот микросервис обладает базой данных сообщений.

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

В формате сервисной архитектуры все понятно. У нас N-е кол-во сервисов и одна база данных и у нас есть возможность через JOIN запрашивать данные клиента из таблицы клиентов (или N-го кол-ва связанных таблиц).

А как правильно поступать в ситуации с микросервисами? Ведь вызов получения данных клиента по идентификатору из друго микросервиса достаточно дорог.

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

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

Возможно  это будет не совсем рационально, но эту проблему можно решить несколькими способами:
* Объявить сервис с пользователями Golden Source по домену пользователей
* Спроектировать публичное представление пользователя
* При изменении пользователя - испускать соответствующее событие через какой-то канал
* В сервисе с сообщениями иметь простой справочник, который не управляется сервисом напрямую, а только через события
* Непосредственно в самом сообщении только ссылку на пользователя из этого справочника

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

Недостатки:
* Какое-никакое дублирование данных
* Некоторое время будут устаревшие данные
* Если надежный канал построить сложно/невозможно по каким-либо причинам, то нужно будет разрабатывать дополнительные сервисы синхронизации.

Достоинства:
* В конечном итоге ФИО пользователей и другие атрибуты станут консистентными

Возможная альтернатива без дублирования данных - сократить кол-во вызовов, использовать пакетные запросы (сразу много пользователей за один вызов)

Ну, я обычно обогащаю данные на bff, там забрать из сервиса с ФИО актуальные данные не сложно, в некоторых сценариях добавив кэш

если задача показать пользователю его диалоги с другими пользователями, то у нормального человека вряд ли будут тысячи и тысячи контактов в истории. Можно показать первый экран истории (скажем 20-30 записей) а их соединить на BFF с профилями пользователя не проблема, особенно если делать пакетный вызов. Если это история сообщений, а не контактов, то обычно переписка ведется пакетами сообщений, то есть много сообщений на один контакт. Тогда на один экран истории вообще будет 2-3 контакта. Дальше делать ленивое пролистывание истории вглубь.
Нам же поисковые системы не раз рассказывали что большинство пользователей никогда не переходит на вторую страницу результатов поиска.

Да, но зависит от задачи. Например, в этом чатике 2.5к контактов )

Но я за простоту. Сделал бы сначала пакетными запросами